QFX ನ MAC EVPN ನಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ ಆದರೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಟೇಬಲ್ನಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ ಏಕೆ

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

ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುವ ಎರಡು ಟೇಬಲ್ಗಳು

Junos EVPN ನಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಪ್ರತಿ ಇನ್ಸ್ಟಾನ್ಸ್ಗೆ MAC ವಿಳಾಸಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಹೇಗೆ ಬಂದಿತು ಎಂಬುದನ್ನೂ ಸೇರಿಸುತ್ತದೆ: ಆಕ್ಸೆಸ್ ಪೋರ್ಟ್ನಿಂದ ಕಲಿತದ್ದು, Type 2 ಮಾರ್ಗದಲ್ಲಿ ಸ್ವೀಕರಿಸಿದ್ದು, ಅಥವಾ ಮಲ್ಟಿಹೋಮಿಂಗ್ ಗುಂಪಿನ ಭಾಗವಾಗಿ ಗುರುತಿಸಿದ್ದು. Juniper ನ show evpn database ಉಲ್ಲೇಖ ವೀಕ್ಷಣೆಯನ್ನು ಓದಲು ಸಾಧ್ಯವಾಗಿಸುವ ಪ್ರತಿ-MAC ಮತ್ತು ಪ್ರತಿ-ಇನ್ಸ್ಟಾನ್ಸ್ ಫಿಲ್ಟರ್ಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ಇದು ಇನ್ಸ್ಟಾನ್ಸ್ ಮತ್ತು MAC ಕೀಲಿಯ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಸಾರಾಂಶ, ಹಾರ್ಡ್ವೇರ್ ಫ್ರೇಮ್ಗಳನ್ನು ಸ್ವಿಚ್ ಮಾಡುವ ಟೇಬಲ್ ಅಲ್ಲ.

ಸ್ವಿಚಿಂಗ್ ಟೇಬಲ್ ಅದೇ ಫಾರ್ವರ್ಡಿಂಗ್ ಸ್ಥಿತಿ. ಎರಡೂ ಔಟ್ಪುಟ್ಗಳು MACಗಳನ್ನು VLAN ಅಥವಾ VNI ಸಂದರ್ಭದ ಪಕ್ಕದಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡುತ್ತವೆ, ಅದಕ್ಕೇ ಅವನ್ನು ಸಾಲು ಸಾಲಾಗಿ ಹೋಲಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕೇ ಹೋಲಿಕೆ ದಾರಿತಪ್ಪಿಸುತ್ತದೆ. ಡೇಟಾಬೇಸ್ನ ನಮೂದು ಮಾರ್ಗವು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು ಇನ್ಸ್ಟಾನ್ಸ್ಗೆ ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ; ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಅದನ್ನು ಫಾರ್ವರ್ಡಿಂಗ್ಗಾಗಿ ಸ್ಥಾಪಿಸಿದೆಯೇ ಎಂಬುದನ್ನು ಅದು ಹೇಳುವುದಿಲ್ಲ.

Type 2 ಮಾರ್ಗವು MAC, ಐಚ್ಛಿಕ IP, ಲೇಬಲ್ ಅಥವಾ VNI, ಮಾರ್ಗ ವ್ಯತ್ಯಾಸಕ ಮತ್ತು ದೂರದ VTEP ಅನ್ನು ಹೆಸರಿಸುವ ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ. ತಂತಿ ಮತ್ತು ಆ ಮಾರ್ಗದ ನಡುವೆ ನಾಲ್ಕು ವಿಷಯಗಳು ಮುರಿಯಬಹುದು: ಹೋಸ್ಟ್ ಎಂದಿಗೂ ಕಲಿಯಲ್ಪಡುವುದಿಲ್ಲ, ಮಾರ್ಗ ಎಂದಿಗೂ ಘೋಷಿಸಲ್ಪಡುವುದಿಲ್ಲ, ಇಂಪೋರ್ಟ್ನಲ್ಲಿ ಅದು ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತದೆ, ಅಥವಾ ಅದರ ಮುಂದಿನ ಹಾಪ್ ಬಗೆಹರಿಯುವುದಿಲ್ಲ. ಪ್ರತಿ ವೈಫಲ್ಯವು ಬೇರೆ ಟೇಬಲ್ ಗುಂಪನ್ನು ತುಂಬಿ ಬಿಡುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕೇ ಈ ಕ್ರಮವನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಸಾಧ್ಯ.

ಸ್ಥಳೀಯ ಕಲಿಕೆ ಇನ್ನೂ ಮೊದಲು ನಡೆಯುತ್ತದೆ

ಸಾಮಾನ್ಯ ಊಹೆ ಎಂದರೆ EVPN MAC ಕಲಿಕೆಯನ್ನು ವಹಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಖಾಲಿ ಡೇಟಾಬೇಸ್ ಓವರ್ಲೇ ಸಮಸ್ಯೆ ಎಂದರ್ಥವಾಗಬೇಕು. ಸ್ಥಳೀಯ ಕಲಿಕೆ ಇನ್ನೂ ಆಕ್ಸೆಸ್ ಬದಿಯಲ್ಲಿ ನಡೆಯುತ್ತದೆ, VXLAN ಇರುವ ಮೊದಲಿನಂತೆಯೇ: ಸ್ವಿಚ್ ಅನುಮತಿಸಿದ ಫ್ರೇಮ್ನ ಮೂಲ MAC ಅನ್ನು ಸರಿಯಾದ VLAN ಮತ್ತು ಸೇವೆಯಲ್ಲಿ ಕಲಿಯುತ್ತದೆ, ಮತ್ತು ನಂತರವೇ ಅದಕ್ಕೆ Type 2 ರಚಿಸುತ್ತದೆ. ಸಂಬಂಧಿತ ಫ್ರೇಮ್ ಕಳುಹಿಸದ ಹೋಸ್ಟ್ಗೆ ಘೋಷಿಸಲು ಏನೂ ಇಲ್ಲ. VLAN ಸದಸ್ಯತ್ವ, ಫಿಲ್ಟರ್ ಅಥವಾ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯ ಕೆಳಗಿರುವ ಸದಸ್ಯನಿಂದ ಯಾವ ಹೋಸ್ಟ್ನ ಫ್ರೇಮ್ಗಳು ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತವೆಯೋ ಅದು ಓವರ್ಲೇ ದೃಷ್ಟಿಯಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತದೆ.

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

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

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

ದೂರದ MAC ಎಲ್ಲಿ ಕಳೆದುಹೋಗುತ್ತದೆ

ದೂರದ MAC ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಮೌನವಾಗಿ. Type 2 ಮಾರ್ಗ ಬರುತ್ತದೆ, ಆದರೆ ಅದರ ಮಾರ್ಗ ಗುರಿ ಮತ್ತು VNI ಸ್ಥಳೀಯ ಸಂರಚನೆಗೆ ಹೊಂದಿದಾಗ ಮಾತ್ರ ಅದು ಇನ್ಸ್ಟಾನ್ಸ್ ಪ್ರವೇಶಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಮುಂದಿನ ಹಾಪ್ ತಲುಪಬಹುದಾದ VTEP ಗೆ ಬಗೆಹರಿದಾಗ ಮಾತ್ರ ಬಳಸಲು ಸಾಧ್ಯ. ಮಾರ್ಗ ಗುರಿಯ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವುದು BGP ಟೇಬಲ್ನಲ್ಲಿ ಯಾವ ಇನ್ಸ್ಟಾನ್ಸ್ ಕೂಡ ಕೇಳದ ಮಾನ್ಯ ಮಾರ್ಗವನ್ನು ಬಿಡುತ್ತದೆ.

ಮೂರು ವೀಕ್ಷಣೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಓದಿ: ಮಾರ್ಗದ ಅಸ್ತಿತ್ವ, ಡೇಟಾಬೇಸ್ ನಮೂದು, ಫಾರ್ವರ್ಡಿಂಗ್ ನಮೂದು. ಕೆಳಗಿನ ಆಜ್ಞೆಗಳು ಪ್ರತಿ ಹಂತದಲ್ಲಿ ಅದೇ MAC ಅನ್ನು ಕೇಳುತ್ತವೆ, ಮತ್ತು ಮಾದರಿ ವಿಳಾಸವು ಔಟ್ಪುಟ್ಗಳನ್ನು ಹೋಲಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

ಆ ಔಟ್ಪುಟ್ಗಳು ಮೂರು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ. bgp.evpn.0 ನಲ್ಲಿ ಮಾರ್ಗವಿದ್ದರೂ ಡೇಟಾಬೇಸ್ ನಮೂದು ಇಲ್ಲದಿದ್ದರೆ ಅದು ಇಂಪೋರ್ಟ್ ನೀತಿ, ಮಾರ್ಗ ಗುರಿ ಅಥವಾ ಇನ್ಸ್ಟಾನ್ಸ್ ಸಂರಚನೆಯತ್ತ ಸೂಚಿಸುತ್ತದೆ. ಡೇಟಾಬೇಸ್ ನಮೂದು ಇದ್ದರೂ ಫಾರ್ವರ್ಡಿಂಗ್ ನಮೂದು ಇಲ್ಲದಿದ್ದರೆ ಅದು ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ನತ್ತ ಸೂಚಿಸುತ್ತದೆ, ಅದು ಬೇರೆ ಎಸ್ಕಲೇಶನ್ ಮಾರ್ಗಕ್ಕೆ ಸೇರುತ್ತದೆ. ಮುಂದಿನ ಹಾಪ್ ಬಗೆಹರಿಯದ ಸಕ್ರಿಯ ಮಾರ್ಗ ಸಾರಿಗೆ ಅಥವಾ ಲೇಬಲ್ ಸಮಸ್ಯೆ, ಮತ್ತು MAC ಡೀಬಗ್ಗಿಂಗ್ನ ಯಾವುದೇ ಪ್ರಮಾಣ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.

