sh stat peer dre output showing zero

[udaykumar.bh]

Hi, i have an issue where in WAVE-574 box running with sofware image 4.1.1c configured in off-path wccp mode is not able peering with headend WAE box. sh stat peer dre output shows all zero (logs provided below). I have prov.ided wccp configs from WAVE box n router below, plz advise accordingly

WAVE-574#sh stat peer dre

Current number of connected peers:  0
Current number of active peers:     0
Current number of degrade peers:    0
Maximum number of connected peers:  0
Maximum number of active peers:     0
Maximum number of degraded peers:   0

Active peer details:
WAVE-574#

WCCP config on WAVE:

!
wccp router-list 1 X.X.X.1 ---------------------------router lan ip address
wccp tcp-promiscuous router-list-num 1
wccp version 2
!
egress-method negotiated-return intercept-method wccp
!

WCCP config on router:

!

interface fastethernet0/0

ip address x.x.x.1 255.255.255.0

ip wccp 61 redirect in
ip wccp 62 redirect out

!

ROUTER# sh run | inc wccp
ip wccp 61 redirect-list REDIRECT-TO-WAE
ip wccp 62 redirect-list REDIRECT-TO-WAE
ip wccp 61 redirect in
ip wccp 62 redirect out
ROUTER#

Thanks,

Uday

[Thomas Jardin]

Hi Uday,

Couple of things.  First, I assume you have the ip wccp 61 redirect and 62 out on the same interface?

You also have to look at the Data Center side.  If you are using an ACL on the WCCP at the DC, make sure you have added permit statements for the users at this new site.

I've also seen issues where there is a new interface on the DC router to this new site and there needs to be a WCCP redirect statement on that interface.

I wouldn't use show stat peer to troubleshoot this isue.

I would use show stat conn to make sure you are seeing the flows on the box.  You won't get peer info until you have an optimized connection.

I hope this helps,

Tom Jardin

Cisco TAC

[udaykumar.bh]

Hi Thomas, thanks for ur quick response!

Yes i have the ip wccp 61 redirect and 62 out on the same interface at site.

I have added this new site's x.x.x.0/24 subnet in the ACL entry at DC too. I infact have sh stat conn all output also and same here i m providing, which shows peer ID N/A and ConnType as PT No Peer, PT In Progress.

WAVE-574#sh stat conn all

Peer ID             ConnType
N/A                 PT No Peer
N/A                 PT No Peer
N/A                 PT In Progress
N/A                 PT In Progress
N/A                 PT In Progress
N/A                 PT In Progress
N/A                 PT In Progress

Regrd

Uday

[Thomas Jardin]

Hi Uday,

Well, now we have to roll our sleeves up a bit.  There are a couple of possibilities.

1, Still something with WCCP.  To get an optimized connection we need four separate redirections.  Two on the edge, two on the Core.  If it is correct, we will see the traffic in both directions on each WAE.  You can check this very easily with TCPdump to the screen.

First identify a flow that is seen on the WAE with the show stat conn command. Then do a tcpdump to the screen with this format

