Varför BGP över en VPN inte styr underlagets väg

Två platser peerar BGP över en IPsec-tunnel, lär sig varandras prefix och diagrammet byter namn till vägkontroll. Det är den etiketten som startar förvirringen. Sessionen utbyter nåbarhet och tillämpar politik, men den har inget att säga om vilken leverantör, kabel eller router som transporterar de krypterade paketen. Jag har sett ett team bygga om en fungerande tunnel eftersom de förväntade sig att en BGP-rutändring skulle flytta trafiken till en annan fiberväg som sessionen aldrig kunde påverka.

Vad folk tror att en session köper

Det mesta av förväntan kommer från hur en rutändring ser ut i ett labb. Du annonserar ett prefix över tunneln, den bortre sidan installerar det och trafiken flyttar sig. Samma sekvens händer på en router som faktiskt har rattar för trafikteknik, så de två blandas ihop. I labbet delar båda platserna oftast en enda accesslänk, och det är just därför skillnaden aldrig syns där.

BGP är ett nåbarhetsprotokoll. Det berättar för en peer att du kan leverera paket för ett prefix och låter varje sida rangordna de erbjudanden den får. Det är verkligen användbart över en tunnel: prefix dyker upp och försvinner när platser kommer och går, och du kan avvisa ett intervall utan att skriva en statisk rutt på varje kantutrustning. Vad det inte gör är att sätta en leverantörs routrar under din kontroll.

Underlaget bär det yttre huvudet. Din tunnelslutpunkt skickar krypterade paket till en peer-adress, och nätet mellan de två adresserna vidarebefordrar dem med de rutter som dess operatörer har installerat. Ingenting i BGP-sessionen ändrar det beslutet, om inte samma leverantör erbjuder en stödd tjänst som gör det.

Vad sessionen faktiskt bär

BGP-talaren öppnar en TCP-anslutning till port 179 hos sin peer och använder meddelandeformaten och vägattributen som definieras i RFC 4271. När peer-adressen ligger inne i tunneln måste tunneln vara uppe och adressen nåbar innan sessionen ens kan börja. Ett slutfört IKE-utbyte är inte en BGP-granne. Ruttbaserade IPsec-implementationer släpper igenom trafik först när en matchande tunnelrutt finns, och den policybaserade behöver peer-adressen inne i den skyddade väljaren. Att vända på detta ger det klassiska tillståndet där tunneln är grön och sessionen sitter sysslolös.

När sessionen är uppe bestämmer politiken vad som korsar den. Prefixlistor, AS-path-filter, ett tak för maximalt antal prefix och ett uttryckligt beslut om standardrutter är minimum, och de gäller i båda riktningarna. En peer som accepterar allt den tar emot kan ge dig en standardrutt som tyst ersätter den lokala internetåtkomsten. De två riktningarna behöver separata listor, eftersom det du accepterar från en peer och det du annonserar till den är två olika beslut.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Sedan biter MTU. Inkapslingen krymper nyttolasten, så en stor uppdatering kan stoppa en session som ser perfekt etablerad ut: peeren blir kvar uppe, prefixen kommer aldrig och inget uppenbart hamnar i loggen. Begränsa TCP MSS på tunnelgränssnittet, eller sätt en tunnel-MTU med plats för overhead, innan du skyller på filtren.

Vart de yttre paketen fortfarande tar vägen

Krypterade paket från en plats till den andra går ut genom det som den lokala routern väljer för peerens publika adress. Om båda platserna köper transit från samma leverantör, korsar samma metronät eller ena sidan sitter bakom carrier-grade NAT, överlever tunneln ett leverantörsavbrott bara av en slump. Att räkna tunnelikoner i ett övervakningsverktyg säger ingenting om detta.

Ruttval och installation av vidarebefordran är också separata händelser. Ett prefix kan sitta i BGP-tabellen som det bästa och ändå saknas i vidarebefordranstabellen, eftersom nästa hopp inte går att lösa upp eller en mer specifik rutt vinner. När någon rapporterar att BGP har lärt sig prefixet men att trafiken inte flyter, är den användbara frågan om det är installerat och vilket nästa hopp det pekar på.

