Konfigurera och kontrollera BGP i Sophos Firewall

BGP utbyter utvalda routes mellan routrar. I en Sophos Firewall är det särskilt användbart vid flera platser, redundanta anslutningar samt VPN till AWS eller Azure. För ett enskilt målnät med en fast Next Hop är en statisk route oftast enklare.

I följande exempel upprättar två Sophos Firewalls en eBGP-session via ett transitnät. Till slut står Neighbor i Established, Firewall A känner till LAN-nätet bakom Firewall B och omvänt.

⚠️ Dynamic Routing ska endast vara åtkomligt för den avsedda motparten. En ändring av Router ID avbryter alla BGP-sessioner; en ändring av Local AS tar dessutom bort alla konfigurerade Neighbors och Networks. Båda ändringarna hör därför hemma i ett planerat underhållsfönster med en aktuell backup.

BGP i sju steg

För en enkel IPv4-konfiguration krävs följande steg:

Fastställ transit-IP-adresser, lokalt ASN och motpartens ASN samt de nät som ska annonseras.
Kontrollera direkt IP-nåbarhet mellan de två BGP-peererna.
Tillåt under Administration > Device access Dynamic Routing endast för peer-zonen eller via en snäv Local Service ACL Exception; kontrollera separat de brandväggsregler som designen kräver.
Ange Router ID och Local AS under Routing > BGP.
Lägg till peer-IP-adressen som Neighbor med Remote AS.
Ange endast de lokala prefix som behövs under Networks.
Kontrollera under Routing > Information > BGP-IPv4 State Established, den inlärda routen och därefter verklig trafik.

Vad BGP avgör i brandväggen

BGP besvarar frågan vilka nät som kan nås via vilken router. Varje deltagare behöver därför några tydligt åtskilda värden:

Local AS betecknar det egna autonoma systemet. Två olika ASN bildar en eBGP-anslutning; samma ASN på båda sidor skulle vara iBGP.
Remote AS är motpartens ASN.
Router ID identifierar BGP-routern i BGP-topologin. Det ser ut som en IPv4-adress, men behöver inte vara en interfaceadress och ska förbli unikt och stabilt.
En Neighbor är motpartens IPv4- eller IPv6-adress som BGP-sessionen upprättas med. I exemplet är detta transit-IP-adressen.
Ett Network är ett lokalt prefix som brandväggen ska annonsera till motparten.

BGP tillåter ingen nyttotrafik och krypterar den inte. Dynamic Routing under Device Access eller en Local Service ACL styr den lokala BGP-tjänsten. Trafik via inlärda routes kräver dessutom brandväggsregler, returväg och en medveten NAT-konfiguration.

För dynamisk routing inom en sammanhängande intern routingdomän är OSPF ofta mer naturligt. BGP passar bättre mellan olika autonoma system, mot molnleverantörer eller när routes måste påverkas selektivt med policyer.

Planera exempeltopologin

Exemplet använder två platser:

Firewall A: Local AS 65010, Router ID 192.0.2.10, transit-IP 198.51.100.1/30, LAN 10.10.10.0/24
Firewall B: Local AS 65020, Router ID 192.0.2.20, transit-IP 198.51.100.2/30, LAN 10.20.20.0/24
Transitnät: 198.51.100.0/30

Intervallen 192.0.2.0/24 och 198.51.100.0/24 är dokumentationsnät. De ersätts med miljöns faktiska värden. De två privata ASN-värdena passar ett internt exempel; vid en anslutning till AWS, Azure eller en leverantör används de ASN- och peer-värden som motparten anger.

Router ID ska väljas medvetet och vara unikt och stabilt. Med Automatic använder SFOS den högsta interface-IP-adressen. Om den ändras senare kan även routerns identitet ändras oväntat. Ett manuellt värde undviker detta beroende.

Förbered BGP säkert

Följande ska vara uppfyllt före konfigurationen:

Brandväggen körs i Gateway Mode. BGP är inte tillgängligt i Transparent Mode.
De båda transit-IP-adresserna når varandra direkt. Med en XFRM-tunnel måste även tunnelinterfacet vara uppe.
Local AS, Remote AS, peer-IP-adresser och tillåtna prefix har stämts av med motparten.
Den lokala routningstabellen och planerade Networks är dokumenterade, så att varje annonsering kan kontrolleras specifikt efter konfigurationen.
En aktuell konfigurationsbackup och en oberoende managementåtkomst finns tillgängliga.
Brandväggsregler och returvägar för den senare nyttotrafiken är planerade.

Grunderna för transitinterface och zon förklaras i Konfigurera zoner och interface i Sophos Firewall. Före en ändring i en produktiv routingmiljö ska det dessutom finnas en aktuell brandväggsbackup utanför appliance-enheten.

Tillåt Dynamic Routing selektivt

Under Administration > Device access är Dynamic Routing som standard avstängt för alla zoner. För ett separat nät som endast används som transit kan tjänsten aktiveras i dess zon.

Om peer-interfacet delar sin LAN- eller WAN-zon med andra nät är en Local Service ACL Exception för den konkreta peer-IP-adressen eller det snäva transitnätet säkrare än att tillåta hela zonen. Under Administration > Device access > Local service ACL exception rule > Add skapas en Accept-regel med IP version, Source zone, Source networks and hosts, Destination hosts, tjänsten Dynamic Routing och lämplig Rule position. Testa därefter åtkomst från den tillåtna peer-IP-adressen och från en otillåten källa.

Sophos BGP-hjälp anger dessutom att brandväggsregler krävs för inkommande och utgående BGP-trafik. Samtidigt anger hjälpen för Device Access att lokala tjänster inte styrs med brandväggsregler. Formuleringarna är inte entydigt samstämmiga. Hantera därför Local Service ACL för den lokala BGP-tjänsten, reglerna som den aktuella tunnel- eller leverantörsdesignen kräver och de vanliga reglerna för routad nyttotrafik var för sig. Av detta följer inte att en generell Any-to-Any-regel för TCP 179 ska skapas. Säkra enhetsåtkomst i Sophos Firewall beskriver det lokala åtkomstlagret mer ingående.

Konfigurera BGP i WebAdmin

Följande steg utförs på båda brandväggarna. Endast de lokala värdena och motpartens värden byter plats.

1. Ange Router ID och Local AS

Ange följande värden på Firewall A i Global configuration under Routing > BGP:

Om det redan finns en BGP-konfiguration måste det aktuella läget dokumenteras innan ändringen tillämpas: ett ändrat Router ID återställer alla BGP-sessioner; ett ändrat Local AS tar bort alla Neighbors och Networks. Sådana ändringar tillämpas endast i ett planerat underhållsfönster.

Router ID assignment: Manual
Router ID: 192.0.2.10
Local AS: 65010

På Firewall B används också Manual samt 192.0.2.20 och 65020. Tillämpa därefter den globala konfigurationen.

Local AS accepterar värden från 1 till 4294967295. För interna miljöer utan publikt ASN anger Sophos det privata intervallet 64512 till 65535.

2. Lägg till motparten som Neighbor

Klicka på Add under Routing > BGP > Neighbors och ange följande på Firewall A:

IP version: IPv4
IP address: 198.51.100.2
Remote AS: 65020

Firewall B använder 198.51.100.1 som Neighbor och 65010 som Remote AS. Spara därefter på respektive brandvägg med Save.

Neighbor-adressen är inte det fjärranslutna LAN-nätet eller Router ID, utan motpartens direkt nåbara transit-IP-adress. Om IP-adressen inte kan nås eller ASN-värdena har förväxlats kan sessionen inte nå Established.

3. Annonsera lokalt LAN

Klicka på Add under Routing > BGP > Networks. Firewall A annonserar:

IP version: IPv4
IP address: 10.10.10.0
Subnet mask: 255.255.255.0 (/24)

På Firewall B anges i stället 10.20.20.0 och 255.255.255.0 (/24).

En Network-post anger vilket prefix BGP ska annonsera; den ersätter varken den lokala routen eller en brandväggsregel. Kontrollera efter att posten har sparats inte bara sessionen, utan även det annonserade prefixet och det prefix som motparten har tagit emot. Endast prefix som faktiskt behövs ska finnas i listan.

Förstå IPv6-Neighbors och nätverk

SFOS stöder även IPv6 under Neighbors och Networks. Det föregående exemplet håller sig medvetet till IPv4; för IPv6 anges IP-version, peerens direkt nåbara IPv6-adress och IPv6-prefixet separat.

WebAdmin lägger automatiskt till nödvändig separation. I en ren CLI-konfiguration är standardvärdena asymmetriska: IPv4 Networks är först aktiva för alla Neighbors, även IPv6. IPv6 Networks är inte aktiva för någon Neighbor. Ange uttryckligen dessa tillstånd för en IPv6-Neighbor:

address-family ipv4 unicast
no neighbor <ipv6-neighbor> activate
exit
address-family ipv6 unicast
neighbor <ipv6-neighbor> activate

För att motsvara WebAdmin-defaults i CLI anger Sophos även no bgp ebgp-requires-policy och bgp log-neighbor-changes. show running-config visar bara värden som avviker från default; automatiskt Router ID och exempelvis maximum-paths ibgp 16 kanske inte visas. Verifiera IPv4 och IPv6 separat under Routing > Information > BGP-IPv4 och BGP-IPv6, med egna IPv6-regler och returvägar.

Kontrollera och verifiera BGP

En upprättad session bekräftar inte ensam ett fungerande paketflöde. Verifieringen sker därför på flera nivåer:

Under Routing > Information > BGP-IPv4 > Neighbors ska motparten visas med State Established.
Under Routes förväntar sig Firewall A prefixet 10.20.20.0/24; Firewall B förväntar sig 10.10.10.0/24.
Under Summary kontrolleras sessionen och antalet mottagna prefix.
Under Diagnostics > Tools > Route lookup kontrolleras till exempel målet 10.20.20.10 på Firewall A.
Därefter testas en verklig tjänst mellan en värd i respektive LAN. Log Viewer och Packet Capture ska visa förväntad regel, rätt transitinterface och returtrafik.

En Neighbor i Established bevisar endast att BGP-utbytet fungerar. Först den inlärda routen, korrekt Route Lookup och en verklig anslutning bekräftar hela konfigurationen. För kontroll av paketflödet hjälper Testa en Sophos Firewall-regel med Log Viewer och Packet Capture.

Samma exempel via CLI

Som ett alternativ till WebAdmin kan samma grundkonfiguration anges i routing-CLI efter SSH-inloggning. Kör inte följande kommandon i en redan konfigurerad exempelmiljö. Spara aktuellt läge före ändringar; en ASN-ändring tar bort Neighbors och Networks och kräver backup och underhållsfönster. Ingången beror på SFOS-versionen.

SFOS 22: följande menysökväg öppnar bgp>. Endast denna ingång börjar med enable:

3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP

På Firewall A där inget ASN ännu har tilldelats:

enable
configure terminal
router bgp 65010

SFOS 23: 3. Route Configuration > 1. Configure Unicast Routing öppnar direkt router#; varken det tredje menyvalet eller enable ingår i denna väg. För den första ASN-tilldelningen på Firewall A:

configure terminal
router bgp 65010

Om ASN redan har tilldelats i SFOS 23 används i stället router bgp utan ASN efter configure terminal för att välja den befintliga konfigurationen. router bgp 65010 används för den första tilldelningen eller en medvetet planerad ASN-ändring, inte för en okontrollerad omtilldelning.

Fortsätt i BGP-konfigurationsläge efter exakt en av dessa ingångssekvenser:

no bgp ebgp-requires-policy
bgp log-neighbor-changes
bgp router-id 192.0.2.10
neighbor 198.51.100.2 remote-as 65020
address-family ipv4 unicast
network 10.10.10.0/24
exit
end
show running-config
write

På Firewall B ersätts Local AS, Router ID, Neighbor, Remote AS och Network med 65020, 192.0.2.20, 198.51.100.1, 65010 respektive 10.20.20.0/24.

show running-config används för kontroll. write sparar CLI-konfigurationen permanent, gör posterna synliga i WebAdmin och bevarar dem efter en omstart. Utan write är ändringen inte fullständigt avslutad.

end lämnar konfigurationsläget före dessa två kommandon. För SFOS 23 dokumenterar Sophos den förväntade sparbekräftelsen Integrated configuration saved to /conf/routing/frr.conf; detta är inte enhetsutmatning som har observerats här. Jämför sedan konfigurationen och WebAdmin-posterna med de avsedda värdena.

Den ytterligare officiellt dokumenterade kontrollen är:

show ip bgp

Den visar kända BGP-prefix och deras sökvägsinformation. Neighbor State och Summary kontrolleras tillförlitligt under Routing > Information > BGP-IPv4.

⚠️ Blanda inte avancerad CLI-konfiguration och WebAdmin utan kontroll. Om en Neighbor redigeras i WebAdmin kan ytterligare CLI-värden, till exempel ett Neighbor-lösenord eller en Route Map, tas bort. När sådana inställningar används ska först show running-config sparas och BGP-konfigurationen därefter hanteras vidare via CLI.

SFOS 23.0: experimentellt BFD för BGP

Bidirectional Forwarding Detection (BFD) övervakar nåbarheten till en BGP Neighbor med egna kontrollpaket. Det gör att brandväggen kan upptäcka ett avbrott tidigare än med enbart BGP-timers. Detta valfria förfarande ingår inte i den föregående BGP-grundkonfigurationen och ska inte tillämpas på äldre SFOS-versioner.

⚠️ I SFOS 23.0 är BFD experimentellt. Den dokumenterade användningen gäller BGP i Standalone-Deployments; detta innebär inget godkännande för HA-kluster eller andra routingprotokoll. För andra protokoll måste Sophos Support involveras. Avanet rekommenderar att börja i en isolerad testmiljö. BFD ska inte aktiveras i produktion utan en återställningsväg som har bekräftats för den installerade builden.

Omfattning och förberedelser

Sophos anger BGP-IPv4- och BGP-IPv6-Neighbors samt eBGP, iBGP, eBGP multihop och Route Reflector-Neighbors som användningsfall för BFD. Följande exempel håller sig till den redan konfigurerade IPv4-motparten 198.51.100.2 på Firewall A. Det innebär inget ytterligare löfte om stöd för en viss Cloud VPN-tjänst eller en viss multihop-topologi.

Innan arbetet påbörjas måste BGP-sessionen, de förväntade prefixen och applikationstrafiken fungera utan BFD. Motparten måste vara förberedd för BFD; peer-adresser, nåbarhet och timers stäms av med dess administratör. Dokumentera aktuell SFOS-build och spara show running-config, Neighbor-status och Route Lookup. Ha dessutom backup, underhållsfönster och oberoende managementåtkomst tillgängliga. Stäm i förväg av med Sophos Support hur BFD-bindningen till Neighbor, en eventuell ytterligare peer-profil och tjänsten ska tas bort för denna build. BFD-anvisningen dokumenterar inga fullständiga Remove- eller Stop-kommandon för detta.

Om den övervakade motparten inte längre kan nås tar brandväggen omedelbart bort alla routes som lärts in från den ur routningstabellen. Trafiken kan växla till en alternativ väg endast om en sådan finns; annars förlorar de berörda näten sin route. När motparten återkommer beskriver Sophos att routes återställs och att trafiken växlar tillbaka till den ursprungliga vägen. Därför kontrolleras både avbrott och återkomst, inklusive vilken route som faktiskt väljs.

Starta tjänsten och övervaka motparten

BFD-tjänsten är avstängd som standard. Följande kommandon ändrar routingdriften; innan de körs måste utgångsläget vara sparat och återställningsvägen bekräftad. Öppna 5. Device Management > 3. Advanced shell via CLI och starta tjänsten där:

service -ds nosync bfdd:start

Växla därefter till routing-CLI med vtysh i samma Advanced Shell:

vtysh

Lägg i routing-CLI till BFD-bindningen för den redan befintliga Neighbor på Firewall A. Router ID, Local AS, Remote AS och Networks lämnas oförändrade:

configure terminal
router bgp
neighbor 198.51.100.2 bfd
end
write

Ersätt 198.51.100.2 med den faktiska Neighbor-adressen, inte med dess LAN eller Router ID. På Firewall B är motsvarande adress i exemplet 198.51.100.1. Motparten konfigureras enligt anvisningarna för dess egen produkt. Om BGP Neighbor ännu saknas ska artikelns BGP-grundkonfiguration slutföras först; BFD ersätter den inte. write sparar routingkonfigurationen, men bevisar varken att BFD-sessionen fungerar eller att tjänsten startar automatiskt efter en omstart.

Ändra timers endast vid motiverat behov

För det första testet rekommenderar Avanet de dokumenterade standardvärdena: Detect multiplier 3, Transmit interval 300 ms och Receive interval 300 ms. Mycket korta intervall eller en känslig multiplikator kan öka bearbetningsbelastningen. Dessa värden innebär inget löfte om en fast omkopplingstid.

Timers anges i BFD-konfigurationen, inte i BGP Neighbor-kommandot. Om en explicit peer-profil behövs visar följande block i routing-CLI de dokumenterade standardvärdena för samma exempelpeer:

configure terminal
bfd
peer 198.51.100.2
 detect-multiplier 3
 transmit-interval 300
 receive-interval 300
end
write

peer startar peer-övervakningen med standardtimers; detta extra block behövs inte om endast BGP-bindningen ska konfigureras. För detect-multiplier dokumenterar Sophos intervallet 1–155, och för båda intervallen 10–4294967 ms. Transmit-värdet anger det minsta sändningsintervallet utan jitter, medan Receive-värdet anger det förväntade minsta mottagningsintervallet. Motparten beräknar sin detekteringstid utifrån den lokala multiplikatorn och det större värdet av det lokala sändningsintervallet och det fjärranslutna mottagningsintervallet. Därför stäms båda sidorna av, i stället för att enbart välja ett så litet lokalt värde som möjligt. Ytterligare timers direkt efter neighbor … bfd är inte giltig syntax.

Verifiera BFD, routes och applikation tillsammans

Dessa två kontroller i routing-CLI är skrivskyddade:

show bfd peers
show bfd peers brief

För avsedd peer förväntas Status: up. Den detaljerade utmatningen ska visa lämpliga lokala och fjärranslutna timers samt Diagnostics: ok och Remote diagnostics: ok; kortvyn visar peer-adress och tillhörande status. Kontrollera därefter BGP-sessionen under Routing > Information > BGP-IPv4 respektive BGP-IPv6, de förväntade prefixen, Route Lookup och verklig applikationstrafik igen. Enbart BFD up bekräftar varken rätt BGP-route eller datavägen.

Utför ett avbrottstest endast i en godkänd testmiljö eller ett planerat underhållsfönster, utan att äventyra den oberoende managementåtkomsten. Dokumentera i förväg de prefix som lärts in från den övervakade motparten och den planerade ersättningsvägen. Under det kontrollerade peer-avbrottet ska de berörda routena försvinna och, om en ersättningsroute finns, ska den och applikationstrafiken fungera. Efter återställningen kontrolleras åter BFD up, BGP, återkomna prefix, vald väg och applikation. Ingen enhetsutmatning eller lyckad omkoppling framställs här som redan testad.

Avgränsa fel och återställ ändringen