tcpdump -n host 172.16.1.208   (one of the IP's you see) This is what you will see

wave-474-1#tcpdump -n host 172.16.1.208
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:48:39.193179 IP 172.16.1.208.62631 > 172.16.10.8.23: . ack 1434737728 win 15702
15:48:39.193230 IP 172.16.10.8.23 > 172.16.1.208.62631: P 1:217(216) ack 0 win 23

You can see that I have traffic in both directions so WCCP is working at this site.

If it looks something like this, it is missign a WCCP redirect.

15:48:39.193179 IP 172.16.1.208.62631 > 172.16.10.8.23: . ack 1434737728 win 15702
15:48:39.393178 IP 172.16.1.208.62631 > 172.16.10.8.23: . ack 217 win 15486
15:48:39.593191 IP 172.16.1.208.62631 > 172.16.10.8.23: . ack 384 win 15319
15:48:39.793149 IP 172.16.1.208.62631 > 172.16.10.8.23: . ack 546 win 15157
15:48:39.994126 IP 172.16.1.208.62631 > 172.16.10.8.23: . ack 708 win 16384
15:48:40.195109 IP 172.16.1.208.62631 > 172.16.10.8.23: . ack 870 win 16222

So, you see we are not seeing any traffic with the source IP of 172.16.10.8.  Then you have to trace the traffic from that IP to see which interface it is hitting on the WCCP router and double check the ACL and redirect statement.

2,  It is possilble that WCCP is working correctly at both sites and you are seeing traffic in both directions.  Then it is some type of security device stripping the TCP options.   WAAS works by adding options to the SYN packets which includes the PEER ID of the device and the desired optimization.  If you have a Cisco ASA or recent code of PIX, there is an option you can configure in the security settings of;

IP inspect WAAS. 

If none of this helps, then it is more complex than can be handled on this forum.  You'll need a TAC case.

One other simple thing to check is that you have the WCCP on the L3 interface, not the physical interface.

Best of luck,

Tom

[udaykumar.bh]

Hi Tom,

I have taken tcpdump for that wave box and same is mentioned below. I dont find traffic in both direction.

Here, 192.168.1.254 is one of the host at the site and 145.0.16.8 is the application server ip at DC. i m not suspecting any issue by security device as other sites are working fine. i have wccp applied on physical interface at the site where as at DC end it is on L3 interface.

WAVE-574#sh stat conn all

Local IP:Port       Remote IP:Port      Peer ID             ConnType
192.168.1.254:3898   145.0.16.8:26004 N/A                 PT In Progress
145.0.16.8:26004 192.168.1.254:3898   N/A                 PT In Progress
WAVE-574#

WAVE-574#tcpdump -n host 192.168.1.254
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:30:27.522014 IP 192.168.1.254.137 > 192.168.1.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:30:28.271077 IP 192.168.1.254.137 > 192.168.1.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:30:29.021131 IP 192.168.1.254.137 > 192.168.1.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:30:59.771824 IP 192.168.1.254.137 > 192.168.1.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:31:00.520826 IP 192.168.1.254.137 > 192.168.1.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

Thanks,

Uday

[Thomas Jardin]

Hi Uday,

Something is wrong here.  You are seeing UDP broadcast packets, not the traffic you are trying to optimize, so I think your tcpdump didn't get the correct interface.  Are you using gig 2/0, port-channel or Standby interfaces?  If so, run tcpdump -D  The -D will give you the correct interface.

Then you have to do

tcpdump -i   -n host 192.168.1.254

The correct interface could be eth1 if you are using gig 2.0 or Bond0 or eth11:0 depending on the output from tcpdump -D .

Tom

[udaykumar.bh]

Hi Tom,

In this box i dont have inline card and i am using managment interface Giga 1/0.

Here is the output for tcpdump -D command  and i m wondering why this output not listing managment interfaces!!

In fact i have same config and same 574 device at another site where WCCP is working fine. plz suggest..

WAVE-574#tcpdump -D
1.eth0
2.any (Pseudo-device that captures on all interfaces)
3.lo

WAVE-574#

Thanks..

Uday

[Thomas Jardin]

Hi Uday,

Are you able to attach a show tech-support from the WAE and a show run from the router that is doing the WCCP?

If not on this forum, then we'll need a TAC case to dig deeper into this issue.  The tcpdump should have shown more than it did.  You only have one interface and it seems like he WCCP just isn't working.

Tom

[udaykumar.bh]

Hi Tom,

The issue is now resolved, however still i didnt know the root cause for this behaviour!! i can see WCCP is working perfectly fine now.

For your info, in our WAAS setup there are 76 WAVE devices, most of the sites deployed in inline mode and few of them are wccp mode. This issue was observed while pulling the optimization report and i found wccp implemented sites reported zero optimization, however sites deployed in inline mode were not having issue. i m just wondering what went wrong with wccp implemented sites!!!

Thanks,

Uday