Problemen met BGP-flappen tussen Ultra Packet Core en Nexus-Switch oplossen vanwege onjuiste configuratie

Downloadopties

PDF (278.1 KB)
Met Adobe Reader op diverse apparaten bekijken
ePub (104.2 KB)
Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
Mobi (Kindle) (96.6 KB)
Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken

Bijgewerkt:8 februari 2023

Document-id:220206

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inhoud

Inleiding

In dit document wordt de oplossing beschreven voor de BGP-flaps (Border Gateway Protocol) tussen Cisco Ultra Packet Core (UPC) en Nexus 9000-switch die zijn geconfigureerd met een redundante BGP-verbinding.

Probleem

BGP-flappen worden geactiveerd wanneer een van de redundante interfaces tussen de Cisco Ultra Packet Core en Nexus switch-flappen.

Voorwaarden

De Ultra Packet Core (UPC) node is verbonden met Nexus Leaf A en Leaf B op afzonderlijke poorten. De BGP IPv6-peers worden ingesteld en de standaardroutes worden op de UPC-node geïnstalleerd. Afbeelding 1 toont het netwerkdiagram op hoog niveau met het redundante pad naar Leaf-switches.

Figure 1: Network Diagram Afbeelding 1: Netwerkdiagram

Configuratie

UPC-poortconfiguratie met VLAN en interfacebinding:

port ethernet 1/10
    no shutdown
    vlan 140
        no shutdown
        bind interface saegw_vlan140_1/10 saegw
#exit

#exit
port ethernet 1/11
    no shutdown
    vlan 141
        no shutdown
        bind interface saegw_vlan141_1/11 saegw
#exit
#exit
end

UPC-interfaceconfiguratie met IP-adressen:

interface saegw_vlan140_1/10
  ip address 10.11.11..8 255.255.255.0
  ipv6 address fd00:10:11:11::8/64 secondary
  bfd interval 300 min_rx 300 multiplier 3
#exit
interface saegw_vlan141_1/11
  ip address 10.11.12.8 255.255.255.0
  ipv6 address fd00:10:11:12::8/64 secondary
  bfd interval 300 min_rx 300 multiplier 3
#exit

UPC BGP-configuratie:

router bgp 25949
  router-id 172.19.20.30
  maximum-paths ebgp 4
  neighbor 10.11.11..1 remote-as 25949
  neighbor 10.11.11..1 fall-over bfd 
  neighbor 10.11.12.1 remote-as 25949
  neighbor 10.11.12.1 fall-over bfd 
  neighbor fd00:10:11:11::1 remote-as 25949
  neighbor fd00:10:11:12::1 remote-as 25949
  address-family ipv4
    neighbor 10.11.11..1 route-map accept_default in
    neighbor 10.11.11..1 route-map gw-1-OUT out
    neighbor 10.11.12.1 route-map accept_default in
    neighbor 10.11.12.1 route-map gw-1-OUT out
    redistribute connected
#exit
address-family ipv6
  neighbor fd00:10:11:11::1 activate
  neighbor fd00:10:11:11::1 route-map accept_v6_default in
  neighbor fd00:10:11:11::1 route-map allow_service_ips_v6 out
  neighbor fd00:10:11:12::1 activate
  neighbor fd00:10:11:12::1 route-map accept_v6_default in
  neighbor fd00:10:11:12::1 route-map allow_service_ips_v6 out
  redistribute connected
#exit

ipv6 prefix-list name accept_v6_default_routes seq 10 permit ::/0
route-map accept_v6_default permit 10
  match ipv6 address prefix-list accept_v6_default_routes
#exit

Nexus 9000-switch:

Interface vlan140
ipv6 address fd00:10:11:11::1/64
no ipv6 redirects

interface vlan141
ipv6 address fd00:10:11:12::1/64
no ipv6 redirects

vrf upc
address-family ipv4 unicast
advertise l2vpn evpn
maximum-paths ibgp 2
address-family ipv6 unicast
advertise l2vpn evpn
maximum-paths ibgp 2
neighbor fd00:10:11:12::5
remote-as 25949
address-family ipv6 unicast
neighbor fd00:10:11:12::6
remote-as 25949
address-family ipv6 unicast
neighbor fd00:10:11:12::8
remote-as 25949
address-family ipv6 unicast

analyse

In eerste instantie wordt een normale BGP-communicatie waargenomen tussen een van de UPC-interfaces (fd00:10:11:12:8) en de Nexus-switch (fd00:10:11:12:1 behoort tot vlan141) die TCP ACK-berichten bevat:

2023-01-01 01:01:59.000000 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=8664 Win=31744 Len=0 TSV=2412344062 TSER=531234647
2023-01-01 01:01:59.000087 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=11520 Win=37376 Len=0 TSV=2412344062 TSER=531234647
2023-01-01 01:01:59.000162 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=14376 Win=43008 Len=0 TSV=241234062 TSER=531234647
2023-01-01 01:01:59.000281 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=17232 Win=49152 Len=0 TSV=2412344062 TSER=531234647
2023-01-01 01:01:59.000936 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=20663 Win=48640 Len=0 TSV=2412344063 TSER=531234647

Als de Leaf-B-interface naar UPC uitvalt, wordt er een fout gedrag waargenomen in de logs waar een nieuwe BGP-verbindingspoging wordt gestart door de UPC ( bron: fd00:10:11:12:8) naar de Leaf-A op interface fd00:10:11:11:11:1, die behoort tot een ander VLAN, vlan140.

2023-01-01 22:36:12.370117 fd00:10:11:12::8 -> fd00:10:11:11::1 TCP 41987 > bgp [SYN] Seq=0 Win=14400 Len=0 MSS=1440 TSV=2412347369 TSER=0 WS=9

Een dergelijk ongeldig BGP SYN-bericht dat op de verkeerde interface wordt verzonden, resulteert in de BGP-down. Wanneer de Nexus adverteert zijn eigen verbonden route en UPC krijgt een route voor de interface die was down over BGP, dan UPC probeert verbinding via een andere interface met een andere / verkeerde uitgaande IP.

Oplossing

Vanwege de configuratie waarnaar wordt verwezen in de sectie Conditie van dit artikel, probeert UPC, wanneer een van de interfaces niet werkt, de gekoppelde route-informatie van beide Leaf's via de andere interface naar die Leaf te communiceren, aangezien UPC de gekoppelde route-informatie van beide Leaf's ontvangt.

Om te voorkomen dat UPC de BGP-verbindingsinstelling berichten van de verkeerde interface verzendt, zijn hier de configuratiewijzigingen ter overweging:

Voeg in de UPC-configuratie voor de buurman toe update-source. Deze configuratie voorkomt dat de BGP-verbinding een andere interface gebruikt als de hoofdinterface niet werkt. Wanneer bijvoorbeeld saegw_vlan140_1/10 (fd00:10:11:11:1/64) is uitgeschakeld, kan de node geen uitgaande interface gebruiken saegw_vlan141_1/11 voor BGP peer fd00:10:11:11:8.
Hier volgt een voorbeeldconfiguratie:
```
neighbor fd00:10:11:11::1 update-source fd00:10:11:11::8
neighbor fd00:10:11:12::1 update-source fd00:10:11:12::8
```
Blokkeer in de Nexus-configuratie de voorvoegsels van de verkeerde interfaces.
We weigeren bijvoorbeeld routes voor het overbodige blad over buurman fd00:10:11:11:1
```
neighbor fd00:10:11:11::1
update prefix list to deny fd00:10:11:12::8/64
```
In de Nexus-switch moet de EBGP-peering van de VTEP naar een extern knooppunt over VXLAN in een tenant-VRF staan en moet de update-source van een loopback interface (peering over VXLAN) worden gebruikt zoals aanbevolen in de Cisco Nexus 9000 Configuration Guide