Peer saknas eller förblir down: Kontrollera tjänstestart och BFD-bindning i show running-config, och jämför därefter faktisk peer-adress, nåbarhet och motpartens BFD-konfiguration. Samla in lokal och fjärransluten diagnostik samt timers med show bfd peers. Lägg inte till en bred Any-to-Any-regel som generell lösning; involvera Sophos Support om åtkomstkraven är oklara.
BFD fungerar inte längre efter en ändring: Ändringar av tillhörande inställningar, exempelvis måladress eller Remote Gateway, kan ta bort BFD-inställningarna. Jämför konfigurationen med det sparade utgångsläget, konfigurera BFD på nytt för berörd Neighbor och genomför hela verifieringen.
Instabil session eller högre belastning efter timerändring: Återställ de tidigare dokumenterade värdena i samma BFD-peer-kontext och spara med write. Om utgångsläget var standardprofilen visar blocket ovan 3 och 300 ms. Kontrollera därefter båda peerernas diagnostik, BGP-routes och trafik innan fler värden ändras.
Fullständig återställning: Använd endast den återställningsplan som i förväg har bekräftats för denna build och jämför därefter BGP-konfigurationen utan BFD med det sparade utgångsläget. Varken ett påhittat no-kommando eller ett generellt stopp av tjänsten ersätter denna plan. Att ta bort hela BGP Neighbor är inte en likvärdig BFD-rollback, eftersom även dess routes då försvinner. Slutför återställningen först när BGP-sessionen, nödvändiga prefix, managementåtkomsten och applikationen åter är i avsett tillstånd.

Weight, MED och global Route Precedence

Global Route Precedence anger prioritetsordningen mellan kategorierna static, sdwan_policyroute och vpn. Den ska skiljas från de attribut som BGP använder för sitt eget vägval. system route_precedence show visar det aktuella globala värdet; ändra det endast när dessa tre kategorier faktiskt konkurrerar. Justera routingprioritet i Sophos Firewall beskriver hela kontroll- och återställningsförfarandet.

Mellan olika routingprotokoll avgör bland annat Administrative Distance. Inom BGP utvärderas BGP-attribut. Sophos anger exempelvis att en högre Weight föredras; för i övrigt jämförbara vägar föredras ett lägre MED.

Detta är särskilt viktigt när samma prefix både tillhandahålls via redistribute ospf och lärs in från en BGP Neighbor. Den lokalt genererade, redistribuerade routen har som standard Weight 32768, medan routen som lärts in från en Neighbor har Weight 0. Utan en medveten justering väljs därför den redistribuerade routen. Om vägen via motparten ska föredras måste den tilldelas en högre Weight, och den resulterande routen ska därefter kontrolleras.

Använd MED för flera ingångsvägar

SFOS 23: kontrollera namn i förväg. Inventera namnen för Access Lists, Prefix Lists och Route Maps i alla dynamiska routingprotokoll innan de skapas eller återanvänds. De lagras i en gemensam konfigurationsfil och namnen måste vara unika mellan protokollen. Undvik namnkollisioner och kontrollera avsedda Neighbor-/policybindningar mot aktuell och sparad konfiguration. Detta krav ersätter inte den nedan krävda MED-återställningsplanen som har bekräftats för den installerade builden; körbar MED-konfiguration förblir pausad tills planen har bekräftats.

Uppgradering till SFOS 23.0: Från denna version använder alla dynamiska routingprotokoll en integrerad konfiguration. Vid uppgradering från en tidigare version lägger brandväggen automatiskt till protokollprefix i namnen på Route Maps, Prefix Lists och Access Lists, men bara om det finns en namnkonflikt. Den uppdaterar även automatiskt alla referenser till de konfigurationer som har bytt namn. Detta innebär inte att alla objekt byter namn.

Efter uppgraderingen jämförs de objektnamn och referenser som sparats i förväg med aktuell show running-config, och kopplingen mellan gamla och aktuella namn dokumenteras. Kontrollera att avsedda Neighbor-/Route-Map-bindningar fortfarande pekar på rätt policyer, inklusive befintliga MED-bindningar. Återställ inte gamla namn utan att kontrollera denna koppling. Kontrollera under Routing > Information > BGP-IPv4 > Routes och med show ip bgp hos motparten att förväntade nätverksprefix finns, att otillåtna nätverksprefix saknas och att avsedd väg väljs; kontrollera även den väg som faktiskt används med Route Lookup. Denna kontroll ersätter inte den nedan krävda MED-återställningsplanen för den installerade builden och häver inte pausen för MED-konfiguration.

