MPLS ಶಾಖಾ ರೂಟಿಂಗ್: CE ಏನು ಕಲಿಯುತ್ತದೆ ಮತ್ತು ಯಾರಿಂದ
ಶಾಖೆಯ ಅಂಚು ಪೂರೈಕೆದಾರರ ಅಂಚಿನೊಂದಿಗೆ ರೂಟ್ಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತದೆ, ದೂರದ ಶಾಖೆಯೊಂದಿಗೆ ಅಲ್ಲ. ಒಂದು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅನುಸರಿಸಿ ಮತ್ತು ಸೈಟ್ ಸ್ವೀಕರಿಸುವ ಮೊದಲು ಎರಡೂ ಹಸ್ತಾಂತರಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
ಒಂದು ಶಾಖೆಯ ಹೋಸ್ಟ್ ಇನ್ನೊಂದು ಶಾಖೆಯ ಸರ್ವರ್ಗೆ ಸಂಪರ್ಕ ತೆರೆಯುತ್ತದೆ, ಮತ್ತು ಎರಡೂ ಸೈಟ್ಗಳು ಒಂದೇ ನಿರ್ವಹಿತ MPLS ಲೇಯರ್ 3 VPN ಹಿಂದೆ ಇವೆ. ಹೋಸ್ಟ್ ತನ್ನ ಸ್ವಂತ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಅನ್ನು ಮಾತ್ರ ತಿಳಿದಿದೆ ಮತ್ತು ಬೇರೆ ಏನೂ ಇಲ್ಲ, ಇದು ಸರಿಯಾಗಿದೆ. ಮುಖ್ಯವಾದುದು ಎಂದರೆ ಸ್ಥಳೀಯ ಗ್ರಾಹಕ ಅಂಚು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ತನ್ನ ಪೂರೈಕೆದಾರ ಅಂಚಿಗೆ ಒಪ್ಪಿಸುತ್ತದೆ, ಮತ್ತು ಪೂರೈಕೆದಾರರ VPN ರೂಟಿಂಗ್ ಸ್ಥಿತಿ ಅದನ್ನು ಗಮ್ಯಸ್ಥಾನ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಹೊಂದಿರುವ ಶಾಖೆಗೆ ತಲುಪಿಸುತ್ತದೆ.
ಮಾರ್ಗದಲ್ಲಿ ಒಂದು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅನುಸರಿಸುವುದು ಯಾವ ಭಾಗ ಗ್ರಾಹಕರ ಜವಾಬ್ದಾರಿ ಮತ್ತು ಯಾವ ಭಾಗ ಸೇವೆಗೆ ಸೇರಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಅತ್ಯಂತ ವೇಗದ ದಾರಿ.
10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24
ಪ್ರತಿ ಹಾಪ್ನ ಕೆಲಸ ಎಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ
CE-A ಗೆ ದೂರದ LAN ಗೆ ಮಾರ್ಗ ಬೇಕು, ಅದು ತನ್ನ ಸ್ಥಳೀಯ ಪೂರೈಕೆದಾರ ಸಂಪರ್ಕದ ಕಡೆಗೆ ತೋರಿಸಬೇಕು, ದೂರದ ಶಾಖೆಯ WAN ವಿಳಾಸದ ಕಡೆಗೆ ಅಲ್ಲ. ನಂತರ ಪೂರೈಕೆದಾರರು VPN ರೂಟಿಂಗ್ ಸ್ಥಿತಿಯನ್ನು ಬಳಸಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ತಮ್ಮ ಕೋರ್ ಮೂಲಕ ಸಾಗಿಸುತ್ತಾರೆ, ಮತ್ತು CE-B ಅದನ್ನು ಗಮ್ಯಸ್ಥಾನ LAN ಗೆ ತಲುಪಿಸುತ್ತದೆ. ಯಾವುದೇ ಹಂತದಲ್ಲಿ ಹೋಸ್ಟ್ ಲೇಬಲ್ಗಳು, VRF ಅಥವಾ ಇನ್ನೊಂದು ಬದಿಯ ಇಂಟರ್ನೆಟ್ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ.
ಟಿಕೆಟ್ಗಳಲ್ಲಿ ಪದೇ ಪದೇ ಕಾಣುವ ತಪ್ಪು ಎಂದರೆ ಶಾಖೆ A ಯಲ್ಲಿ ಶಾಖೆ B ಯ WAN ವಿಳಾಸವನ್ನು ಮುಂದಿನ ಹಾಪ್ ಆಗಿ ಸಂರಚಿಸುವುದು. ಎರಡೂ ಶಾಖೆಗಳು ಒಂದೇ ಸೇವೆಯನ್ನು ಖರೀದಿಸಿವೆ, ಹಾಗಾಗಿ ಅವು ನೆರೆಹೊರೆಯವರಾಗಿರಬೇಕು ಎಂದು ಅನಿಸುತ್ತದೆ. ಆದರೆ ಅವು ಅಲ್ಲ: ಮುಂದಿನ ಹಾಪ್ ನಿಮ್ಮ ಬಳಿ ನಿಜವಾಗಿ ಇರುವ ರೂಟಿಂಗ್ ವಿನ್ಯಾಸದ ಮೂಲಕ ತಲುಪಬಹುದಾಗಿರಬೇಕು, ಮತ್ತು ದೂರದ CE ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ನಿರ್ವಹಿಸದ ಉಪಕರಣದ ಹಿಂದೆ ಹಲವು ಹಾಪ್ ದೂರದಲ್ಲಿರುತ್ತದೆ. ಈ ಊಹೆಯ ಮೇಲೆ ನಿರ್ಮಿಸಿದ ಸ್ಥಿರ ಮಾರ್ಗ ಸಕ್ರಿಯವಾಗಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ಯಾವುದಕ್ಕೂ ಪರಿಹರಿಸುವುದಿಲ್ಲ, ಇದು ಕಾಣೆಯಾದ ಮಾರ್ಗಕ್ಕಿಂತ ಕೆಟ್ಟದು ಏಕೆಂದರೆ ಕೋಷ್ಟಕದಲ್ಲಿ ಅದು ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ.
RFC 4364 ಗ್ರಾಹಕ ಮತ್ತು ಪೂರೈಕೆದಾರ ಅಂಚುಗಳ ನಡುವಿನ ವಿನಿಮಯವನ್ನು ಪೂರೈಕೆದಾರರ VPN ಮಾರ್ಗ ವಿತರಣೆಯಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಮತ್ತು ಇದು ಈ ಕೈಪಿಡಿ ವ್ಯವಹರಿಸುವ ಗಡಿಯಾಗಿದೆ. ಗ್ರಾಹಕರ ಕೆಲಸ ಎಂದರೆ ತನ್ನ ಅಂಚಿಗೆ ಏನು ತಲುಪಿಸಬಹುದು ಎಂದು ಹೇಳುವುದು ಮತ್ತು ಸೇವೆ ನೀಡುವ ತಲುಪುವಿಕೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದು.
ಹಸ್ತಾಂತರ ಯಾವುದಕ್ಕೆ ಒಪ್ಪಬೇಕು
ಯಾಂತ್ರಿಕತೆಯನ್ನು ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ಸೇರಿ ಆರಿಸಿ, ಅವರ ಸುತ್ತ ಅಲ್ಲ. ಸ್ಥಿರ ಮಾರ್ಗಗಳು, BGP ಅಥವಾ CE ಮತ್ತು PE ನಡುವಿನ ರೂಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ ಒಪ್ಪಂದ ಎಲ್ಲವೂ ಕಾನೂನುಬದ್ಧ, ಮತ್ತು OSPF ಗೆ ಈ ಹಸ್ತಾಂತರಕ್ಕಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ MPLS VPN ಮಾದರಿ ಇದೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಎರಡು ದೂರದ ಗ್ರಾಹಕ ಅಂಚುಗಳ ನಡುವೆ ಅನಿರ್ದಿಷ್ಟ ಪೂರೈಕೆದಾರ ಕೋರ್ ಮೂಲಕ OSPF ನೆರೆಹೊರೆ ನಿರ್ಮಿಸಲು ಕಾರಣವಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಪೂರೈಕೆದಾರ ಒಪ್ಪದ ಮತ್ತು ಬೆಂಬಲಿಸಲಾಗದ ವಿನ್ಯಾಸ.
ಹೊಸ LAN ಕಾರ್ಯಾರಂಭಕ್ಕೆ ಮೊದಲು ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ಬರೆಯಿರಿ: ಪೂರ್ವಪ್ರತ್ಯಯ, CE ಯಲ್ಲಿನ ಸ್ಥಳೀಯ ಮುಂದಿನ ಮಾರ್ಗ, ಪೂರೈಕೆದಾರ ಸ್ವೀಕರಿಸುವ ಪ್ರಕಟಣೆ, ಮತ್ತು ಪೂರೈಕೆದಾರ ಹಿಂತಿರುಗಿಸುವ ಮಾರ್ಗಗಳು. ಒಪ್ಪಂದ ವಿಧಿಸುವ ಯಾವುದೇ ಫಿಲ್ಟರಿಂಗ್, ಪೂರ್ವಪ್ರತ್ಯಯ ಮಿತಿ ಅಥವಾ ಸೈಟ್ಗಳ ನಡುವಿನ ನಿರ್ಬಂಧವನ್ನು ಸೇರಿಸಿ. ಆರೋಗ್ಯಕರ ನೆರೆಹೊರೆ ಮಾಹಿತಿ ವಿನಿಮಯದ ಮಾರ್ಗವಾಗಿದೆ, ಮತ್ತು ಅದು ನಿರ್ದಿಷ್ಟ ಪೂರ್ವಪ್ರತ್ಯಯ ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ; ನಿಮ್ಮ ಹೊಸ ಉಪಜಾಲವು ಫಿಲ್ಟರ್ನಲ್ಲಿ ಕುಳಿತಿರುವಾಗ ಸೆಷನ್ ಆನ್ ಆಗಿರಬಹುದು.
ನಂತರ ಉತ್ತರವನ್ನು ಅನುಸರಿಸಿ. ಶಾಖೆ B ಗೆ ಮೂಲ LAN ಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ಸ್ವೀಕರಿಸುವ ಬದಿಯ ಹೋಸ್ಟ್ಗೆ ತನ್ನದೇ ಗೇಟ್ವೇ ಮತ್ತು ತನ್ನದೇ ಸೇವಾ ಅನುಮತಿಗಳು ಬೇಕು. CE-A ಯಲ್ಲಿ ಕಾಣುವ ಮಾರ್ಗ ಅರ್ಧ ಪ್ರಯಾಣವನ್ನು ಮಾತ್ರ ಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ಅರ್ಧ ಪ್ರಯಾಣವೇ ping ಪರೀಕ್ಷೆಯ ಒಂದು ದಿಕ್ಕು ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತಿರುವಾಗ ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ವಿಫಲವಾಗುವ ಕಾರಣ.
ಸ್ವೀಕಾರಕ್ಕೆ ಮೊದಲು ಎರಡೂ ಹಸ್ತಾಂತರಗಳನ್ನು ಪರಿಶೀಲಿಸಿ
ಎರಡೂ ಗ್ರಾಹಕ ಅಂಚುಗಳಲ್ಲಿ ರೂಟಿಂಗ್ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಿ, ಉದ್ದೇಶಿತ LAN ಪೂರ್ವಪ್ರತ್ಯಯಗಳು VPN ಗೆ ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟಿವೆ ಎಂದು ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ಖಚಿತಪಡಿಸಿ, ನಂತರ ಪ್ರತಿ ದಿಕ್ಕಿನಲ್ಲಿ ಒಂದು ಅನುಮತಿಸಿದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ. ಕೇವಲ ಮಾರ್ಗ ಕೋಷ್ಟಕಗಳು ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಕೇವಲ ಅಪ್ಲಿಕೇಶನ್ ಪರೀಕ್ಷೆ ಕಾರ್ಯನಿರ್ವಹಿಸದಿದ್ದಾಗ ಯಾವ ನಿಯಂತ್ರಣ ಸಮತಲ ವಿಫಲವಾಯಿತು ಎಂದು ಹೇಳುವುದಿಲ್ಲ.
show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10
ಮೂರು ಔಟ್ಪುಟ್ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ. ಮೊದಲನೆಯದು ಅಂಚು ಏನನ್ನು ನಂಬುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಎರಡನೆಯದು ಏನನ್ನು ಮತ್ತು ಯಾವ ಸಹವರ್ತಿಯಿಂದ ಕಲಿತಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಮೂರನೆಯದು ನಿಜವಾಗಿ ಏನನ್ನು ರವಾನಿಸುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಅವುಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಸಾಮಾನ್ಯವಾಗಿ ಕಾಣೆಯಾದ ಪ್ರಕಟಣೆಯಲ್ಲ, ನೀತಿ ಅಥವಾ ಪುನರಾವರ್ತನೆಯ ಸಮಸ್ಯೆ, ಮತ್ತು ಪೂರೈಕೆದಾರರನ್ನು ತನಿಖೆಗೆ ಕೇಳುವ ಮೊದಲು ಅದನ್ನು ಪರಿಹರಿಸುವುದು ಯೋಗ್ಯ. ಈ ಮೂರು ಔಟ್ಪುಟ್ಗಳನ್ನು ಆಪರೇಟರ್ನೊಂದಿಗಿನ ಕರೆಗೆ ತೆಗೆದುಕೊಂಡು ಹೋಗಿ, ಏಕೆಂದರೆ ಅವು ಬೆಂಬಲ ಇಂಜಿನಿಯರ್ ಇಲ್ಲದಿದ್ದರೆ ಕೇಳುವ ಪ್ರಶ್ನೆಗಳ ಹೆಚ್ಚಿನವಕ್ಕೆ ಉತ್ತರಿಸುತ್ತವೆ.
ಸೇವೆ ಏನನ್ನು ನೀಡುವುದಿಲ್ಲ ಎಂದು ತಿಳಿಯಿರಿ
ಇದು ಲೇಯರ್ 3 ರ ರೂಟ್ ಮಾಡಿದ ಪ್ರವೇಶ. ಇದು ಕಚೇರಿಗಳ ನಡುವೆ ಪ್ರಸಾರವನ್ನು ವಿಸ್ತರಿಸುವ ಲೇಯರ್ 2 ಸರ್ಕ್ಯೂಟ್ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಅನ್ವೇಷಣೆ ಪ್ರೋಟೋಕಾಲ್ಗಳು, ಪ್ರಸಾರದ ಮೇಲೆ ಅವಲಂಬಿತ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಮತ್ತು ಹಂಚಿದ ವಿಭಾಗದ ಊಹೆಗಳು ಅದರೊಂದಿಗೆ ಪ್ರಯಾಣಿಸುವುದಿಲ್ಲ. ಮುದ್ರಣ, ಹೆಸರು ಬ್ರೌಸಿಂಗ್ ಮತ್ತು ಸ್ಥಳೀಯ ವಿಭಾಗವನ್ನು ಅವಲಂಬಿಸಿರುವ ಯಾವುದಕ್ಕೂ ತನ್ನದೇ ವಿನ್ಯಾಸ ಬೇಕು.
VPN ಬೇರ್ಪಡಿಕೆ ಕೂಡ ಎನ್ಕ್ರಿಪ್ಶನ್ ಅಲ್ಲ. ಲೇಬಲ್ ಸ್ವಿಚಿಂಗ್ ಗ್ರಾಹಕರನ್ನು ಪೂರೈಕೆದಾರರ ನೆಟ್ವರ್ಕ್ನ ಒಳಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುತ್ತದೆ, ಮತ್ತು ಒಪ್ಪಂದ ಗೋಪ್ಯತೆ ಬೇಡಿದರೆ ಅದು ಪೇಲೋಡ್ ಅನ್ನು ಗೋಪ್ಯ ಮಾಡುವುದಿಲ್ಲ. ಅದು ಮುಖ್ಯವಾದ ಸ್ಥಳದಲ್ಲಿ ಅದನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ ಓವರ್ಲೇ ಒದಗಿಸಬೇಕು.
ಕೊನೆಯದಾಗಿ, ಸೇವಾ ಮಾದರಿಯನ್ನು ಸೈಟ್ನ ರೂಟಿಂಗ್ ಸಂರಚನೆಯ ಪಕ್ಕದಲ್ಲಿ ಬರೆದಿಡಿ. ಮುಂದೆ ಉಪಜಾಲ ಸೇರಿಸುವ ಇಂಜಿನಿಯರ್ ಯಾವ ಪೂರ್ವಪ್ರತ್ಯಯಗಳು ಪ್ರಕಟವಾಗುತ್ತವೆ, ಯಾರು ಅವುಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು ನಿರೀಕ್ಷಿತ ಮರಳುವ ಮಾರ್ಗ ಯಾವುದು ಎಂದು ಓದಲು ಸಾಧ್ಯವಾಗಬೇಕು: BGP/MPLS IP VPN ವಿಶೇಷಣೆ ಇವೆಲ್ಲದರ ಹಿಂದಿನ ಮಾದರಿಗೆ ಉಲ್ಲೇಖವಾಗಿದೆ.