SYN/ECN generated by router 6807-XL on SLA HTTP

[compterds]

Hello There,

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,

Yoann

[Giuseppe Larosa]

Hello Yoann,

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

Giuseppe

[compterds]

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.

Yoann

[Giuseppe Larosa]

Hello Yann,

see the following link I was referring to last significant bits in DSCP byte

https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml#ecn-field

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

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk40661

and

https://en.wikipedia.org/wiki/Explicit_Congestion_Notification

Why it is setting this flag ?

from second link we see the following description

ECN works as follows:

• The initial TCP SYN handshake includes the addition of ECN-echo capability and Congestion Window Reduced (CWR) capability flags to allow each system to negotiate with its peer as to whether it will properly handle packets with the CE bit set during the data transfer. 
• The sender sets the ECN Capable Transport (ECT) bit in all packets sent. 
• If the sender receives a TCP packet with the ECN-echo flag set in the TCP header, the sender will adjust its congestion window, as if it had undergone fast recovery from a single lost packet.
• The next sent packet will set the TCP CWR flag, to indicate to the receiver that it has reacted to the congestion. The additional caveat is that the sender will react in this way at most once every RTT interval. Further, TCP packets with the ECN-echo flag set will have no further effect on the sender within the same RTT interval. 
• The receiver will set the ECN-echo flag in all packets, when it receives a packet with the CE bit set. This will continue until it receives a packet with the CWR bit set, indicating that the sender has reacted to the congestion. The ECT flag is set only in packets that contain a data payload. TCP ACK packets that contain no data payload should be sent with the ECT bit clear.

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

Giuseppe