cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1091
Views
0
Helpful
6
Replies

WAAS No Peer - Insufficient option Space?

desmckee
Level 1
Level 1

Hi,

I have a WAAS trial deployment running with a pair of 612s in the data centre and a coupe for remote 674s.

One site appears to be running fine (has optimised connections, both sides see each other in topology) but my new site cant discover the peer. From what I have read this commonly seems to be asymmetric routing but I only have one path in and out so it cant be that.

Checking show stat auto-discovery and debug auto-discover conn I see that my 'Insufficient Option-Space' count is increasing. Does anyone know what this means or how to resolve the undiscovered peer? I see the conns from the remote site in the head-end WAAS, so I believe that means WCCP is at least sending the traffic to the head-end device.

FYI the difference between the working and non-working sites is that one is using GRE/IPSec (working) and the other is plain IPSec (not working). Again, I don't believe its MSS or MTU as the default 1380 is large enough to pass unfragmented.

Thanks for your help,

Des

6 Replies 6

Zach Seils
Level 7
Level 7

Des,

The 'Insufficient Option-Space' counter indicates that there is not enough room in the TCP options header field to insert our auto-discovery options.

Is there another device in the path (WAN optimization device, etc.) that could be inserting their own options?

Zach

Thanks, there is actually, but its not configured to do anything - the other working site passes through it (the WAAS are meant to replace it). Ive disabled it just to make sure, and cleared the counters and at least i dont see that any more.

All i see now at either end is the no peer / assymetric counters increasing.

This is a bug from the remote end when i initiated an rdp to a machine on that lan:

No peer found. init_devid=00:1a:64:ca:7a:2c, my_devid=00:1a:64:ca:7a:2c

Thats the mac address of the remote device itself - i.e. init device same as remote device, does that suggest anything?

Cheers

TCP Option 21 needs to be present for auto-discovery to work. If missing, you will seen 'no peer' even if the WAE is intercepting at the other end. Firewalls have a tendency to clear this option. Other devices may as well.

You will want to run a TCPDUMP on both WAEs and save it to a file. Try to access something across the WAAS and get the nopeer/asymetric to appear. Stop the network capture and download to your desktop. Review the network trace SYN/SYN Ack packets. When reviewing the packets received from the remote WAE, TCP Option 21 should be present. If missing, you will want to review why.

HTH,

Dan Laden

Thanks for that, one step closer, but it seems to be option 33 (according to the ASA) that was being dropped? One of my head-end boxes can now see the remote WAE, but not the other one - are there any other options that i need to look out for being dropped?

Thanks

In fact, I think the devices still aren't auto-discovering after all; although they show in the topology table in the GUI, doing show stat tfo peer on either of the head end devices or the remote device shows no peer.

Looking at tcpdump, I definitely seem to see the MAC addresses entered into option21 / 33 at either end:

Remote end:

14:41:36.225065 IP (tos 0x0, ttl 58, id 50033, offset 0, flags [DF], length: 64) TERM_SERVER_IP.51979 > DEST_SERVER_IP.ssh: S [tcp sum ok] 1505981933:1505981933(0) win 49640

14:41:38.267296 IP (tos 0x0, ttl 250, id 0, offset 0, flags [none], length: 56) DEST_SERVER_IP.ssh > TERM_SERVER_IP.51979: S [tcp sum ok] 227079900:227079900(0) ack 1505981934 win 4128

Head-end:

14:41:34.505685 IP (tos 0x0, ttl 55, id 50033, offset 0, flags [DF], length: 64) TERM_SERVER_IP.51979 > DEST_SERVER_IP.ssh: S [tcp sum ok] 1505981933:1505981933(0) win 49640

14:41:34.508646 IP (tos 0x0, ttl 253, id 0, offset 0, flags [none], length: 56) DEST_SERVER_IP.ssh > TERM_SERVER_IP.51979: S [tcp sum ok] 3768269639:3768269639(0) ack 1505981934 win 4128

Those MACs are the correct addresses for the NIC on the WAEs. Shouldn't show stat tfo peer be showing the head and remote end devices (as with my other boxes)? I know ssh wont be optimised, but I just want to see the devices recognise each other as peers.

Thanks for your help.

Debugging auto-discovery at the remote end, it seems that it seems to think the peer is incompatible for some reason?

kernel: %WAAS-SYS-7-900000: Entering ad_aoim_check_peer_compat. peerid = 00:1a:64:f2:17:b7, ad_ver=3, pe_ao_type = 1

Oct 20 15:59:50 xxxxxx 2009 Oct 20 15: kernel: %WAAS-SYS-7-900000: ad_aoim_check_peer_compat -> peer invalid - returning not found

BTW we are running 4.1.1.23 on all devices.

Thanks

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: