Ping on bridge interface

One customer needed an internet connection at his fabric which is located far away
from ISP, so we decided to build a wireless link with four antennas to arrive from
ISP to customer base. ISP asked us to build a transparent link, so the setup is as followos:

1.RB411, wireless interface is R52H configured as bridge with dynamic WDS on bridge1.
bridge1 is configured with proxy-arp and stp enabled. Ports on bridge1 are ether1 and the
dynamic WDS interface. IP address: xxx.xxx.xx.120/24 bridge1

2.RB433, wlan1 interface is R52 configured as wds station with dynamic WDS on bridge1.
wlan2 interface is R52H configured as AP bridge with dynamic WDS on bridge1.
bridge1 is configured with proxy-arp and stp enabled. Ports on bridge1 are wlan1 and the
dynamic WDS interface. IP address:xxx.xxx.xx.121/24 bridge1

3.RB411, wireless interface is configured as WDS station with dynamic WDS on bridge1.
bridge1 is configured with proxy-arp and stp enabled. Ports on bridge1 are ether1 and wlan1
IP address: xxx.xxx.xx.122/24 bridge1

Gateway and DNS are the same. On the extremities of the link are connected the ISP switches
and routers.

Now, I am experiencing a strange ping behaviour on this link. I constantly loose nearly 20% of ping
on the first radio, say I have 50 replies and then 10 timeouts. The more strange is that while
I am having a time out on radio 1, the one with IP .120, I can succesfully ping the second, the one
with IP .121.
This happens on all the three routerboards. One thing to notice is that, even if I loose the ping
the connection is not lost. I have tested this uploading on the last routerboard via FTP the new
packages, nearly 18.5MB with no interruption.

Is this related to the bridge configuration? Can any one help on this?

Thank you, Toni

I have seen a similar problem on my bridged network. I link multiple nodes via static WDS. The bridges are all using rstp, ROS 3.11 and 3.13.

From a client at the extremity of the network, I ping the local node, the one to which my client is directly connected. I see very long round trip times and some timeouts. However, actual traffic from this same client thru the bridged network to the gateway works just fine.

After many experiments to eliminate other problems, I ran packet sniffer and to my surprise, my ping packets were being sent past the local bridge, which was assigned the IP address I was pinging, and continued all the way to the root bridge at the gateway node, and then sent back to my local node and then to my client.

This would appear to be a case of the bridge mac address table or arp table being messed up. However, I checked the mac address table on each bridge using bridge → hosts and it all looks correct. I check the arp table on both my local node and gateway node and the IP address correctly is associated with the administered mac address of the local bridge.

All of the MT nodes can ping each other with minimal delay. The problem only occurred when a client tried to ping its local MT node.

This particular mesh network had 5 nodes. The problem only showed up on one of the MT nodes. Using the same laptop computer, I could visit another node and ping it with no delay. At these other nodes, packet sniffer showed that the ping packets never left the local node, which is the correct behavior.

After many reboots of both the problem node and gateway node, the problem went away and never returned.

I encountered this same problem at another network several months ago, and it also went away after several reboots. At that time, I did not try the packet sniffer so I can’t say for sure the problem was the same.

I have tried to recreate this problem in my lab with no success. I don’t know what caused it.

If you are having odd ping problems, I suggest a packet sniff to determine if your pings are taking a very long detour before being sent where they belong.