VEEAM traffic on port 2500 not Accelerated-shows pt only

[burkerust]

We have setup a classifier and tried setting possible but our Veeam replication traffic on port 2500 just gets passed thru. Has anyone else setup acceleration on Veeam backup and Replication?

[Nicolas Fournier]

Hi Rusty,

What do you get an your WAE when you issue a "show statistics connection pass-through server-port 2500' command on your WAE when a Veeam session is going through the device?

This should give you more info on the reason this traffic is in pass-through.

You can find a list of the possible PT values together with a quick explanation of those under the following link:

http://www.cisco.com/en/US/partner/docs/app_ntwk_services/waas/waas/v421/command/reference/execmds.html#wp3113061

Regards,

Nicolas

[burkerust]

Thanks Nicolas for your reply. Our show stat con  shows PT in progress no matter what settings we change on the classifier for port 2500.

[Nicolas Fournier · Accepted solution]

Hi Rusty,

PT In Progress means the WAAS hasn't seen the whole 3WHS of this TCP connection.

I see two possible causes:

1.) Persistent connections

If your VEEAM connection existed before the WAE was put into place and if it wasn't re-established afterwards, you'll always see this connection as PT In Progress, no classifiers will help there. To have it optimized, you'll need to reset this connection and force your application to establish a new one.

2.) Some traffic bypassing the WAE

If your application is creating new connections all the time, then what you see means that some of the traffic between the client and the server is bypassing the WAE.

To see exactly what is going on, you can take a capture on your WAE with tethereal.

Something like this should help you:

tethereal -R "tcp.port eq 2500"

Once the capture is started, establish the VEEAM session and verify that you see the 3 packets of the 3WHS. If you don't, you'll have to investigate the packet path between the client and the server.

Regards,

Nicolas

[burkerust]

Ran command as you said, attached is the start of the capture. Any suggestions?

[Nicolas Fournier · Accepted solution]

Hi Rusty,

If you have a look at the capture, you'll notice that all packets have a source IP of 10.68.20.200 and a destination of 10.68.25.25.

The "tcp.port eq 2500" should capture all the packets that have port 2500 as either source or destination port and here, we only see packets with it as destination.

This means that the return traffic from 10.68.25.25 to 10.68.20.200 is bypassing the WAE since we don't see it there.

You'll need to investigate the traffic path from the VEEAM server to your client and force both sides of the communication to go through your WAE (traceroute might help you to identify the path).

Regards,

Nicolas

[burkerust]

I f you look in the new attachment you can now see a successfull 3WHS so now it's working (YEAH and Thanks). The single direction led to my network engineer revisiting a 6509 switch interface and removed an ip address which immediately started picking up traffic on port 2500. So you have helped us solve a support issue opened two weeks ago with Cisco. Our concern now is:  TCP Previous segment lost  and TCP CHECKSUM INCORRECT causing retransmits but the dup's went away. Thanks again for your help and any ideas about the retrans would be great!

Rusty Burke

Systems Engineer

Cal Dive International

[Nicolas Fournier · Accepted solution]

Hi Rusty,

I wouldn't worry too much about those two issues.

1.)  [TCP CHECKSUM INCORRECT]

It is most the likely due to TCP checksum offload. For more info on it: http://wiki.wireshark.org/CaptureSetup/Offloading?action=show&redirect=TCP_checksum_offload

2.) [TCP Previous segment lost]

Once WAAS auto discovery is finished, we shift the sequence number of the packets between the two WAE by 2Gb to be able to differentiate the optimized and the non optimized part of the connection.

Tethereal doesn't know about this shift and thinks that those 2Gb were lost and thus report lost segments when there are none.

Regards,

Nicolas