సైట్ లోపల అదే iESI, సైట్ల మధ్య ప్రత్యేకం: Junos కుట్టు

రెండు గేట్వే జోడీలు రెండు డేటా సెంటర్లకు సేవ చేస్తాయి, మరియు డిజైన్కు ఎన్ని interconnect ESI విలువలు కావాలో ఎవరో నిర్ణయించాలి. సమాధానం ప్రతి గేట్వే సమూహానికి ఒకటి, ప్రతి fabricకు ఒకటి కాదు మరియు ప్రతి గేట్వేకు ఒకటి కాదు. దీన్ని తప్పుగా చేస్తే కాన్ఫిగర్ చేసినట్లు కనిపించే మరియు తప్పు forwarder ఎంచుకునే fabric ఏర్పడుతుంది, లేదా వేరుగా ఉండాల్సిన రెండు సైట్లు విలీనమవుతాయి. నియమం మరియు దాని మినహాయింపులు గేట్వే జాబితా పక్కన రాయదగినవి.

రెండు పరిధులు, రెండు నియమాలు

సైట్ లోపల, అదనపు interconnect గేట్వేలు ఒక multihomed ముగింపు బిందువుగా పనిచేస్తాయి, కాబట్టి అవి ఒకే interconnect ESIని పంచుకుంటాయి. వాటి peers రెండు స్వతంత్ర సభ్యులకు బదులు ఒక తార్కిక సభ్యుడిని చూడాలి. పంచుకున్న విలువ యొక్క మొత్తం అర్థం అదే.

సైట్ల మధ్య, ప్రతి గేట్వే సమూహం తన సొంత విలువను పొందుతుంది. ఒకే గుర్తింపును పంచుకునే రెండు డేటా సెంటర్లు నియంత్రణ తలంలో ఒక multihomed సమూహంగా మారుతాయి, ఇది సాధారణంగా WAN ద్వారా కుట్టు డిజైన్ ఉద్దేశించేది కాదు. ఒక సమూహంలోని రెండు సైట్లు ఒకదానికొకటి వైఫల్య మోడ్లను కూడా వారసత్వంగా పొందుతాయి.

సైట్ లోపల: సమూహానికి ఒక గుర్తింపు

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

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

సైట్ల మధ్య: వేర్వేరు విలువలు, లేదా ఉద్దేశపూర్వక విలీనం

ప్రతి సైట్కు ప్రత్యేకమైన విలువ రెండు గేట్వే సమూహాలను వేరుగా ఉంచుతుంది. ఉద్దేశం నిజంగా ఒక multihomed సమూహాన్ని సైట్ల మధ్య విస్తరించడమే అయితే, అది దాని సొంత ఆలస్యం, వైఫల్యం మరియు ఫార్వార్డింగ్ పరిణామాలతో కూడిన మరో నిర్మాణం, మరియు దాన్ని గుర్తింపు ఎంపికగా కాకుండా నిర్మాణంగా నిర్ణయించాలి. నిర్వహణ విండో ముందు ఆ నిర్ణయాన్ని లిఖితపూర్వకంగా కోరండి.

ఉద్దేశించిన భేదాన్ని ప్రణాళికలో రాయండి, తద్వారా తర్వాత పని చేసే సైట్ టెంప్లేట్ను కాపీ చేసే ఇంజనీర్ దాని గుర్తింపును కూడా తీసుకురాడు.

peer ప్రకటన గుర్తింపులో భాగం

సమూహంలోని ప్రతి గేట్వే తన స్థానిక peersను 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 మార్పుగా సమీక్షించబడుతుంది. గుర్తింపు చిత్రం చెప్పినట్లు చేస్తుందనడానికి ఫలితాలే ఏకైక సాక్ష్యం.