EIGRP ನೆರೆಹೊರೆಯವರೋ ಅಥವಾ DMVPN ಟ್ರಾನ್ಸಿಟ್‌ನೋ? ಮೊದಲು ಪಾತ್ರವನ್ನು ಪರಿಶೀಲಿಸಿ

ನೆರೆಹೊರೆ ಇಲ್ಲ, ಮತ್ತು ಮಧ್ಯದ ರೌಟರ್ ಸ್ಪಷ್ಟವಾದ ಶಂಕಿತನಂತೆ ಕಾಣುತ್ತದೆ. ಅದು ನಿರಪರಾಧಿಯಾಗಿರಬಹುದು. ಹೊರ ಟನೆಲ್ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವುದು ಮತ್ತು overlay ರೂಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ ಭಾಗವಹಿಸುವುದು ಎರಡು ಬೇರೆ ಬೇರೆ ಕೆಲಸಗಳು, ಮತ್ತು ಸಾಧನವು ಎರಡನೆಯದನ್ನು ಮಾಡದೆಯೇ ಮೊದಲನೆಯದನ್ನು ಮಾಡಬಹುದು. ಕೆಳಗಿನ ಐದು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ಮೊದಲ ವಿಫಲವಾದದ್ದರಲ್ಲಿ ನಿಲ್ಲಿಸಿ.

ಹಂತ 1: ಎರಡು ಪಾತ್ರಗಳನ್ನು ಬರೆಯಿರಿ

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

ಟ್ರಾನ್ಸಿಟ್ ರೌಟರ್ ತನ್ನ ಸಾಮಾನ್ಯ IP ರೂಟಿಂಗ್ ಮತ್ತು ನೀತಿಯಿಂದ ಹೊರ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ಸಂರಕ್ಷಿತ ಟನೆಲ್ ಒಳಗೆ ಸಾಗಿಸುವ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಅದು ಚಲಾಯಿಸಬೇಕಿಲ್ಲ, ಮತ್ತು ಆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮುಂದೆ ಕಳುಹಿಸಲು EIGRP ಪ್ರಕ್ರಿಯೆಯೂ ಬೇಕಿಲ್ಲ.

ಹಂತ 2: ಮಧ್ಯದ ಸಾಧನ ಏನನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಮಧ್ಯದ ರೌಟರ್ ಟನೆಲ್ ಅನ್ನು ಕೊನೆಗೊಳಿಸಿ spoke ಗಳೊಂದಿಗೆ EIGRP ನೆರೆಹೊರೆಗಳನ್ನು ರೂಪಿಸಬೇಕಿದ್ದರೆ, ಉತ್ತರ ಸಂಪೂರ್ಣ ಬದಲಾಗುತ್ತದೆ. ಆ ಸಾಧನಕ್ಕೆ ಬೆಂಬಲಿತ overlay ರೂಟಿಂಗ್ ವರ್ತನೆ ಬೇಕು, ಮತ್ತು ಅದನ್ನು ಟ್ರಾನ್ಸಿಟ್ ಎಂದು ಕರೆಯುವುದರಿಂದ ನೆರೆಹೊರೆಯ ಅಗತ್ಯ ಮಾಯವಾಗುವುದಿಲ್ಲ. ರೂಟಿಂಗ್ ಸಂರಚನೆಗಿಂತ ಮೊದಲು ಟನೆಲ್ ಸಂರಚನೆಯನ್ನು ಓದಿ. ಆ ಉತ್ತರವೇ ಮುಂದಿನ ಪ್ರತಿ ಪರಿಶೀಲನೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಆದ್ದರಿಂದ ಮೊದಲ ನಿಜವಾದ ಪ್ರಶ್ನೆ ಯಾವ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಸರಿಹೊಂದಿಸುವುದು ಎಂಬುದಲ್ಲ. ಪ್ರಶ್ನೆ ಎಂದರೆ ಆ ಪೆಟ್ಟಿಗೆ hub, spoke, ಸರಳ underlay ಹಾಪ್, ಅಥವಾ ತುದಿಗಳ ನಡುವೆ ಫ್ರೇಮ್‌ಗಳನ್ನು ಸಾಗಿಸುವ Layer 2 ಸೇವೆಯೇ ಎಂಬುದು.

ಹಂತ 3: ನೆರೆಹೊರೆಯವರ ನಿಯಂತ್ರಣ ಸಮತಲವನ್ನು ಪರಿಶೀಲಿಸಿ

ನೆರೆಹೊರೆಯವರಾಗಿರಬೇಕಾದ ಪ್ರತಿ ಸಾಧನದಲ್ಲಿ ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ದೃಢೀಕರಿಸಿ: EIGRP ಉದಾಹರಣೆ ಮತ್ತು ಸ್ವಾಯತ್ತ ವ್ಯವಸ್ಥೆ ಸಂಖ್ಯೆ, ದೃಢೀಕರಣ ನಿಯತಾಂಕಗಳು, ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವ ಇಂಟರ್ಫೇಸ್, ಮತ್ತು ಆ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಒಳಗೊಳ್ಳುವ ನೆಟ್‌ವರ್ಕ್ ಹೇಳಿಕೆ. ಅವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಾದರೂ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ ಇಂಟರ್ಫೇಸ್ ಮೇಲಿರುತ್ತದೆ ಮತ್ತು ping ಮುಂದುವರಿಯುತ್ತದೆ, ಆದರೆ ನೆರೆಹೊರೆ ಕೆಳಗಿರುತ್ತದೆ.

RFC 7868 EIGRP ಅನ್ನು ಮಲ್ಟಿಕಾಸ್ಟ್ ನಿಯಂತ್ರಣ ವಿನಿಮಯವಿರುವ IP ಪ್ರೋಟೋಕಾಲ್ ಎಂದು ವಿವರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೆರೆಹೊರೆ ಸಂಬಂಧವನ್ನು ಮಧ್ಯವರ್ತಿ ರೌಟರ್ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಗಮ್ಯಸ್ಥಾನದ ಕಡೆಗೆ ರೂಟ್ ಮಾಡಿ ಪ್ರತಿನಿಧಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಒಂದೋ ನಿಯಂತ್ರಣ ವಿನಿಮಯವು ಸಹವರ್ತಿಯನ್ನು ತಲುಪುತ್ತದೆ, ಇಲ್ಲವೇ ನೆರೆಹೊರೆ ರೂಪುಗೊಳ್ಳುವುದಿಲ್ಲ.

ಹಂತ 4: ಸಾಗಣೆ ನಿಯಂತ್ರಣ ವಿನಿಮಯವನ್ನು ತಲುಪಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಮುಂದೆ, overlay ಉದ್ದೇಶಿತ ತುದಿಗಳ ನಡುವೆ ನಿಯಂತ್ರಣ ಸಂಚಾರವನ್ನು ನಿಜವಾಗಿಯೂ ಸಾಗಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಸಹವರ್ತಿಯ NHRP ಮ್ಯಾಪಿಂಗ್ ಮತ್ತು ಅದನ್ನು ತಲುಪುವ ಹೊರ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ಮೇಲಿದೆ ಮತ್ತು ಸಂಚಾರವನ್ನು ದಾಟಿಸುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ಯಶಸ್ವಿ underlay ping ಹೊರ ಮಾರ್ಗ ಇದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; overlay ನಿಯಂತ್ರಣ ವಿನಿಮಯ ತಲುಪಿಸಲಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಪಾರದರ್ಶಕ Layer 2 ಸೇವೆ, ಬಿಂದು-ಇಂದ-ಬಿಂದು ಟನೆಲ್ ಮತ್ತು ಬಹು-ಬಿಂದು DMVPN ಕ್ಲೌಡ್ ಮಲ್ಟಿಕಾಸ್ಟ್ ಅನ್ನು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ತಲುಪಿಸುತ್ತವೆ. ಮೂರೂ ಒಂದೇ ರೀತಿ ವರ್ತಿಸುತ್ತವೆ ಎಂದು ಭಾವಿಸುವ ಬದಲು ನಿಜವಾಗಿ ನಿಯೋಜಿಸಲಾದದ್ದಕ್ಕೆ ಬೆಂಬಲಿತ ಇಂಟರ್ಫೇಸ್, NHRP ಮತ್ತು ಮಲ್ಟಿಕಾಸ್ಟ್ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸಿ.

ಹಂತ 5: ಭಾಗವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದಿದ್ದರೆ ಗಡಿಯನ್ನು ಮರು ವಿನ್ಯಾಸ ಮಾಡಿ

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

ಚಿತ್ರದಲ್ಲಿ ಪ್ರತಿ ಸಾಧನದ ಪಾತ್ರವನ್ನು ದಾಖಲಿಸಿ ಮತ್ತು ಅದನ್ನು ಸಂರಚನೆಯೊಂದಿಗೆ ಇರಿಸಿ. RFC 7868 ಪ್ರೋಟೋಕಾಲ್ ವಿನಿಮಯವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಮತ್ತು ಆ ವ್ಯಾಖ್ಯಾನವೇ ಟ್ರಾನ್ಸಿಟ್ ಫಾರ್ವರ್ಡಿಂಗ್‌ನಿಂದ ನೆರೆಹೊರೆ ಸಂಬಂಧವನ್ನು ಅಣಕಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ಆಧಾರ.

ಎಲ್ಲಾ ಐದು ಪರಿಶೀಲನೆಗಳ ನಂತರವೂ ನೆರೆಹೊರೆ ವಿಫಲವಾದರೆ, ಉಳಿದ ಶಂಕಿತರು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ವೈಶಿಷ್ಟ್ಯಗಳು, ಉದಾಹರಣೆಗೆ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಮಲ್ಟಿಕಾಸ್ಟ್ ನಿರ್ವಹಣೆ ಮತ್ತು 88 ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವ ನೀತಿ. ಇವು ನಿರ್ದಿಷ್ಟ, ಪರೀಕ್ಷಿಸಬಹುದಾದ ಕಾರಣಗಳು ಮತ್ತು ಮಧ್ಯದ ರೌಟರ್‌ಗೆ ದೂರ ಹೇಳುವ ಇನ್ನೊಂದು ಸುತ್ತಿಗಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯದವು.