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 సురక్షిత ప్లేస్‌హోల్డర్.

తర్వాత సమాధానాలు విఫలమైన దశను సూచించనివ్వండి. అటాచ్‌మెంట్‌లో అభ్యాసం లేకపోవడం యాక్సెస్ వైపు; డేటాబేస్ ఎంట్రీ లేని మార్గం ఇంపోర్ట్; ఫార్వర్డింగ్ స్థితి లేని డేటాబేస్ ఎంట్రీ ప్రోగ్రామింగ్. ఏదైనా, సేకరించిన అవుట్‌పుట్‌లను హోస్ట్, ఇంటర్‌ఫేస్, సేవ మరియు బిల్డ్‌తో అప్పగించండి, తద్వారా తదుపరి ఇంజనీర్ ప్రశ్నను పునరావృతం చేయకుండా మార్గాన్ని పునఃసృష్టించగలరు.