Routing to Failed WANn - with NSD FAIL WAN[n] detected?

Kurt Schumacher · ‎08-14-2010

DUT: RV016-V3 v4.0.0.4-tm

Trafic is still sent to failed interface with NSD FAIL WAN[n] :

(Why is the interface named WAN1, WAN2, ... but here WAN[2] ? Conistency please!)

C:\Users\ks>tracert www.google.ch zu www.google.ch [207.69.188.186] über maximal 30 Abschnitte:

Routenverfolgung

1    <1 ms    <1 ms    <1 ms 1.1.168.192.in-addr.arpa [192.168.1.1]
2     1 ms     1 ms     1 ms 33.22.221.81.in-addr.arpa [81.221.22.33]
3     *        *        *     Zeitüberschreitung der Anforderung.
4     *        *        *     Zeitüberschreitung der Anforderung.
5     *        *        *     Zeitüberschreitung der Anforderung.
...

C:\Users\ks>time
Aktuelle Zeit: 14:24:14.36

Aug 14 14:23:50 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 14:23:50 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 14:23:49 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2

...any connections accepted here were sent to eth2... and eth2 is WAN2 (more consitency issues - can't be difficult on a router where hte security zone is identaicl to an interface...!)

Aug 14 14:23:07 2010	System Log	NSD FAIL WAN[2]
Aug 14 14:22:58 2010	Connection Accepted	...
Aug 14 14:22:54 2010	Connection Accepted	...
Aug 14 14:22:28 2010	Connection Accepted	...
Aug 14 14:22:21 2010	Connection Accepted	...
Aug 14 14:22:14 2010	System Log	WAN connection is up : 81.221.22.36/255.255.255.248 gw 81.221.22.33 on eth2

Kurt Schumacher · ‎08-14-2010

New test: WAN2 (eth2) not reachable (disconnected in the upstream), WAN1 (eth1) DHCP - warm boot.

System up at Aug 14 22:58:57 2010

(DHCP Server offered 10.10.1.227 to rv016-3v Aug 14 22:59:08)

(DHCP Server assigned 10.10.1.227 to rv016-3v Aug 14 22:59:08)

(The DHCP Server time stamp makes sense, a few seconds before the WAN2 goes up with the static config, assume the interfasces are configured in sequence WAN1...WAN7)

WAN2 (eth2) up at Aug 14 22:59:12 2010

NSD FAIL WAN[2] at Aug 14 22:59:55 2010 - 45 seconds after WAN2 up (configured for four retries, timeout 15 second). Takes six or seven minutes, until the routing is established!

WAN1 (eth1) up at Aug 14 23:02:36 2010 (DHCP client delay 2:30 min?)

First ICMP packet sent to eth1 at Aug 14 23:06:05 2010 (3:30 minutes after interface up? No notification of NSD UP for WAN1, no logging likely)

All-in-all seven minutes?!?

Re-routing works - but much later as expected. How intentional is this?

Aug 14 23:07:22 2010	Connection Accepted	UDP 192.168.1.100:137->72.14.233.114:137 on eth1
Aug 14 23:07:22 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:22 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:20 2010	Kernel	last message repeated 4 times
Aug 14 23:07:19 2010	System Log	recvfrom: Network is down
Aug 14 23:07:17 2010	Connection Accepted	UDP 192.168.1.100:137->209.85.250.140:137 on eth1
Aug 14 23:07:16 2010	Connection Accepted	TCP 192.168.1.100:51496->72.163.4.70:443 on eth1
Aug 14 23:07:16 2010	Connection Accepted	TCP 72.163.4.70:443->192.168.1.100:51492 on eth0
Aug 14 23:07:16 2010	Connection Accepted	TCP 192.168.1.100:51489->72.163.4.70:443 on eth1
Aug 14 23:07:15 2010	Connection Accepted	TCP 192.168.1.100:51489->72.163.4.70:443 on eth1
Aug 14 23:07:15 2010	Connection Accepted	TCP 192.168.1.100:51488->84.53.164.170:443 on eth1
Aug 14 23:07:15 2010	Connection Accepted	TCP 192.168.1.100:51487->72.163.4.70:443 on eth1
Aug 14 23:07:15 2010	Connection Accepted	TCP 192.168.1.100:51487->72.163.4.70:443 on eth1
Aug 14 23:07:15 2010	Connection Accepted	TCP 192.168.1.100:51486->198.133.219.10:443 on eth1
Aug 14 23:07:14 2010	Connection Accepted	TCP 192.168.1.100:51486->198.133.219.10:443 on eth1
Aug 14 23:07:14 2010	Connection Accepted	TCP 192.168.1.100:51486->198.133.219.10:443 on eth1
Aug 14 23:07:13 2010	Connection Accepted	TCP 192.168.1.100:51485->209.46.39.130:443 on eth1
Aug 14 23:07:11 2010	Connection Accepted	UDP 192.168.1.100:137->64.233.174.34:137 on eth1
Aug 14 23:07:11 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:11 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:11 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:10 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:10 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:10 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:09 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:09 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:09 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:08 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:08 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:08 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:02 2010	Connection Accepted	UDP 192.168.1.100:137->172.31.208.69:137 on eth1
Aug 14 23:07:02 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:02 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:02 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:01 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:01 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:01 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:00 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:00 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:07:00 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:06:59 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:06:59 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:06:59 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->74.125.77.147 on eth1
Aug 14 23:06:37 2010	Connection Accepted	TCP 192.168.1.100:51165->10.10.1.170:1138 on eth1
Aug 14 23:06:20 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:20 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:20 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:19 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:19 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:19 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:18 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:17 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:17 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:16 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:16 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:16 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:15 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:15 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:10 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:06 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:06 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:06:05 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth1
Aug 14 23:05:40 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:05:07 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:04:43 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:04:10 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:04:09 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:04:09 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:04:09 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:03:38 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:03:09 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:02:40 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:02:36 2010	System Log	WAN connection is up : 10.10.1.227/255.255.255.0 gw 10.10.1.254 on eth1
Aug 14 23:02:07 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:01:39 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:01:10 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:01:06 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:01:05 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:01:05 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:00:49 2010	System Log	HTTP Basic authentication success for user: admin
Aug 14 23:00:39 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:00:38 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:00:38 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:00:38 2010	Connection Accepted	ICMP type 8 code 0 192.168.1.100->207.69.188.186 on eth2
Aug 14 23:00:37 2010	Connection Accepted	TCP 192.168.1.100:51165->10.10.1.170:1138 on eth1
Aug 14 22:59:55 2010	System Log	NSD FAIL WAN[2]
Aug 14 22:59:42 2010	Connection Accepted	TCP 192.168.1.100:51165->10.10.1.170:1138 on eth1
Aug 14 22:59:24 2010	Connection Accepted	TCP 192.168.1.100:51166->10.10.1.170:8912 on eth1
Aug 14 22:59:24 2010	Connection Accepted	TCP 192.168.1.100:51166->10.10.1.170:8912 on eth1
Aug 14 22:59:23 2010	Connection Accepted	TCP 192.168.1.100:51166->10.10.1.170:8912 on eth1
Aug 14 22:59:23 2010	Connection Accepted	TCP 192.168.1.100:51165->10.10.1.170:1138 on eth1
Aug 14 22:59:23 2010	Connection Accepted	TCP 192.168.1.100:51165->10.10.1.170:1138 on eth1
Aug 14 22:59:12 2010	System Log	WAN connection is up : 81.221.22.36/255.255.255.248 gw 81.221.22.33 on eth2
Aug 14 22:59:04 2010	Kernel	upnpd[655]: Advertisements Sent. Listening for requests ...
Aug 14 22:59:03 2010	Kernel	upnpd[655]: IGD root device successfully registered.
Aug 14 22:59:02 2010	Kernel	upnpd[655]: Succesfully set the Web Server Root Directory.
Aug 14 22:59:02 2010	Kernel	upnpd[655]: UPnP SDK Successfully Initialized.
Aug 14 22:58:57 2010	System Log	rv016-v3 : System is up

osaleem · ‎08-16-2010

Hi Kurt,

Can you elaborate your setup in general so we replicate the issue.

Thank you,

Azhi

Kurt Schumacher · ‎08-16-2010

WAN1, and WAN2 as seen, WAN3...WAN7 disconnected. Fancy a config backup?

Brian Bergin · ‎08-29-2010

Azhi,

We're seeing the same thing. We have 2 WAN connections, WAN1 = 32 Mb/sec cable modem, WAN2 = 3 Mb/sec ADSL modem. WAN1 has been flaky for weeks. If I return to our v2 RV082 running 2.0.0.19-tm it's very capable of handling the instablity and removing the connection, the v3 device on 4.0.0.4 continues to allow traffic to queue on WAN1 even when WAN1 isn't passing traffic. I'm also happy to send a config backup.

ddiep · ‎08-30-2010

Brian,

As we tried to recreate the problem. please email me your config backup of router. Please elaborate as what's *flaky*? Link constantly goes up and down?

- You happen to have log capture when link is bouncing?

- Can you try to reverse the connection (ie. WAN2 = 32 Mb/sec cable modem, WAN1 = 3 Mb/sec ADSL modem.) Will you still see the problem on WAN2.

- Also capture screen shot of link status.

Thanks!

Kurt Schumacher · ‎08-30-2010

Don,

For both of us, the router is continue to send traffic to the interface which can not pass the data anymore. The detection in place is either not reliable, the routing is adjusted much to late - this is what we see as *flaky*.

-Kurt.

Brian Bergin · ‎09-14-2010

Don,

This continues to be a problem in 4.0.0.7. Any word on a fix? Our cable company is having to deal with the US Government on replacing some wire (it runs under some Government land so it's a royal pain to get anything done as I'm sure you can imagine) so we've been able to really hammer the RV082 v3 with an up and down WAN connection (the port never goes down, but the cable modem will simply stop passing traffic because of this bad cable). As it stands now there's no way the v3 units will be well received by anyone who has used a v2 unit in this situation.

IMHO, this has to be the #1 priority for Cisco at this point. If this doesn't get fixed you might as well discontinue the SKUs.

ddiep · ‎09-14-2010

Brian,

We understand the seriousness of this issue and are working on the fix. The next firmware will not only fixing this issue but also number of other issues that found internally and from this EFT forum. It is required thorough inspection of software update and more strenuous testing. Therefore it probably might take a while before we release the next firmware. Sorry for the inconvenient for the time being. Will keep you posted.

High regards,

Don

Brian Bergin · ‎09-14-2010

It's perfectly fine if it takes a while to release the fix. That it's fixed is all that matters. I just hadn't seen any comments in this tread and just wanted to get a update.