1000v - VEM VSG Traffic flow

[David Undernehr]

Can someone please explain the traffic flow process between the VEM to the VSG and back. I recently had a problem where users reported latency when connecting to a certain application.

To resolve the issue TAC had me turn off TCP State-checks which resolved the issue. Now all traffic is going from the VEM to the VSG regardless whether or not the TCP conversation has been seen before.

What issues or problems can I expect with turning this feature off. Loss of performance is the only thing I can think of since now the VSG has to perform policy lookups on every packet. What else do I lose with having TCP STATE-CHECK turned off?

Thanks in advance!

[answanso]

Hi David,

The tcp state-check command checks for the following violations:

- Seq numbers outside of the expected window

- Ack numbers outside of the expected window

- Invalid window size variations

There is a defect you could be running into in which a few scenarios caused TCP failures which inturn make the connection hang or seem slow. The defect is:

CSCtz91858  - N1KV: TCP connections protected by VSG fail with 'tcp state-checks'

Symptom:

Under certain conditions, TCP connections processed by VSG may fail. The output of 'show vsn statistics vpath' on the VSM will show packets dropped for the following reason:

TCP chkfail WndVari

Conditions:

All of the following conditions must be met:

1. The VSM must be running version 4.2(1)SV1(5.1).
2. The following command must be enabled on the VSM:

vsn type vsg global
   tcp state-checks

*Note: A similar issue affected 4.2(1)SV1(4a). See CSCtw80870 for more details.

Workaround:

Disable the 'tcp state-checks' command on the VSM. vPath will no longer perform basic layer 4 TCP state checks on the traffic when this command is disabled.

Wait for the next release of NX-OS for 1000v and you can attempt to re-enable the feature. If the connections still appear slow, you can use the show vsn statistics vpath | include TCP command to see if packets are dropped due to the TCP state checks.

HTH

Anthony

[David Undernehr]

Thanks Anthony for the helpful information. I am going to read the bug ID you mention in the reply.

Two Questions:

1.) I am assuming the TCP State-Check feature is also used to optimize the TCP flows by offloading the policy lookups from the VSG to the VEM (vPath) if enabled. However, with this feature disabled now all TCP flows are processed by the VSG policy lookups regardless if the TCP stream has been seen before or not. Is my understanding of the TCP STATE CHECK correct and if so what kind of performance issues can I expect with this feature disabled?

2.) Do you have any white papers/datasheet you can send me on TCP STATE CHECK so I can get a deeper understanding of this technology? I have read the command reference guide but unfortunately it is pretty vague.

Thanks,

David

[answanso · Accepted solution]

Hi David,

It is my understanding that the state-check is done on the vPath for the checks I mentioned above. It does not offload or optimize flows per say, rather ensure the validity of TCP state of the flow. Disabling it, simply removes these checks within the vPath, which in your case resolves the slowness because the traffic is no longer matched against the 3 criteria above and erroneously dropped.

Unfortunately I haven't found any external documentation that really outlines this in plain english. I will keep my eye out and if I happen across some, I will post it here in the future.

Thanks

Anthony

[David Undernehr]

I must be thinking of Fast Path off loading. Thanks again Anthony for your time and help.

Sent from Cisco Technical Support iPad App