Multi-Exit Discriminator (MED) talar om för ett direkt angränsande AS vilken av flera ingångsvägar till det lokala AS som ska föredras. Lägre MED är bättre och default är 0. Ett högre värde annonseras därför på den mindre önskade vägen. Som standard jämförs MED bara när samma prefix lärs över flera länkar från samma angränsande AS.

MED är inte transitivt. När mottagande AS skickar routen vidare till ett annat AS återställs värdet till 0. BGP utvärderar först Weight, Local Preference, en lokalt genererad route, AS Path-längd och Origin Type. MED avgör bara om dessa attribut är lika. Ett konfigurerat värde bevisar därför inte att önskad väg vinner.

Sophos anger MED med en utgående Route Map med fast sekvensnummer och kopplar den till en viss Neighbor inom IPv4 Address Family. out ändrar annonseringen till den motparten; det styr inte direkt Sophos Firewalls utgående dataväg. Den officiella sidan för SFOS 22 dokumenterar konfigurationen, men inte en fullständig återställning. Ändringen ska därför utföras först när de exakta borttagningskommandona har bekräftats separat för den installerade SFOS-versionen och dokumenterats i en återställningsplan tillsammans med en tidigare sparad show running-config.

Efter en godkänd ändring ska show ip bgp på den mottagande routern visa förväntad MED och föredragen väg. På en Sophos-motpart visas routen dessutom under Routing > Information > BGP-IPv4 > Routes. Utan denna jämförelse före och efter är avsnittet ett beslutsunderlag, inte en produktionsändring som är klar att utföra.

BGP över route-based IPsec och Cloud VPN

BGP kan köras över ett adresserat XFRM-interface i en route-based Site-to-Site IPsec-tunnel. Båda XFRM-interfacen får då lämpliga transit-IP-adresser. Dynamic Routing tillåts selektivt för VPN-zonen; regler för nyttotrafiken krävs ändå.

Vid molnanslutningar väljs värdena inte fritt:

För AWS Site-to-Site VPN kommer Inside Tunnel-adresser, Remote AS och andra tunnelvärden från AWS-konfigurationen. Båda AWS-tunnlarna kontrolleras separat.
Med Azure VPN Gateway måste den lokala XFRM-IP-adressen stämma med avsedd BGP-peer-IP; lokalt ASN och Azure-ASN måste vara olika.

En grön IPsec-tunnel och en BGP Neighbor i Established är två separata kontrollpunkter. Därefter måste förväntade prefix och verklig applikationstrafik fungera.

Avgränsa fel systematiskt

Neighbor stannar i Active eller visas inte

Active betyder inte att sessionen fungerar aktivt. Brandväggen fortsätter att försöka upprätta en BGP-anslutning. Kontrollera först direkt nåbarhet till peer-IP-adressen, interface- och tunnelstatus, Local AS, Remote AS samt Neighbor-IP. Kontrollera därefter om Dynamic Routing är tillåtet i rätt zon eller via en lämplig Local Service ACL Exception.

Med XFRM ska det också säkerställas att båda tunneladresserna stämmer och att IPsec-tunneln är uppe. För moln- och XFRM-konfigurationer kontrolleras dessutom de regler som ingår i respektive VPN-design. Om deras Services är begränsade måste TCP 179 ingå mellan de två peer-IP-adresserna. Device Access eller Local Service ACL för den lokala BGP-tjänsten är fortfarande separat från detta.

Neighbor är Established, men fjärrnätet saknas

Sessionen fungerar, men prefixet annonseras eller accepteras inte. Kontrollera Network-posten, dess IP-version och nätmask samt show running-config på den sändande brandväggen. Kontrollera därefter Routes och Summary hos motparten för att fastställa om prefixet kommer fram eller avvisas av en lokal policy.

Om ett nät bakom en policybaserad IPsec-tunnel saknas efter en uppgradering till SFOS 22 kan det tidigare beroendet av redistribute kernel vara orsaken. BGP-sessionen kan ändå förbli Established; SFOS 22: IPsec-rutter och redistribute kernel förklarar versionsändringen och måldesignen med route-based XFRM.

BGP-routen är synlig, men används inte

Kontrollera först med Route Lookup vilken route som vinner för en konkret mål-IP-adress. En mer specifik route har företräde framför ett bredare prefix. Om flera källor konkurrerar ska Administrative Distance, BGP-attribut och först därefter den globala Route Precedence-kategorin bedömas separat.

Routen stämmer, men trafiken fungerar inte

BGP har slutfört sin uppgift när rätt route är installerad. Därefter finns felet oftast i brandväggsregeln, NAT, returvägen eller målsystemet. För normalt routade platsnät behövs ofta ingen SNAT eftersom båda sidor ska känna till de verkliga LAN-prefixen.

Avancerade inställningar försvann efter en ändring i WebAdmin

WebAdmin visar endast grundvärdena. Om en Neighbor sparades där efter en avancerad CLI-konfiguration kan lösenord, Route Map eller ändrade standardvärden ha tagits bort. Även tillämpning av Global configuration tar bort ändringar av bgp log-neighbor-changes och no bgp ebgp-requires-policy. Jämför med den sparade konfigurationen, återställ värdena via CLI och spara med write.

Kontrollera BGP- och routingloggar

Loggreferensen för SFOS 22 hänvisar BGP och BGPv6 till filen bgpd.log. zebra.log gäller installationen av dynamiska IPv4- och IPv6-routes i kärnan; för route-based IPsec avser xfrmi.log XFRM-tunnelinterfacet. Denna koppling gör det möjligt att skilja feltyperna åt: kontrollera först BGP-sessionen och annonseringen, därefter överföringen till systemets routningstabell och vid behov tunnelstatusen. Tjänster och loggfiler i Sophos Firewall förklarar åtkomsten och beskriver ytterligare filer. Odokumenterade live-shell-kommandon behövs inte för denna verifiering.

Rulla tillbaka ändringen säkert

Innan BGP tas bort måste det finnas en alternativ väg eller ett underhållsfönster för varje inlärt målnät. Först tas berörda Networks och Neighbors bort, därefter ändras den globala BGP-konfigurationen endast om inga andra peers är beroende av den. Dynamic Routing får inte avaktiveras förrän zonen inte längre behöver någon annan dynamisk routingtjänst.

Ta i WebAdmin först bort annonseringar som inte längre behövs under Routing > BGP > Networks och därefter berörda motparter under Neighbors. Kontrollera efter varje steg att de förväntade ersättningsvägarna är aktiva. Låt Router ID och Local AS vara oförändrade så länge andra BGP-anslutningar är beroende av dem; en ändring av Local AS skulle ta bort alla återstående Neighbors och Networks.

De granskade BGP-översiktssidorna för SFOS 22 och 23 visar syntax för att stänga av BGP-routingkonfigurationen. Detta verifierar dock inte den fullständiga exekveringskontexten eller en säker återställning för den installerade builden. Den avvikande källsyntaxen återges inte som ett körbart kommando och korrigeras inte i tysthet; inget bekräftat daemonstopp eller någon processborttagning härleds från den. Inget destruktivt CLI-kommando rekommenderas. Den som använder avancerade CLI-policyer behöver före återställningen borttagningskommandon som har bekräftats för den installerade builden samt det tidigare konfigurationsblocket sparat.

Därefter kontrolleras Routing Information, Route Lookup, managementåtkomst och verklig trafik igen. En rollback är inte klar förrän inte bara BGP-sessionen har försvunnit, utan alla nödvändiga målnät fortfarande kan nås via den avsedda ersättningsvägen.