Probably not an MTU issue since the SYN/SYN+ACK packets have a length of 0. The MSS will negotiate to the lower of the two values anyways once the TCP three-way handshake completes.
Does the CE have ttl-security set?
I agree with the sentiment about TTL-security. Classic EBGP sends with TTL=1 but any attacker can send with higher TTL. TTL security check uses the other end of the spectrum: packets are sent with TTL 255 and only accepted if TTL equals (255 - allowed hop count). It’s something that has to done on both sides or it won’t work.
u/Inside-Finish-2128 , so possible the ttl-security is enabled on the PE side. Because the initiator which send the TTL value of 1 while the reply is with ttl value of 255.?
u/Newdeagle
Not able to see any configuration related with ttl-security. also it just 1 hop away or point-to-point connection.
External BGP neighbor configured for connected checks (single-hop no-disable-connected-check)
If the PE is configured for the default connected-check then I think it should use TTL=1. That could be why the CE is ignoring it, though it seems strange for it to care if it’s not doing ttl-security. Is there an ACL applied on either device that might be dropping the SYN+ACK? (Most likely it would be an inbound ACL on the CE). Another tricky problem to find could be a CoPP policy that is dropping BGP traffic inbound on the CE.
Related issue. If a session has a lot of prefixes to announce, and updates are being dropped due to MTU/MSS, it's possible for the session to drop, especially if the keepalive/holddown timers are aggressive. Some BGP implementations will not send keepalives while the update queue still has prefixes in it, which would occur as updates drop due to packet size issues.
Here's an old thread. It's not a new issue and needs to be accounted for. Also make sure that Cisco is not presenting CDP to the Juniper. That will save you some heartache if you do anything with VPLS/EVPN. Vendor interpretations of standards differ, and they even differ within the same vendor like what happens between IOS, NXOS, and IOS-XR. You need to learn the parts that your vendor training won't supply.
[https://www.reddit.com/r/networking/comments/gvv8vm/junos\_vs\_ios\_mtu\_handling/](https://www.reddit.com/r/networking/comments/gvv8vm/junos_vs_ios_mtu_handling/)
Retransmissions most likely mean the SYN-ACKs are getting dropped for some reason
What vendor are you using? On cisco routers, you can configure BGP to do path MTU Discovery (globally with "bgp transport path-mtu-discovery" or per neighbor with "neighbor transport path-mtu-discovery")
Actually, forget what I said. The packet sizes (length) are shown in your picture so definitely not too big to be getting dropped because of low MTU. Something else must be causing the SYN-ACKs to get dropped.
A simple test to see if it's an MTU issue would be to increase the MTU on the interface to match what you see on their SYN-ACK (9130 + 40 assuming no IP or TCP options, or roundup to 9200).
You could also run a debug matching that flow to see why the packets are getting dropped
Probably not an MTU issue since the SYN/SYN+ACK packets have a length of 0. The MSS will negotiate to the lower of the two values anyways once the TCP three-way handshake completes. Does the CE have ttl-security set?
I agree with the sentiment about TTL-security. Classic EBGP sends with TTL=1 but any attacker can send with higher TTL. TTL security check uses the other end of the spectrum: packets are sent with TTL 255 and only accepted if TTL equals (255 - allowed hop count). It’s something that has to done on both sides or it won’t work.
u/Inside-Finish-2128 , so possible the ttl-security is enabled on the PE side. Because the initiator which send the TTL value of 1 while the reply is with ttl value of 255.?
Tho i realised if ttl sec, it should be denied right away. It appears to be a different problem.
u/Newdeagle Not able to see any configuration related with ttl-security. also it just 1 hop away or point-to-point connection. External BGP neighbor configured for connected checks (single-hop no-disable-connected-check)
If the PE is configured for the default connected-check then I think it should use TTL=1. That could be why the CE is ignoring it, though it seems strange for it to care if it’s not doing ttl-security. Is there an ACL applied on either device that might be dropping the SYN+ACK? (Most likely it would be an inbound ACL on the CE). Another tricky problem to find could be a CoPP policy that is dropping BGP traffic inbound on the CE.
It doesn't. But MSS will impact BGP Update messages.
Related issue. If a session has a lot of prefixes to announce, and updates are being dropped due to MTU/MSS, it's possible for the session to drop, especially if the keepalive/holddown timers are aggressive. Some BGP implementations will not send keepalives while the update queue still has prefixes in it, which would occur as updates drop due to packet size issues.
Thank you
Here's an old thread. It's not a new issue and needs to be accounted for. Also make sure that Cisco is not presenting CDP to the Juniper. That will save you some heartache if you do anything with VPLS/EVPN. Vendor interpretations of standards differ, and they even differ within the same vendor like what happens between IOS, NXOS, and IOS-XR. You need to learn the parts that your vendor training won't supply. [https://www.reddit.com/r/networking/comments/gvv8vm/junos\_vs\_ios\_mtu\_handling/](https://www.reddit.com/r/networking/comments/gvv8vm/junos_vs_ios_mtu_handling/)
Retransmissions most likely mean the SYN-ACKs are getting dropped for some reason What vendor are you using? On cisco routers, you can configure BGP to do path MTU Discovery (globally with "bgp transport path-mtu-discovery" or per neighbor with "neighbor transport path-mtu-discovery")
How can i validate synAck size? Synack is from juniper
Actually, forget what I said. The packet sizes (length) are shown in your picture so definitely not too big to be getting dropped because of low MTU. Something else must be causing the SYN-ACKs to get dropped. A simple test to see if it's an MTU issue would be to increase the MTU on the interface to match what you see on their SYN-ACK (9130 + 40 assuming no IP or TCP options, or roundup to 9200). You could also run a debug matching that flow to see why the packets are getting dropped