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.
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