On 18/05/2022 17:36, Blake Dunlap wrote:
Others have explained this. Basically, a BGP peer gets locked onto one
of the LAG links and will migrate to another link in the event that the
specific link goes down. This is normal behavior.
-Hank
Is it about 4000 msec of flapping? Perhaps the bundle member in question
is delaying to go down for some reason?
On Thu, May 5, 2022, 11:07 Hank Nussbacher <[email protected]
<mailto:[email protected]>> wrote:
I have 4 individual links defined as part of a Bundle-ether (IOS-XR
5.3.3 on ASR9010):
interface TenGigE0/2/0/1
bundle id 2 mode active
flow-control bidirectional
carrier-delay up 100 down 4000
! They are all part of a bundle...
interface Bundle-Ether2
mtu 9192
bundle minimum-active links 2
When I shut off just 1 of these 4 links - the bundle stays up yet
certain BGP sessions flap for about 5 seconds - different peers
depending on which of the 4 links gets turned down.
My BGP config:
router bgp 378
rpki server x.139.197.151
transport tcp port 8282
refresh-time 600
!
bgp log neighbor changes detail
address-family ipv4 unicast
bgp dampening 5 750 3000 10
bgp attribute-download
!
neighbor x.x.125.1
remote-as xxxx5
address-family ipv4 unicast
send-community-ebgp
soft-reconfiguration inbound
What could be causing the bgp peer to flap even though the LAG stays up?
Thanks,
Hank
_______________________________________________
cisco-nsp mailing list [email protected]
<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-nsp
<https://puck.nether.net/mailman/listinfo/cisco-nsp>
archive at http://puck.nether.net/pipermail/cisco-nsp/
<http://puck.nether.net/pipermail/cisco-nsp/>
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
