all-active EVPN-లో Linux క్రియాశీల-బ్యాకప్ బాండ్: ఏం విరుగుతుంది

సర్వర్పై క్రియాశీల-బ్యాకప్ బాండ్ పెట్టండి, ఫ్యాబ్రిక్పై all-active ఈథర్నెట్ సెగ్మెంట్ పెట్టండి, తిరిగి వచ్చే ట్రాఫిక్లో సగం ఒక్క లోపం కౌంటర్ కదలకుండానే కనుమరుగైపోవచ్చు. రెండు కాన్ఫిగరేషన్లలో ఏదీ తనంతట తాను తప్పు కాదు. సమస్య వాటి మధ్య అప్పగింతలో ఉంది, అక్కడ ఒక వైపు ఒకే పోర్టును ఎంచుకుంటుంది, మరో వైపు కనెక్ట్ అయిన ప్రతి లీఫ్ పంపగలదని ఊహిస్తుంది. ప్రతి దిశలో ఒక ఫ్రేమ్ను అనుసరించండి, అసంగతి స్పష్టమవుతుంది.

వచ్చే ఫ్రేమ్తో క్రియాశీల-బ్యాకప్ ఏం చేస్తుంది

బాండింగ్ మోడ్ 1 పంపే మార్గంలో సరిగ్గా ఒక slave ఉంచుతుంది, ప్రస్తుతది విఫలమైనప్పుడే దాన్ని మారుస్తుంది. ఆ భాగం బాగా తెలిసింది. ఇక్కడ ముఖ్యమైంది స్వీకరణ వైపు: kernel ఫ్రేమ్ను స్టాక్కు ఇచ్చేది అది క్రియాశీల slaveపై వచ్చినప్పుడే, మరే ఇతర slaveపై కనిపించే ఫ్రేమ్లను పడేస్తుంది. ఈ all_slaves_active సెట్టింగ్ ఆ నియమాన్ని సడలించడానికే ఉంది, డిఫాల్ట్గా ఇది ఆఫ్లో ఉంది. ip -d link show bond0 మోడ్ పక్కన ప్రస్తుత విలువను ముద్రిస్తుంది.

/proc/net/bonding/bond0 క్రియాశీల slaveను పేర్కొంటుంది, ప్రతి slaveకి లింక్ స్థితిని నివేదిస్తుంది. ఇప్పుడు ఏ పోర్టు ట్రాఫిక్ మోస్తోందనేందుకు ఆ ఫైలే ఏకైక నిజాయితీ మూలం.

ఈ మోడ్లో హోస్ట్కు ఒకేసారి ఒకే వాడదగిన స్వీకరణ మార్గం ఉంటుంది, అది ఫ్యాబ్రిక్ గురించి తెలియకుండా స్థానికంగా ఎంపిక చేయబడుతుంది. ఆ హోస్ట్ కోసం ఫ్రేమ్ మరో కేబుల్పై వస్తే, స్విచ్ పోర్టు దాన్ని స్వీకరించినట్టు లెక్కిస్తుంది, హోస్ట్ స్టాక్ దాన్ని ఎప్పటికీ చూడదు, హోస్ట్ సొంత డ్రాప్ కౌంటర్ తప్ప మిగతా అన్ని కౌంటర్లు పూర్తిగా ఆరోగ్యంగా కనిపిస్తాయి.

all-active మల్టీహోమింగ్ దూరపు తదుపరి హాప్తో ఏం చేస్తుంది

EVPN మల్టీహోమింగ్ ESIతో గుర్తించబడే ఒక ఈథర్నెట్ సెగ్మెంట్ను పంచుకునే లీఫ్ల సమితిని వివరిస్తుంది, ఆ సెగ్మెంట్ను మిగిలిన ఫ్యాబ్రిక్కు ప్రకటిస్తుంది. all-active నమూనాలో దూరపు పీర్లు సెగ్మెంట్ చిరునామాలకు ఒకటి కంటే ఎక్కువ తదుపరి హాప్లను ఇన్స్టాల్ చేస్తారు. సర్వర్ వైపు unicast అప్పుడు ఏ లీఫ్కైనా చేరుకోవచ్చు, ఫ్యాబ్రిక్ ప్రతి ప్రవాహానికి స్వేచ్ఛగా ఎంచుకోవచ్చు. ఇదే డిజైన్ మొత్తం ఉద్దేశం, సర్వర్ బాండ్ నెరవేర్చాల్సిన ఊహ కూడా ఇదే.

వరద ట్రాఫిక్ వేరే నియమాన్ని అనుసరిస్తుంది. లీఫ్లు ప్రతి సెగ్మెంట్కు నియమిత ఫార్వర్డర్ను ఎంచుకుంటాయి, కాబట్టి broadcast, తెలియని unicast, multicast సాధారణంగా వాటిలో ఒకటి ద్వారా ప్రవేశిస్తాయి. అందువల్ల unicast, వరద రెండు వేర్వేరు నిర్ణయాలు తీసుకుంటాయి, వాటిలో ఒకటి మాత్రమే హోస్ట్ బాండ్ స్థితిలో కనిపిస్తుంది.

రెండు ఎంపికలు విభేదించే చోటు

