BGP flapping with MTU mismatch

[nassef2010]

Hello Everyone,

This is a typical issue but I want more details, in many cases when BGP flaps every 180 secs "Hold timer", when we adjust MTU the same at both sides, it works fine. But how could MTU affect the keepalive messages which are only 19 bytes, any Interface MTU could handle it. What is the relation between Flapping and MTU?

We assume here that flapping is caused by hold timer expiration due to missing of keepalive messages or that could be caused by something else that is related to MTU?

Thank you.

[Harold Ritter]

@MHM Cisco World , the keepalive being dropped because it is sent in the same TCP segment as the update is only one case. I agree that it will cause an issue, but this is not the only case, as I am trying to explain, but for some reason you seem like you are not seeing my point.

This issue will happen whether the keepalive is delivered within the same TCP segment as the update message or not.

Regards, 

[MHM Cisco World]

If the update (only) full one packet and send and drop 

Then follow by keepalive (only) the peer accept that' it can send selective tcp ack for keepalive.

That my point' previous drop not effect new tcp recieve data.

MHM

[Harold Ritter]

Hi @MHM Cisco World ,

> Then follow by keepalive (only) the peer accept that' it can send selective         > tcpack for keepalive.

The best way to fix it is at the source of the issue,  which is to fix the L2 path MTU or to change the L3 MTU on the two peers to reflect what the L2 network supports.

It would not be very useful to have the BGP session up if the updates are dropped.

Regards,

[Harold Ritter]

One more thing @MHM Cisco World 

I generally see this issue happens because the layer 2 network can't support the MTU that the BGP peers use. for example:

R1 (mtu 900) ----  (mtu 9000) switch1 (mtu 1500) ---- (mtu 1500) switch (9000) ----- (mtu 9000) R2

Try something like this to replicate the issue mentioned by the OP (MTUs can be different). 

Regards,

[MHM Cisco World]

Sure I know' even if I disable pmtu the data max size is set to lowest mtu peer (i.e. the both agree in low mtu) I need SW with lower mtu to test flapping peer.

MHM

[Harold Ritter]

> I need SW with lower mtu to test flapping peer.

Although there are other variants, the layer 2 network is very often the cause of these issues, especially when the two peers are directly connected from a L3 standpoint.

Sometimes 2 routers might appear as directly connected from a L3 standpoint, but the L2 connection might be provided through a L2VPN service and traverse an entire SP network.

That is why it is always a good idea to test the end to end MTU using a "ping <destination> size <mtu size> df-bit" or a similar command depending on the platform and NOS used. 

Regards,