cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1623
Views
0
Helpful
8
Replies
Beginner

WAAS interception method, failure detection and method comparison.

Hi

 

When I configure my WAAS there's a drop down box entitled "Interception method".  The options available are None, WCCP, inline and appNav-controller.  What method should I use if I want to use PBR to send traffic to the WAAS?  I tried selecting WCCP and then not ticking the box to enable the WCCP service and this seemed to work but it seems strange to select a method only to not then enable the service.

What are the advantages and disadvantages of WCCP and PBR?

Also, how will traffic be handled if the WAAS fails?  I did some basic testing with WCCP and when I fail the link to the WAAS it seems to pause a file transfer for some time before resuming.  Is there any way to quickly detect the WAAS failure with WCCP and route the traffic directly to the WAN ?  I can get fast failure detection with PBR and IP SLA but I'm not sure what interception method I should be using with PBR.

 

Thank for any input, Stuart.

Everyone's tags (1)
8 REPLIES 8
Participant

Re: WAAS interception method, failure detection and method comparison.

Hi Stuart,

 

If you're using PBR as redirection method, you should specify "None" !

It it the "router"s responsibility to forward the packets directly to the WAAS "device".

And the WAAS "device" will forward the "optimized" packet back to its default gateway (which hopefully is the router, which has redirected it.

 

WCCP advantages :

1) Automatic load balancing btw. multiple WAAS devices (up to 32 by using unicast)

2) Possible to specify md5 authentication

3) multiple routers can redirect to a WAAS "cluster" (or single device)

4) Redirection and return packets can run within GRE - allows :

  a) multiple layer 3 hops btw. router and WAAS

  b) possible return of packets directly to redirection router instead of default gateway (negotiated return)

WCCP disadvantages :

1) different forwarding and return method depending on router platform :

https://supportforums.cisco.com/t5/data-center-documents/wccp-platform-support-overview/ta-p/3144818#Introduction

2) historically many bugs (many solved now)

3) can be a little difficult to design the redirection

 

PBR disadvantages :

1) requires other technologies to verify reach-ability

2) no load-balancing/sharing btw. WAAS "devices"

 

With regards to failover in general :

If a WAAS device fail, be aware that the TCP session (previously optimized) will require a reconnect btw. client and server, as the TCP sequence numbers changes ! This is irrespective of the redirection method and this can take some time.

Whether PBR is faster than WCCP relies on timers, and maybe whether the router platform supports WCCP configurable timers.

In PBR You can probably run you're IP SLA more often and then trigger on that.

 

Default WCCP timeout is 30 seconds, can be modified down to 9 or 15 seconds (done on WAAS and negotiated, but router has to support it - see previous link).

 

Hope this helps

 

Best Regards

Finn

Beginner

Re: WAAS interception method, failure detection and method comparison.

Finn

 

Thank you for the reply.

 

However, I tried choosing none as the interception method with a PBR policy on my router and it doesn't work.  As a test I tried to start an ftp transfer but the connection hangs then times out when I try to connect to the remote ftp server.  Immediately I change the interception method to wccp it works so long as I have a matching wccp configuration on the router.

I thought it might require an interception ACL so I created one with ip any any in it but still the same result.  It doesn't work unless I have wccp enabled.  I don't need to apply any wccp redirect commands.  All I have on the router is enough to enable service ID 61 and 61.  See below.

ip wccp 61
ip wccp 62

On my router WAN and LAN interfaces I have no wccp configuration.  Only a PBR config

 

interface GigabitEthernet0/1
 description WAN
 ip address 10.0.0.1 255.255.255.252
 ip policy route-map WAAS

 

interface GigabitEthernet0/0.10
 description LAN
 encapsulation dot1Q 10
 ip address 10.10.0.254 255.255.255.0
 ip policy route-map WAAS

 

So the redirection is happening with PBR but will not work unless wccp is there.  When I start the ftp transfer there are 0 packets listed as being redirected on wccp service 61 or 61 and the PBR route-map counters are incrementing.

 

Is this a possible bug ?  It seems strange I need wccp enabled but then don't use it for redirection.

 

Thanks, Stuart.

 

Participant

Re: WAAS interception method, failure detection and method comparison.

Hi Stuart,

 

Even though the manual states : "...WAAS proxy applications receive PBR-redirected traffic in the same manner as WCCP redirected traffic" - enabling WCCP should not have any impact.

But I think that the WAAS device is dropping the packets, because it sees the "redirected" packets more than once.

To verify check for "routing loops" and session drops in one of the log files (dependant on WAAs version) :

 - perform the test again

- pre version 6.x : syslog.txt (use the current log)

- version 6.x and later : waasnet.log  (check the current log)

 

use command : find-pattern match "loop" <logfile>

 

Where is your WAAS located - if it is reachable through one you the interfaces you mentioned, your definitely facing this issue as you are breaking this rule :

 

<quote>

WAEs (Edge-WAE1 and Core-WAE1) must reside in an out-of-band network that is separate from the traffic’s destination and source. For example, Edge-WAE1 is on a subnet that is separate from the clients (the traffic source), and Core-WAE that is on a subnet separate from the file servers and application servers (the traffic destination). Additionally, the WAE may have to be connected to the router that is redirecting traffic to it through a tertiary interface (a separate physical interface) or a subinterface to avoid a routing loop.

<end-quote>

 

Please share your findings

 

Best Regards

Finn

Beginner

Re: WAAS interception method, failure detection and method comparison.

Finn

 

The setup has the WAAS on its own subnet at each site on a router sub-interface.  The LAN is on the same physical interface but a different sub-interface.  The WAN is on its own physical interface.  I only policy route on the LAN and WAN interfaces.  

So at site A the traffic comes in the LAN on one sub-interface and is policy routed to the WAAS on a different sub-interface.  The WAAS returns the traffic to its default gateway's interface which has no policy routing applied.  The traffic is then routed to the other site.

 

At the other site the WAN interface policy routes the traffic to the WAAS on its own sub-interface.  It returns the traffic to it's gateway which has no policy routing and the traffic exits to the LAN.   If it makes any difference the WAAS CM is on this /24 but I don't see any issue with that.

 

Site A

interface GigabitEthernet0/0.10
 description LAN
 encapsulation dot1Q 10

ip address 10.10.0.254 255.255.255.0

ip policy route-map WAAS
 
interface GigabitEthernet0/0.20

 description WAAS interface
 encapsulation dot1Q 20
 ip address 10.20.0.254 255.255.255.0
!
interface GigabitEthernet0/1
 description WAN
 ip address 10.0.0.1 255.255.255.252
ip policy route-map WAAS

!

ip access-list extended WAAS
 permit tcp any any eq ftp
 permit tcp any any eq ftp-data

!

route-map WAAS permit 10
 match ip address WAAS
 set ip next-hop verify-availability 10.20.0.1 1 track 1

 

Site B

interface GigabitEthernet0/0.30

 description LAN interface
 encapsulation dot1Q 30
 ip address 10.30.0.254 255.255.255.0
 ip policy route-map WAAS
 
!
interface GigabitEthernet0/0.40
 Description WAAS and WAAS CM subnet
 encapsulation dot1Q 40
 ip address 10.40.0.254 255.255.255.0
!
interface GigabitEthernet0/1

 description WAN interface
 ip address 10.0.0.2 255.255.255.252
 ip policy route-map WAAS

 

ip access-list extended WAAS
 permit tcp any any eq ftp
 permit tcp any any eq ftp-data

 

route-map WAAS permit 10
 match ip address WAAS
 set ip next-hop verify-availability 10.40.0.1 1 track 1

 

This fails to work.  All I do to get it to work is enable wccp config on the routers but no redirection on any interface.  I then enable wccp on the WAAS and tick the box to use the default gateway as the WCCP router.

I could understand if I was doing wccp redirection in addition to PBR and that caused the problem.  But in this case it only works with wccp enabled with no redirection.    If I remove wccp config on the routers and choose interception method none on the WAAS the file transfer hangs.

 

I will need to go to my lab to see the logs you mentioned.

 

Thanks, Stuart.

Participant

Re: WAAS interception method, failure detection and method comparison.

Hi Stuart,

 

I think you should use different route-map (and thus different) Access-lists on the WAN and LAN interfaces.

PBR is always ingress only.

On the LAN interface where the FTP server, you'll have to reverse the Access-list for catching ftp traffic originating (sourced) from the FTP server.

So something like this (this is only relevant for the site where the FTP server resides on the LAN)

ip access-list extended WAAS-LAN
 permit tcp any any eq ftp
 permit tcp any any eq ftp-data

ip access-list extended WAAS-WAN
 permit tcp any eq ftp any
 permit tcp any eq ftp-data any

 

Also be aware that this won't work for passive FTP and also the direction have to be change for the remote site.

 

Best Regards

Finn

Beginner

Re: WAAS interception method, failure detection and method comparison.

Finn

 

Accepted, the access lists were wrong.  However, I had just cut and pasted the ftp lines.  There were further lines below identifying the traffic by host address in both directions and this was catching the traffic. 

 

The traffic was being optimized when I had the wccp part configured and wccp chosen as the intercept method.  I changed the interception method to "none" without changing the ACL's and that's what triggered the failure.  I also left wccp on the WAAS end and removed it from the routers to break the wccp connections and this caused the failure.  So my mistake for not including the full ACL entries but the issue still stands that the PBR works with wccp configured as the interception method but not with "none" as the interception method.  With "none" the ftp transfer hung. I didn't get prompted to log into the ftp server.  Similarly, I tried a cifs transfer and it hung.  Both failures resolved by setting up wccp even though I had no wccp redirection on the interfaces, just PBR.

 

I have some time scheduled in my lab tomorrow so will do some more testing and will confirm the ACL entries are sufficient to redirect the traffic.

 

