ఇద్దరు కస్టమర్లకు ఒకే /24? VPNv4 కు RD మరియు లేబుల్ కావాలి
ఇద్దరు అద్దెదారులు ఒకే /24 ప్రకటించగలిగేది RD ప్రతి మార్గానికి దాని సొంత గుర్తింపును ఇస్తుంది కాబట్టే. లేబుల్ మరో ప్రశ్నకు సమాధానం ఇస్తుంది: ఎలా ఫార్వర్డ్ చేయాలి.
ఇద్దరు అద్దెదారులు తమ శాఖను ఒకే 10.50.0.0/24 తో సంఖ్యా క్రమంలో పెడతారు, మార్పు తర్వాత ఒకరి మార్గం ప్రొవైడర్ అంచు నుండి మాయమవుతుంది, మరొకరు పని చేస్తూనే ఉంటారు. ఆ టికెట్ వెనుక ఉన్న సరళీకరణ సాధారణంగా మార్గ భేదకాన్ని (RD) వదిలేయడం, ఎందుకంటే "లేబుల్ ఇప్పటికే కస్టమర్ను గుర్తిస్తుంది". అలా చేయదు. RD మరియు లేబుల్ రెండు వేర్వేరు ప్రశ్నలకు సమాధానం ఇస్తాయి, ఈ అంతరం అతివ్యాప్తి చెందే చిరునామాలు బలవంతం చేసినప్పుడే కనిపిస్తుంది.
రెండు ఉండాల్సిన చోట ఒక మార్గం
సాధారణ IPv4 యూనికాస్ట్ ఒకే ప్రిఫిక్స్కు రెండు మార్గాలను పోల్చి మెరుగైనది ఇన్స్టాల్ చేస్తుంది. అద్దెదారు A నుండి 10.50.0.0/24 మరియు అద్దెదారు B నుండి 10.50.0.0/24 ఒకే కీ, కాబట్టి ఒకటి గెలుస్తుంది, మరొకటి బ్యాకప్ మార్గంగా మాత్రమే నిలిచి ఉంటుంది. ప్రోటోకాల్ చెప్పినట్లు చేసింది; నియంత్రణ తలానికి రెండు వేర్వేరు మార్గాలను ఒకే గుర్తింపు కింద నిల్వ చేయమని కోరారు.
ఫలితం లోపంగా కాకుండా పోయిన మార్గంగా కనిపిస్తుంది: పోటీలో ఓడిన PE ఇప్పటికీ తన అద్దెదారును స్థానికంగా ఫార్వర్డ్ చేస్తుంది, కాబట్టి సైట్ లోపలి పరీక్ష విజయవంతమవుతుంది, సైట్ల మధ్య పరీక్ష విఫలమవుతుంది. ఏదైనా విధానాన్ని తాకే ముందు VPNv4 పట్టికలో ఆ ప్రిఫిక్స్ నమోదులను లెక్కించండి.
RD ఒక కీని రెండుగా మారుస్తుంది
ఎనిమిది బైట్ల మార్గ భేదకం IPv4 ప్రిఫిక్స్ ముందు చేర్చబడుతుంది, BGP మోసే వస్తువు IPv4 ప్రిఫిక్స్ బదులు VPN-IPv4 చిరునామా అవుతుంది. ఇద్దరు అద్దెదారులు ఒకే 32 బిట్లను ఉంచుకోగలిగేది ముందున్న 64 బిట్లు భిన్నంగా ఉండటం వల్ల. AS ఆధారిత RD మరియు చిరునామా ఆధారిత RD కోసం ఆకృతి రకాలు ఉన్నాయి, ఎంపిక మూల PE కు చెందుతుంది. PE లు ఒకే AS పంచుకున్నప్పుడు AS ఆధారిత RD సాధారణం, పంచుకోనప్పుడు చిరునామా ఆధారితం.
RD ను సభ్యత్వ ట్యాగ్గా చదవవద్దు. మార్గ లక్ష్యాలు దిగుమతి మరియు ఎగుమతిని నియంత్రిస్తాయి మరియు ఏ VRF లు మార్గాన్ని ఇన్స్టాల్ చేయగలవో నిర్ణయిస్తాయి; RD మార్గానికి దాని సొంత గుర్తింపు ఉందని మాత్రమే హామీ ఇస్తుంది. ప్రతి VRF కు దాని సొంత RD ఇవ్వడం సాధారణ పద్ధతి, ఎందుకంటే అది ఆ మ్యాపింగ్ను మార్గ వీక్షణలో చదవగలిగేలా ఉంచుతుంది.
లేబుల్ స్థానిక ఫార్వర్డింగ్ సూచన
ప్రతి ప్రకటన MPLS లేబుల్ను కూడా మోస్తుంది, దాని అర్థం దాన్ని కేటాయించిన రౌటర్కు మాత్రమే పరిమితం. మరో PE సంబంధం లేని గమ్యానికి అదే సంఖ్యను ఇవ్వవచ్చు. అందుకే లేబుల్ కస్టమర్ గుర్తింపును భర్తీ చేయలేదు: సంఖ్య తదుపరి హాప్ మరియు దాన్ని ఇన్స్టాల్ చేసిన ఫార్వర్డింగ్ స్థితి పక్కన మాత్రమే సరైనది.
కేటాయింపు సూక్ష్మత అమలు మరియు రూపకల్పనను బట్టి మారుతుంది: కొన్ని ప్లాట్ఫారమ్లు ప్రతి VRF కు ఒక లేబుల్ కేటాయిస్తాయి, మరికొన్ని ప్రతి ప్రిఫిక్స్కు, మరియు లేబుల్ కస్టమర్ను కాకుండా ఫార్వర్డింగ్ చర్యను గుర్తించవచ్చు. ఒకే గమ్యానికి చేరే రెండు వేర్వేరు లేబుళ్లు వైరుధ్యం కాదు, రెండు PE లలో ఒకే లేబుల్ సంఖ్య కూడా కాదు.
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
ఒకటి మరొకదాన్ని ఎందుకు భర్తీ చేయలేదు
ప్రకటన చదవడం అంటే నాలుగు విషయాలను కలిసి చూడటం: RD అర్హత పొందిన ప్రిఫిక్స్, మార్గ లక్ష్యాలు, తదుపరి హాప్ మరియు లేబుల్. వినియోగదారు ప్యాకెట్ చదవడం అంటే ఆ సమాచారం నుండి ఇన్స్టాల్ చేసిన స్టాక్ను చూడటం. ఆరోగ్యకరమైన రూపకల్పన రెండు వైపులా సరిపోలుతున్నట్లు చూపిస్తుంది, విరిగిన దానిలో సాధారణంగా ఒక వైపు సరిగ్గా, మరొకటి పాతదిగా ఉంటుంది. ఆ పోలికే గుర్తింపు సమస్యను ఫార్వర్డింగ్ సమస్య నుండి వేరు చేస్తుంది.
నియంత్రణ తలం మరియు డేటా తలం మధ్య చక్కటి విరుద్ధత బోధనా సాధనం, ఎన్కోడింగ్ వివరణ కాదు. RFC 8277 లేబుల్ను లేబుల్ చేసిన NLRI లోపల ఉంచుతుంది, కాబట్టి ప్రకటనే బంధనాన్ని మోస్తుంది; దాన్ని ఫార్వర్డింగ్ కోసం ఉపయోగించడం తర్వాతి, ప్రత్యేక దశ.
అద్దెదారు మార్గం పోయినప్పుడు, ఈ క్రమంలో తనిఖీ చేయండి: ప్రిఫిక్స్ కోసం రెండు VPNv4 నమోదులు, ప్రతి దానిపై సరైన మార్గ లక్ష్యం, పరిష్కరించగల తదుపరి హాప్, మరియు స్వీకరించే PE కు స్థితి ఉన్న లేబుల్. గుర్తింపును ఫార్వర్డింగ్ విలువతో సరిచేయడం, లేదా దానికి విరుద్ధంగా, ఒక తనిఖీలో ఉత్తీర్ణమై తర్వాత దానిలో విఫలమవుతుంది.