📬 ISN 245: Jak Nie Zepsuć BGP? Redystrybucja pod Lupą + Nokia i AI w Sieci!

BGP Handoff na jednym przełączniku

The Collapsed Edge: Simulating a BGP WAN Handoff on a Single Device

“You don’t need a rack full of expensive routers to master ISP BGP handoffs. You just need a single L3 switch, a VRF, and a 6-inch patch cable.

LinkedInInka Parviainen

Symulacja styku CE–PE zazwyczaj wymaga co najmniej dwóch urządzeń. Wystarczy jednak jeden przełącznik L3, kabel patch i VRF, żeby odtworzyć pełen handoff BGP w kontrolowanym środowisku.

Kluczowy trick polega na podziale pojedynczego przełącznika na dwie logiczne domeny routingu:

• Port 3 (Gi1/0/3) — strona enterprise, Global Routing Table, adres 10.0.0.1/30
• Port 4 (Gi1/0/4) — strona ISP, VRF ISP_GATEWAY, adres 10.0.0.2/30

Fizyczny kabel między tymi portami wymusza wyjście ruchu jako sygnał elektryczny z portu 3 i ponowne wejście na porcie 4 jako „nowy" pakiet. Przełącznik traktuje oba porty jak oddzielne urządzenia — bo konfiguracja VRF uniemożliwia wewnętrzne przeciekanie między tablicami routingu.

Ponieważ wiele przełączników L3 nie obsługuje eBGP między VRF a Global Table, sesja działa jako iBGP w AS 65001 z poleceniem route-reflector-client. Strona enterprise rozgłasza prefix 192.0.2.0/24 (Loopback0 jako symulowany serwer). VRF ISP odpowiada domyślną trasą przez default-originate.

Minimalny blok konfiguracji BGP po stronie enterprise:

router bgp 65001
 neighbor 10.0.0.2 remote-as 65001
 address-family ipv4
  network 192.0.2.0 mask 255.255.255.0
  neighbor 10.0.0.2 activate
  neighbor 10.0.0.2 route-reflector-client

Po stronie VRF ISP wystarczy dodać neighbor 10.0.0.1 default-originate w odpowiedniej address-family.

Idle — BGP nie próbuje nawiązać połączenia. Najczęstsza przyczyna: brak L3 connectivity (sprawdź ping) albo brak neighbor activate w address-family.

Active — BGP próbuje, ale bezskutecznie. Typowe powody: niezgodność remote-as lub konflikt Router ID (oba końce sesji mają ten sam ID). Rozwiązanie: bgp router-id w konfiguracji VRF nadaje unikalne ID stronie ISP. Po poprawkach wymuś reset: clear ip bgp *.

Zanim uznasz lab za działający:

show ip bgp summary                              # stan sesji = liczba?
show ip bgp neighbors 10.0.0.2 advertised-routes # czy wysyłam trasy?
show ip route vrf ISP_GATEWAY                    # czy ISP je widzi?
ping vrf ISP_GATEWAY 10.0.0.1                    # czy mostek działa?

Pułapka redystrybucji tras statycznych do BGP

The Traps of Redistributing Backup Static Routes into BGP

I recently encountered an interesting routing scenario involving BGP and a backup static route that resulted in unexpected fallback behavior and traffic forwarding to incorrect next-hop. The Setup Consider a scenario where router R2 receives the prefix 10.

LinkedInChingiz Khalafov

Konfiguracja zapasowej trasy statycznej z redystrybcją do BGP wygląda prosto. W praktyce może trwale zablokować ruch na ścieżce backupowej — nawet po przywróceniu sesji eBGP.

Scenariusz: R2 odbiera prefiks 10.110.10.10/32 przez eBGP od R1 (AD 20). Jako backup skonfigurowana jest trasa statyczna z wyższym AD (240) przez R3, redystrybowana do BGP.

Przy prawidłowej pracy eBGP — wszystko działa. Problem pojawia się w sekwencji:

1. Sąsiad eBGP wycofuje prefiks → trasa statyczna wchodzi do RIB
2. Redystrybucja wstrzykuje ją do tablicy BGP jako trasę lokalną
3. Cisco automatycznie przypisuje lokalnie wstrzykniętym trasom Weight = 32768
4. Sąsiad eBGP przywraca prefiks → R2 widzi dwie ścieżki w BGP

I tu zaczyna się problem. BGP ocenia atrybuty sekwencyjnie, a Weight jest pierwszym kryterium selekcji. Trasa z redystrybucji ma weight 32768, trasa eBGP ma weight 0 — BGP nigdy nie zmieni swojego wyboru na ścieżkę zewnętrzną. Trasa statyczna pozostaje zablokowana w RIB, tworząc wieczną pętlę redystrybucji.

Paths: (2 available, best #2, table default)
  64512
    10.12.1.1 from 10.12.1.1 — valid, external
  Local
    10.23.2.2 from 0.0.0.0 — weight 32768, valid, sourced, best <<<<

Problem pojawia się w dwóch sytuacjach: gdy sąsiad eBGP wycofuje i ponownie ogłasza prefiks, oraz gdy redystrybucja jest skonfigurowana przed nawiązaniem sesji eBGP.

Ważna obserwacja: jeśli trasa statyczna i redystrybucja zostają dodane podczas stabilnej sesji eBGP, problem nie wystąpi — trasa statyczna nigdy nie trafi do RIB i nie zostanie wstrzyknięta do BGP.

Opcja preferowana: Zastąp trasę statyczną sesją eBGP z R3. Użyj Local Preference do sterowania priorytetem ścieżek — wyższa wartość dla tras od R1 zapewni czysty failover i failback bez efektów ubocznych.

Opcja alternatywna: Jeśli redystrybucja trasy statycznej jest niezbędna, użyj route-mapy, która wyzeruje weight i obniży local-preference do wartości poniżej domyślnej (100):

route-map REDIST-STATIC permit 10
 match tag 1234
 set local-preference 50
 set weight 0

Przy weight = 0 BGP przechodzi do kolejnego kryterium: Local Preference. Trasa eBGP przychodząca z domyślnym LP=100 wygrywa z LP=50 redystrybowanej trasy statycznej. BGP instaluje ją w RIB, usuwa trasę statyczną, pętla zostaje przerwana.

Gotowe scenariusze do labowania

GitHub - ipspace/netlab-examples: Sample virtual lab topologies for the netlab tool

Sample virtual lab topologies for the netlab tool. Contribute to ipspace/netlab-examples development by creating an account on GitHub.

GitHubipspace

Repozytorium oferuje gotowe, wirtualne topologie sieciowe do narzędzia netlab. Znajdziesz tu dziesiątki przykładów obejmujących różne technologie sieciowe takie jak BGP, DHCP, DMVPN, EIGRP, VXLAN, MPLS, IS-IS, OSPF, VLAN, VRF czy emulację WAN. Przykłady są dostępne do uruchomienia lokalnie lub w darmowym środowisku GitHub Codespaces, także na sprzęcie Apple silicon.

Claude Code + Nokia

GitHub - antoinekh/nokia-sr-skills: Claude Code skill plugin: inspect & operate Nokia SR OS (SROS) and SR Linux - NOS detection, on-demand YANG models, version detection, config formats, CLI/NETCONF/gNMI.

Claude Code skill plugin: inspect & operate Nokia SR OS (SROS) and SR Linux - NOS detection, on-demand YANG models, version detection, config formats, CLI/NETCONF/gNMI. - antoinekh/nokia-sr-skills

GitHubantoinekh

Plugin uczy Claude, jak rozróżniać i obsługiwać dwa systemy sieciowe Nokii - SR OS (SROS) i SR Linux (SRL). Potrafi wykrywać system NOS, pobierać odpowiednie modele YANG na żądanie, czytać wersję oprogramowania, rozumieć różne formaty konfiguracji oraz stosować odpowiednie metody operacji (NETCONF, MD-CLI, gNMI). Wskazuje też na językowy serwer Nokia srpls. 

Lab IPv6 – ile naprawdę potrzebujesz, żeby zacząć?