Skip to main content
Dragnipur
Dragnipur
New Member
January 27, 2020
Question

BGP instability on IPSEC tunnel

  • January 27, 2020
  • 2 replies
  • 32177 views

Hello,

we are running a SDWAN infrastructure with one Hub and several spoke. All sites are equipped with 60E clusters running 6.2.3.

On one of my spoke I have a strange behavior.

each 3 min I have this error in router events logs:

BGP: %BGP-5-ADJCHANGE: neighbor 192.168.88.254 Down BGP Notification FSM-ERR

followed by

BGP: %BGP-5-ADJCHANGE: neighbor 192.168.88.254 Up

The problem is that during this event all connexions from spoke to hub are shut during roughly 30 sec

 

any idea ?

 

2 replies

emnoc
emnoc
New Member
January 29, 2020

Fix the issue that's breaking the ipsec-tunnel connection or adjust the timers, but 30sec is normal for a new BGP new open to come around.

 

Ken Felix

Dragnipur
DragnipurAuthor
New Member
January 29, 2020

I found the solution. The tunnel was totaly fine. With a static route I had no connectivity loss.

The solution was to remove some routes announced from the hub site, which seemed to mess with bgp neighbor association...

emnoc
emnoc
New Member
January 29, 2020

TIP: Do you have any max-prefixes received settings, that would always reset the BGP connections.

 

Ken Felix

Toshi_Esumi
SuperUser
Toshi_Esumi
SuperUser
January 25, 2022

That could happen when some MTU issues exist over the tunnel and BGP table advertised by the hub is larger than the size that can pass through.

NilayS
NilayS
New Member
September 23, 2025

Is there a way to find out the size of BGP Table based on the total number of routes?

Toshi_Esumi
SuperUser
Toshi_Esumi
SuperUser
September 23, 2025

It's not easy to calculate BGP UPDATE message size based on the number of routes. Because IPv4 NLRI field size is not fixed length (each prefix is max 5 bytes). I wouldn't suspect the MTU issue unless more than 200 routes.
https://support.huawei.com/enterprise/en/doc/EDOC1100174721/fe267bec/bgp-update

But if you suspect that, it's not so important to calculate the total size of packets, which by the way you can see them in PCAP, but important to test if an MTU issue exists or not. And more importantly fix the MTU issue.

Toshi 

Terms & ConditionsCookie settingsAccessibility statement