EVPN ಆಲ್-ಆಕ್ಟಿವ್ನಲ್ಲಿ Linux ಆಕ್ಟಿವ್-ಬ್ಯಾಕಪ್ ಬಾಂಡ್: ಏನು ಮುರಿಯುತ್ತದೆ

ಸರ್ವರ್ನಲ್ಲಿ ಆಕ್ಟಿವ್-ಬ್ಯಾಕಪ್ ಬಾಂಡ್ ಇರಿಸಿ, ಫ್ಯಾಬ್ರಿಕ್ನಲ್ಲಿ ಆಲ್-ಆಕ್ಟಿವ್ ಈಥರ್ನೆಟ್ ಸೆಗ್ಮೆಂಟ್ ಇರಿಸಿ, ಮತ್ತು ಹಿಂತಿರುಗುವ ಟ್ರಾಫಿಕ್ನ ಅರ್ಧ ಭಾಗ ಒಂದೇ ಒಂದು ದೋಷ ಕೌಂಟರ್ ಅಲುಗಾಡದೆಯೇ ಮಾಯವಾಗಬಹುದು. ಎರಡೂ ಸಂರಚನೆಗಳಲ್ಲಿ ಯಾವುದೂ ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ತಪ್ಪಲ್ಲ. ಸಮಸ್ಯೆ ಅವುಗಳ ನಡುವಿನ ಹಸ್ತಾಂತರದಲ್ಲಿದೆ, ಅಲ್ಲಿ ಒಂದು ಬದಿ ಒಂದೇ ಪೋರ್ಟ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು ಬದಿ ಸಂಪರ್ಕಿತ ಪ್ರತಿಯೊಂದು ಲೀಫ್ ತಲುಪಿಸಬಲ್ಲದು ಎಂದು ಊಹಿಸುತ್ತದೆ. ಪ್ರತಿ ದಿಕ್ಕಿನಲ್ಲಿ ಒಂದು ಫ್ರೇಮ್ ಅನ್ನು ಅನುಸರಿಸಿ ಮತ್ತು ಅಸಂಗತಿ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.

ಆಕ್ಟಿವ್-ಬ್ಯಾಕಪ್ ಒಳಬರುವ ಫ್ರೇಮ್ಗೆ ಏನು ಮಾಡುತ್ತದೆ

ಬಾಂಡಿಂಗ್ ಮೋಡ್ 1 ಕಳುಹಿಸುವ ಮಾರ್ಗದಲ್ಲಿ ನಿಖರವಾಗಿ ಒಂದು ಸ್ಲೇವ್ ಇರಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರಸ್ತುತದ್ದು ವಿಫಲವಾದಾಗ ಮಾತ್ರ ಅದನ್ನು ಬದಲಿಸುತ್ತದೆ. ಆ ಭಾಗ ಚೆನ್ನಾಗಿ ತಿಳಿದಿದೆ. ಇಲ್ಲಿ ಮುಖ್ಯವಾದದ್ದು ಸ್ವೀಕರಿಸುವ ಬದಿ: ಕರ್ನೆಲ್ ಫ್ರೇಮ್ ಅನ್ನು ಸ್ಟ್ಯಾಕ್ಗೆ ನೀಡುವುದು ಅದು ಸಕ್ರಿಯ ಸ್ಲೇವ್ಗೆ ಬಂದಾಗ ಮಾತ್ರ, ಮತ್ತು ಬೇರೆ ಯಾವುದೇ ಸ್ಲೇವ್ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಫ್ರೇಮ್ಗಳನ್ನು ಬಿಸಾಡುತ್ತದೆ. ಈ all_slaves_active ಸೆಟ್ಟಿಂಗ್ ಆ ನಿಯಮವನ್ನು ಸಡಿಲಗೊಳಿಸಲು ಇದೆ, ಮತ್ತು ಡಿಫಾಲ್ಟ್ ಆಗಿ ಆಫ್ ಇದೆ. ip -d link show bond0 ಮೋಡ್ನ ಪಕ್ಕದಲ್ಲಿ ಪ್ರಸ್ತುತ ಮೌಲ್ಯವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ.

/proc/net/bonding/bond0 ಸಕ್ರಿಯ ಸ್ಲೇವ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಸ್ಲೇವ್ಗೆ ಲಿಂಕ್ ಸ್ಥಿತಿಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಯಾವ ಪೋರ್ಟ್ ಈಗ ಟ್ರಾಫಿಕ್ ಹೊರುತ್ತಿದೆ ಎಂಬುದಕ್ಕೆ ಆ ಫೈಲ್ ಒಂದೇ ಪ್ರಾಮಾಣಿಕ ಮೂಲ.

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

ಆಲ್-ಆಕ್ಟಿವ್ ಮಲ್ಟಿಹೋಮಿಂಗ್ ದೂರದ ಮುಂದಿನ ಹಾಪ್ಗೆ ಏನು ಮಾಡುತ್ತದೆ

EVPN ಮಲ್ಟಿಹೋಮಿಂಗ್ ESI ಯಿಂದ ಗುರುತಿಸಲ್ಪಟ್ಟ ಒಂದು ಈಥರ್ನೆಟ್ ಸೆಗ್ಮೆಂಟ್ ಹಂಚಿಕೊಳ್ಳುವ ಲೀಫ್ಗಳ ಗುಂಪನ್ನು ವಿವರಿಸುತ್ತದೆ ಮತ್ತು ಆ ಸೆಗ್ಮೆಂಟ್ ಅನ್ನು ಫ್ಯಾಬ್ರಿಕ್ನ ಉಳಿದ ಭಾಗಕ್ಕೆ ಘೋಷಿಸುತ್ತದೆ. ಆಲ್-ಆಕ್ಟಿವ್ ಮಾದರಿಯಲ್ಲಿ, ದೂರದ ಪೀರ್ಗಳು ಸೆಗ್ಮೆಂಟ್ನ ವಿಳಾಸಗಳಿಗೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಂದಿನ ಹಾಪ್ಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತವೆ. ಸರ್ವರ್ನ ಕಡೆಗಿನ ಯುನಿಕಾಸ್ಟ್ ಆಗ ಯಾವುದೇ ಲೀಫ್ಗೆ ತಲುಪಬಹುದು, ಮತ್ತು ಫ್ಯಾಬ್ರಿಕ್ ಪ್ರತಿ ಹರಿವಿಗೆ ಮುಕ್ತವಾಗಿ ಆಯ್ಕೆ ಮಾಡಬಹುದು. ಇದೇ ವಿನ್ಯಾಸದ ಸಂಪೂರ್ಣ ಉದ್ದೇಶ, ಮತ್ತು ಸರ್ವರ್ನ ಬಾಂಡ್ ಪೂರೈಸಬೇಕಾದ ಊಹೆಯೂ ಇದೇ.

ಪ್ರವಾಹಿತ ಟ್ರಾಫಿಕ್ ಬೇರೆ ನಿಯಮವನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಲೀಫ್ಗಳು ಪ್ರತಿ ಸೆಗ್ಮೆಂಟ್ಗೆ ನಿಗದಿತ ಫಾರ್ವರ್ಡರ್ ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಬ್ರಾಡ್ಕಾಸ್ಟ್, ಅಜ್ಞಾತ ಯುನಿಕಾಸ್ಟ್ ಮತ್ತು ಮಲ್ಟಿಕಾಸ್ಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಅವುಗಳಲ್ಲಿ ಒಂದರ ಮೂಲಕ ಪ್ರವೇಶಿಸುತ್ತವೆ. ಹೀಗಾಗಿ ಯುನಿಕಾಸ್ಟ್ ಮತ್ತು ಪ್ರವಾಹ ಎರಡು ಬೇರೆ ನಿರ್ಣಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಹೋಸ್ಟ್ನ ಬಾಂಡ್ ಸ್ಥಿತಿಯಲ್ಲಿ ಕಾಣುತ್ತದೆ.

ಎರಡು ಆಯ್ಕೆಗಳು ಒಪ್ಪದಿರುವ ಸ್ಥಳ

ಕರ್ನೆಲ್ ತನ್ನ ಸಕ್ರಿಯ ಸ್ಲೇವ್ ಅನ್ನು ಲಿಂಕ್ ಸ್ಥಿತಿ ಮತ್ತು ತನ್ನದೇ ನೀತಿಯಿಂದ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಫ್ಯಾಬ್ರಿಕ್ ಮುಂದಿನ ಹಾಪ್ಗಳನ್ನು EVPN ಮಾರ್ಗಗಳಿಂದ, ಮತ್ತು ನಿಗದಿತ ಫಾರ್ವರ್ಡರ್ ಅನ್ನು ಲೀಫ್ಗಳ ನಡುವಿನ ಆಯ್ಕೆಯಿಂದ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆ ಇನ್ನೊಂದನ್ನು ಸಂಪರ್ಕಿಸುವುದಿಲ್ಲ. ಅವು ಬೇರೆ ಬೇರೆ ಲೀಫ್ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿದಾಗ ವೈಫಲ್ಯ ದಿಕ್ಕು-ನಿರ್ದಿಷ್ಟವಾಗಿರುತ್ತದೆ: ಸರ್ವರ್ ಕಳುಹಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಹೊರಹೋಗುತ್ತದೆ, ಮತ್ತು ಉತ್ತರಗಳು ಮಾಯವಾಗುತ್ತವೆ.

