05-28-2008 11:03 PM
Hello!
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
.........wae1..................wae2
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
Socket:
Allocation failures: 0
Accept pair allocation failures: 0
Unix allocation failures: 0
Connect lookup failures: 0
Packets:
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
05-28-2008 11:21 PM
Ad,
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
05-29-2008 12:00 AM
How it is possible to check up it and to repair?
05-30-2008 03:10 PM
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.
Zach
06-24-2008 01:21 AM
Hi.
traceroute from both WAE:
WAE-1#traceroute 192.168.170.141
traceroute to 192.168.170.141 (192.168.170.141), 30 hops max, 38 byte packets
1 192.168.40.110 (192.168.40.110) 0.857 ms 0.601 ms 0.760 ms
2 192.168.167.66 (192.168.167.66) 64.795 ms 63.484 ms 63.462 ms
3 192.168.170.141 (192.168.170.141) 64.988 ms 64.300 ms 73.255 ms
WAE-1#
WAE-2#traceroute 192.168.40.109
traceroute to 192.168.40.109 (192.168.40.109), 30 hops max, 38 byte packets
1 192.168.170.142 (192.168.170.142) 0.119 ms 0.095 ms 0.137 ms
2 192.168.167.65 (192.168.167.65) 57.637 ms 61.645 ms 58.478 ms
3 192.168.40.109 (192.168.40.109) 66.764 ms 61.275 ms 70.447 ms
WAE-2#
On tcpdump client packets are visible, packets from WAE it is not visible, only from Central-manager on 443 port it is visible.
06-27-2008 02:20 AM
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.
Zach
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide