cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Ask the Expert- SD-WAN

2387
Views
0
Helpful
1
Replies
Highlighted
Beginner

WCCP WSA packet return - is it encapsulated in GRE or not

Hi All,

I have complex WSA design at my customer premisses with primary WSA cluster, and secondary WSA cluster on distanced disaster ecovery site.

As we have network topology where WCCP client is not directly connected to wccp router (IE router1 must forward packets to WSA-cluster-2 on disaster recovery site if wsa cluster-1 on primary site fails), we must use GRE as froward, and return method.

As WCCP documentation on Cisco site is rather poor (and that is a mild word), and some wiki documents I understood that if you use GRE as forwarding method and GRE as return method when WSA retrives HTTP/s site for clients behalf it will ENCAPSULATE returning packet to GRE and push it back to router that first made redirection.

Little picture is shown below:                           

                                              Internet

wsa_cluster1---  router1                           router2-backup -------wsa3 (wsa_cluster2-backup)

                            |                                              |

                     Firewall1 prim                      firewall - backup

                                      \                                 /

                                          Users subnets

So, basically since I have firewalls on my path here is traffic flow:

1. client makes http request

2. request follows primary path to primary locations router

3. since primary wsa cluster is dead, router1 enacapsulates users traffic into GRE and forwards it to WSA3's IP address)

4. Untill this moment we are doing fine...

5. IronPort receives SYN packet from client that

6. IronPort WSA3 returns SYN, ACK but: here is the problem

    WSA DOES NOT encapsulate return packet towards client in GRE tunnel but forwards plain ip packet with IP.src of desired HTTP site and IP.dst that equals to clients IP address.

7. since this connection is not mathched with incoming connection through firewall-bakup, connections are dropped and customer never receives appropriate packets from IronPort

8. If IronPort WSA returned packet towards ROUTER1 encapsulated in GRE we would not have a problem...

So my question is - why WSA can not be forced to encapsulate return packet into GRE and return int to int's WCCP routers address ???

I had to read every RFC I found to find some kind of explanation what is "return method", and (surprise !!!!) found out that negotiated return method is used ONLY if proxy bypass is performed on wccp cache engine !!!

But, from other hand, WAAS (that is also Cisco product) supports WCCP as redirection method, and also can be configured to return traffic to clients WCCP GRE encapsulated, Generic GRE encapsulated, or return packets can be forwarded as plain IP packet (as IronPort WSA does - apparently).

So in order to support all network devices and more challanging scenarios, my opinion is that there must be an option to configure how (and if) return  packets (from WSA towards clients) are encapsuleted in WCCP GRE, Generic GRE, or maybe just forwarded back to directly connected router without encapsulation.

Can this be done ?

What can be options of making this scenario to work...

Best regards,

Ana

1 REPLY 1
Beginner

Re: WCCP WSA packet return - is it encapsulated in GRE or not

Ana,

As you have discovered, the WSA only uses GRE return for traffic that is in the bypass list. This is because traffic in the bypass list is being returned to the router to deliver directly (bypassed from the WSA).

For client return traffic, the WSA uses standard routing, since the WSA is responding back to the source IP (SYN/ACK), not "returning" packets (the same packet sent from the client) back to the router. The WSA supports static routes in Network -> Routes, in case the clients need different routers to be accessed.

I have filed a the following feature Request:

75576 Utilize WCCP GRE return for all client traffic

I hope this explains a little better as to why it's working differently.

Cheers,

Josh