Re: [c-nsp] Link down affecting BGP peer

2022-05-19 Thread Saku Ytti
On Thu, 19 May 2022 at 10:27, Hank Nussbacher  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.

I'm not sure about normal behaviour and certainly objectively broken.

Even though ultimately some physical interfaces serialise those BGP
packets out, the fast external fallover should be tracking the
aggregate interface, not some member. What should happen when a member
comes down is that the hash=>interface table has one interface less,
so the packet is now hashed out to some of the remaining interfaces.

We can accept flaps if we don't know the physical interface is down,
while it is down. Like if the carrier-delay down is higher than bgp
keepalive or if the interface is blackholing for whatever reason.
Other than that, no, it's broken.

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] Link down affecting BGP peer

2022-05-19 Thread Hank Nussbacher

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 > 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 5
    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 cisco-nsp@puck.nether.net

https://puck.nether.net/mailman/listinfo/cisco-nsp

archive at http://puck.nether.net/pipermail/cisco-nsp/




___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] Link down affecting BGP peer

2022-05-18 Thread Blake Dunlap
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  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 5
>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  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] Link down affecting BGP peer

2022-05-06 Thread Mark Tinka




On 5/6/22 07:04, Ted Pelas Johansson wrote:


Try configuring MicroBFD/BoB rather than using Logic bundle/BLB, see more 
details at 
https://community.cisco.com/t5/service-providers-blogs/bfd-over-logical-bundle-blb-implementation-on-ncs5500-platforms/ba-p/3309345


Is this a p2p or LAN?

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] Link down affecting BGP peer

2022-05-05 Thread Mark Tinka




On 5/5/22 18:04, Hank Nussbacher wrote:



What could be causing the bgp peer to flap even though the LAG stays up?


Could be that the session flows are hashed to the 1 member link that you 
fail.


Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] Link down affecting BGP peer

2022-05-05 Thread Ted Pelas Johansson
Try configuring MicroBFD/BoB rather than using Logic bundle/BLB, see more 
details at 
https://community.cisco.com/t5/service-providers-blogs/bfd-over-logical-bundle-blb-implementation-on-ncs5500-platforms/ba-p/3309345

/Ted

> On 5 May 2022, at 18:07, Hank Nussbacher  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 5
>   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  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] Link down affecting BGP peer

2022-05-05 Thread Aaron
Are the sessions that bounced hashed to use the failed/turned off link?


On Thu, May 5, 2022 at 12:07 PM Hank Nussbacher  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 5
>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  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


[c-nsp] Link down affecting BGP peer

2022-05-05 Thread Hank Nussbacher
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 5
  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  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/