BGP Keeps on Dropping...

[arnoldsotis110882]

Error:  

Jan  23 02:00:21.003: %BGP-3-BGP_NO_REMOTE_READ: x.x.x.x connection timed out - has not accepted a message from us for 20000ms (hold time), 0 messages pending transmition.

Jan  23 02:00:21.003: %BGP-3-NOTIFICATION: sent to neighbor x.x.x.x passive 4/0 (hold time expired) 0 bytes

Jan  23 02:00:21.003: %BGP_SESSION-5-ADJCHANGE: neighbor x.x.x.x IPv4 Unicast topology base removed from session  BGP Notification sent

i already change the hold down timer and keepalive timer to lower value but it won't change. bgp still dropping frequently

added policy map config but still having the same result.

policy-map parent

class class-default

    shape average 3300000 103000 0

can anyone help me figuring out waht is the exat issue?

Thank you

[Firuz Azimov]

Hello Jose

Where it configured ? I never see in configuration mss 536. Could you tell where exactly see ?

[rsimoni]

Hi Firuz,

I guess Jose put you on the right track. TCP traffic is somehow limited to 536 bytes by some devices in between.

If you don't see anything on the intermediate routers remember to also check other devices such as firewalls/load balancers etc.

Riccardo

[Firuz Azimov]

One of the peers should have:

R1(config)#ip tcp mss 536

Best Regards,

Jose.

No I dont have this configuration on both peers. But in middle there are many L2 switches (no routers between peers).

Should I configure on peers ip tcp mss 1460 ?

Or I need to find why

Datagrams (max data segment is 536 bytes) ?

[Firuz Azimov]

I think I find a problem.

One peer is path-mtu capable, but other end no. I wanna enable globally ip tcp path-mtu-discovery
I hope this helps.

Do u know any restriction for this command?

[Bonny Dinis]

Hi,

I am also facing same issue, could you please  brief what you have done to resolve the issue & what does this actually mean *physically transferred the connection between router A and B.*

Thanks

[j.a.m.e.s]

I just hit this issue on iBGP peering between two Cat3850s - the peerings were between loopbacks - which is quite a standard setup in the world of iBGP. The switches were connected directly via 10G fibres and system MTU was set like this:

system mtu 9198

The loopbacks have a maximum MTU of 1500b which can't be changed:

switch-01#  sho inter lo0 | in MTU
  MTU 1514 bytes, BW 8000000 Kbit/sec, DLY 5000 usec,

The BGP process was wrongly detecting the MTU as 9000b

switch-01#show ip bgp vpnv4 vrf vf-main neighbors 10.0.0.2 | inc path-mtu
Transport(tcp) path-mtu-discovery is enabled
switch-01#show ip bgp vpnv4 vrf vf-main neighbors 10.0.0.2 | inc segment
Maximum output segment queue size: 50
Datagrams (max data segment is 9158 bytes

Setting ip mtu 1500 on the physical link between the two peers solved this. After setting that, BGP negotiated a segment size of 1460b and the peering has been stable since.

It's a mystery why the MTU was wrongly detected and possibly a minor bug in this platform. I would be interested to know what others think about this.

The error in syslog was:

%BGP-3-BGP_NO_REMOTE_READ: 10.0.0.2 connection timed out - has not accepted a message from us for XXms (hold time)