OSPF ಗರಿಷ್ಠ ಮೆಟ್ರಿಕ್: ಶಾಖೆಯನ್ನು ತೆಗೆದುಹಾಕದೆ ಅದರ ಟ್ರಾನ್ಸಿಟ್ ಅನ್ನು ನಿರುತ್ಸಾಹಗೊಳಿಸುವುದು

ಎರಡು ಕಚೇರಿಗಳು ಶಾಖೆಯ ಮೂಲಕ ಸಂಪರ್ಕಗೊಂಡಿವೆ, ಅದು ತನ್ನದೇ ಸಂಚಾರ ಮತ್ತು ಬಹಳ ಕಡಿಮೆ ಬೇರೆಯದನ್ನು ಸಾಗಿಸಬೇಕು. ಶಾಖೆಗೆ ಎರಡೂ ಸೈಟ್ಗಳಿಗೆ ಮಾರ್ಗಗಳು ಬೇಕು, ಮತ್ತು ಯಾವುದೇ ಸೈಟ್ ಅವುಗಳ ನಡುವಿನ ಮಾರ್ಗವಾಗಿ ಅದಕ್ಕೆ ಆದ್ಯತೆ ನೀಡಬಾರದು. ಶಾಖೆಯನ್ನು ಟೋಪಾಲಜಿಯಿಂದ ತೆಗೆದುಹಾಕುವುದು ಟ್ರಾನ್ಸಿಟ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವನ್ನು ಮುರಿಯುತ್ತದೆ, ಏಕೆಂದರೆ ಶಾಖೆ ಇನ್ನೂ ಎರಡೂ ಸೈಟ್ಗಳನ್ನು ತಲುಪಬೇಕು ಮತ್ತು ಎರಡೂ ಸೈಟ್ಗಳು ಇನ್ನೂ ಶಾಖೆಯನ್ನು ತಲುಪಬೇಕು.

ನೀವು ಬಯಸುವುದು ಆದ್ಯತೆ, ರೂಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ನಲ್ಲಿ ವ್ಯಕ್ತವಾಗಿರುವ, ಶಾಖೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಲುಪಬಹುದಾದಂತೆ ಬಿಡುತ್ತದೆ ಮತ್ತು ಅದರ ಮೂಲಕ ಹಾದುಹೋಗುವ ಯಾವುದಕ್ಕೂ ಅದನ್ನು ಕೆಟ್ಟ ಆಯ್ಕೆಯನ್ನಾಗಿ ಮಾಡುತ್ತದೆ. ರೌಟರ್ಗಳು ಸಮಸ್ಯೆಯನ್ನು ನೋಡುವ ಕ್ರಮದಲ್ಲೇ ನಡೆಯಿರಿ.

ನೀವು ತಪ್ಪಿಸಲು ಬಯಸುವ ಮಾರ್ಗದಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಟೋಪಾಲಜಿಯನ್ನು ಪ್ರೋಟೋಕಾಲ್ ನೋಡುವಂತೆ ಚಿತ್ರಿಸಿ, ರೇಖಾಚಿತ್ರ ನೋಡುವಂತೆ ಅಲ್ಲ. ಯಾವ ಇಂಟರ್ಫೇಸ್ಗಳು ನೆರೆಹೊರೆಗಳನ್ನು ರೂಪಿಸುತ್ತವೆ, ಯಾವುವು ಒಂದೇ ಪ್ರದೇಶದಲ್ಲಿವೆ, ಮತ್ತು ಶಾಖೆಗೆ ಆದ್ಯತೆ ನೀಡಿದರೆ ಆ ನೆರೆಹೊರೆಗಳಲ್ಲಿ ಯಾವುವು ಎರಡು ಕಚೇರಿಗಳ ನಡುವೆ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುತ್ತವೆ? ಇವು ಮೂರು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳು, ಮತ್ತು ರೇಖಾಚಿತ್ರ ಅವುಗಳಲ್ಲಿ ಯಾವುದಕ್ಕೂ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಉತ್ತರಿಸುವುದಿಲ್ಲ.

