Question

Hit save a bit quick there. I just updated the firmware and this is still happening and we've spent a day debugging this and we're basically done dealing with this device. The config is eth0 and wifi bridged together and cell modem out. Eth0 is direct connected into a single Cisco ASA. Wifi and eth0 are bridged to br-lan. This RUT950 was going to be a failover network for the ASA primary network path being out of a different interface. What is happening is after 5 mins of traffic the RUT950 falls off the network. After much debugging we've narrowed down what we think is going on.

from root run ip monitor. This will show any network changes on the RUT950. What we'll see is we can ping the RUT from the ASA. We'll see a lladdr get created (arp table gets populated on the RUT). 30 seconds after this (no traffic is coming from the ASA) a message will pop up saying the lladdr is now stale. After 300 seconds you'll see a laddr delete message. At this point the ASA's MAC address as been removed from the route cache or something. Any attempt to ping the RUT will fail. Packet captures on the ASA show packets with the correct destination MAC going into the RUT. Packet capture on the eth0 interface or the br-lan bridge interfaces shows NOTHING.

Clear the arp table on the ASA to for the ASA to request arp address via broadcast again and like magic the RUT will now be pingable again for 300 seconds.

There are no VPNs or anything else on this device. Its just hide outbound access behind the cellmodem. I poked around linux trying to figure out what is going on. My theory is the RUT950 should be probing the MAC address of the ASA once it goes stale state to verify its still there but packet captures show this isn't happening. There is only a single arp request for the ASA's Mac, 5 seconds after the initial arp request from the ASA. After that the RUT950 will no longer request the MAC address of the ASA.

To be clear..

From asa I ping RUT.

ASA -> broadcast arp who has x.x.x.254

RUT -> ASA x.x.x.254 is a 11:22:33:44:55:66

ASA -> RUT - > echo request

RUT -> ASA -> echo reply

repeated 5 times

5 seconds pass

RUT - who has x.x.x.253 (ASA IP)

ASA x.x.x.253 is at 99:88:77:66:55:44:33

nothing happens for 300 seconds

ASA -> RUT echo request (verified destination MAC is correct and doesn't show up in eth0 or br-lan)

No reply from RUT

Clear arp on ASA. This will force ASA to send broadcast arp who has again.

process repeats.

Answer 1

Hello

Have you tried using RUT with another network device?

Please repeat all steps and send me the troubleshoot file via PM, you can find it in the tab: System->Administration->Troubleshoot

Best regards.

Comments

I did not try a different device. i'm done with the RUT950. This is way too basic of a configuration to have this catastrophic level of failure. This is going right into the garbage.

if you want to see the issue run the linux command "ip monitor" on the RUT950, start a packet capture and then watch the network. Ping the RUT so the arp broadcast goes out then don't do anything for 300 seconds and watch the packet capture to verify nothing goes out. in 300 seconds you should see a delete message on the ip monitor output. Once this happens the device you pinged from should no longer be able to ping the RUT. I tried to replicate this with a ASA connected to a ubuntu 16 box and didn't have this problem. Ubuntu doesn't show that delete command on the ip monitor output and is able to stay on the network.

Come to think of it I didn't put the IP on a bridge under ubuntu I put it on the physical interface so maybe its related to bridge. No idea see if you can figure it out.

---

I'm sorry to hear this.

Please tell me which firmware version are you using?

Pehaps you are using an old firmware version, you can update the firmware here and try again.

BR

---

I don't recall what it was running before but now its running RUT9XX_R_00.06.07.1_WEBUI.bin. I think it was 6.06 before. Its already disconnected so I can't get anything off it at this point.

---

Hi, today I finally tested my router in bridge mode with different computers and different operating systems. Unfortunately I was unable to reproduce the problem you described, the connection works successfully all day.

BR.