L3VPN ಹಸ್ತಾಂತರ: ಖಾಸಗಿ ಮಾರ್ಗಗಳು, ಡೀಫಾಲ್ಟ್, ಅಥವಾ ಪೂರ್ಣ ಕೋಷ್ಟಕ?
CE ಏನು ಸ್ವೀಕರಿಸಬೇಕು ಎಂಬುದು ಹೊಂದಿಕೆಯಾಗದ ಸಂಚಾರ ಎಲ್ಲಿಂದ ನಿರ್ಗಮಿಸುತ್ತದೆ ಎಂಬುದರಿಂದ ನಿರ್ಧಾರವಾಗುತ್ತದೆ. ಹಸ್ತಾಂತರವನ್ನು ಕ್ರಮವಾಗಿ ಪರಿಶೀಲಿಸಿ, ವೈಫಲ್ಯದ ಸಂದರ್ಭವನ್ನು ಒಪ್ಪಿ, ನಂತರವೇ ಕೋಷ್ಟಕದ ಗಾತ್ರದ ಬಗ್ಗೆ ವಾದಿಸಿ.
ನಿಮ್ಮ ಸರ್ಕ್ಯೂಟ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, VRF ಸಂರಚಿಸಲಾಗಿದೆ, ಮತ್ತು ಪೂರೈಕೆದಾರರು ಉಳಿದ ವಿನ್ಯಾಸವನ್ನು ನಿರ್ಧರಿಸುವ ಸಣ್ಣ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುತ್ತಾರೆ: ಗ್ರಾಹಕ ತುದಿ ಏನನ್ನು ಸ್ವೀಕರಿಸಬೇಕು? ಮೂರು ಉತ್ತರಗಳು ಸಾಮಾನ್ಯ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಲೇಬಲ್ ಸ್ಟಾಕ್ ಇರುವುದರಿಂದ ಉದ್ಭವಿಸುವುದಿಲ್ಲ. ಅವು ಸಂಚಾರವು ಶಾಖೆಯಿಂದ ಎಲ್ಲಿಂದ ನಿರ್ಗಮಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತ ಸೇವಾ ನಿರ್ಧಾರಗಳು.
ಹಸ್ತಾಂತರವನ್ನು ಕ್ರಮವಾಗಿ ಪರಿಶೀಲಿಸುವುದು ಇದನ್ನು ಸರಿಯಾಗಿ ಮಾಡಲು ಅಗ್ಗವಾದ ದಾರಿ. ಯಾವುದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗದ ಸಂಚಾರಕ್ಕೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದರಿಂದ ನೀವು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ, ನಂತರ ಖಾಸಗಿ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಮತ್ತು ಅವುಗಳ ವೈಫಲ್ಯ ವರ್ತನೆಯನ್ನು ಬರೆಯುತ್ತೀರಿ, ನಂತರವೇ ಎಷ್ಟು ದೊಡ್ಡ ಫೀಡ್ ಅನ್ನು ಹೊತ್ತುಕೊಳ್ಳಲು ಸಿದ್ಧರಿದ್ದೀರಿ ಎಂದು ಚರ್ಚಿಸುತ್ತೀರಿ.
ಯಾರೂ ಯೋಜಿಸದ ಸಂಚಾರದಿಂದ ಪ್ರಾರಂಭಿಸಿ
ಯಾವುದೇ ಪೂರ್ವಪ್ರತ್ಯಯ ಪಟ್ಟಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಮೊದಲು ಒಂದು ಪ್ರಶ್ನೆ ಕೇಳಿ: ಪ್ಯಾಕೆಟ್ ಯಾವುದೇ ಖಾಸಗಿ ಮಾರ್ಗಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ ಅದು ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕು? ತನ್ನದೇ ಆದ ಇಂಟರ್ನೆಟ್ ಸರ್ಕ್ಯೂಟ್ ಇರುವ ಶಾಖೆ ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಥಳೀಯ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯ ವೆಬ್ ಸಂಚಾರ ಸ್ಥಳೀಯ ಫೈರ್ವಾಲ್ ಮೂಲಕ ಹೊರಟು ಪೂರೈಕೆದಾರರನ್ನು ಎಂದಿಗೂ ಸ್ಪರ್ಶಿಸುವುದಿಲ್ಲ. ಆ ವಿನ್ಯಾಸದಲ್ಲಿ VPN ಕೇವಲ ದೂರದ ಖಾಸಗಿ ಸೈಟ್ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾದ ಪೂರ್ವಪ್ರತ್ಯಯಗಳು ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ.
ಕೇಂದ್ರೀಯ ನಿರ್ಗಮನವನ್ನು ಬಳಸುವಂತೆ ಉದ್ದೇಶಿಸಿದ ಶಾಖೆ ವಿರುದ್ಧ ಸಂದರ್ಭ. ಅಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಸೇವೆಯೊಳಗೆ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಪೂರೈಕೆದಾರರು ಅಥವಾ ಕೇಂದ್ರೀಯ ಸೈಟ್ ಮುಂದುವರಿಕೆ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಮತ್ತು ಯಾವುದೇ ಅನುವಾದವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಆ ಮಾಲೀಕರು ಇಲ್ಲದೆ "VPN ಗೆ ಡೀಫಾಲ್ಟ್" ಎಂದರೆ ಹೆಸರುಗಳನ್ನು ಪರಿಹರಿಸುವ ಆದರೆ ಯಾವುದನ್ನೂ ತಲುಪದ ಶಾಖೆ ಉಂಟಾಗುತ್ತದೆ.
ಎರಡು ವಿನ್ಯಾಸಗಳು ಮಾರ್ಗ ವೈಫಲ್ಯ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನ, ಅದಕ್ಕಾಗಿಯೇ ಊಹಿಸುವುದು ದುಬಾರಿ. ಸ್ಥಳೀಯ ಡೀಫಾಲ್ಟ್ನೊಂದಿಗೆ, ಕಳೆದುಹೋದ ಖಾಸಗಿ ಮಾರ್ಗ ಆ ಸಂಚಾರವನ್ನು ಇಂಟರ್ನೆಟ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಫೈರ್ವಾಲ್ ಅದನ್ನು ಬಿಸಾಡುತ್ತದೆ ಅಥವಾ, ಕೆಟ್ಟದಾಗಿ, ನೀವು ಉದ್ದೇಶಿಸದ ಯಾವುದೋ ಉತ್ತರಿಸುತ್ತದೆ. ಕೇಂದ್ರೀಯ ಡೀಫಾಲ್ಟ್ನೊಂದಿಗೆ, ಅದೇ ನಷ್ಟ ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ ಮತ್ತು ಟಿಕೆಟ್ "ಇಡೀ ಶಾಖೆ ಕೆಳಗಿದೆ" ಎಂದು ಬರುತ್ತದೆ. ಯಾವುದೇ ವೈಫಲ್ಯ ತನ್ನಷ್ಟಕ್ಕೇ ತಪ್ಪಲ್ಲ, ಆದರೆ ನೀವು ಮಾರಿದ ಸೇವೆಗೆ ಒಂದೇ ಸರಿಹೊಂದುತ್ತದೆ, ಮತ್ತು BGP ಸಂರಚನೆ ಮಾತ್ರ ಯಾವುದನ್ನು ನಿರ್ಮಿಸಿದಿರಿ ಎಂದು ಹೇಳುವುದಿಲ್ಲ.
ಖಾಸಗಿ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಅವುಗಳ ವೈಫಲ್ಯ ಸಂದರ್ಭದೊಂದಿಗೆ ಬರೆಯಿರಿ
ಶಾಖೆ ತಲುಪಬೇಕಾದ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುವು ಸಂಕ್ಷೇಪಿಸಲಾಗಿದೆ ಎಂದು ಗಮನಿಸಿ. ಒಂದು ಬಿಟ್ ಮಿತಿಮೀರಿ ವಿಶಾಲವಾದ ಸಮುಚ್ಚಯವು ಅಜ್ಞಾತ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು VPN ಗೆ ಎಳೆಯುತ್ತದೆ, ಇದು ದೂರದ ಬದಿ ಅವುಗಳನ್ನು ನಿಜವಾಗಿ ಹೊಂದಿ ಮುಂದುವರಿಸಿದರೆ ಮಾತ್ರ ಸರಿ.
ನಂತರ ಖಾಸಗಿ ಸೇವೆ ವಿಫಲವಾದಾಗ ಉದ್ದೇಶಿತ ವರ್ತನೆಯನ್ನು ವಿವರಿಸಿ. ಉಳಿಸಿಕೊಂಡ ತಿರಸ್ಕಾರ ಮಾರ್ಗವು ಸಂಚಾರವನ್ನು ಅನಧಿಕೃತ ಮಾರ್ಗದಿಂದ ದೂರವಿಡುತ್ತದೆ ಮತ್ತು ಸ್ವಚ್ಛ, ನಿರೀಕ್ಷಿತ ವಿರಾಮವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ತೇಲುವ ಡೀಫಾಲ್ಟ್ ಬ್ಯಾಕಪ್ ಮಾರ್ಗಕ್ಕೆ ಬದಲಾಗುವ ಮೂಲಕ ಲಭ್ಯತೆಯನ್ನು ಕಾಪಾಡಬಹುದು, ಆದರೆ ಆ ಬ್ಯಾಕಪ್ ಮಾರ್ಗಕ್ಕೆ ಆ ಸಂಚಾರವನ್ನು ಸಾಗಿಸಲು ಅನುಮತಿ ಇದ್ದರೆ ಮಾತ್ರ.
ಲಭ್ಯತೆ ಮತ್ತು ಅನುಮತಿಸಿದ ಬ್ಯಾಕಪ್ ಅನ್ನು ಹಸ್ತಾಂತರ ದಾಖಲೆಯಲ್ಲಿ ಎರಡು ಪ್ರತ್ಯೇಕ ಅವಶ್ಯಕತೆಗಳಾಗಿ ಇರಿಸಿ. ಅವುಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವ ತಂಡಗಳು ಒಪ್ಪಿದ ನೀತಿ ಜಾರಿಯಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವ ಬದಲು ಶಾಖೆ ವಿಫಲವಾಗಬೇಕಿತ್ತೇ ಎಂದು ವಾದಿಸುತ್ತವೆ.
CE ನಿಜವಾಗಿ ಏನನ್ನು ಸ್ಥಾಪಿಸಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ
ಸಂರಚನಾ ಉದ್ದೇಶ ಮತ್ತು ಮುಂದುವರಿಕೆ ಸ್ಥಿತಿ ಸಾಕಷ್ಟು ಬಾರಿ ಭಿನ್ನವಾಗುವುದರಿಂದ ಪರಿಶೀಲನೆ ಘಟನಾ ವಿಮರ್ಶೆಯಲ್ಲ, ಹಸ್ತಾಂತರದಲ್ಲೇ ಸೇರಬೇಕು. IOS-XE ಗ್ರಾಹಕ ತುದಿಯಲ್ಲಿ ಕೆಳಗಿನ ಮೂರು ಆದೇಶಗಳು ಮೂರು ವಿಭಿನ್ನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ: ಏನು ನೀಡಲಾಯಿತು, ಏನು ಸ್ವೀಕರಿಸಲಾಯಿತು ಮತ್ತು ನಿಜವಾಗಿ ಏನು ಬಳಕೆಯಾಗುತ್ತಿದೆ.
show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0
ಮೂರನ್ನೂ ಹಸ್ತಾಂತರದ ದಿನವೇ ಚಲಾಯಿಸಿ, ಒಂದು ತಿಂಗಳ ನಂತರವಲ್ಲ, ಏನು ಒಪ್ಪಲಾಯಿತು ಎಂದು ಯಾರಿಗಾದರೂ ಇನ್ನೂ ನೆನಪಿರುವಾಗ. ಮೊದಲ ಔಟ್ಪುಟ್ soft-reconfiguration inbound ಅಥವಾ ಸಂಗ್ರಹಿಸಿದ route refresh ಅನ್ನು ಅವಲಂಬಿಸಿದೆ; ಎರಡೂ ಇಲ್ಲದೆ CE ಏನನ್ನು ತಿರಸ್ಕರಿಸಿತು ಎಂದು ತೋರಿಸಲಾಗದು. ಎರಡನೆಯದು ನೀತಿಯ ನಂತರ ಸ್ವೀಕರಿಸಿದ ಮತ್ತು ಉತ್ತಮ ಮಾರ್ಗಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಮೂರನೆಯದು ಡೀಫಾಲ್ಟ್ ನಿಜವಾಗಿ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಅದು ಇಡೀ ಹಸ್ತಾಂತರದಲ್ಲಿ ಅತ್ಯಂತ ಉಪಯುಕ್ತ ಸಾಲು.
ಸೈಟ್ ದ್ವಿ-ಸಂಪರ್ಕ ಹೊಂದಿದ್ದರೆ ಎರಡನೇ CE ಯಲ್ಲಿ ಅದೇ ಪರಿಶೀಲನೆಗಳನ್ನು ಚಲಾಯಿಸಿ. ಎರಡು ತುದಿಗಳ ನಡುವಿನ ಅಸಮ್ಮಿತ ಸ್ವೀಕೃತಿ "ಒಂದು ಸರ್ವರ್ನಿಂದ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಇನ್ನೊಂದರಿಂದ ಇಲ್ಲ" ಎಂಬುದರ ಸಾಮಾನ್ಯ ಕಾರಣ, ಮತ್ತು ಸಮ್ಮಿತೀಯವಾಗಿ ಕಾಣುವ ಸಂರಚನಾ ವ್ಯತ್ಯಾಸದಲ್ಲಿ ಅದು ಕಾಣುವುದಿಲ್ಲ.
ದೊಡ್ಡ ಫೀಡ್ ಅನ್ನು ಊಹಿಸದೆ ಅರ್ಹತೆ ನಿರ್ಧರಿಸಿ
ಕೆಲವೊಮ್ಮೆ ಗ್ರಾಹಕರಿಗೆ VRF ಒಳಗೆ ಇಂಟರ್ನೆಟ್ ಮಾರ್ಗ ಮಾಹಿತಿ ನಿಜವಾಗಿಯೂ ಬೇಕು — ನೀತಿ ಮಾರ್ಗದರ್ಶನಕ್ಕಾಗಿ ಅಥವಾ ಪೂರ್ವಪ್ರತ್ಯಯದಿಂದ ನಿರ್ದೇಶಿಸುವ ಕೇಂದ್ರೀಯ ನಿರ್ಗಮನಕ್ಕಾಗಿ. ಅದು ಹೇಳಬೇಕಾದ, ವ್ಯಾಪ್ತಿ ನಿಗದಿಪಡಿಸಬೇಕಾದ ಮತ್ತು ಬೆಲೆ ಹಾಕಬೇಕಾದ ಅವಶ್ಯಕತೆ, ಗುಪ್ತ ಡೀಫಾಲ್ಟ್ ಅಲ್ಲ. ಅದರೊಂದಿಗೆ RIB ಮತ್ತು FIB ಗಾಗಿ ಮೆಮೊರಿ, ನವೀಕರಣಗಳಿಗೆ CPU, ಫಿಲ್ಟರ್ ನಿರ್ವಹಣೆ ಮತ್ತು ಪರಿಣಾಮವಾಗಿ ಉಂಟಾಗುವ ಕೋಷ್ಟಕದ ಮಾಲೀಕರು ಬರುತ್ತಾರೆ.
ಸಾಮರ್ಥ್ಯದ ವಾದಗಳು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ತಪ್ಪಾಗುತ್ತವೆ. ಪೂರ್ಣ ಕೋಷ್ಟಕ VRF ಒಳಗೆ ನಿಷೇಧಿತವಲ್ಲ, ಉಚಿತವೂ ಅಲ್ಲ. ಹಾಗೆಯೇ, ಇಂದಿನ ವೆಚ್ಚವನ್ನು ಹಳೆಯ ಮಾರ್ಗ ಸಂಖ್ಯೆಯಿಂದ ಊಹಿಸಲಾಗದು, ಮತ್ತು ಚಿಕ್ಕ ಲೇಬಲ್ ಹಂಚಿಕೆ ಮಾರ್ಗಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ವೆಚ್ಚವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ.
BGP/MPLS IP VPN ವಿವರಣೆ VPN ಸೇವೆಯ ಪಕ್ಕದಲ್ಲಿ ಹಲವು ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಚರ್ಚಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಗ್ರಾಹಕನಿಗೂ ಪೂರ್ಣ ಕೋಷ್ಟಕ ಅಥವಾ ಡೀಫಾಲ್ಟ್ ಕಡ್ಡಾಯ ಎಂದು ಘೋಷಿಸುವುದಿಲ್ಲ, ಮತ್ತು "ಪ್ರಮಾಣಿತ ಅಭ್ಯಾಸ" ಎಂಬ ಹೇಳಿಕೆ ಬಂದಾಗ ತೋರಿಸಲು ಯೋಗ್ಯವಾದ ಭಾಗ ಅದೇ: RFC 4364.
ಹಸ್ತಾಂತರವನ್ನು ಮುಚ್ಚಲು ಜಾಹೀರಾತು ಮಾಡಿದ ಗಣ, ಸ್ವೀಕರಿಸಿದ ಗಣ ಮತ್ತು ಆಯ್ಕೆ ಮಾಡಿದ ಗಣವನ್ನು ಒಪ್ಪಿದ ನಿರ್ಗಮನ ನೀತಿಯ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸಿ, ಮತ್ತು ಒಂದು ಖಾಸಗಿ ಗಮ್ಯಸ್ಥಾನ, ಒಂದು ಉದ್ದೇಶಿತ ಸಾರ್ವಜನಿಕ ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಒಂದು ಮಾರ್ಗ ನಷ್ಟದ ಸಂದರ್ಭವನ್ನು ಪರೀಕ್ಷಿಸಿ. ಆ ಮೂರು ಪರೀಕ್ಷೆಗಳ ಸಹಿ ಮಾಡಿದ ದಾಖಲೆ ಹೆಚ್ಚಿನ ಜಾಲಗಳು ಏನು ಮಾಡುತ್ತವೆ ಎಂಬ ಯಾವುದೇ ಹೇಳಿಕೆಗಿಂತ ಹೆಚ್ಚು ವಾದಗಳನ್ನು ಬಗೆಹರಿಸುತ್ತದೆ.