Thanks again for your input.  It's much appreciated.

 

Stuart.

Beginner

Re: WAAS interception method, failure detection and method comparison.

Ok.  So I did some further testing today.

 

I simplified my access-lists to catch all IP traffic between the hosts I do the file transfer between.  This was in place before but I had only cut and pasted lines with ftp on them which gave the false impression the ACL's were applied incorrectly.

 

ip access-list extended WAAS

 permit ip host 10.10.0.100 host 10.30.0.100

 permit ip host 10.30.0.100 host 10.10.0.100

 

I use a route-map to reference the access-list

 

route-map WAAS permit 10

 match ip address WAAS

 set ip next-hop verify-availability 10.20.0.1 1 track 1  <- Track the WAAS being alive.

 

The track is up so we can discount that.

 

I then apply the route-map as a policy to the LAN and WAN interfaces on each router

 

Router-A

interface GigabitEthernet0/0.10

 description LAN

 encapsulation dot1Q 10

 ip address 10.10.0.254 255.255.255.0

 ip policy route-map WAAS

!

interface GigabitEthernet0/1

 description WAN

 ip address 10.0.0.1 255.255.255.252

 ip policy route-map WAAS

 

On the WAAS subnet there is no policy

 

interface GigabitEthernet0/0.20

 description WAAS subnet

 encapsulation dot1Q 20

 ip address 10.20.0.254 255.255.255.0

 

I do an identical access-list at the far end so it matches traffic in both directions.

 

ip access-list extended WAAS

 permit ip host 10.10.0.100 host 10.30.0.100

 permit ip host 10.30.0.100 host 10.10.0.100

 

And an identical route-map and policy.

 

route-map WAAS permit 10

 match ip address WAAS

 set ip next-hop verify-availability 10.40.0.1 1 track 1

 

Router-B

interface GigabitEthernet0/0.30

 description LAN interface

 encapsulation dot1Q 30

 ip address 10.30.0.254 255.255.255.0

 ip policy route-map WAAS

 

interface GigabitEthernet0/1

 description WAN interface

 ip address 10.0.0.2 255.255.255.252

 ip policy route-map WAAS

 

I don’t apply any policy on the WAAS subnet

 

interface GigabitEthernet0/0.40

 description WAAS subnet

 encapsulation dot1Q 40

 ip address 10.40.0.254 255.255.255.0

 

On both WAAS I have interception method "none"

 

When I try to setup an ftp session it hangs.  On the client it sends 3 x syn packets but never sees a syn-ack.  On the server it never sees any of the 3 syn packets so I have to assume the syn is getting dropped somewhere.  I suspect at the 1st WAAS

 

I looked in the WAAS syslog.txt file for the pattern loop and there is nothing.

 

To get the transfer working I do the following

 

Enable wccp on each WAAS as the interception method with the default gateway as the wccp router.

 

Then on both routers

Ip wccp 61

Ip wccp 62

 

That’s all.  No redirection on any interface

 

As soon as I do that I see the following

 

Router A

Dec 19 12:14:51.994: %WCCP-5-SERVICEFOUND: Service 61 acquired on WCCP client 10.20.0.1

Dec 19 12:14:51.994: %WCCP-5-SERVICEFOUND: Service 62 acquired on WCCP client 10.20.0.1

Router B

Dec 19 13:00:19.372: %WCCP-5-SERVICEFOUND: Service 61 acquired on WCCP client 10.40.0.1

*Dec 19 13:00:19.372: %WCCP-5-SERVICEFOUND: Service 62 acquired on WCCP client 10.40.0.1

 

I then try the ftp transfer again and it works.  There is no WCCP redirection anywhere.  The PBR is only on the LAN and WAN interfaces to re-route traffic as it enters the interface and the interface to the WAAS has no PBR or wccp on it.

 

Similarly, when I try to map a network drive to pull a file across the drive mapping times-out until I put the wccp config on.  Then it maps immediately and I can pull my file across.  On the WAAS I see

 

ConnID        Source IP:Port          Dest IP:Port            PeerID Accel RR

    67        10.30.0.100:20     10.10.0.100:56123 50:3d:e5:9d:5c:45 TDL   98.6%

    68     10.10.0.100:56124       10.30.0.100:445 50:3d:e5:9d:5c:45 TGDL  98.8%

 

So I have a cifs and ftp session in progress and optimizing.

 

I then tried removing the wccp config from the routers but leaving the WAAS with interception method and it worked.  So the common factor here seems to be that the WAAS must have interception method wccp configured to use PBR. 

 

Stuart.

 

 

Highlighted
Participant

Re: WAAS interception method, failure detection and method comparison.

Hi Stuart,

 

This is strange, I don't see why and I've found no Cisco doc stating this.

What platforms and software version are you running on your routers and WAAS ?

Maybe TAC can assist ?

Last thing that popped my eye is that in some documentation when your running with names access-list you have to specify the "name" keyword. It's a long shot, but I'm out of suggestions.

 

Best Regards

Finn

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards