01-24-2012 05:49 AM - edited 03-04-2019 03:00 PM
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
Solved! Go to Solution.
06-12-2013 02:15 AM
Hello Jose
Where it configured ? I never see in configuration mss 536. Could you tell where exactly see ?
06-12-2013 02:20 AM - edited 12-18-2018 01:33 AM
06-12-2013 02:31 AM
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
06-12-2013 03:29 AM
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) ?
06-13-2013 01:31 AM
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?
07-17-2018 06:54 AM
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
09-06-2021 01:36 AM - edited 09-06-2021 01:37 AM
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)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide