BGP instability on IPSEC tunnel

[Dragnipur]

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 ?

[emnoc]

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]

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]

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

Ken Felix

[staniel87]

Dragnipur wrote:

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

Hi, can you elaborate and provide little more details on how you manage to solve this issue. We are experiencing similar problem but cant figure it out.

Thanks.

[acsmith]

I'm having this same problem. anyone have additional information? 

[DUSTINREEVES]

can you please elaborate on the routes you removed?

[Toshi_Esumi]

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]

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

[Toshi_Esumi]

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