08-14-2010 05:54 AM
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 |
08-14-2010 02:36 PM
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 |
08-16-2010 02:26 PM
Hi Kurt,
Can you elaborate your setup in general so we replicate the issue.
Thank you,
Azhi
08-16-2010 02:51 PM
WAN1, and WAN2 as seen, WAN3...WAN7 disconnected. Fancy a config backup?
08-29-2010 03:09 AM
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.
08-30-2010 01:40 PM
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!
08-30-2010 04:12 PM
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.
09-14-2010 07:53 AM
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.
09-14-2010 09:17 AM
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
09-14-2010 10:34 AM
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.
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