wae does not see the neighbour

Unanswered Question
May 28th, 2008


Is available 2 wae-612 (accelerator) and 1 wae-512 (CM)

It is impossible to start in any way them in work.

The scheme:

net1 - freebsd1 - internet - freebsd2 - net2


the Traffic on wae from freebsd is transferred through ipfw.

In logs wae2:

java: %WAAS-CMS-5-700001: ce(DataFeedPoll): update dataserver lastUpdateTime to: 1211867708092 status 0

In wae1 it is not present.

Prompt in what I was mistaken.

#sh tfo auto-discovery

Auto discovery structure:

Allocation Failure: 0

Allocation Success: 3236

Deallocations: 3236

Timed Out: 1

Auto discovery table:

Bucket Overflows: 0

Table Overflows: 0

Entry Adds: 3236

Entry Drops: 3236

Entry Count: 0

Lookups: 3278

Bind hash add failures: 0

Route Lookup:

Failures: 0

Success: 0


Allocation failures: 0

Accept pair allocation failures: 0

Unix allocation failures: 0

Connect lookup failures: 0


Memory allocation failures: 0

Total Sent: 3283

Total Received: 6511

Incorrect length or checksum received: 0

Invalid filtering tuple received: 0

Received for dead connection: 0

Ack dropped in synack received state: 0

Non Syn dropped in nostate state: 0

Auto discovery failure:

No peer or asymmetric route: 3232

Insufficient option space: 0

Invalid option content: 0

Invalid connection state: 0

Missing Ack conf: 0

Auto discovery success TO:

Internal server: 0

External server: 0

Auto discovery success FOR:

Internal client: 0

External client: 0

Auto discovery success SYN retransmission:

Zero retransmit: 0

One retransmit: 0

Two+ retransmit: 0

Auto discovery Miscellaneous:

Intermediate device: 0

RST received: 0

SYNs found with our device id: 0

SYN retransmit count resets: 0

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Zach Seils Wed, 05/28/2008 - 23:21


The counter:

No peer or asymmetric route: 3232

indicates that the WAE is either 1) not seeing the SYN-ACK for the connection, or 2) the WAE is seeing the SYN-ACK, but it does not contain auto-negotiation options.


Zach Seils Fri, 05/30/2008 - 15:10

I would first verify (via traceroute, etc.) that traffic is traversing paths on both sides of the WAN that the WAEs are on.

Next you can take a packet capture on the WAE (using tcpdump) to verify that the WAE does indeed see traffic in both directions.


slava_ram Tue, 06/24/2008 - 01:21


traceroute from both WAE:


traceroute to (, 30 hops max, 38 byte packets

1 ( 0.857 ms 0.601 ms 0.760 ms

2 ( 64.795 ms 63.484 ms 63.462 ms

3 ( 64.988 ms 64.300 ms 73.255 ms



traceroute to (, 30 hops max, 38 byte packets

1 ( 0.119 ms 0.095 ms 0.137 ms

2 ( 57.637 ms 61.645 ms 58.478 ms

3 ( 66.764 ms 61.275 ms 70.447 ms


On tcpdump client packets are visible, packets from WAE it is not visible, only from Central-manager on 443 port it is visible.

Zach Seils Fri, 06/27/2008 - 02:20

The WAE will preserve the source/destination IP addresses from the original packets. If you are seeing packets on the WAE, then that's an indication that redirection is working properly.

Next we need to find out why auto-discovery is failing. You can use the debug 'debug tfo conn auto' for this. If there is a significant amount of traffic going through the WAEs, you can use an access list to restrict which traffic is subject to the debug.



This Discussion