ಎರಡು ಬೆಂಬಲಿತ ಮಾರ್ಗಗಳಿವೆ, ಮತ್ತು ಅವು ಪರಸ್ಪರ ಬದಲಾಯಿಸಲಾಗದವು. ಫ್ಯಾಬ್ರಿಕ್ ಒಂದೇ ತಾರ್ಕಿಕ ಜೋಡಣೆಯಾಗಿ ಪರಿಗಣಿಸಬಹುದಾದ ಬಾಂಡ್ ಅನ್ನು ಹೋಸ್ಟ್ಗೆ ಕೊಡಿ, ಅಂದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಲೀಫ್ಗಳೊಂದಿಗೆ ಮಾತುಕತೆ ನಡೆಸಿದ LACP ಬಾಂಡ್, ಮತ್ತು ಎರಡೂ ಲಿಂಕ್ಗಳು ನಿಜವಾಗಿಯೂ ಒಟ್ಟಿಗೆ ಸಕ್ರಿಯವಾಗಿರುತ್ತವೆ. ಅಥವಾ ಫ್ಯಾಬ್ರಿಕ್ನಿಂದ ಸಿಂಗಲ್-ಆಕ್ಟಿವ್ ವಿತರಣೆಯನ್ನೂ ಒಪ್ಪಿಕೊಳ್ಳಿ, ಇದರಿಂದ ಸೆಗ್ಮೆಂಟ್ ಬಾಂಡ್ನಂತೆಯೇ ಒಂದು-ಪೋರ್ಟ್-ಒಂದು-ಸಲ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಕೆಲಸ ಮಾಡದಿರುವುದು ಒಂದೇ ಪೋರ್ಟ್ನಲ್ಲಿ ಕೇಳುವ ಬಾಂಡ್ನ ಮುಂದೆ ಆಲ್-ಆಕ್ಟಿವ್ ಸೆಗ್ಮೆಂಟ್, ನೀವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿಷ್ಕ್ರಿಯ ಸ್ಲೇವ್ಗಳಲ್ಲಿ ಸ್ವೀಕೃತಿ ಆನ್ ಮಾಡಿ ಅದರ ನಂತರ ಬರುವ ದ್ವಿಗುಣ ವಿತರಣೆಯನ್ನು ಒಪ್ಪಿಕೊಳ್ಳದ ಹೊರತು.

ಬ್ಯಾಕಪ್ ಕೇಬಲ್ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುವುದೇಕೆ

ಟ್ರಾಫಿಕ್ ಹೊರದಿರುವ ಕೇಬಲ್ ಸಹ ಲಿಂಕ್ ಅಪ್ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಬಾಂಡ್ನಲ್ಲಿನ ಸ್ಟ್ಯಾಂಡ್ಬೈ ಸ್ಲೇವ್ ಸಿದ್ಧವಾಗಿ ಕಾಣುವಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಆಪರೇಟರ್ಗಳು ಅದನ್ನು ಪುನರಾವರ್ತನೆ ಎಂದು ಓದಿ ಪ್ರಶ್ನೆ ಕೇಳುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತಾರೆ.

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

ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ವಿತರಣೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ, ಲಿಂಕ್ ಸ್ಥಿತಿಯನ್ನಲ್ಲ

ಪ್ರತಿ ವೈಫಲ್ಯಕ್ಕೆ ಒಂದು ಸಾಲು ಮತ್ತು ಪ್ರತಿ ದಿಕ್ಕಿಗೆ ಒಂದು ಕಾಲಂ ಇರುವ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ನಿರ್ಮಿಸಿ, ನಂತರ ಇಂಟರ್ಫೇಸ್ ಸ್ಥಿತಿಯ ಬದಲು ವಿತರಿಸಿದ ಟ್ರಾಫಿಕ್ ತುಂಬಿಸಿ. ಮೊದಲ ಸಾಲು ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆ, ಮತ್ತು ಅಸಂಗತಿ ಅಲ್ಲಿಯೇ ಅಡಗಿದೆ, ಏಕೆಂದರೆ ಲಕ್ಷಣವು ಅಪ್ಲಿಕೇಶನ್ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ.

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

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