Det ärliga svaret för en designgenomgång är en lista över delade beroenden: accesskrets, uppströmsleverantör, anläggning och varje tillståndsbärande enhet på returvägen. En session över tunneln kan inte ta bort ett beroende som den inte sitter ovanpå.

Tre beslut som det är värt att skilja på

När en design blandar dessa går varje avbrottsdiskussion i cirklar. Skilj dem först på papperet och koppla sedan var och en till den enhet som faktiskt upprätthåller den.

Varje rad har en annan ägare. Den första är en förhandling, den andra är konfiguration på dina enheter, den tredje är mestadels någon annans nät. En ändringsbegäran som namnger raden den rör är mycket lättare att godkänna än en som säger BGP-problem.

Felfall som det är värt att planera för

Att acceptera en peers sammanfattningsrutt är den vanligaste självförvållade skadan. Någon annonserar ett kort aggregat för att förenkla utbytet, den bortre sidan accepterar det och trafik för intervall som inte ligger bakom tunneln följer tunneln och dör. Filtrera på de exakt förväntade prefixen, eller använd en prefixlista med rätt gränser, och acceptera aldrig ett bart aggregat för att det får sessionen att se prydlig ut.

Tidpunkten för tillbakadragning är den andra. Detektering beror på hålltider, på BFD om du aktiverade det, på tunnelns död-peer-detektering och på hur snabbt den bortre sidan slutar annonsera. Befintliga sessioner är ett eget problem: en ny rutt kan återställa nya anslutningar medan etablerade TCP-sessioner fortsätter använda inaktuella adresser, och tillståndsbärande brandväggar eller NAT på vägen kan hålla poster som inte längre stämmer. Sätt applikationsåterställning i acceptanskriterierna i stället för att anta att en rutändring ordnar allt.

Den tredje är asymmetri i returvägen. Trafik kan anlända över tunneln och komma tillbaka över en leverantörslänk som aldrig var menad att bära den, vilket visar sig som enkelriktat ljud, misslyckade handskakningar eller en brandvägg som släpper svaren. Kontrollera båda riktningarna var för sig.

Vad som ska skrivas i avtalet, och hur det verifieras

Begär de tillåtna prefixen skriftligt: vem som har rätt att skapa varje intervall, om en standardrutt är tillåten och vilka adressfamiljer tunneltjänsten stöder. RFC 8212 gjorde uttrycklig import- och exportpolitik till förväntan för eBGP i implementationer som följer den, så en peer som fortfarande lutar sig mot implicit acceptera-allt-beteende är värd att fråga.

Verifiera sedan från enheten i stället för från diagrammet. Användbara kommandon på FRR-liknande routrar:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Lägg till två observationer som rutttabellen inte kan ge dig. Fånga på det yttre gränssnittet för att bekräfta vilken adress de inkapslade paketen faktiskt riktar sig mot, till exempel tcpdump -ni eth0 udp port 51820 för en WireGuard-tunnel, eller ett ESP-filter för IPsec. Spåra sedan mot peerens publika adress och jämför hoppen med ett spår inne i tunneln; om båda följer samma leverantörskedja bor din redundans i rutpolitiken och inte i nätet.

Till sist, testa en tillbakadragning med avsikt. Ta ner tunneln i ett underhållsfönster, notera hur länge prefixet blir installerat, vad som händer med befintliga sessioner och om den bortre sidan faller tillbaka till en rutt du faktiskt skulle acceptera. Den övningen säger mer om designen än något diagram.

En rutt är inte ett tillstånd. Prefixen du kommer överens om att utbyta säger ingenting om vilka användare som kan nå vilken tjänst bakom tunneln, så håll autentisering, tillåtna tjänster och värdbrandväggar exakt där de var. En nåbar peer är inte heller tillstånd för obegränsad transit eller för att skapa godtyckliga adresser, och den sortens befogenhet hör hemma i avtalet som en kommersiell fråga, inte i en BGP-politikrad.

• Namnge de prefix varje sida kan skapa, och de som den aldrig får acceptera.
• Begränsa MSS på tunneln och bekräfta att stora uppdateringar faktiskt anländer.
• Lista de delade underlagsberoendena, inte antalet tunnlar.
• Mät en verklig tillbakadragning och notera vad applikationen gör.