kernel దాని క్రియాశీల slaveను లింక్ స్థితి, తన స్వంత విధానం నుంచి ఎంచుకుంటుంది. ఫ్యాబ్రిక్ తదుపరి హాప్లను EVPN మార్గాల నుంచి, నియమిత ఫార్వర్డర్ను లీఫ్ల మధ్య ఎంపిక నుంచి ఎంచుకుంటుంది. ఏ ప్రక్రియా మరొకదాన్ని సంప్రదించదు. అవి వేర్వేరు లీఫ్లను ఎంచుకుంటే వైఫల్యం దిశపై ఆధారపడి ఉంటుంది: సర్వర్ పంపేది సాధారణంగా బయటకు వెళ్తుంది, సమాధానాలు మాయమవుతాయి.

రెండు మద్దతు మార్గాలు ఉన్నాయి, అవి ఒకదానికొకటి ప్రత్యామ్నాయం కావు. ఫ్యాబ్రిక్ ఒకే తార్కిక కనెక్షన్గా పరిగణించగల బాండ్ను హోస్ట్కు ఇవ్వండి, ఆచరణలో ఇది లీఫ్లతో చర్చించిన LACP బాండ్, రెండు లింకులు నిజంగా కలిసి క్రియాశీలంగా ఉంటాయి. లేదా ఫ్యాబ్రిక్ నుంచి single-active పంపిణీని కూడా అంగీకరించండి, సెగ్మెంట్ బాండ్ లాగానే ఒక-పోర్టు-ఒకసారి నమూనాను అనుసరిస్తుంది. పనిచేయనిది ఒకే పోర్టులో వినిపించే బాండ్ ముందు all-active సెగ్మెంట్ పెట్టడం, మీరు ఉద్దేశపూర్వకంగా నిష్క్రియ slaveలపై స్వీకరణ ఆన్ చేసి దాని తర్వాత వచ్చే ద్వంద్వ పంపిణీని అంగీకరించకపోతే.

బ్యాకప్ కేబుల్ ఆరోగ్యంగా కనిపిస్తూనే ఉండేది ఎందుకు

ట్రాఫిక్ మోయని కేబుల్ కూడా లింక్ అప్ అని నివేదిస్తుంది, బాండ్లోని స్టాండ్బై slave సిద్ధంగా కనిపించేలా రూపొందించబడింది. ఆపరేటర్లు దాన్ని పునరావృత్తిగా చదివి ప్రశ్నలు అడగడం మానేస్తారు.

బదులుగా తిరిగి వచ్చే ఫ్రేమ్ ఏ భౌతిక పోర్టును వాడిందో అడగండి. హోస్ట్పై, బాండ్కు బదులు slaveకు స్వీకరించిన ప్యాకెట్లను లెక్కించండి, ఎందుకంటే బాండ్ కౌంటర్ అసమానతను దాచుతుంది. లీఫ్పై, చూడండి సర్వర్ MAC కోసం బ్రిడ్జ్ ఫార్వర్డింగ్ నమోదులు మరియు EVPN మార్గం మోసే తదుపరి-హాప్ సమితి. నమోదు హోస్ట్ లింక్ స్టాండ్బై ఉన్న లీఫ్ను సూచిస్తే, డిజైన్ హోస్ట్ నిర్లక్ష్యం చేసే పోర్టుకు పంపిస్తోంది. ఇది హార్డ్వేర్ లోపం కాదు, కాన్ఫిగరేషన్ అసంగతి, ఎంత లింక్-స్థితి పర్యవేక్షణ చేసినా అది బయటపడదు.

రెండు దిశల్లో పంపిణీని పరీక్షించండి, లింక్ స్థితిని కాదు

ప్రతి వైఫల్యానికి ఒక వరుస, ప్రతి దిశకు ఒక నిలువు వరుస ఉన్న మ్యాట్రిక్స్ నిర్మించి, ఇంటర్ఫేస్ స్థితికి బదులు పంపిణీ అయిన ట్రాఫిక్ నింపండి. మొదటి వరుస సాధారణ నిర్వహణ, అసంగతి అక్కడే దాగి ఉంది, ఎందుకంటే లక్షణం అప్లికేషన్ సమస్యలా కనిపిస్తుంది.

తర్వాత క్రియాశీల హోస్ట్ లింక్ను తీసేయండి, ఒక లీఫ్ను తీసేయండి, ఆ లీఫ్ అప్లింక్లను తీసేయండి, ప్రతిదాన్ని వరుసగా పునరుద్ధరించండి. ప్రతి దశ తర్వాత క్రియాశీల slave, EVPN సెగ్మెంట్ స్థితి, దూరపు ఫార్వర్డింగ్ నమోదు, రెండు దిశల్లో గమనించిన throughput నమోదు చేయండి. హోస్ట్ లింక్ పైన ఉండగా ఫ్యాబ్రిక్ మార్గాన్ని కోల్పోయే లీఫ్ ఆసక్తికరమైన సందర్భం, ఎందుకంటే కనెక్షన్ ప్రకటించబడుతూనే ఉంటుంది, నిశ్శబ్దంగా చివరి వీధి కావచ్చు. కొత్త unicast ప్రవాహాలతో, అప్లికేషన్ ఆధారపడే వరద ట్రాఫిక్తో పరీక్షించండి, ఎందుకంటే రెండూ వేర్వేరు ఫార్వర్డింగ్ నిర్ణయాలు తీసుకుంటాయి.

మీరు ఉద్దేశించిన మార్గం ద్వారా ద్విదిశ పంపిణీని మ్యాట్రిక్స్ చూపితేనే డిజైన్ను అంగీకరించండి. లింక్ అప్లో ఉన్న రెండు కేబుళ్లు ఆ ఫలితం కాదు.