ಅದನ್ನು ಸರಿಪಡಿಸಿದ ರೀಬೂಟ್ ತುಂಬಾ ಕಡಿಮೆ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ

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

ಯಾವುದೇ ನಿರ್ವಹಣಾ ವಿಂಡೋ ಮೊದಲು ರೀಸ್ಟಾರ್ಟ್ ಏನನ್ನು ಅಳಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ. ಈ ಮೂರು ಆಜ್ಞೆಗಳು ಮೊದಲು ಮತ್ತು ನಂತರ ಹೋಲಿಸಲು ಸಾಕು, ಮತ್ತು ಸಾಧನದಲ್ಲಿ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ.

show evpn database instance blue
show route table bgp.evpn.0
show version

ಆ ಔಟ್ಪುಟ್ಗಳನ್ನು ದಿನಾಂಕ ಮತ್ತು ಸಾಫ್ಟ್ವೇರ್ ಬಿಲ್ಡ್ನೊಂದಿಗೆ ಸಂಗ್ರಹಿಸಿ. ಅದೇ ರೀಸ್ಟಾರ್ಟ್ ಮೊದಲು ಕೆಲಸ ಮಾಡಿತ್ತು ಎಂಬ ನಂತರದ ವರದಿ ಸುಳಿವು, ಸಾಕ್ಷಿ ಅಲ್ಲ, ಮತ್ತು ಹಿಂದಿನ ಔಟ್ಪುಟ್ ಅನ್ನು ಯಾರಾದರೂ ಇಟ್ಟುಕೊಂಡಾಗ ಮಾತ್ರ ವ್ಯತ್ಯಾಸ ಕಾಣಿಸುತ್ತದೆ.

ಹೆಚ್ಚಿನ ಪ್ರಕರಣಗಳನ್ನು ನಿರ್ಣಯಿಸುವ ನಾಲ್ಕು ಅವಲೋಕನಗಳು

ನಾಲ್ಕು ಅವಲೋಕನಗಳು ಬಹುತೇಕ ಎಲ್ಲಾ ಪ್ರಕರಣಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತವೆ: ಅಟ್ಯಾಚ್ಮೆಂಟ್ ಮತ್ತು ಅದರ ಸೇವೆ, ಮಾದರಿ ಮೌಲ್ಯವಾಗಿ MAC, ಮಾರ್ಗ ಮತ್ತು ಡೇಟಾಬೇಸ್ನ ಸ್ಥಿತಿ, ಮತ್ತು ಬಳಕೆಯಲ್ಲಿರುವ ಬಿಲ್ಡ್. ಸ್ಪಷ್ಟವಾಗಿ ಮಾದರಿಯಾದ MAC ಆಯ್ಕೆಮಾಡಿ, ಯಾರೂ ಅದನ್ನು ಉತ್ಪಾದನಾ ವಿಳಾಸ ಎಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸದಂತೆ: ಮೊದಲ ಆಕ್ಟೆಟ್ 02 ಸ್ಥಳೀಯವಾಗಿ ನಿರ್ವಹಿಸಲಾದ ಯುನಿಕಾಸ್ಟ್ ವಿಳಾಸವನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಉಳಿದ ಆಕ್ಟೆಟ್ಗಳು ಮುಕ್ತವಾಗಿವೆ, ಆದ್ದರಿಂದ 02:00:00:00:00:5c ಸುರಕ್ಷಿತ ಪ್ಲೇಸ್ಹೋಲ್ಡರ್.

ನಂತರ ಉತ್ತರಗಳು ವಿಫಲವಾದ ಹಂತವನ್ನು ಸೂಚಿಸಲಿ. ಅಟ್ಯಾಚ್ಮೆಂಟ್ನಲ್ಲಿ ಕಲಿಕೆ ಇಲ್ಲದಿರುವುದು ಆಕ್ಸೆಸ್ ಬದಿ; ಡೇಟಾಬೇಸ್ ನಮೂದು ಇಲ್ಲದ ಮಾರ್ಗ ಇಂಪೋರ್ಟ್; ಫಾರ್ವರ್ಡಿಂಗ್ ಸ್ಥಿತಿ ಇಲ್ಲದ ಡೇಟಾಬೇಸ್ ನಮೂದು ಪ್ರೋಗ್ರಾಮಿಂಗ್. ಏನೇ ಆಗಲಿ, ಸಂಗ್ರಹಿಸಿದ ಔಟ್ಪುಟ್ಗಳನ್ನು ಹೋಸ್ಟ್, ಇಂಟರ್ಫೇಸ್, ಸೇವೆ ಮತ್ತು ಬಿಲ್ಡ್ನೊಂದಿಗೆ ಹಸ್ತಾಂತರಿಸಿ, ಇದರಿಂದ ಮುಂದಿನ ಇಂಜಿನಿಯರ್ ಪ್ರಶ್ನೆಯನ್ನು ಪುನರಾವರ್ತಿಸುವ ಬದಲು ಮಾರ್ಗವನ್ನು ಮರುಸೃಷ್ಟಿಸಬಹುದು.