VPN ಸೈಟ್ಗಳಲ್ಲಿ ರೌಟಿಂಗ್ ಲೂಪ್ ಮತ್ತು ರೂಟ್ ಫ್ಲಾಪಿಂಗ್ ನಡುವೆ ವ್ಯತ್ಯಾಸ ತಿಳಿಯುವುದು ಹೇಗೆ
ರೌಟಿಂಗ್ ಲೂಪ್ ಮತ್ತು ಫ್ಲಾಪಿಂಗ್ ರೂಟ್ ಒಂದೇ ರೀತಿಯ ವಿರಾಮದ ನಷ್ಟವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಗೇಟ್ವೇಗಳ ಮೇಲಿನ ಮೂರು ಪರಿಶೀಲನೆಗಳು ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತವೆ.
ಎರಡು ಸೈಟ್ಗಳು, ಒಂದು ಸುರಂಗ ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯ ಪ್ರತಿಕ್ರಿಯಿಸಿ ನಂತರ ಸುಮ್ಮನಾಗುವ ದೂರದ ಪ್ರಿಫಿಕ್ಸ್. ಮೊದಲ ಪ್ರತಿಕ್ರಿಯೆ ಅದನ್ನು ರೌಟಿಂಗ್ ಲೂಪ್ ಎಂದು ಕರೆಯುವುದು, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಅದು ನಿಖರವಾಗಿ ಹಾಗೆಯೇ ಇರುತ್ತದೆ. ಆದರೆ ಲೂಪ್ ಮತ್ತು ಫ್ಲಾಪಿಂಗ್ ರೂಟ್ ಒಂದೇ ದೂರನ್ನು ಹುಟ್ಟಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಿಗೆ ವಿರುದ್ಧ ರೀತಿಯ ದುರಸ್ತಿ ಬೇಕು: ಒಂದು ಎಂದಿಗೂ ಮುಗಿಯದ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿರ್ಣಯ, ಇನ್ನೊಂದು ಟೇಬಲ್ ಬಿಟ್ಟು ಹೋಗುವ ಪ್ರಿಫಿಕ್ಸ್. ಮೂರು ಅವಲೋಕನಗಳು ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತವೆ, ಮತ್ತು ಫಿಲ್ಟರ್ ಮುಟ್ಟುವ ಅಥವಾ ಸುರಂಗವನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಮೂರನ್ನೂ ಗೇಟ್ವೇ ಆಜ್ಞಾ ಸಾಲಿನಿಂದ ಸಂಗ್ರಹಿಸಬಹುದು.
ಲೂಪ್ ಹಾಪ್ ಮೇಲೆ ಹಾಪ್ ನಿರ್ಧಾರವಾಗುತ್ತದೆ. ಸೈಟ್ A ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ B ಯನ್ನು ಮುಂದಿನ ಹಾಪ್ ಎಂದು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, B ಅದೇ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ A ಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಎರಡು ಸುತ್ತಿನ ನಂತರ TTL ನಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ. ಫ್ಲಾಪಿಂಗ್ ಅನ್ನು ಬದಲಿಗೆ ರೌಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ ನಿರ್ಧರಿಸುತ್ತದೆ: ಪ್ರಿಫಿಕ್ಸ್ ಹಿಂಪಡೆಯಲಾಗುತ್ತದೆ, ಮತ್ತೆ ಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ ಅಥವಾ ಪರ್ಯಾಯ ಮುಂದಿನ ಹಾಪ್ನಿಂದ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ, ಹೀಗಾಗಿ ಕೆಲವು ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ರೂಟ್ ಇಲ್ಲದೇ ಇರುತ್ತದೆ, ಇನ್ನು ಕೆಲವು ಸಂಪೂರ್ಣ ಒಳ್ಳೆಯದನ್ನು ಅನುಸರಿಸುತ್ತವೆ.
ಪ್ರಶ್ನೆಯನ್ನು ಪರಿಹರಿಸುವ ಮೂರು ಪರಿಶೀಲನೆಗಳು
ಮೊದಲ ನಿರ್ಣಯಕ್ಕೆ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವ ಅಗತ್ಯವಿಲ್ಲ. ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಪ್ರಿಫಿಕ್ಸ್ನ ಸ್ಥಿತಿ, ಪ್ರತಿ ಬದಿಯು ಆಯ್ಕೆ ಮಾಡುವ ಮುಂದಿನ ಹಾಪ್, ಮತ್ತು ಪುನರಾವರ್ತನೆಯಾಗುವ ಅಥವಾ ಆಗದ ಹಾಪ್ ಎಣಿಕೆ ಬೇಕು. ಸಂಚಾರ ವಿಫಲವಾಗುವಾಗ ಪ್ರಿಫಿಕ್ಸ್ ಅದೇ ಮುಂದಿನ ಹಾಪ್ನೊಂದಿಗೆ ಸ್ಥಾಪಿತವಾಗಿದ್ದರೆ, ಲೂಪ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗದಲ್ಲಿದೆ. ಪ್ರಿಫಿಕ್ಸ್ ಮಾಯವಾಗಿ ಮತ್ತೆ ಬಂದರೆ, ದೋಷ ಫಾರ್ವರ್ಡಿಂಗ್ನ ಮೇಲಿದೆ ಮತ್ತು ದುರಸ್ತಿ ರೌಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ಗೆ ಸೇರಿದೆ, ಸ್ಥಿರ ರೂಟ್ಗೆ ಅಲ್ಲ.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
ಆರಂಭಿಸುವ ಮೊದಲು ಒಂದು ಎಚ್ಚರಿಕೆ. ಲೂಪ್ ಆಗುತ್ತಿರುವ ಸುರಂಗದ ಮೂಲಕ ಇದನ್ನು ಓದುತ್ತಿದ್ದರೆ, ರೂಟ್ ಬದಲಿಸಿದ ಕ್ಷಣ ನಿಮ್ಮ ಸೆಷನ್ ಸಾಯುತ್ತದೆ. ನೀವು ದುರಸ್ತಿ ಮಾಡಲಿರುವ ಪ್ರಿಫಿಕ್ಸ್ ಮೇಲೆ ಅವಲಂಬಿತವಲ್ಲದ ಕನ್ಸೋಲ್ ಅಥವಾ ನಿರ್ವಹಣಾ ಮಾರ್ಗವನ್ನು ತೆರೆಯಿರಿ.
ಮೊದಲ ಪರಿಶೀಲನೆ: ಪ್ರಿಫಿಕ್ಸ್ ಸ್ಥಿರವಾಗಿದೆಯೇ ಅಥವಾ ಅಲುಗಾಡುತ್ತಿದೆಯೇ
ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಏನು ಭರವಸೆ ನೀಡುತ್ತದೆ ಎಂದಲ್ಲ, ಕೆರ್ನೆಲ್ ಏನನ್ನು ಸ್ಥಾಪಿಸಿತು ಎಂದು ಕೇಳಿ. ಲಿನಕ್ಸ್ ಗೇಟ್ವೇನಲ್ಲಿ ip route get 10.20.30.40 ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗ ನಡೆಸುವ ಅದೇ ಹುಡುಕಾಟವನ್ನು ನಡೆಸುತ್ತದೆ, ನೀತಿ ಕೋಷ್ಟಕಗಳೂ ಸೇರಿದಂತೆ, ಆದರೆ ip route show 10.20.30.0/24 ನಮೂದನ್ನು ಸ್ವತಃ ತೋರಿಸುತ್ತದೆ. ip monitor route ಪ್ರತಿ ಬದಲಾವಣೆಯನ್ನು ಅದು ಸಂಭವಿಸಿದ ಕ್ಷಣ ಪ್ರಸಾರ ಮಾಡುತ್ತದೆ, ಇದು ಪ್ರಿಫಿಕ್ಸ್ ಬರುವುದನ್ನು ಮತ್ತು ಹೋಗುವುದನ್ನು ನೋಡುವ ಅತಿ ವೇಗದ ದಾರಿ.
FRR ಅಥವಾ BIRD ಓಡಿಸುವ ರೌಟರ್ನಲ್ಲಿ ಆಸಕ್ತಿಕರವಾದದ್ದು ಫಾರ್ವರ್ಡಿಂಗ್ ಟೇಬಲ್ ಅಲ್ಲ. show ip bgp 10.20.30.0/24 ಆಯ್ದ ಮಾರ್ಗ ಮತ್ತು ಅದರ ಅಪ್ಟೈಮ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ; ಪ್ರತಿ ಕೆಲವು ನಿಮಿಷಗಳಿಗೆ ಮರುಹೊಂದಿಸುವ ಅಪ್ಟೈಮ್ ನೀವು ಹೆಸರಿಸಬಹುದಾದ ಫ್ಲಾಪಿಂಗ್, ಲೂಪ್ ಅಲ್ಲ. show ip bgp summary ನೆರೆಹೊರೆಯ ಸ್ಥಿತಿ ಮತ್ತು ಪ್ರಿಫಿಕ್ಸ್ ಎಣಿಕೆಗಳನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪದೇ ಪದೇ ಬೀಳುವ ಪೀರ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗದಿಂದ ತಪ್ಪನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಉತ್ತರವನ್ನು ಬರೆಯಿರಿ. ಪಿಂಗ್ಗಳು ವಿಫಲವಾಗುತ್ತಿದ್ದಾಗ ಹತ್ತು ನಿಮಿಷ ಸ್ಥಿರವಾಗಿರುವುದು, ಮತ್ತು ಹತ್ತು ನಿಮಿಷಗಳಲ್ಲಿ ನಾಲ್ಕು ಬಾರಿ ಮಾಯವಾಗುವುದು ಬೇರೆ ಬೇರೆ ಮುಂದಿನ ಹೆಜ್ಜೆಗಳಿಗೆ ಕರೆದೊಯ್ಯುತ್ತವೆ. ಎರಡನೆಯದು ಸ್ಥಿರ ರೂಟ್ನ ಎಲ್ಲಾ ಸಿದ್ಧಾಂತಗಳನ್ನು ಅಪ್ರಸ್ತುತಗೊಳಿಸುತ್ತದೆ.
ಎರಡನೇ ಪರಿಶೀಲನೆ: ಮುಂದಿನ ಹಾಪ್ ಆಗಮನದ ಸುರಂಗಕ್ಕೆ ಹಿಂತಿರುಗಿ ತೋರಿಸುತ್ತದೆಯೇ
ಲೂಪ್ಗೆ ಎರಡು ಗೇಟ್ವೇಗಳ ಒಪ್ಪಿಗೆ ಬೇಕು. ಪ್ಯಾಕೆಟ್ ಸ್ವೀಕರಿಸುವ ಸೈಟ್ನಲ್ಲಿ ಪ್ಯಾಕೆಟ್ ಹೊರಹೋಗಲು ಬಳಸುವ ಮಾರ್ಗವನ್ನು ನೋಡಿ: ನಿಜವಾದ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ip route get 10.20.30.40 from 10.10.5.20, ಏಕೆಂದರೆ ನೀತಿ ನಿಯಮವು ಮುಖ್ಯ ಕೋಷ್ಟಕಕ್ಕಿಂತ ಬೇರೆಯಾಗಿ ಉತ್ತರಿಸಬಹುದು. ನಂತರ ಅದನ್ನು ಕಳುಹಿಸಿದ ಸೈಟ್ನಲ್ಲಿ ಹುಡುಕಾಟವನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಪ್ರತಿ ಬದಿಯೂ ಅದೇ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಇನ್ನೊಂದನ್ನು ಮುಂದಿನ ಹಾಪ್ ಎಂದು ಆಯ್ಕೆ ಮಾಡಿದರೆ, ಲೂಪ್ ಸಾಬೀತಾಗಿದೆ ಮತ್ತು ಯಾವುದೇ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಏನನ್ನೂ ಸೇರಿಸುವುದಿಲ್ಲ.
ಕಾರಣ ಬಹುತೇಕ ಯಾವಾಗಲೂ ಸುರಂಗವನ್ನು ದಾಟಬಾರದಿದ್ದ ಘೋಷಣೆ ಆಗಿರುತ್ತದೆ. ಸುರಂಗಕ್ಕೆ ಮರುಹಂಚಿಕೆ ಮಾಡಿದ ಡೀಫಾಲ್ಟ್ ರೂಟ್, ದೂರದ ಸೈಟ್ನ ಸ್ವಂತ ಸಬ್ನೆಟ್ ಅನ್ನು ಆವರಿಸುವ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ, ಅಥವಾ ಮುನ್ನೆಚ್ಚರಿಕೆಗಾಗಿ ಪೀರ್ನತ್ತ ತೋರಿಸುವ ಸ್ಥಿರ ರೂಟ್ — ಎಲ್ಲವೂ ಅದೇ ಪರಸ್ಪರ ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ. ಸುರಂಗ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಾಪಿತವಾಗಿದ್ದರೂ ಸಂಚಾರವನ್ನು ವೃತ್ತದಲ್ಲಿ ಸಾಗಿಸಬಹುದು; strongSwan ನ ಫಾರ್ವರ್ಡಿಂಗ್ ಟಿಪ್ಪಣಿಗಳು ಆ ಅಗತ್ಯದ ರೌಟಿಂಗ್ ಬದಿಯನ್ನು ವಿವರಿಸುತ್ತವೆ.
WireGuard ತನ್ನದೇ ಟಿಪ್ಪಣಿಗೆ ಅರ್ಹ, ಏಕೆಂದರೆ ದೂಷಿಸಲು ಯಾವುದೇ ಘೋಷಣೆ ಇಲ್ಲ. wg show ಪ್ರತಿ ಪೀರ್ನ AllowedIPs ಅನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಕೆರ್ನೆಲ್ ಪೀರ್ನಿಗೆ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಆ ವ್ಯಾಪ್ತಿಯೊಳಗೆ ಬಿದ್ದರೆ ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತದೆ. ಅಲ್ಲಿನ ಲೂಪ್ ಎಂದರೆ ಒಂದಕ್ಕೊಂದು ಮೇಲೊತ್ತುವ AllowedIPs ವ್ಯಾಪ್ತಿ ಅಥವಾ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹಿಂದಕ್ಕೆ ತೋರಿಸುವ ಸ್ಥಿರ ರೂಟ್, ಆದ್ದರಿಂದ ದುರಸ್ತಿ ಆ ಎರಡು ಸ್ಥಳಗಳಲ್ಲಿ ಮಾತ್ರ ಇರುತ್ತದೆ.
ಮೂರನೇ ಪರಿಶೀಲನೆ: ಹಾಪ್ ಎಣಿಕೆಯನ್ನು ಓದಿ, ನಕ್ಷತ್ರಗಳನ್ನಲ್ಲ
traceroute -n -I 10.20.30.40 ಮತ್ತು mtr -n -r -c 20 10.20.30.40 ಎರಡೂ ಮಾರ್ಗವನ್ನು ತೋರಿಸುತ್ತವೆ, ಮತ್ತು ICMP ಕ್ರಮವು UDP ಪ್ರೋಬ್ಗಳನ್ನು ತಿನ್ನುವ ಫಿಲ್ಟರಿಂಗ್ನಿಂದ ಹೆಚ್ಚಾಗಿ ಪಾರಾಗುತ್ತದೆ. ಲೂಪ್ ಒಂದೇ ಎರಡು ಗೇಟ್ವೇ ವಿಳಾಸಗಳ ಸಣ್ಣ ಪುನರಾವರ್ತಿತ ಅನುಕ್ರಮದಂತೆ ಕಾಣುತ್ತದೆ, ಪ್ರತಿ ಬಾರಿ TTL ಏರುತ್ತದೆ. ಕುಸಿತವು ಉತ್ತರಿಸಿದ ಕೊನೆಯ ಗೇಟ್ವೇ ನಂತರದ ನಕ್ಷತ್ರಗಳಂತೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಒಂದೇ ಮೌನ ಹಾಪ್ ಯಾವುದಕ್ಕೂ ಸಾಕ್ಷಿಯಲ್ಲ.
ಮಾರ್ಗ ಅಸ್ಪಷ್ಟವಾದಾಗ, ತಂತಿಯ ಮೇಲಿನ TTL ಓದಿ. ಎರಡೂ ಗೇಟ್ವೇಗಳಲ್ಲಿ tcpdump -ni any -vv icmp ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ನ TTL ಮತ್ತು ಪ್ರತಿ ಸಮಯ ಮೀರಿದ ಉತ್ತರದ ಮೂಲ ವಿಳಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗದಲ್ಲಿ ಇರಬಹುದಾದ ಹಾಪ್ ಸಂಖ್ಯೆಗಿಂತ ಕಡಿಮೆ TTL ನೊಂದಿಗೆ ದೂರದ ಸೈಟ್ ತಲುಪಿದರೆ, traceroute ತೋರಿಸದ ಹಾಪ್ಗಳನ್ನು ಯಾವುದೋ ಸೇರಿಸುತ್ತಿದೆ, ಮತ್ತು ಇದು ಒಂದು ಸೈಟ್ನ ಫೈರ್ವಾಲ್ ಇನ್ನೊಂದರ ಪರವಾಗಿ ಪ್ರೋಬ್ಗಳಿಗೆ ಉತ್ತರಿಸಿದಾಗ ಸಂಭವಿಸುತ್ತದೆ.
ಪ್ರಿಫಿಕ್ಸ್ನ ಮಾಲೀಕರನ್ನು ದುರಸ್ತಿ ಮಾಡಿ, ನಂತರ ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ
ಯಾವ ಸೈಟ್ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ ಮತ್ತು ಯಾವ ಟ್ರಾನ್ಸಿಟ್ ಮಾರ್ಗಗಳು ಅನುಮತಿಸಲ್ಪಟ್ಟಿವೆ ಎಂದು ನಿರ್ಧರಿಸಿ, ನಂತರ ಆ ಮಾಲೀಕರ ಬಳಿ ಘೋಷಣೆ ಅಥವಾ ಸ್ಥಿರ ರೂಟ್ ಬದಲಿಸಿ. ಸ್ವೀಕರಿಸುವ ಸೈಟ್ ಸರಿಪಡಿಸುವುದು ಆಮಿಷವಾದರೂ ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪು: ಅದು ಒಂದು ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಲೂಪ್ ಮರೆಮಾಡಿ ಮುಂದಿನದಕ್ಕೆ ಕೆಟ್ಟ ಘೋಷಣೆಯನ್ನು ಜಾಗದಲ್ಲೇ ಬಿಡುತ್ತದೆ. ರೂಟ್ ಟ್ಯಾಗ್ಗಳು, ವಿತರಣಾ ಪಟ್ಟಿಗಳು ಮತ್ತು split-horizon ನಿಯಮಗಳು ಇದನ್ನು ಮೂಲದಲ್ಲೇ ನಿಲ್ಲಿಸಲು ಇವೆ, ಮತ್ತು ಅವು ಒಂದೇ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಹೊಂದುವ ಫಿಲ್ಟರ್ಗಿಂತ ಅಗ್ಗ.
ಬದಲಾವಣೆಯ ನಂತರ ಹೋಗುವ ಮತ್ತು ಹಿಂತಿರುಗುವ ದಿಕ್ಕನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಲಕ್ಷಣದಲ್ಲಿ ಯಾವುದೇ ಗೋಚರ ಸುಧಾರಣೆ ಇಲ್ಲದೆ ಲೂಪ್ ಕಪ್ಪು ಕುಳಿಯಿಂದ ಬದಲಾಗಬಹುದು. ಎರಡೂ ತುದಿಗಳಿಂದ ip route get ಚಲಾಯಿಸಿ, ಗೇಟ್ವೇ ಅಲ್ಲದ ಹೋಸ್ಟ್ನಿಂದ ಸಂಚಾರ ಕಳುಹಿಸಿ, ಮತ್ತು ಫ್ಲಾಪಿಂಗ್ ಅನ್ನು ದುರಸ್ತಿ ಎಂದು ತಪ್ಪಾಗಿ ಗ್ರಹಿಸದಂತೆ ip monitor route ಕನಿಷ್ಠ ಒಂದು ಹೋಲ್ಡ್ ಟೈಮರ್ನವರೆಗೆ ಚಾಲನೆಯಲ್ಲಿರಲಿ.
ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಈ ಐದು ಅಂಶಗಳನ್ನು ದೃಢೀಕರಿಸಿ: ಪ್ರಿಫಿಕ್ಸ್ ಸ್ಥಿರವಾಗಿದೆಯೇ ಅಥವಾ ಅಲುಗಾಡುತ್ತಿದೆಯೇ, ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಮುಂದಿನ ಹಾಪ್ ಸುರಂಗದತ್ತ ತೋರಿಸುತ್ತದೆಯೇ, ಹಾಪ್ ಎಣಿಕೆ ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆಯೇ, ಒಂದೇ ಸೈಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಹೊಂದಿದೆಯೇ, ಮತ್ತು ಬದಲಾವಣೆಯನ್ನು ತಡೆದುಕೊಳ್ಳುವ ನಿರ್ವಹಣಾ ಮಾರ್ಗ ನಿಮ್ಮಲ್ಲಿದೆಯೇ. ಐದರಲ್ಲಿ ಯಾವುದಾದರೂ ಅಜ್ಞಾತವಾಗಿದ್ದರೆ, ಉಳಿದ ನಾಲ್ಕು ಊಹೆಗಳು.