ನಂತರ ಪರ್ಯಾಯ ಮಾರ್ಗವನ್ನು ಹುಡುಕಿ. ಕಚೇರಿಗಳ ನಡುವಿನ ಏಕೈಕ ಮಾರ್ಗ ಶಾಖೆಯ ಮೂಲಕ ಹಾದುಹೋದರೆ, ಯಾವುದೇ ಮೆಟ್ರಿಕ್ ಸಂಚಾರವನ್ನು ಅಲ್ಲಿಂದ ಸರಿಸಲಾರದು, ಏಕೆಂದರೆ ಸಂಚಾರಕ್ಕೆ ಹೋಗಲು ಸ್ಥಳವಿಲ್ಲ. ಪುನರುಕ್ತಿ ಈ ವಿನ್ಯಾಸದ ವಿವರವಲ್ಲ; ಅದು ಪೂರ್ವಭಾವಿ ಷರತ್ತು. ಕಾಗದದ ಮೇಲೆ ಮಾತ್ರ ಇರುವ ಎರಡನೇ ಮಾರ್ಗವನ್ನು ಎಣಿಸುವುದಿಲ್ಲ.

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

ಈ ಮೂರು ನೋಟಗಳು ವಿಭಿನ್ನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ: ಯಾರು ನೆರೆಯವರು, ಯಾವ ಇಂಟರ್ಫೇಸ್ಗಳು ಭಾಗವಹಿಸುತ್ತವೆ ಮತ್ತು ಯಾವ ವೆಚ್ಚದಲ್ಲಿ, ಮತ್ತು ಸಾಧನವು ಈಗ ಯಾವ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಸುರಂಗ ನಿಯೋಜನೆ ನಾಲ್ಕನೆಯದನ್ನು ಸೇರಿಸುತ್ತದೆ: ರೇಖಾಚಿತ್ರದಲ್ಲಿನ ರೇಖೆಯು ಅದರ ಮೂಲಕ ನೆರೆಹೊರೆ ರೂಪುಗೊಂಡಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ, ಮತ್ತು ರೂಪುಗೊಂಡ ನೆರೆಹೊರೆ ಮುಂದುವರಿಕೆ ಅದೇ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ. ಸುರಂಗ ವಿನ್ಯಾಸಗಳಲ್ಲೇ ಈ ಅಂತರ ಹೆಚ್ಚಾಗಿ ಕಾಣುತ್ತದೆ.

ಗರಿಷ್ಠ ಮೆಟ್ರಿಕ್ ಏನನ್ನು ಘೋಷಿಸುತ್ತದೆ

RFC 6987 ತನ್ನ ಸ್ಟಬ್ ಅಲ್ಲದ ಕೊಂಡಿಗಳನ್ನು ಗರಿಷ್ಠ ಕೊಂಡಿ ಮೆಟ್ರಿಕ್ನೊಂದಿಗೆ ಘೋಷಿಸುವ ರೌಟರ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ, ಅದನ್ನು 0xffff ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ರೌಟರ್ ಇನ್ನೂ ತನ್ನನ್ನು ಮತ್ತು ತನ್ನ ಕೊಂಡಿಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ; ಅದು ಅವುಗಳಿಗೆ ಶ್ರೇಣಿಯ ಮೇಲ್ತುದಿಯಲ್ಲಿ ಬೆಲೆ ಹಾಕುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಇತರ ರೌಟರ್ ಅದರ ಮೂಲಕ ಹಾದುಹೋಗುವ ಮಾರ್ಗವನ್ನು ದುಬಾರಿ ಎಂದು ಲೆಕ್ಕ ಹಾಕುತ್ತದೆ.

ಇದು router-LSA ಬದಲಾವಣೆ, ಟೋಪಾಲಜಿ ತೆಗೆದುಹಾಕುವುದಲ್ಲ. ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ: router-LSA ಫ್ಲಶ್ ಮಾಡುವುದು ಟೋಪಾಲಜಿ ಮಾಹಿತಿಯನ್ನೇ ಹಿಂಪಡೆಯುತ್ತದೆ, ಇದು ರೌಟರ್ ಮತ್ತು ಅದರ ಹಿಂದಿನ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ತಲುಪಲು ಬೇಕಾದ ಸಂಬಂಧಗಳನ್ನೂ ಹಿಂಪಡೆಯಬಹುದು. ಘೋಷಣೆಯನ್ನು ಇಟ್ಟುಕೊಂಡು ಅದರ ಬೆಲೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದು ಆ ಸಂಬಂಧಗಳನ್ನು ಸಂರಕ್ಷಿಸುತ್ತದೆ. ಈ ತಂತ್ರ ಮತ್ತು ತೆಗೆದುಹಾಕುವಿಕೆಯ ನಡುವಿನ ಸಂಪೂರ್ಣ ವ್ಯತ್ಯಾಸ ಅಷ್ಟೇ.

RFC 6987 ಕಾರ್ಯವಿಧಾನಕ್ಕೂ ಪ್ರದೇಶ ಪ್ರಕಾರಗಳು ಅಥವಾ ನಿಯುಕ್ತ ರೌಟರ್ ಆಯ್ಕೆಗೂ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ. ಸ್ಟಬ್ ಪ್ರದೇಶ ಪ್ರದೇಶ ಗಡಿಯಲ್ಲಿ ಕೊಂಡಿ ಸ್ಥಿತಿ ಘೋಷಣೆಗಳ ಒಂದು ವರ್ಗವನ್ನು ತಡೆಯುತ್ತದೆ, ಮತ್ತು ಸ್ಟಬ್ ರೌಟರ್ ತನ್ನದೇ ಕೊಂಡಿಗಳಿಗೆ ಬೆಲೆ ಹಾಕುತ್ತದೆ. ಹೋಲುವ ಪದಗಳು, ಸಂಬಂಧವಿಲ್ಲದ ಯಂತ್ರಾಂಶ.

ಏಕೆ ತಲುಪುವಿಕೆ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಟ್ರಾನ್ಸಿಟ್ ಉಳಿಯುವುದಿಲ್ಲ

ಇತರ ರೌಟರ್ಗಳಿಗೆ ಇನ್ನೂ ಶಾಖೆಯ ಸಂಪರ್ಕಿತ ಪ್ರಿಫಿಕ್ಸ್ಗಳಿಗೆ ಮಾರ್ಗವಿದೆ, ಏಕೆಂದರೆ ಶಾಖೆ ಇನ್ನೂ ಅವುಗಳನ್ನು ಘೋಷಿಸುತ್ತದೆ ಮತ್ತು ಕೊಂಡಿಗಳು ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. ಬದಲಾಗುವುದು ಬೇರೆಡೆಗೆ ಹೋಗುವಾಗ ಶಾಖೆಯ ಮೂಲಕ ಹಾದುಹೋಗುವ ಯಾವುದೇ ಮಾರ್ಗದ ಒಟ್ಟು ವೆಚ್ಚ. ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಚಲಿಸುವುದಿಲ್ಲ; ರೌಟರ್ ದಾಟುವ ಬೆಲೆ ಮಾತ್ರ ಬದಲಾಗುತ್ತದೆ.

ಮೂಲ ಅಥವಾ ಗಮ್ಯಸ್ಥಾನ ಶಾಖೆಯೇ ಆಗಿರುವ ಸಂಚಾರಕ್ಕೆ, ದುಬಾರಿ ಕೊಂಡಿ ಇನ್ನೂ ಏಕೈಕ ಸೂಕ್ತ ಮಾರ್ಗದಲ್ಲಿದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಎರಡು ಕಚೇರಿಗಳ ನಡುವಿನ ಸಂಚಾರಕ್ಕೆ, ಪರ್ಯಾಯ ಮಾರ್ಗ ಈಗ ವೆಚ್ಚದಲ್ಲಿ ಗೆಲ್ಲುತ್ತದೆ, ಮತ್ತು ಶಾಖೆ ಟೋಪಾಲಜಿಯಿಂದ ಮಾಯವಾಗದೆ ಮುಂದುವರಿಕೆ ನಿರ್ಧಾರದಿಂದ ಹೊರಬರುತ್ತದೆ. ಎರಡು ದಿಕ್ಕುಗಳು, ಎರಡು ವಿಭಿನ್ನ ಉತ್ತರಗಳು, ಮತ್ತು ಎರಡೂ ಕಾರ್ಯವಿಧಾನ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತವೆ.

ಇದು ಊಹಿಸುವ ಬದಲು ಪರಿಶೀಲಿಸಬೇಕಾದ ನಡವಳಿಕೆ. ಶಾಖೆ ಉತ್ಪಾದಿಸುವ router-LSA ಅನ್ನು ನೋಡಿ, ನಂತರ ಶಾಖೆಯ ಹಿಂದಿನ ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಇನ್ನೊಂದು ಕಚೇರಿಯ ಗಮ್ಯಸ್ಥಾನಕ್ಕಾಗಿ ಇನ್ನೊಂದು ರೌಟರ್ ಆಯ್ಕೆ ಮಾಡುವ ಮಾರ್ಗವನ್ನು ನೋಡಿ. ಎರಡೂ ಉತ್ತರಗಳು ಭಿನ್ನವಾಗಿರಬೇಕು, ಮತ್ತು ಇಲ್ಲದಿದ್ದರೆ, ಮೆಟ್ರಿಕ್ ಬದಲಾವಣೆ ನೀವು ಭಾವಿಸುವ ನಿರ್ಧಾರವನ್ನು ತಲುಪುತ್ತಿಲ್ಲ.

ಕೊನೆಯ ಮಾರ್ಗದ ಸಮಸ್ಯೆ

ಅದೇ RFC ಈ ತಂತ್ರವು ಬಳಕೆಯನ್ನು ನಿಷೇಧಿಸುವುದಿಲ್ಲ ಎಂದು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ. ಪರ್ಯಾಯ ಮಾರ್ಗ ವಿಫಲವಾದಾಗ, ರೌಟರ್ಗಳು ಶಾಖೆಯ ಮೂಲಕ ಹೋಗುವ ದುಬಾರಿ ಮಾರ್ಗಕ್ಕೆ ಮರಳುತ್ತವೆ, ಏಕೆಂದರೆ ಅದು ಇನ್ನೂ ಮಾನ್ಯ ಮಾರ್ಗ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಮಾರ್ಗವಿಲ್ಲದಿರುವುದಕ್ಕಿಂತ ದುಬಾರಿ ಮಾರ್ಗವನ್ನು ಆದ್ಯತೆ ನೀಡುತ್ತದೆ.

ಆ ಮರಳುವಿಕೆ ಸ್ವೀಕಾರಾರ್ಹವೇ ಎಂಬುದು ನಿಯೋಜನೆಗೆ ಮೊದಲು ಉತ್ತರಿಸಬೇಕಾದ ನೀತಿ ಪ್ರಶ್ನೆ. ಸಣ್ಣ ಅಪ್ಲಿಂಕ್ನಲ್ಲಿರುವ ಶಾಖೆ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಕಚೇರಿಗಳ ನಡುವಿನ ಸಂಚಾರವನ್ನು ಸಾಗಿಸಿದರೆ ಅದು ಅಡ್ಡಿಯಿಂದಲೂ ಕೆಟ್ಟದಾಗಿರಬಹುದು, ಮತ್ತು ನಿರ್ವಹಣಾ ಕಿಟಕಿಯ ಸಮಯದಲ್ಲಿ ಅದು ನಿಖರವಾಗಿ ನೀವು ಬಯಸುವುದಾಗಿರಬಹುದು. ಎರಡೂ ಉತ್ತರಗಳು ಕಾನೂನುಬದ್ಧ; ಮೌನವಲ್ಲ.

ಅಗತ್ಯವು ಆದ್ಯತೆಯಲ್ಲದೆ ಕಟ್ಟುನಿಟ್ಟಿನ ನಿಷೇಧವಾಗಿದ್ದರೆ, ಮೆಟ್ರಿಕ್ ವಿನ್ಯಾಸ ಮಾತ್ರ ಅದನ್ನು ನೀಡುವುದಿಲ್ಲ. ಉದ್ದೇಶಕ್ಕೆ ಹೊಂದುವ ಮುಂದುವರಿಕೆ ಜಾರಿಗೊಳಿಸುವಿಕೆ ಮತ್ತು ಸಂಚಾರ ಹೇಗಾದರೂ ಬಂದಾಗಿನ ಸಂದರ್ಭಕ್ಕೆ ವ್ಯಾಖ್ಯಾನಿಸಿದ ನಡವಳಿಕೆ ನಿಮಗೆ ಬೇಕು. ಮಾರ್ಗವನ್ನು ಬಳಸಬಹುದಾದುದೆಂದು ಘೋಷಿಸಿ ನಂತರ ಸಂಚಾರವನ್ನು ಬಿಟ್ಟುಬಿಡುವುದು ರೂಟಿಂಗ್ ಲೂಪ್ಗಿಂತ ಕಷ್ಟಕರವಾದ ಕಪ್ಪು ಕುಳಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

OSPFv3 ಗಾಗಿ RFC R-ಬಿಟ್ ಅನ್ನು ಟ್ರಾನ್ಸಿಟ್ ಭಾಗವಹಿಸುವಿಕೆಯನ್ನು ಹೊರಗಿಡುವ ಬೇರೆ ವಿಧಾನವಾಗಿ ಚರ್ಚಿಸುತ್ತದೆ. ಅದು ಗರಿಷ್ಠ-ಮೆಟ್ರಿಕ್ ತಂತ್ರದಂತೆಯೇ ಕೊನೆಯ ಮಾರ್ಗದ ನಡವಳಿಕೆಯನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುತ್ತದೆ ಎಂದು ಊಹಿಸಬೇಡಿ, ಮತ್ತು ಎರಡು ವಿಳಾಸ ಕುಟುಂಬಗಳ ನಡುವೆ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಒಂದೇ ವೈಶಿಷ್ಟ್ಯ ಎಂಬಂತೆ ನಕಲಿಸಬೇಡಿ.

ಸಾಮಾನ್ಯ ಮತ್ತು ವಿಫಲ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಅದನ್ನು ಸಾಬೀತುಪಡಿಸಿ

ಎರಡು ಬಾರಿ ಪರೀಕ್ಷಿಸಿ: ಒಮ್ಮೆ ಎರಡೂ ಮಾರ್ಗಗಳು ಲಭ್ಯವಿರುವಾಗ, ಒಮ್ಮೆ ಆದ್ಯತೆಯ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಹಾಕಿದಾಗ. ಮೊದಲ ಪರೀಕ್ಷೆ ಆದ್ಯತೆ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯದು ಆದ್ಯತೆಯನ್ನು ಗೌರವಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ನೆಟ್ವರ್ಕ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಎರಡನೇ ಪರೀಕ್ಷೆಯನ್ನು ಬಿಟ್ಟುಬಿಡುವುದು ಪ್ರಮುಖ ಅರ್ಧವನ್ನು ಪರಿಶೀಲಿಸದೆ ಬಿಡುತ್ತದೆ.

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

ಡೇಟಾಬೇಸ್ ನೋಟವು ಘೋಷಿತ ಮೆಟ್ರಿಕ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ, ಮಾರ್ಗ ಹುಡುಕಾಟವು ಆಯ್ಕೆಮಾಡಿದ ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಜಾಡು ಪ್ಯಾಕೆಟ್ಗಳು ವಾಸ್ತವವಾಗಿ ಎಲ್ಲಿಗೆ ಹೋದವು ಎಂದು ತೋರಿಸುತ್ತದೆ. ಈ ಮೂರೂ ಹೊಂದಿಕೆಯಾದಾಗ, ನಿಮ್ಮ ಬಳಿ ಸರಿಯಾಗಿ ಕಾಣುವ ಸಂರಚನೆಯಲ್ಲ, ಪರಿಶೀಲಿಸಿದ ವಿನ್ಯಾಸವಿದೆ.

ನಂತರ ಆದ್ಯತೆಯ ಮಾರ್ಗವನ್ನು ಮರುಸ್ಥಾಪಿಸಿ ಮತ್ತು ಶಾಖೆ ತನ್ನದೇ ಸಂಚಾರವನ್ನು ಮಾತ್ರ ಸಾಗಿಸಲು ಮರಳುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಮರುಸ್ಥಾಪನೆಯ ಹಂತವು ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆಗಲ್ಲ, ಪರೀಕ್ಷೆಗೆ ಸೇರುತ್ತದೆ, ಏಕೆಂದರೆ ಮುಂದಿನ ಬದಲಾವಣೆಯವರೆಗೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ವಿನ್ಯಾಸವು ವಿನ್ಯಾಸವಲ್ಲ. ಎರಡೂ ಫಲಿತಾಂಶಗಳನ್ನು ಬರೆಯಿರಿ, ಮರಳುವಿಕೆ ಸೇರಿದಂತೆ, ಏಕೆಂದರೆ ಎರಡನೆಯದು ಯಾರಿಗಾದರೂ ರಾತ್ರಿ ಮೂರು ಗಂಟೆಗೆ ಬೇಕಾಗುವ ಉತ್ತರ.