VPN ಮೇಲಿನ BGP ನಿಮ್ಮ ಅಂಡರ್‌ಲೇ ಮಾರ್ಗವನ್ನು ನಿಯಂತ್ರಿಸದಿರುವುದೇಕೆ
VPN ಮೇಲಿನ BGP ತಲುಪುವಿಕೆಯನ್ನು ವಿನಿಮಯ ಮಾಡಿ ಮಾರ್ಗ ನೀತಿಯನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ, ಆದರೆ ಅಂಡರ್‌ಲೇ ಇನ್ನೂ ಹೊರ ಮಾರ್ಗವನ್ನೇ ಆರಿಸುತ್ತದೆ. ಸೆಷನ್ ನಿಜವಾಗಿ ಏನನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ.
ಎರಡು ಸೈಟ್‌ಗಳು IPsec ಸುರಂಗದ ಮೇಲೆ BGP ಪೀರ್ ಮಾಡುತ್ತವೆ, ಪರಸ್ಪರರ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಕಲಿಯುತ್ತವೆ, ಮತ್ತು ರೇಖಾಚಿತ್ರವು ಮಾರ್ಗ ನಿಯಂತ್ರಣ ಎಂದು ಮರುಲೇಬಲ್ ಆಗುತ್ತದೆ. ಆ ಲೇಬಲ್‌ನಿಂದಲೇ ಗೊಂದಲ ಆರಂಭವಾಗುತ್ತದೆ. ಸೆಷನ್ ತಲುಪುವಿಕೆಯನ್ನು ವಿನಿಮಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ನೀತಿಯನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ, ಆದರೆ ಯಾವ ಪ್ರದಾತ, ಕೇಬಲ್ ಅಥವಾ ರೌಟರ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ಅದಕ್ಕೆ ಮಾತಿಲ್ಲ. ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಸುರಂಗವನ್ನು ತಂಡವೊಂದು ಮತ್ತೆ ನಿರ್ಮಿಸುವುದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ, ಏಕೆಂದರೆ BGP ಮಾರ್ಗ ಬದಲಾವಣೆ ಸಂಚಾರವನ್ನು ಸೆಷನ್ ಎಂದಿಗೂ ಪ್ರಭಾವಿಸಲಾಗದ ಇನ್ನೊಂದು ಫೈಬರ್ ಮಾರ್ಗಕ್ಕೆ ಸರಿಸುತ್ತದೆ ಎಂದು ಅವರು ನಿರೀಕ್ಷಿಸಿದ್ದರು.
ಸೆಷನ್ ಏನನ್ನು ಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಜನರು ಊಹಿಸುವುದು
ನಿರೀಕ್ಷೆಯ ಬಹುಪಾಲು ಪ್ರಯೋಗಾಲಯದಲ್ಲಿ ಮಾರ್ಗ ಬದಲಾವಣೆ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದರಿಂದ ಬರುತ್ತದೆ. ನೀವು ಸುರಂಗದ ಮೇಲೆ ಪ್ರಿಫಿಕ್ಸ್ ಘೋಷಿಸುತ್ತೀರಿ, ದೂರದ ಬದಿ ಅದನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ಸಂಚಾರ ಚಲಿಸುತ್ತದೆ. ಅದೇ ಕ್ರಮ ಸಂಚಾರ ಎಂಜಿನಿಯರಿಂಗ್ ನಿಯಂತ್ರಣಗಳನ್ನು ನಿಜವಾಗಿ ಹೊಂದಿರುವ ರೌಟರ್‌ನಲ್ಲೂ ಸಂಭವಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡನ್ನೂ ಗೊಂದಲಿಸಲಾಗುತ್ತದೆ. ಪ್ರಯೋಗಾಲಯದಲ್ಲಿ ಎರಡೂ ಸೈಟ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಪ್ರವೇಶ ಕೊಂಡಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಅದಕ್ಕೇ ವ್ಯತ್ಯಾಸ ಅಲ್ಲಿ ಎಂದಿಗೂ ಕಾಣಿಸುವುದಿಲ್ಲ.
BGP ಒಂದು ತಲುಪುವಿಕೆ ಪ್ರೋಟೋಕಾಲ್. ಇದು ಪೀರ್‌ಗೆ ನೀವು ಪ್ರಿಫಿಕ್ಸ್‌ಗಾಗಿ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ತಲುಪಿಸಬಹುದು ಎಂದು ಹೇಳುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಬದಿಗೂ ಸಿಗುವ ಕೊಡುಗೆಗಳನ್ನು ಶ್ರೇಣೀಕರಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಇದು ಸುರಂಗದ ಮೇಲೆ ನಿಜವಾಗಿಯೂ ಉಪಯುಕ್ತ: ಸೈಟ್‌ಗಳು ಬಂದು ಹೋಗುವಂತೆ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಮಾಯವಾಗುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿ ಎಡ್ಜ್ ಸಾಧನದಲ್ಲಿ ಸ್ಥಿರ ಮಾರ್ಗ ಬರೆಯದೆ ನೀವು ಒಂದು ಶ್ರೇಣಿಯನ್ನು ನಿರಾಕರಿಸಬಹುದು. ಅದು ಮಾಡದಿರುವುದು ಪ್ರದಾತದ ರೌಟರ್‌ಗಳನ್ನು ನಿಮ್ಮ ನಿಯಂತ್ರಣಕ್ಕೆ ತರುವುದು.
ಅಂಡರ್‌ಲೇ ಹೊರ ಶೀರ್ಷಿಕೆಯನ್ನು ಸಾಗಿಸುತ್ತದೆ. ನಿಮ್ಮ ಸುರಂಗದ ಅಂತ್ಯಬಿಂದು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಪೀರ್ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಎರಡು ವಿಳಾಸಗಳ ನಡುವಿನ ಜಾಲವು ಅದರ ನಿರ್ವಾಹಕರು ಸ್ಥಾಪಿಸಿದ ಮಾರ್ಗಗಳಿಂದ ಅವುಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. BGP ಸೆಷನ್‌ನಲ್ಲಿ ಯಾವುದೂ ಆ ನಿರ್ಧಾರವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ, ಅದೇ ಪ್ರದಾತ ಅದನ್ನು ಮಾಡುವ ಬೆಂಬಲಿತ ಸೇವೆಯನ್ನು ಒದಗಿಸದ ಹೊರತು.
ಸೆಷನ್ ನಿಜವಾಗಿ ಏನನ್ನು ಸಾಗಿಸುತ್ತದೆ
BGP ವಕ್ತಾರ ತನ್ನ ಪೀರ್‌ನ 179 ಪೋರ್ಟ್‌ಗೆ TCP ಸಂಪರ್ಕ ತೆರೆಯುತ್ತದೆ, RFC 4271-ರಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಿದ ಸಂದೇಶ ಸ್ವರೂಪಗಳು ಮತ್ತು ಮಾರ್ಗ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಬಳಸಿ. ಪೀರ್ ವಿಳಾಸ ಸುರಂಗದ ಒಳಗಿದ್ದಾಗ, ಸೆಷನ್ ಆರಂಭವಾಗುವ ಮೊದಲೇ ಸುರಂಗ ಏರಿರಬೇಕು ಮತ್ತು ಆ ವಿಳಾಸ ತಲುಪಬಲ್ಲದಾಗಿರಬೇಕು. ಪೂರ್ಣಗೊಂಡ IKE ವಿನಿಮಯವು BGP ನೆರೆಯವಲ್ಲ. ಮಾರ್ಗ ಆಧಾರಿತ IPsec ಅನುಷ್ಠಾನಗಳು ಹೊಂದಿಕೆಯಾಗುವ ಸುರಂಗ ಮಾರ್ಗ ಇದ್ದಾಗ ಮಾತ್ರ ಸಂಚಾರವನ್ನು ಹಾದುಹೋಗಲು ಬಿಡುತ್ತವೆ, ಮತ್ತು ನೀತಿ ಆಧಾರಿತ ಅನುಷ್ಠಾನಕ್ಕೆ ರಕ್ಷಿತ ಆಯ್ಕೆದಾರನ ಒಳಗೆ ಪೀರ್ ವಿಳಾಸ ಬೇಕು. ಇದನ್ನು ತಲೆಕೆಳಗೆ ಮಾಡಿದರೆ ಸುರಂಗ ಹಸಿರಾಗಿದ್ದು ಸೆಷನ್ ನಿಷ್ಕ್ರಿಯವಾಗಿ ಕುಳಿತಿರುವ ಸಾಂಪ್ರದಾಯಿಕ ಸ್ಥಿತಿ ಉಂಟಾಗುತ್ತದೆ.
ಸೆಷನ್ ಏರಿದ ನಂತರ, ಅದನ್ನು ಯಾವುದು ದಾಟುತ್ತದೆ ಎಂಬುದನ್ನು ನೀತಿ ನಿರ್ಧರಿಸುತ್ತದೆ. ಪ್ರಿಫಿಕ್ಸ್ ಪಟ್ಟಿಗಳು, AS-ಮಾರ್ಗ ಶೋಧಕಗಳು, ಗರಿಷ್ಠ ಪ್ರಿಫಿಕ್ಸ್ ಮಿತಿ ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗಗಳ ಬಗ್ಗೆ ಸ್ಪಷ್ಟ ನಿರ್ಧಾರ ಕನಿಷ್ಠ, ಮತ್ತು ಅವು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಅನ್ವಯಿಸುತ್ತವೆ. ಸಿಗುವುದೆಲ್ಲವನ್ನೂ ಸ್ವೀಕರಿಸುವ ಪೀರ್ ನಿಮಗೆ ಸ್ಥಳೀಯ ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶವನ್ನು ಮೌನವಾಗಿ ಬದಲಿಸುವ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ನೀಡಬಹುದು. ಎರಡೂ ದಿಕ್ಕುಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ಪಟ್ಟಿಗಳು ಬೇಕು, ಏಕೆಂದರೆ ಪೀರ್‌ನಿಂದ ನೀವು ಏನನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ ಮತ್ತು ಅವನಿಗೆ ಏನನ್ನು ಘೋಷಿಸುತ್ತೀರಿ ಎಂಬುದು ಬೇರೆ ಬೇರೆ ನಿರ್ಧಾರಗಳು.
router bgp 65010
neighbor 10.255.0.2 remote-as 65020
address-family ipv4 unicast
neighbor 10.255.0.2 prefix-list SITE-B-IN in
neighbor 10.255.0.2 prefix-list SITE-B-OUT out
neighbor 10.255.0.2 maximum-prefix 50
ಮುಂದೆ MTU ಕಚ್ಚುತ್ತದೆ. ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಉಪಯುಕ್ತ ಪೇಲೋಡ್ ಅನ್ನು ಕುಗ್ಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ದೊಡ್ಡ ನವೀಕರಣವು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಾಪಿತವಾದಂತೆ ಕಾಣುವ ಸೆಷನ್ ಅನ್ನು ನಿಲ್ಲಿಸಬಹುದು: ಪೀರ್ ಮೇಲೆಯೇ ಇರುತ್ತದೆ, ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ಎಂದಿಗೂ ಬರುವುದಿಲ್ಲ, ಮತ್ತು ಲಾಗ್‌ನಲ್ಲಿ ಸ್ಪಷ್ಟವಾದುದೇನೂ ಬೀಳುವುದಿಲ್ಲ. ಶೋಧಕಗಳನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಸುರಂಗ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ TCP MSS ಅನ್ನು ಮಿತಿಗೊಳಿಸಿ, ಅಥವಾ ಓವರ್‌ಹೆಡ್‌ಗೆ ಜಾಗ ಬಿಟ್ಟು ಸುರಂಗ MTU ಸೆಟ್ ಮಾಡಿ.
ಹೊರ ಪ್ಯಾಕೆಟ್‌ಗಳು ಇನ್ನೂ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ
ಒಂದು ಸೈಟ್‌ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ ಪ್ಯಾಕೆಟ್‌ಗಳು ಸ್ಥಳೀಯ ರೌಟರ್ ಪೀರ್‌ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಆರಿಸುವ ಮೂಲಕ ಹೊರಬರುತ್ತವೆ. ಎರಡೂ ಸೈಟ್‌ಗಳು ಒಂದೇ ಪ್ರದಾತದಿಂದ ಟ್ರಾನ್ಸಿಟ್ ಖರೀದಿಸಿದರೆ, ಒಂದೇ ಮೆಟ್ರೋ ಸೌಲಭ್ಯವನ್ನು ದಾಟಿದರೆ, ಅಥವಾ ಒಂದು ಬದಿ ಕ್ಯಾರಿಯರ್-ಗ್ರೇಡ್ NAT ಹಿಂದೆ ಇದ್ದರೆ, ಸುರಂಗ ಪ್ರದಾತ ವೈಫಲ್ಯದಿಂದ ಆಕಸ್ಮಿಕವಾಗಿ ಮಾತ್ರ ಪಾರಾಗುತ್ತದೆ. ಮೇಲ್ವಿಚಾರಣಾ ಸಾಧನದಲ್ಲಿ ಸುರಂಗ ಐಕಾನ್‌ಗಳನ್ನು ಎಣಿಸುವುದು ಅದರ ಬಗ್ಗೆ ನಿಮಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ಮಾರ್ಗ ಆಯ್ಕೆ ಮತ್ತು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆಯ ಸ್ಥಾಪನೆಯೂ ಪ್ರತ್ಯೇಕ ಘಟನೆಗಳು. ಪ್ರಿಫಿಕ್ಸ್ BGP ಕೋಷ್ಟಕದಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿ ಕುಳಿತು ಇನ್ನೂ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಕೋಷ್ಟಕದಿಂದ ಕಾಣೆಯಾಗಬಹುದು, ಏಕೆಂದರೆ ಮುಂದಿನ ಹಾಪ್ ಪರಿಹರಿಸಲಾಗದಿರಬಹುದು ಅಥವಾ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗ ಗೆಲ್ಲುತ್ತದೆ. BGP ಪ್ರಿಫಿಕ್ಸ್ ಕಲಿತಿದೆ ಆದರೆ ಸಂಚಾರ ಹರಿಯುತ್ತಿಲ್ಲ ಎಂದು ಯಾರಾದರೂ ವರದಿ ಮಾಡಿದಾಗ, ಉಪಯುಕ್ತ ಪ್ರಶ್ನೆ ಎಂದರೆ ಅದು ಸ್ಥಾಪಿತವಾಗಿದೆಯೇ ಮತ್ತು ಯಾವ ಮುಂದಿನ ಹಾಪ್‌ಗೆ ತೋರಿಸುತ್ತದೆ.
ವಿನ್ಯಾಸ ಪರಿಶೀಲನೆಗೆ ಪ್ರಾಮಾಣಿಕ ಉತ್ತರ ಹಂಚಿಕೆಯ ಅವಲಂಬನೆಗಳ ಪಟ್ಟಿ: ಪ್ರವೇಶ ಸರ್ಕ್ಯೂಟ್, ಮೇಲ್ಮುಖ ಪ್ರದಾತ, ಸೌಲಭ್ಯ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗದಲ್ಲಿ ಯಾವುದೇ ಸ್ಥಿತಿ-ಸಂರಕ್ಷಕ ಸಾಧನ. ಸುರಂಗದ ಮೇಲಿನ ಸೆಷನ್ ತಾನು ಮೇಲೆ ಕುಳಿತಿಲ್ಲದ ಅವಲಂಬನೆಯನ್ನು ತೆಗೆಯಲಾರದು.
ಬೇರ್ಪಡಿಸಲು ಯೋಗ್ಯವಾದ ಮೂರು ನಿರ್ಧಾರಗಳು
ವಿನ್ಯಾಸ ಇವುಗಳನ್ನು ಬೆರೆಸಿದಾಗ, ಪ್ರತಿ ಅಡಚಣೆ ಸಂಭಾಷಣೆಯೂ ವೃತ್ತದಲ್ಲಿ ಸುತ್ತುತ್ತದೆ. ಮೊದಲು ಅವುಗಳನ್ನು ಕಾಗದದ ಮೇಲೆ ಬೇರ್ಪಡಿಸಿ, ನಂತರ ಪ್ರತಿಯೊಂದನ್ನೂ ನಿಜವಾಗಿ ಜಾರಿಗೊಳಿಸುವ ಸಾಧನಕ್ಕೆ ಜೋಡಿಸಿ.
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path diversity that was never there |
ಪ್ರತಿ ಸಾಲಿಗೂ ಬೇರೆ ಮಾಲೀಕ. ಮೊದಲನೆಯದು ಮಾತುಕತೆ, ಎರಡನೆಯದು ನಿಮ್ಮ ಸಾಧನಗಳಲ್ಲಿನ ಸಂರಚನೆ, ಮೂರನೆಯದು ಬಹುಪಾಲು ಬೇರೆಯವರ ಜಾಲ. ತಾನು ಸ್ಪರ್ಶಿಸುವ ಸಾಲನ್ನು ಹೆಸರಿಸುವ ಬದಲಾವಣೆ ವಿನಂತಿಯನ್ನು ಅನುಮೋದಿಸುವುದು BGP ಸಮಸ್ಯೆ ಎನ್ನುವ ವಿನಂತಿಗಿಂತ ಬಹಳ ಸುಲಭ.
ಯೋಜನೆ ಮಾಡಲು ಯೋಗ್ಯವಾದ ವೈಫಲ್ಯ ವಿಧಾನಗಳು
ಪೀರ್‌ನ ಸಾರಾಂಶ ಮಾರ್ಗವನ್ನು ಸ್ವೀಕರಿಸುವುದು ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಸ್ವಯಂ-ಉಂಟುಮಾಡಿದ ಗಾಯ. ಯಾರೋ ವಿನಿಮಯ ಸರಳಗೊಳಿಸಲು ಚಿಕ್ಕ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ ಘೋಷಿಸುತ್ತಾರೆ, ದೂರದ ಬದಿ ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಸುರಂಗದ ಹಿಂದೆ ಇಲ್ಲದ ಶ್ರೇಣಿಗಳ ಸಂಚಾರ ಸುರಂಗವನ್ನು ಅನುಸರಿಸಿ ಸಾಯುತ್ತದೆ. ನಿಖರವಾಗಿ ನಿರೀಕ್ಷಿತ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳ ಮೇಲೆ ಶೋಧಿಸಿ, ಅಥವಾ ಸರಿಯಾದ ಮಿತಿಗಳಿರುವ ಪ್ರಿಫಿಕ್ಸ್ ಪಟ್ಟಿ ಬಳಸಿ, ಮತ್ತು ಸೆಷನ್ ಅಚ್ಚುಕಟ್ಟಾಗಿ ಕಾಣುತ್ತದೆ ಎಂದು ಬರಿಯ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯನ್ನು ಎಂದಿಗೂ ಸ್ವೀಕರಿಸಬೇಡಿ.
ಹಿಂಪಡೆಯುವ ಸಮಯ ಎರಡನೆಯದು. ಪತ್ತೆ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಟೈಮರ್‌ಗಳು, ನೀವು ಸಕ್ರಿಯಗೊಳಿಸಿದ್ದರೆ BFD, ಸುರಂಗದ ಸತ್ತ ಪೀರ್ ಪತ್ತೆ ಮತ್ತು ದೂರದ ಬದಿ ಎಷ್ಟು ಬೇಗ ಘೋಷಣೆ ನಿಲ್ಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ. ಇರುವ ಸೆಷನ್‌ಗಳು ಪ್ರತ್ಯೇಕ ಸಮಸ್ಯೆ: ಹೊಸ ಮಾರ್ಗ ಹೊಸ ಸಂಪರ್ಕಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದು, ಆದರೆ ಸ್ಥಾಪಿತ TCP ಸೆಷನ್‌ಗಳು ಹಳೆಯದಾದ ವಿಳಾಸಗಳನ್ನು ಬಳಸುತ್ತಲೇ ಇರುತ್ತವೆ, ಮತ್ತು ಮಾರ್ಗದಲ್ಲಿನ ಸ್ಥಿತಿ-ಸಂರಕ್ಷಕ ಫೈರ್‌ವಾಲ್‌ಗಳು ಅಥವಾ NAT ಇನ್ನು ಹೊಂದಿಕೆಯಾಗದ ನಮೂದುಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬಹುದು. ಮಾರ್ಗ ಬದಲಾವಣೆ ಎಲ್ಲವನ್ನೂ ಸರಿಪಡಿಸುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಅಪ್ಲಿಕೇಶನ್ ಚೇತರಿಕೆಯನ್ನು ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳಲ್ಲಿ ಇರಿಸಿ.
ಮೂರನೆಯದು ಹಿಂತಿರುಗುವ ಮಾರ್ಗದ ಅಸಮಮಿತಿ. ಸಂಚಾರ ಸುರಂಗದ ಮೂಲಕ ಬಂದು ಅದನ್ನು ಸಾಗಿಸಲು ಎಂದಿಗೂ ಉದ್ದೇಶಿಸದ ಪ್ರದಾತ ಕೊಂಡಿಯ ಮೂಲಕ ಹಿಂತಿರುಗಬಹುದು, ಇದು ಏಕಮುಖ ಶಬ್ದ, ವಿಫಲ ಕೈಕುಲುಕುವಿಕೆ ಅಥವಾ ಉತ್ತರಗಳನ್ನು ಬಿಸಾಡುವ ಫೈರ್‌ವಾಲ್ ಆಗಿ ಕಾಣುತ್ತದೆ. ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ.
ಒಪ್ಪಂದದಲ್ಲಿ ಏನನ್ನು ಬರೆಯಬೇಕು, ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸಬೇಕು
ಅನುಮತಿಸಲಾದ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಲಿಖಿತವಾಗಿ ಕೇಳಿ: ಪ್ರತಿ ಶ್ರೇಣಿಯನ್ನು ರೂಪಿಸುವ ಅಧಿಕಾರ ಯಾರಿಗೆ ಇದೆ, ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಅನುಮತಿಸಲಾಗಿದೆಯೇ, ಮತ್ತು ಸುರಂಗ ಸೇವೆ ಯಾವ ವಿಳಾಸ ಕುಟುಂಬಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. RFC 8212 ಅದನ್ನು ಅನುಸರಿಸುವ ಅನುಷ್ಠಾನಗಳಲ್ಲಿ eBGPಗೆ ಸ್ಪಷ್ಟ ಆಮದು ಮತ್ತು ರಫ್ತು ನೀತಿಯನ್ನು ನಿರೀಕ್ಷೆಯನ್ನಾಗಿ ಮಾಡಿತು, ಆದ್ದರಿಂದ ಇನ್ನೂ ಸೂಚ್ಯ ಎಲ್ಲವನ್ನೂ-ಸ್ವೀಕರಿಸು ಆಚರಣೆಯನ್ನು ಅವಲಂಬಿಸಿರುವ ಪೀರ್ ಪ್ರಶ್ನಿಸಲು ಯೋಗ್ಯ.
ನಂತರ ರೇಖಾಚಿತ್ರದಿಂದ ಅಲ್ಲ, ಸಾಧನದಿಂದ ಪರಿಶೀಲಿಸಿ. FRR ಶೈಲಿಯ ರೌಟರ್‌ಗಳಲ್ಲಿ ಉಪಯುಕ್ತ ಆದೇಶಗಳು:
show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16
ಮಾರ್ಗ ಕೋಷ್ಟಕ ನಿಮಗೆ ನೀಡಲಾಗದ ಎರಡು ಅವಲೋಕನಗಳನ್ನು ಸೇರಿಸಿ. ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಟ್ ಆದ ಪ್ಯಾಕೆಟ್‌ಗಳು ನಿಜವಾಗಿ ಯಾವ ವಿಳಾಸವನ್ನು ಗುರಿಯಾಗಿಸುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಲು ಹೊರ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ, ಉದಾಹರಣೆಗೆ tcpdump -ni eth0 udp port 51820 WireGuard ಸುರಂಗಕ್ಕೆ, ಅಥವಾ IPsecಗೆ ESP ಶೋಧಕ. ನಂತರ ಪೀರ್‌ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸದ ಕಡೆಗೆ ಟ್ರೇಸ್ ಮಾಡಿ ಮತ್ತು ಸುರಂಗದ ಒಳಗಿನ ಟ್ರೇಸ್‌ನೊಂದಿಗೆ ಹಾಪ್‌ಗಳನ್ನು ಹೋಲಿಸಿ; ಎರಡೂ ಒಂದೇ ಪ್ರದಾತ ಸರಪಳಿಯನ್ನು ಅನುಸರಿಸಿದರೆ, ನಿಮ್ಮ ಪುನರುಕ್ತಿ ಜಾಲದಲ್ಲಲ್ಲ, ಮಾರ್ಗ ನೀತಿಯಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ.
ಕೊನೆಯದಾಗಿ, ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಹಿಂಪಡೆಯುವಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ. ನಿರ್ವಹಣಾ ಕಿಟಕಿಯಲ್ಲಿ ಸುರಂಗವನ್ನು ಇಳಿಸಿ, ಪ್ರಿಫಿಕ್ಸ್ ಎಷ್ಟು ಕಾಲ ಸ್ಥಾಪಿತವಾಗಿರುತ್ತದೆ, ಇರುವ ಸೆಷನ್‌ಗಳಿಗೆ ಏನಾಗುತ್ತದೆ ಮತ್ತು ದೂರದ ಬದಿ ನೀವು ನಿಜವಾಗಿ ಸ್ವೀಕರಿಸುವ ಮಾರ್ಗಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತದೆಯೇ ಎಂದು ದಾಖಲಿಸಿ. ಆ ಅಭ್ಯಾಸವು ಯಾವುದೇ ರೇಖಾಚಿತ್ರಕ್ಕಿಂತ ವಿನ್ಯಾಸದ ಬಗ್ಗೆ ಹೆಚ್ಚು ಹೇಳುತ್ತದೆ.
ಮಾರ್ಗ ಅನುಮತಿಯಲ್ಲ. ವಿನಿಮಯ ಮಾಡಲು ಒಪ್ಪುವ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ಯಾವ ಬಳಕೆದಾರರು ಸುರಂಗದ ಹಿಂದಿನ ಯಾವ ಸೇವೆಯನ್ನು ತಲುಪಬಹುದು ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ದೃಢೀಕರಣ, ಅನುಮತಿಸಲಾದ ಸೇವೆಗಳು ಮತ್ತು ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್‌ಗಳನ್ನು ಅವು ಇದ್ದಲ್ಲೇ ಇರಿಸಿ. ತಲುಪಬಲ್ಲ ಪೀರ್ ಕೂಡ ಅಪರಿಮಿತ ಟ್ರಾನ್ಸಿಟ್‌ಗೆ ಅಥವಾ ಅನಿಯಂತ್ರಿತ ವಿಳಾಸಗಳನ್ನು ರೂಪಿಸಲು ಅನುಮತಿಯಲ್ಲ, ಮತ್ತು ಅಂತಹ ಅಧಿಕಾರ ಒಪ್ಪಂದದಲ್ಲಿ ವಾಣಿಜ್ಯ ಪ್ರಶ್ನೆಯಾಗಿ ಇರಬೇಕು, BGP ನೀತಿ ಸಾಲಿನಲ್ಲಿ ಅಲ್ಲ.
- ಪ್ರತಿ ಬದಿ ರೂಪಿಸಬಹುದಾದ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಮತ್ತು ಎಂದಿಗೂ ಸ್ವೀಕರಿಸಬಾರದ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಹೆಸರಿಸಿ.
- ಸುರಂಗದಲ್ಲಿ MSS ಮಿತಿಗೊಳಿಸಿ ಮತ್ತು ದೊಡ್ಡ ನವೀಕರಣಗಳು ನಿಜವಾಗಿ ಬರುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
- ಹಂಚಿಕೆಯ ಅಂಡರ್‌ಲೇ ಅವಲಂಬನೆಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ, ಸುರಂಗಗಳ ಸಂಖ್ಯೆಯನ್ನಲ್ಲ.
- ನಿಜವಾದ ಹಿಂಪಡೆಯುವಿಕೆಯನ್ನು ಅಳೆಯಿರಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಗಮನಿಸಿ.