ಕೋರ್ನಲ್ಲಿ VPNv4 ಗೆ MPLS ಬೇಕೇ? ಕಡ್ಡಾಯವಲ್ಲ
BGP VPNv4 ಮಾರ್ಗ ವಿತರಣಾ ಸಂದರ್ಭವನ್ನು ಮಾತುಕತೆ ಮಾಡುತ್ತದೆ, ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಹಾದಿಯನ್ನಲ್ಲ. ಆಮದು, ಮುಂದಿನ ಹಾಪ್ ಪರಿಹಾರ ಮತ್ತು ನೀವು ನಡೆಸಬಹುದಾದ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಅನ್ನು ಬೇರ್ಪಡಿಸಿ.
ಎರಡು ರೂಟರ್ಗಳ ನಡುವೆ VPNv4 ವಿಳಾಸ ಕುಟುಂಬವನ್ನು ಆನ್ ಮಾಡುವುದು ಮಾರ್ಗ ವಿತರಣಾ ಸಂದರ್ಭವನ್ನು ಮಾತ್ರ ಸೃಷ್ಟಿಸುತ್ತದೆ, ಅದಕ್ಕಿಂತ ಹೆಚ್ಚೇನಿಲ್ಲ. ಅದು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಹಾದಿಯನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ ಮತ್ತು ಗ್ರಾಹಕ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ದೂರದ ಅಂತ್ಯ ಬಿಂದುವಿಗೆ ಯಾವ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಒಯ್ಯುತ್ತದೆ ಎಂದು ಹೇಳುವುದಿಲ್ಲ. ಈ ಎರಡು ಸಂಗತಿಗಳನ್ನು ಬೇರ್ಪಡಿಸಿದಾಗ, «ಕೋರ್ನಲ್ಲಿ ಇದಕ್ಕೆ MPLS ಬೇಕೇ» ಎಂಬ ಪ್ರಶ್ನೆ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಬೆಂಬಲಿಸುವ ಡೇಟಾ ಪ್ಲೇನ್ ಬಗ್ಗೆ ಕಿರಿದಾದ ಮತ್ತು ಉತ್ತರಿಸಬಹುದಾದ ಪ್ರಶ್ನೆಯಾಗುತ್ತದೆ.
ವಿಳಾಸ ಕುಟುಂಬ ನಿಜವಾಗಿ ಏನನ್ನು ಮಾತುಕತೆ ಮಾಡುತ್ತದೆ
ಬಹುಪ್ರೋಟೋಕಾಲ್ BGP AFI 1 ಮತ್ತು SAFI 128 ಅಡಿಯಲ್ಲಿ VPNv4 ನೆಟ್ವರ್ಕ್ ಪದರದ ತಲುಪುವಿಕೆ ಮಾಹಿತಿಯನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ನಮೂದು ಮಾರ್ಗ ಭೇದಕವನ್ನು ಪೂರ್ವಪ್ರತ್ಯಯ ಮತ್ತು ಲೇಬಲ್ನೊಂದಿಗೆ ಜೋಡಿಸುತ್ತದೆ. ಸೆಷನ್ ಎರಡೂ ಪಕ್ಷಗಳು ಆ ಮಾಹಿತಿಯನ್ನು ಎನ್ಕೋಡ್ ಮತ್ತು ಡಿಕೋಡ್ ಮಾಡಬಲ್ಲವು ಎಂದು ಮಾತುಕತೆ ಮಾಡುತ್ತದೆ. ಅದು ಮಾತುಕತೆ ಮಾಡದಿರುವುದು ಡೇಟಾ ಪ್ಲೇನ್. ಈ ಪ್ಯಾರಾಗ್ರಾಫ್ನ ನಂತರದ ಎಲ್ಲವೂ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆಗೆ ಸಂಬಂಧಿಸಿದೆ, ಮತ್ತು ಅದರ ಯಾವುದೂ ಸೆಷನ್ ಏಳುವುದರಿಂದ ನಿರ್ಧಾರವಾಗುವುದಿಲ್ಲ.
ಆದ್ದರಿಂದ ಯಶಸ್ವಿ ಸೆಷನ್ ನಿಯಂತ್ರಣ ಪ್ಲೇನ್ ಸಾಮರ್ಥ್ಯದ ಸಾಕ್ಷಿ, ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆಯದ್ದಲ್ಲ. ರೂಟರ್ ಸಾವಿರಾರು VPNv4 ನಮೂದುಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಂಡು ಪ್ರತಿ ಗ್ರಾಹಕ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕೈಬಿಡಬಹುದು, ಮತ್ತು ಆರಂಭದಲ್ಲೇ ಎರಡು ವೈಫಲ್ಯ ವರ್ಗಗಳು ಗೊಂದಲಕ್ಕೀಡಾಗುವುದಕ್ಕೆ ಇದೇ ಕಾರಣ.
NLRI ಯಲ್ಲಿನ ಲೇಬಲ್ ಗಮನಿಸಿ. ಇದು ಸೇವಾ ಲೇಬಲ್, VRF ಒಳಗಿನ ಪೂರ್ವಪ್ರತ್ಯಯಕ್ಕೆ ಬಂಧಿಸಲ್ಪಟ್ಟಿದೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ನಿರ್ಗಮನ ಅಂತ್ಯ ಬಿಂದುವನ್ನು ತಲುಪಿದಾಗ ಅದಕ್ಕೆ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಪಾತ್ರವಿದೆ. ಯಾವುದೇ ಸಂಕ್ರಮಣ ಸಾಧನ ಅದನ್ನು ಓದುತ್ತದೆಯೇ ಎಂಬುದು ಪ್ರತ್ಯೇಕ ವಿನ್ಯಾಸ ನಿರ್ಧಾರ.
ಸ್ವೀಕೃತಿ, ಆಮದು ಮತ್ತು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆ ಮೂರು ಹಂತಗಳು
ಮಾರ್ಗವನ್ನು ಸ್ವೀಕರಿಸುವುದು, ಅದನ್ನು ಬಳಸಲು ಅನುಮತಿ ಇರುವುದು ಮತ್ತು ಅದರೊಂದಿಗೆ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಲು ಸಾಧ್ಯವಾಗುವುದನ್ನು ಸಾಧನದ ವಿವಿಧ ಭಾಗಗಳು ನಿರ್ವಹಿಸುತ್ತವೆ. BGP ಕೇಳಿದ್ದನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ; ಆಮದು ನೀತಿ ಮತ್ತು ಮಾರ್ಗ ಗುರಿ ಹೊಂದಿಕೆ ಯಾವ VRF ಅದನ್ನು ಪರಿಗಣಿಸಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ; ನಂತರ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಪ್ಲೇನ್ ಘೋಷಿತ ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಅದು ನಿಜವಾಗಿ ತಂತಿಗೆ ತಳ್ಳಬಹುದಾದ ಯಾವುದೋ ಒಂದಕ್ಕೆ ಪರಿಹರಿಸಬೇಕು.
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
ಅತ್ಯಂತ ಆಶ್ಚರ್ಯಕರ ವೈಫಲ್ಯಗಳು ವಾಸಿಸುವುದು ಈ ಮಧ್ಯ ಹಂತದಲ್ಲೇ. ಮಾರ್ಗವು BGP ಕೋಷ್ಟಕದಲ್ಲಿ ಇರಬಹುದು, ಮಾನ್ಯವಾಗಿರಬಹುದು ಮತ್ತು ಅತ್ಯುತ್ತಮವೂ ಆಗಿರಬಹುದು, ಆದರೆ VRF ಮಾರ್ಗ ಕೋಷ್ಟಕ ಖಾಲಿಯಾಗಿ ಉಳಿಯುತ್ತದೆ ಏಕೆಂದರೆ ಯಾವುದೇ ಮಾರ್ಗ ಗುರಿ ಆಮದು ಪಟ್ಟಿಗೆ ಹೊಂದಿಕೆಯಾಗಲಿಲ್ಲ. ಪ್ರೋಟೋಕಾಲ್ ದೋಷ ಸಂಭವಿಸದ ಕಾರಣ ಯಾವುದೂ ಪ್ರೋಟೋಕಾಲ್ ದೋಷವನ್ನು ದಾಖಲಿಸುವುದಿಲ್ಲ.
ಕೊನೆಯ ಹಂತವು ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಬೆಂಬಲ ಕಾಣುವ ಸ್ಥಳ. ಅಂಡರ್ಲೇನಲ್ಲಿ ತಲುಪಬಹುದಾದ ಮುಂದಿನ ಹಾಪ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ VPN ಸೇವಾ ಸಾಗಣೆಯಾಗಿ ಪರಿಹರಿಸಲ್ಪಡುವುದಿಲ್ಲ, ಮತ್ತು ಸಾಧನವು ನಿರ್ದಿಷ್ಟ ಸುರಂಗ ಪ್ರಕಾರ, ನಿರ್ದಿಷ್ಟ ಲೇಬಲ್ ಕಾರ್ಯಾಚರಣೆ ಅಥವಾ ಎರಡನ್ನೂ ಬೇಡಬಹುದು. ಪರಿಹಾರ ಸ್ಥಿತಿಯನ್ನು ಓದುವುದು ಮಾರ್ಗ ಸಂಖ್ಯೆಯನ್ನು ಓದುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮಾಹಿತಿಪೂರ್ಣ.
IP ಕೋರ್ ಎಂದೂ ಸ್ವಿಚ್ ಮಾಡದ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಸಾಗಿಸಬಹುದು
ಉಳಿಸಿಕೊಳ್ಳಲು ಯೋಗ್ಯವಾದ ವ್ಯತ್ಯಾಸ «ಕೋರ್ MPLS ಚಲಾಯಿಸುವುದಿಲ್ಲ» ಮತ್ತು «ಸೇವೆಯಲ್ಲಿ ಎಲ್ಲಿಯೂ ಲೇಬಲ್ ಇಲ್ಲ» ನಡುವಿನದು. ಇವು ಬೇರೆ ಬೇರೆ ಪ್ರತಿಪಾದನೆಗಳು, ಮತ್ತು ಮೊದಲನೆಯದು ಮಾತ್ರ ಸಂಕ್ರಮಣ ಸಾಧನಗಳ ಬಗ್ಗೆ. RFC 4023 IP ಅಥವಾ GRE ಸುರಂಗಗಳ ಮೂಲಕ MPLS ಸಾಗಿಸುವಿಕೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಕಾರ್ಯವಿಧಾನವೇ ಸಂಪೂರ್ಣ IP ಕೋರ್ನಲ್ಲಿ ಎರಡನೆಯ ಪ್ರತಿಪಾದನೆಯನ್ನು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningfulಸಂಕ್ರಮಣ ರೂಟರ್ಗಳು ಹೊರಗಿನ IP ಗಮ್ಯಸ್ಥಾನದ ಆಧಾರದಲ್ಲಿ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತವೆ ಮತ್ತು ಗ್ರಾಹಕ ಪೂರ್ವಪ್ರತ್ಯಯಗಳಾಗಲೀ ಸ್ಥಳೀಯ ಲೇಬಲ್ ಸ್ವಿಚಿಂಗ್ ಆಗಲೀ ಅಗತ್ಯವಿಲ್ಲ. ದೂರದ ತುದಿಯಲ್ಲಿ ಹೊರಗಿನ ಸುರಂಗ ತೆಗೆದುಹಾಕಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಸೇವಾ ಲೇಬಲ್ ತನ್ನ ಕೆಲಸವನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಕೋರ್ ಅಪಾರದರ್ಶಕ ಪೇಲೋಡ್ ಅನ್ನು ಸಾಗಿಸಿತು, ಮತ್ತು IP ನೆಟ್ವರ್ಕ್ ಯಾವುದರಲ್ಲಿ ಉತ್ತಮವೋ ಅದು ನಿಖರವಾಗಿ ಅದೇ.
ಈ ವಿನ್ಯಾಸ ನಿಮಗೆ ನೀಡದಿರುವುದು ಸಾರ್ವತ್ರಿಕ ಖಾತರಿ. ಪ್ರತಿ ರೂಟರ್ ಪ್ರತಿ VPNv4 ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಯಾವುದೇ GRE ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಪರಿಹರಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಇದು ಸಾಕ್ಷಿಯಲ್ಲ, ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಸ್ಥಳೀಯ MPLS ಸಂರಚನೆಯನ್ನು ಅಳಿಸಲು ಕಾರಣವೂ ಅಲ್ಲ. ಇದು ಸಾರ್ವತ್ರಿಕ ಪ್ರತಿಪಾದನೆಗೆ ಪ್ರತಿ ಉದಾಹರಣೆ, ಮತ್ತು ಪ್ರಾಯೋಗಿಕ ಪ್ರಶ್ನೆ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗೆ ಸ್ಥಳೀಯವಾಗಿ ಉಳಿಯುತ್ತದೆ. ಆ ಪ್ರಶ್ನೆಯನ್ನು ಪ್ರೋಟೋಕಾಲ್ ನಿಯಮವಾಗಿ ಅಲ್ಲ, ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಮಿತಿಯಾಗಿ ದಾಖಲಿಸಿ.
ಬಾಕ್ಸ್ನಲ್ಲಿ ಸರಪಳಿ ಮುರಿಯುವವರೆಗೆ ನಡೆಯಿರಿ
ಸ್ವೀಕರಿಸಿದ ಮಾರ್ಗದಿಂದ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ವಿಫಲವಾಗುವ ಮೊದಲ ಹಂತದಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಹಿಂದಿನ ಹಂತ ಮುರಿದಿರುವಾಗ ಮುಂದಿನ ಹಂತಗಳನ್ನು ರೋಗನಿರ್ಣಯ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸಾಮಾನ್ಯ ಅನುಷ್ಠಾನದಲ್ಲಿ ನಾಲ್ಕು ಆಜ್ಞೆಗಳು ಅದರ ಬಹುಪಾಲನ್ನು ಒಳಗೊಳ್ಳುತ್ತವೆ.
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_Aಅವುಗಳನ್ನು ನಾಲ್ಕು ಸ್ವತಂತ್ರ ಪರಿಶೀಲನೆಗಳಾಗಿ ಅಲ್ಲ, ಅನುಕ್ರಮವಾಗಿ ಓದಿ. ಮೊದಲನೆಯದು ಕುಟುಂಬ ಸಕ್ರಿಯವಾಗಿದೆ ಮತ್ತು ಸಹಪೀರ್ ಮಾರ್ಗಗಳನ್ನು ವಿನಿಮಯ ಮಾಡುತ್ತಿದೆ ಎಂದು ದೃಢೀಕರಿಸುತ್ತದೆ; ಎರಡನೆಯದು ಪೂರ್ವಪ್ರತ್ಯಯವು ಉಪಯುಕ್ತ ಮುಂದಿನ ಹಾಪ್ನೊಂದಿಗೆ ಬಂದಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ; ಮೂರನೆಯದು ಆಮದು ಅರ್ಹತೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ನಾಲ್ಕನೆಯದು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಪ್ಲೇನ್ ಅದಕ್ಕೆ ಲೇಬಲ್ ಅಥವಾ ಸುರಂಗವನ್ನು ಬಂಧಿಸಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ.
ನಂತರ ಕೆಲಸದ ಹೊರೆಯ ಹಾದಿಯನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ, ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಅನ್ನು ತಾಳುವ MTU ಯೊಂದಿಗೆ. GRE ಹೆಡರ್ ಬೈಟ್ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಸಣ್ಣ ಪ್ರೋಬ್ಗಳನ್ನು ದಾಟುವ ಹಾದಿಯು ಪೂರ್ಣ ಗಾತ್ರದ ಪ್ಯಾಕೆಟ್ಗಳಲ್ಲಿ ಒಂದೇ ದಿಕ್ಕಿನಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು, ಅದು ಸಾಗಣೆ ದೋಷದ ಬದಲು ಅಪ್ಲಿಕೇಶನ್ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ.
ಎರಡು ಕಾರ್ಯಾಚರಣಾ ಟಿಪ್ಪಣಿಗಳು ಚಕ್ರವನ್ನು ಮುಚ್ಚುತ್ತವೆ. GRE ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್, ಗೋಪ್ಯತೆಯಲ್ಲ, ಆದ್ದರಿಂದ ಅವಿಶ್ವಾಸಾರ್ಹ ಸಂಕ್ರಮಣ ನೆಟ್ವರ್ಕ್ಗೆ ಊಹೆಯ ಬದಲು ಮೇಲೆ ಬೆಂಬಲಿತ ಭದ್ರತಾ ವ್ಯವಸ್ಥೆ ಬೇಕು. ಮತ್ತು ವಿನ್ಯಾಸ ಪರಿಶೀಲನೆಗೆ ಮೊದಲು ಪ್ಲಾಟ್ಫಾರ್ಮ್ ನಿಜವಾಗಿ ಯಾವ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಆ ಒಂದೇ ಉತ್ತರವು ಕೇವಲ-IP ಕೋರ್ ಸರಿಯಾದ ಆಯ್ಕೆಯೇ ಅಥವಾ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಲಾಗದ ಯೋಜನೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.