OTV ಸೇರಿಸುವ ಮೊದಲು, ನಿಮಗೆ ಬೇಕಾದ Ethernet ಒಪ್ಪಂದವನ್ನು ಬರೆಯಿರಿ
ಸೈಟ್ಗಳ ಸಂಖ್ಯೆ, VLAN ವ್ಯಾಪ್ತಿ, ಕಲಿಕೆ, flooding ಮತ್ತು ವೈಫಲ್ಯದ ನಡವಳಿಕೆ ಇದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. overlay ಬದಲಿಸುವ ಮೊದಲು ನಿಮ್ಮ L2VPN ಈಗಾಗಲೇ ನೀಡುವ ಒಪ್ಪಂದವನ್ನು ಹೋಲಿಸಿ.
ಒಂದು workload ಎರಡನೇ ಡೇಟಾ ಸೆಂಟರ್ಗೆ ಸ್ಥಳಾಂತರಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಮೊದಲನೆಯದರಿಂದ ಚೆನ್ನಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿದ್ದ ಸೇವೆಯಲ್ಲಿ ಸಮಯ ಮೀರಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಯಾರೋ OTV ಸೂಚಿಸುತ್ತಾರೆ, ಏಕೆಂದರೆ ಇರುವ Layer 2 VPN «broadcast ಮಾಡುವುದಿಲ್ಲ». ಆ ತೀರ್ಮಾನ ಸಾಮಾನ್ಯವಾಗಿ ಆತುರದ್ದು. ಸೇವಾ ವರ್ಗ ಮತ್ತು ನೀವು ಖರೀದಿಸಿದ ನಿರ್ದಿಷ್ಟ ಒಪ್ಪಂದ ಎರಡು ಬೇರೆ ಪ್ರಶ್ನೆಗಳು, ಮತ್ತು ಸಮಯ ಮೀರುವಿಕೆ ಇನ್ನೂ ಯಾವುದಕ್ಕೂ ಆರೋಪಿಸಲ್ಪಟ್ಟಿಲ್ಲ.
ಹೋಲಿಕೆ ಪ್ರಾರಂಭಿಸುವ ಲಕ್ಷಣ
ಉತ್ಪನ್ನಗಳನ್ನು ಹೋಲಿಸುವ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ಗೆ ನಿಜವಾಗಿ ಏನು ಬೇಕು ಎಂದು ಬರೆಯಿರಿ. ಸೈಟ್ಗಳ ಸಂಖ್ಯೆ, VLAN ವ್ಯಾಪ್ತಿ, ವಿಳಾಸ ಕಲಿಕೆ, flooding ಸಹನಶೀಲತೆ ಮತ್ತು ವೈಫಲ್ಯದ ನಡವಳಿಕೆ ಅಗತ್ಯವನ್ನು ವಿವರಿಸುತ್ತವೆ. «Layer 2» ಮತ್ತು «OTV» ಆರ್ಕಿಟೆಕ್ಚರ್ಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಸ್ವತಃ ಅಗತ್ಯವಲ್ಲ. ಒಂದು ಪುಟದಲ್ಲಿ ಐದು ಗುಣಲಕ್ಷಣಗಳು ಯಾವುದೇ ಮಾರಾಟಗಾರ ಹೋಲಿಕೆಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುತ್ತವೆ.
ನಂತರ ಪ್ರಸ್ತುತ ಸೇವೆ ಆ ಐದು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಈಗಾಗಲೇ ಪೂರೈಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಪೂರೈಕೆದಾರ ನಿರ್ವಹಿಸುವ Layer 2 VPN ನಲ್ಲಿ multipoint ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಕಂಟ್ರೋಲ್-ಪ್ಲೇನ್ ಕಲಿಕೆ ಇರಬಹುದು, ಅವನ್ನು ಇನ್ವಾಯ್ಸ್ನ ಮೇಲೆ ಒಂದು ನೋಟವು ಉಲ್ಲೇಖಿಸಿರಲಿಲ್ಲ.
ಪ್ರಸ್ತುತ ಸೇವೆ ಅವನ್ನು ಪೂರೈಸಿದರೆ, ಸಮಯ ಮೀರುವಿಕೆ ಬೇರೆಲ್ಲೋ ಇದೆ: MTU ಸಮಸ್ಯೆ, ರೂಟಿಂಗ್ ಅಸಮಾನತೆ, ಸೈಟ್ಗಳ ನಡುವೆ ಭಿನ್ನವಾದ ಫೈರ್ವಾಲ್ ನಿಯಮ. overlay ಬದಲಿಸಿದರೆ ಆ ಕಾರಣವೇ ಇರುವುದು ಮತ್ತು ಒಂದು ಸ್ಥಳಾಂತರ ಸೇರಿಕೊಳ್ಳುತ್ತದೆ.
ಲೇಬಲ್ ನಿಮಗೆ ಏನು ಹೇಳುವುದಿಲ್ಲ
Layer 2 VPN ಒಂದು ವರ್ಗ, ಉತ್ಪನ್ನವಲ್ಲ. ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ VPWS ಮತ್ತು multipoint VPLS ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತವೆ, ಮತ್ತು ವರ್ಗವು ಕಂಟ್ರೋಲ್-ಪ್ಲೇನ್ ಕಲಿಕೆ ಮತ್ತು ಲೂಪ್ ನಿರ್ವಹಣೆ ಇರುವ ಸೇವೆಗಳನ್ನೂ ಸರಳವಾದವನ್ನೂ ಒಳಗೊಳ್ಳುತ್ತದೆ. ಪ್ರತಿ Layer 2 VPN ನಿಖರವಾಗಿ ಎರಡು ಸೈಟ್ಗಳನ್ನು ಸಂಪರ್ಕಿಸಿ ಎಲ್ಲವನ್ನೂ flood ಮಾಡುತ್ತದೆ ಎಂಬ ಊಹೆ ತಪ್ಪು ಹೋಲಿಕೆ ಮಾಡುವ ದಾರಿ. ಒಪ್ಪಂದದ ಮೇಲಿನ ಹೆಸರು ಅದರ ಹಿಂದಿನ ಫಾರ್ವರ್ಡಿಂಗ್ ಕೋಷ್ಟಕದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ಇರುವ ಸೇವೆಯು ಯಾವ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾದರಿಯನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ ಎಂದೂ, ಅಪ್ಲಿಕೇಶನ್ಗೆ ಯಾವುದು ಬೇಕು ಎಂದೂ ಕೇಳಿ. hub-and-spoke ಅಗತ್ಯ ಮತ್ತು full-mesh ಅಗತ್ಯ ಎರಡನ್ನೂ Layer 2 ಎಂದು ವಿವರಿಸಿದರೂ ಬೇರೆ ಬೇರೆ ವಿನ್ಯಾಸಗಳನ್ನು ನೀಡುತ್ತವೆ.
OTV ತನ್ನ ಗಡಿಯನ್ನು ಎಲ್ಲಿ ಎಳೆಯುತ್ತದೆ
OTV IP ಸಾಗಣೆಯ ಮೇಲೆ ಚಲಿಸುತ್ತದೆ, ಕಂಟ್ರೋಲ್-ಪ್ಲೇನ್ MAC ತಲುಪುವಿಕೆ ಮತ್ತು ನಿರ್ಧಾರಿತ edge ಪಾತ್ರಗಳೊಂದಿಗೆ. ಸ್ಥಳೀಯ spanning-tree ಮಾಹಿತಿ ಸ್ಥಳೀಯವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ, ಸಾಗಣೆಯಾದ್ಯಂತ ಒಂದು ಅನಿಯಂತ್ರಿತ ಡೊಮೇನ್ ಆಗಿ ವಿಸ್ತರಿಸುವುದಿಲ್ಲ. ಇದು ಸಾಮಾನ್ಯ ಬ್ರಿಡ್ಜ್ಡ್ ವಿಸ್ತರಣೆಯಿಂದ ನಿಜವಾದ ವ್ಯತ್ಯಾಸ, ಮತ್ತು ಜನರು ಇದನ್ನು ಆಶ್ರಯಿಸುವ ಕಾರಣ ಅದೇ.
ಗಡಿ ಲಾಭದಷ್ಟೇ ಮುಖ್ಯ. ಅಜ್ಞಾತ unicast, broadcast ಮತ್ತು multicast ನಿರ್ವಹಣೆ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಮತ್ತು ಅದರ ಸಂರಚನೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ, ಮತ್ತು edge ಜೋಡಿ ಬೆಂಬಲಿತ multihoming ಕಾರ್ಯವಿಧಾನದ ಮೂಲಕ ಸಹಕರಿಸಬೇಕು. ಅದೇ VLAN ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಎರಡು ಸ್ವತಂತ್ರ ಸಾಧನಗಳು ಒಂದೇ ವಿನ್ಯಾಸವಲ್ಲ, ಮತ್ತು ಅವು ಬೇರೆ ವೈಫಲ್ಯ ಸ್ಥಿತಿ ಉಂಟುಮಾಡುತ್ತವೆ.
Flooding ಕಡಿಮೆಯಾಗುತ್ತದೆ, ತೆಗೆಯುವುದಿಲ್ಲ
ಕೆಲವು ಅನಗತ್ಯ flooding ಅಡಗಿಸುವುದು ಯಾವುದೇ broadcast ಅಥವಾ multicast ಫ್ರೇಮ್ ಎಂದಿಗೂ ವಿಸ್ತರಣೆಯನ್ನು ದಾಟದಿರುವ ಭರವಸೆಗೆ ಸಮಾನವಲ್ಲ. ಒಂದು ಸೈಟ್ನಲ್ಲಿ ಪ್ರಾರಂಭವಾದ ಬಿರುಗಾಳಿ ಇನ್ನೂ ಸಾಗಣೆಯನ್ನು ತಿನ್ನಬಹುದು, ಮತ್ತು ಒಂದು ಟ್ರಾಫಿಕ್ ವರ್ಗವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ವೈಶಿಷ್ಟ್ಯ ಉಳಿದವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವುದಿಲ್ಲ. ಯಾವುದೇ overlay ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ನಿರಾಶೆ ಈ ವ್ಯತ್ಯಾಸದಿಂದ ಬರುತ್ತದೆ.
ಆದ್ದರಿಂದ ಪ್ರಶ್ನೆ OTV broadcast ಬಿರುಗಾಳಿಗಳನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆಯೇ ಎಂಬುದಲ್ಲ. ಪ್ರಶ್ನೆ ಯಾವ ಟ್ರಾಫಿಕ್ ವರ್ಗಗಳು ದಾಟುತ್ತವೆ, ಯಾವ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ಮತ್ತು ದಾಟುವಾಗ ವೇಗವನ್ನು ಯಾವುದು ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ ಎಂಬುದು.
ಅಲ್ಲಿರುವಾಗ underlay ದೃಢೀಕರಿಸಿ: ಬೆಂಬಲಿತ ವಿತರಣೆ, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರ, ರೂಟಿಂಗ್ ಮತ್ತು ಆಯ್ಕೆ ಮಾಡಿದ ಬಿಡುಗಡೆ ಬೇಡುವ ನೆರೆಹೊರೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ overlay ಜೊತೆ ಉಚಿತವಾಗಿ ಬರುವುದಿಲ್ಲ, ಮತ್ತು 1500 ಬೈಟ್ ಫ್ರೇಮ್ ಹಿಡಿಯುವ ಟನಲ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿಮ್ಮ ಟ್ಯಾಗ್ ಮಾಡಿದ ಫ್ರೇಮ್ಗಳನ್ನು ಹಿಡಿಯುವ ಟನಲ್ ಅಲ್ಲ.
ಲಿಖಿತವಾಗಿ ಕೇಳಬೇಕಾದ ಒಪ್ಪಂದ
ನೀವು ಯಾವ ಸೇವೆ ಆರಿಸಿದರೂ, ಅದೇ ಆರು ಉತ್ತರಗಳನ್ನು ಕೇಳಿ: ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಅಥವಾ multipoint ವ್ಯಾಪ್ತಿ, ಗ್ರಾಹಕ ಫ್ರೇಮ್ ಮತ್ತು ಟ್ಯಾಗ್ ನಿರ್ವಹಣೆ, MAC ಕಲಿಕೆ ಮಾದರಿ, flooding ಮಿತಿಗಳು, ಚೇತರಿಕೆ ನಡವಳಿಕೆ ಮತ್ತು ತುದಿಯಿಂದ ತುದಿವರೆಗಿನ ಗರಿಷ್ಠ ಫ್ರೇಮ್ ಗಾತ್ರ. ಒಂದೇ ಹೆಸರಿನ ಎರಡು ಸೇವೆಗಳು ಅವುಗಳ ಪ್ರತಿಯೊಂದರಲ್ಲೂ ಭಿನ್ನವಾಗಿರಬಹುದು. ಉತ್ತರಗಳನ್ನು ಲಿಖಿತವಾಗಿ ಪಡೆಯಿರಿ, ಏಕೆಂದರೆ ಸೇವೆಯನ್ನು ಸಂರಚಿಸಿದ ಎಂಜಿನಿಯರ್ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವವರಾಗಿರದೇ ಇರಬಹುದು.
ಪ್ರಸ್ತುತ ಸೇವೆ ಸ್ಪಷ್ಟವಾಗಿ ಪೂರೈಸಲಾಗದ ಅಗತ್ಯಕ್ಕೆ ಮಾತ್ರ ಬದಲಾವಣೆ ಆರಿಸಿ. VLAN ಅನ್ನು ಮತ್ತಷ್ಟು ವಿಸ್ತರಿಸುವುದು ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು Ethernet ಅವಲಂಬನೆಗಳನ್ನೂ ಅದರೊಂದಿಗೆ ವಿಸ್ತರಿಸುತ್ತದೆ; ಹೊಸ overlay ಹೆಸರು ಅವನ್ನು ತೆಗೆಯುವುದಿಲ್ಲ.
RFC 4664 ಚೌಕಟ್ಟು ಸೇವಾ ವರ್ಗಗಳು ಮತ್ತು ಅವುಗಳ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾದರಿಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಅದು ಸರಿಯಾದ ಪ್ರಶ್ನೆ ಕೇಳಲು ಬೇಕಾದ ಪದಸಂಪತ್ತು. ಆರು ಉತ್ತರಗಳು ಮತ್ತು ವಿಫಲ ಪರೀಕ್ಷೆಯನ್ನು ಅದೇ ಸಭೆಗೆ ತನ್ನಿ, ಮತ್ತು ನಿರ್ಧಾರ ಲೇಬಲ್ಗಳ ಬಗ್ಗೆ ಆಗಿರುವುದಿಲ್ಲ.