IPv6 i ett MPLS-VPN: tre val, inte en enda adressfamilj
Kundens VPN-rutter, BGP-sessionen mellan PE och transporten i kärnan är separata beslut. En session kan köra i en familj och bära en annan.
Säg „kör en IPv6 L3VPN över IPv6 BGP“ i en designgenomgång, och i den enda meningen gömmer sig tre separata beslut. Vilka prefix som hör till kundens VPN, vilka adresser som bär routingsessionen mellan leverantörens kanter och vilken kärna som flyttar det märkta paketet är oberoende val. De kan alla vara IPv6, de kan vara blandade, och blandning är med avsikt tillåten. Det är uppredningen av de tre som gör ett vagt krav till något en plattform kan testas mot.
Separera de tre uppgifterna
Den första uppgiften är kundrutten: IPv6-prefix som hör till en VPN-routingkontext och måste hållas utanför varje annan kontext. Den andra är routingförbindelsen mellan leverantörens kantroutrar som utbyter dessa prefix. Den tredje är transporten som bär det märkta kundpaketet genom kärnan till den avlägsna kanten. Att namnge bara en av dem är ännu inte en design.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
Varje uppgift har sin egen adressfamilj, sina egna fellägen och ofta sitt eget team. Tabellen är användbar just för att en mening i ett designdokument tenderar att pressa ihop alla tre raderna till en.
Rutefamiljen är VPN-IPv6, inte IPv6 unicast
RFC 4659 definierar BGP/MPLS IPv6 VPN-familjen, och medlemskap i den är mer specifikt än ordet IPv6 antyder. En rutt där är en routedistinguisher kopplad till ett IPv6-prefix, kodad under AFI 2 och SAFI 128. Vanlig IPv6 unicast är en annan familj, så ett annonsmeddelande som i ett looking glass ser ut som ett prefix är kanske inte alls samma objekt. Att läsa familjen fel är det första sättet den här designen går snett.
Skillnaden biter vid kanten, där en rutt först måste landa i rätt VPN-kontext innan den gör något. Att ta emot ett prefix bevisar att utbytet skedde och säger inget om installationen. Den luckan ger den klassiska rapporten där sessionen är uppe och kunden fortfarande är mörk.
Sessionen kan köra i en annan familj än VPN:en
Inget tvingar BGP-förbindelsen mellan två kanter att använda VPN:ens egen familj. Specifikationen tillåter en IPv4- eller IPv6-session, och IPv6 VPN-transport är själv definierad över båda kärntyperna. En IPv6-session säger därför inget om familjen hos det den bär, och den väljer inte heller dataplanet. Tre oberoende bitar, och designen bör bära alla tre var för sig.
Det befriar och är lätt att läsa fel i samma andetag. IPv6-kundrutter kan rida på en session med IPv4-adress, och IPv4-rutter på en IPv6-session, förutsatt att plattformen stöder kombinationen och att nästa hopp löses upp. Det som inte får hända är att låta sessionen antyda nyttolasten, i designdokumentet eller i övervakningen som senare bevisar tjänsten.
Nästa hopp på en IPv4-kärna har sin egen kodning
När kärnan under VPN:en är IPv4 visas rutten inte med ett nästa hopp som ingångskanten kan använda direkt. Den kommer i IPv4-mappad IPv6-form, och så uttrycker specifikationen utgångskanten när transporten under är IPv4. Ingångsroutern måste då göra den mappade adressen till något den faktiskt kan nå genom kärnan, och upplösningen är steget som tyst misslyckas.
Läs det som ett vidarebefordringsberoende och inte som en sträng att kopiera mellan enheter. Bekräfta tre saker på plattformen du faktiskt driftar: det annonserade nästa hoppet löses upp till en användbar väg, etikettstacken accepteras och målet landar i den avsedda VPN-kontexten. Faller något av dem ut blir kvar en session som ser frisk ut och inte vidarebefordrar något, och därför hör kontrollen hemma i acceptanskörningen och inte i en senare incident.
Skriv kravet på fyra rader
Ett krav som är värt att testa namnger fyra saker: VPN-familjen, sessionens transport, kodningen av nästa hopp och kärnans upplägg. Sedan namnger det ett kundprefix att följa från ände till ände: genom utbyte, installation, etikettupplösning och returväg. „Stöder IPv6 BGP“ täcker ingen av de fyra och döljer var missanpassningen faktiskt sitter.
En frisk session utan VPN-IPv6-utbytet är ofullständig, och en mottagen VPN-rutt utan fungerande vidarebefordran är lika ofullständig. Att hålla dem som separata acceptansrader gör nästa felsökningssamtal kort, eftersom raden som fallerar redan är nedskriven.