ಸೈಟ್ ಒಳಗೆ ಅದೇ iESI, ಸೈಟ್ಗಳ ನಡುವೆ ಅನನ್ಯ: Junos ಜೋಡಣೆ

ಎರಡು ಗೇಟ್ವೇ ಜೋಡಿಗಳು ಎರಡು ಡೇಟಾ ಕೇಂದ್ರಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತವೆ, ಮತ್ತು ವಿನ್ಯಾಸಕ್ಕೆ ಎಷ್ಟು interconnect ESI ಮೌಲ್ಯಗಳು ಬೇಕು ಎಂದು ಯಾರಾದರೂ ನಿರ್ಧರಿಸಬೇಕು. ಉತ್ತರ ಪ್ರತಿ ಗೇಟ್ವೇ ಗುಂಪಿಗೆ ಒಂದು, ಪ್ರತಿ fabricಗೆ ಒಂದಲ್ಲ ಮತ್ತು ಪ್ರತಿ ಗೇಟ್ವೇಗೆ ಒಂದಲ್ಲ. ಇದನ್ನು ತಪ್ಪಾಗಿ ಮಾಡಿದರೆ ಕಾನ್ಫಿಗರ್ ಆದಂತೆ ಕಾಣುವ ಮತ್ತು ತಪ್ಪು forwarder ಆಯ್ಕೆ ಮಾಡುವ fabric ಉಂಟಾಗುತ್ತದೆ, ಅಥವಾ ಪ್ರತ್ಯೇಕವಾಗಿರಬೇಕಿದ್ದ ಎರಡು ಸೈಟ್ಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುತ್ತದೆ. ನಿಯಮ ಮತ್ತು ಅದರ ವಿನಾಯಿತಿಗಳನ್ನು ಗೇಟ್ವೇ ಪಟ್ಟಿಯ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯುವುದು ಯೋಗ್ಯ.

ಎರಡು ವ್ಯಾಪ್ತಿಗಳು, ಎರಡು ನಿಯಮಗಳು

ಸೈಟ್ ಒಳಗೆ, ಪೂರಕ interconnect ಗೇಟ್ವೇಗಳು ಒಂದು multihomed ತುದಿ ಬಿಂದುವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವು ಒಂದೇ interconnect ESI ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ. ಅವುಗಳ peerಗಳು ಎರಡು ಸ್ವತಂತ್ರ ಸದಸ್ಯರ ಬದಲು ಒಂದು ತಾರ್ಕಿಕ ಸದಸ್ಯರನ್ನು ನೋಡಬೇಕು. ಹಂಚಿದ ಮೌಲ್ಯದ ಸಂಪೂರ್ಣ ಅರ್ಥ ಅದೇ.

ಸೈಟ್ಗಳ ನಡುವೆ, ಪ್ರತಿ ಗೇಟ್ವೇ ಗುಂಪು ತನ್ನದೇ ಮೌಲ್ಯವನ್ನು ಪಡೆಯುತ್ತದೆ. ಒಂದೇ ಗುರುತನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಎರಡು ಡೇಟಾ ಕೇಂದ್ರಗಳು ನಿಯಂತ್ರಣ ಸಮತಲದಲ್ಲಿ ಒಂದು multihomed ಗುಂಪಾಗುತ್ತವೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ WAN ಮೂಲಕ ಜೋಡಣೆ ವಿನ್ಯಾಸದ ಉದ್ದೇಶವಲ್ಲ. ಒಂದು ಗುಂಪಿನಲ್ಲಿರುವ ಎರಡು ಸೈಟ್ಗಳು ಪರಸ್ಪರ ವೈಫಲ್ಯ ಮೋಡ್ಗಳನ್ನೂ ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುತ್ತವೆ.

ಸೈಟ್ ಒಳಗೆ: ಗುಂಪಿಗೆ ಒಂದು ಗುರುತು

ಜೋಡಿಗೆ ಎರಡೂ peerಗಳಲ್ಲಿ ಅದೇ ಮೌಲ್ಯವನ್ನು, ಅದೇ ಸೇವಾ ಸಂದರ್ಭದಲ್ಲಿ ನೀಡಿ, ಮತ್ತು ಅದನ್ನು ಚಾಟ್ ಥ್ರೆಡ್ನಲ್ಲಿ ಅಲ್ಲದೆ ನೆಟ್ವರ್ಕ್ನ ಗುರುತುಗಳ ಪಟ್ಟಿಯಲ್ಲಿ ದಾಖಲಿಸಿ. ಎರಡು ಸದಸ್ಯರ ನಡುವಿನ ಹೊಂದಾಣಿಕೆ ಇಲ್ಲದಿರುವುದು ಒಂದು ಸದಸ್ಯರ ಗುಂಪು ಮತ್ತು ಸ್ಪಷ್ಟ ಎಚ್ಚರಿಕೆ ಇಲ್ಲದಿರುವುದನ್ನು ಉಂಟುಮಾಡುವ ವೈಫಲ್ಯ ಮೋಡ್. ಕೆಲಸ ಮಾಡುವ ಸೆಷನ್ ನಂಬುವ ಮೊದಲು ಎರಡೂ ಸದಸ್ಯರನ್ನು ಹೋಲಿಸಿ.

ಬೆಂಬಲಿತ ಮಾದರಿ all-active. ಅದೇ ಉಲ್ಲೇಖವು ಈ ಜೋಡಣೆ ಗುರುತಿಗೆ single-active ಕಾರ್ಯಾಚರಣೆ, ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪಡೆದ LACP ಗುರುತುಗಳು ಮತ್ತು source-bmac ಆಯ್ಕೆಗಳನ್ನು ಹೊರಗಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಊಹಿಸಿದ ವಿನ್ಯಾಸವನ್ನು ಗುರುತು ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲೇ ಪರಿಶೀಲಿಸಬೇಕು. ಈ ನಿರ್ಬಂಧ ವಿನ್ಯಾಸದ ಇನ್ಪುಟ್, ಅಡಿಟಿಪ್ಪಣಿ ಅಲ್ಲ.

ಸೈಟ್ಗಳ ನಡುವೆ: ವಿಭಿನ್ನ ಮೌಲ್ಯಗಳು, ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕ ವಿಲೀನ

ಪ್ರತಿ ಸೈಟ್ಗೆ ಅನನ್ಯ ಮೌಲ್ಯವು ಎರಡು ಗೇಟ್ವೇ ಗುಂಪುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುತ್ತದೆ. ಉದ್ದೇಶವು ನಿಜವಾಗಿಯೂ ಒಂದು multihomed ಗುಂಪನ್ನು ಸೈಟ್ಗಳ ನಡುವೆ ವಿಸ್ತರಿಸುವುದಾದರೆ, ಅದು ತನ್ನದೇ ವಿಳಂಬ, ವೈಫಲ್ಯ ಮತ್ತು ಮುಂದುಗಡೆ ಹರಿವಿನ ಪರಿಣಾಮಗಳನ್ನು ಹೊಂದಿರುವ ಬೇರೆ ವಾಸ್ತುಶಿಲ್ಪ, ಮತ್ತು ಅದನ್ನು ಗುರುತಿನ ಆಯ್ಕೆಯಾಗಿ ಅಲ್ಲದೆ ವಾಸ್ತುಶಿಲ್ಪವಾಗಿ ನಿರ್ಧರಿಸಬೇಕು. ನಿರ್ವಹಣಾ ವಿಂಡೋಗೆ ಮೊದಲು ಆ ನಿರ್ಧಾರವನ್ನು ಲಿಖಿತವಾಗಿ ಕೇಳಿ.

ಉದ್ದೇಶಿತ ವ್ಯತ್ಯಾಸವನ್ನು ಯೋಜನೆಯಲ್ಲಿ ಬರೆಯಿರಿ, ಇದರಿಂದ ನಂತರ ಕೆಲಸ ಮಾಡುವ ಸೈಟ್ ಟೆಂಪ್ಲೇಟ್ ನಕಲಿಸುವ ಇಂಜಿನಿಯರ್ ಅದರ ಗುರುತನ್ನೂ ಜೊತೆಗೆ ತರದಿರುತ್ತಾನೆ.

peer ಹೇಳಿಕೆ ಗುರುತಿನ ಭಾಗವಾಗಿದೆ

ಗುಂಪಿನ ಪ್ರತಿ ಗೇಟ್ವೇ ತನ್ನ ಸ್ಥಳೀಯ peerಗಳನ್ನು loopback ವಿಳಾಸದಿಂದ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಆ ಸಂಬಂಧವು ಪ್ರತ್ಯೇಕ MAC-VRF ಒಳಗೆ ಅಲ್ಲದೆ ಜಾಗತಿಕ EVPN ಮಟ್ಟದಲ್ಲಿ ಇರುತ್ತದೆ. ಅದನ್ನು ತಪ್ಪು ಅನುಕ್ರಮಣಿಕೆಯಲ್ಲಿ ಇಡುವುದು commit ಆಗುವ ಆದರೆ ಎಂದಿಗೂ ಗುಂಪನ್ನು ರೂಪಿಸದ ಕಾನ್ಫಿಗರೇಶನ್ ಮಾಡುವ ಸಾಮಾನ್ಯ ದಾರಿ. ಉಲ್ಲೇಖ ಅನುಕ್ರಮಣಿಕೆಯನ್ನು ಒಮ್ಮೆ ಓದಿ, ನಂತರ ಅದಕ್ಕೆ ಅಂಟಿಕೊಳ್ಳಿ.

ಹೇಳಿಕೆಯ ಹೆಸರೂ ಸ್ಥಳಾಂತರಗೊಂಡಿತು. Juniper 24.2R1ನಲ್ಲಿ interconnect peer-gateways ಹೇಳಿಕೆಯನ್ನು ಮರುನಾಮಕರಣ ಮಾಡಿತು ಮತ್ತು 24.4R1ನಲ್ಲಿ ಡೇಟಾ ಕೇಂದ್ರ interconnectಗಾಗಿ interconnect-ನಿರ್ದಿಷ್ಟ ರೂಪವನ್ನು ಮರುಸ್ಥಾಪಿಸಿತು. ಆದ್ದರಿಂದ ಮಧ್ಯಂತರ ಬಿಡುಗಡೆಯಿಂದ ತೆಗೆದ ಸ್ನಿಪ್ಪೆಟ್ ನಿಯೋಜಿತ ಆವೃತ್ತಿ ಸ್ವೀಕರಿಸದ ಹೆಸರನ್ನು ಬಳಸಬಹುದು, ಅಥವಾ ಪ್ರತಿಯಾಗಿ. ಸ್ನಿಪ್ಪೆಟ್ ಯಾವ ಬಿಡುಗಡೆಯಿಂದ ಬಂತು ಎಂಬುದನ್ನು ಸ್ನಿಪ್ಪೆಟ್ನ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸಿ.

iESI ಹಂಚಿಕೊಳ್ಳುವುದು ಏನನ್ನು ಮಾಡುವುದಿಲ್ಲ

ಇದು ನಿಮಗಾಗಿ route target, VNI ಅಥವಾ ಸ್ಥಳೀಯ EVPN ಇನ್ಸ್ಟಾನ್ಸ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವುದಿಲ್ಲ. ಅವು ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಹೊಂದಬೇಕಾದ ಪ್ರತ್ಯೇಕ ಕಾನ್ಫಿಗರೇಶನ್ ಆಗಿ ಉಳಿಯುತ್ತವೆ, ಮತ್ತು ಹೊಂದುವ ಗುರುತು, route target ಹೊಂದದಿರುವಾಗ, ರೂಪುಗೊಂಡು ಏನನ್ನೂ ಸಾಗಿಸದ ಗುಂಪನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಆ ಸೆಟ್ಟಿಂಗ್ಗಳ ಎರಡೂ ಬದಿಗಳನ್ನು ಒಂದೇ ಪಾಸ್ನಲ್ಲಿ ಹೋಲಿಸಿ.

ಇದು peer ತಲುಪುವಿಕೆ ಅಥವಾ designated forwarder ಆಯ್ಕೆಯನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಸಾಮಾನ್ಯ ಸಂದರ್ಭದಲ್ಲಿ unicast ಮತ್ತು ಅಗತ್ಯವಾದ broadcast ಹಾಗೂ multicast ನಡವಳಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಒಂದು ಗೇಟ್ವೇ ತೆಗೆದು ಪುನರಾವರ್ತಿಸಿ, ಉಳಿದ ಸದಸ್ಯನೇ ಗುಂಪನ್ನು ಒಂಟಿಯಾಗಿ ಹೊರುವಂತೆ.

ಆ ಎರಡನೇ ರನ್ ಗುಂಪು ನಿಜವೆಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.

ಗಮನಿಸಿದ ಸದಸ್ಯತ್ವ ಮತ್ತು ಸೇವಾ ಸಂದರ್ಭವನ್ನು ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳೊಂದಿಗೆ ಇರಿಸಿ. ನಂತರದ ಗುರುತಿನ ಬದಲಾವಣೆಯನ್ನು ಆಗ multihoming ಬದಲಾವಣೆಯಾಗಿ, ಅದು ಹಾಗೆಯೇ, ಪರಿಶೀಲಿಸಬಹುದು, ಸ್ಟ್ರಿಂಗ್ನ ಸೌಂದರ್ಯ ತಿದ್ದುಪಡಿಯಾಗಿ ಅಲ್ಲ. ಗುರುತು ರೇಖಾಚಿತ್ರ ಹೇಳುವುದನ್ನು ಮಾಡುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಫಲಿತಾಂಶಗಳೇ ಏಕೈಕ ಸಾಕ್ಷ್ಯ.