Inleiding
Dit document beschrijft de oplossing voor de BGP-flaps (BGP) tussen Cisco Ultra Packet Core (UPC) en Nexus 9000 switch die zijn geconfigureerd met redundante BGP-verbinding.
Probleem
BGP-flaps worden geactiveerd wanneer een van de redundante interfaces tussen de Cisco Ultra Packet Core en Nexus switch flaps.
Voorwaarden
De Ultra Packet Core (UPC) knooppunt is verbonden met Nexus Leaf A en Leaf B op afzonderlijke poorten. De BGP IPv6-peers worden ingesteld en de standaardroutes worden geïnstalleerd op de UPC-knooppunt. Afbeelding 1 toont het netwerkdiagram op hoog niveau met redundant pad naar Blade switches.
Afbeelding 1: Netwerkdiagram
Configuratie
UPC-poortconfiguratie met VLAN en interfaceband:
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 configuratie:
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
Aanvankelijk wordt een normale BGP-communicatie tussen een van de UPC-interfaces (fd00:10:11:12:8) en de Nexus-switch (fd00:10:11:12:1:1 behoort tot vlan141) waargenomen, die TCP ACK-berichten omvat:
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
Bij een storing van de Leaf-B-interface naar UPC, wordt een onjuist gedrag gezien in de logs waar een nieuwe BGP-verbindingspoging wordt geïnitieerd door de UPC ( bron: fd00:10:11:12:8) naar de Leaf-A op interface fd00:10:11:11:11:1, die tot een ander VLAN behoort, 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
Dergelijk ongeldig BGP SYN-bericht verzonden op de verkeerde interface resulteert in de BGP-down. Wanneer de Nexus zijn eigen verbonden route adverteert en UPC een route krijgt voor de interface die was down over BGP, dan probeert UPC verbinding via een andere interface met een andere/verkeerde uitgaande IP.
Oplossing
Vanwege de configuratie in het gedeelte Conditie van dit artikel, aangezien UPC de verbonden routegegevens van beide pagina's van beide interfaces ontvangt, probeert UPC, wanneer een van de interfaces niet beschikbaar is, via de andere interface met dat blad te communiceren.
Om te voorkomen dat UPC de BGP-verbindingsinstallatieberichten vanuit de verkeerde interface verstuurt, staan hier de configuratiewijzigingen ter overweging:
- In een UPC-configuratie toevoegen
update-source
voor de buurvrouw. Deze configuratie voorkomt dat de BGP-verbinding via een andere interface wordt uitgevoerd als de hoofdinterface niet actief is. Bijvoorbeeld, wanneer saegw_vlan140_1/10 (fd00:10:11:11:1/64) is neer dan kan de knoop geen uitgaande interface saegw_vlan141_1/11 voor BGP peer fd00:10:11:11::8 gebruiken.
Hier is 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
- In de Nexus configuratie, blokkeer de prefixes van de verkeerde interfaces.
Bijvoorbeeld, ontkennen wij routes voor het overtollige blad over buur fd00:10:11:11::1
neighbor fd00:10:11:11::1
update prefix list to deny fd00:10:11:12::8/64
- In Nexus switch moet de EBGP-peer van de VTEP naar een extern knooppunt via VXLAN zich in een huurder VRF bevinden en gebruik maken van de
update-source
van een loopback
interface (peer-over-VXLAN) zoals aanbevolen in de Cisco Nexus 9000 configuratiehandleiding