We are currently having multiple issue with a SLA. There are random failure.
This SLA is a basic http get to a ressource from internet.
We are monitoring this ressource on different VRF by different DMZ.
It appears that from one specific vrf, when sla fails, we're seeing the router (6807-XL) sending SYN/ECN.
Our thought is that some device on the path could block this SYN/ECN. But for now, we're investigating why our router generating this specific SYN/ECN. We checked each link (from our internal network) and no congestion happend on any link.
Documentation related to this model is not explicit, have you already seen this ? Could it be some kind of a bug ? Because before this SYN/ECN we have a good tcp session that finishing smoothly as expected.
Thanks in advance,
can you clarify what the affected VRF router is sending?
Because TCP SYN flag is set on the initial packet of TCP session setup.
And this is reasonable if you have configured an IP SLA using a TCP based HTTP get to check availability of service on server on the specified TCP port.
The ECN as far as I know means usage of low order bits of DSCP byte to indicate congestion and it is not related to TCP operations, but it is a sub-field of IP header.
Thanks in advance.
Hope to help
You're right, and I also read about this specific field in ip header.
As I mentionned, we're doing this http get from multiple source (e.g multiple vrf)
Both test are going to internet.
It appears that http get from vrf with a proxy on the path, it is working because the proxy breaking tcp and removing ecn field which is then forwarded to destination without this specific ecn echo.
From the vrf without any proxy, as there is no tcp break, it is not working (surely because ecn is not correctly dealed by an equipment on the path)
My question was more about this specific ECN :
How during TCP SYN, device knows there is a congestion ? Because TCP SYN is the first packet in session establishment and the router is initiating this SYN. There is no previous packet. TCP SYN ECN is seen randomly. When device sending basic TCP SYN it is working perfectly.
The randomly behavior is strange for me to be honest.
I attached the view from wireshark.
see the following link I was referring to last significant bits in DSCP byte
From the capture file I can see that in your case the ECN flag is a TCP flag and not an IPv4 header sub-field as I have supposed.
For the TCP ECN flag see the following link
Why it is setting this flag ?
from second link we see the following description
ECN works as follows:
Or the local device is implementing multiple IP SLA for TCP in different VRFs and it is going short of resources or it would like to negotiate this capability with the remote endpoint.
As you have noted the setting of this TCP flag may cause interoperability problems.
Hope to help