Hello,

I recently posted a topic in 'Scripting' because my router was timing out after applying a new script I created, but appeared to only be happening when I was managing it with Winbox.

Here is a link to that topic: http://forum.mikrotik.com/viewtopic.php?f=9&t=94257

What I did in the end was cut my script into smaller pieces applying each piece slowly until it began to timeout.

I noticed that once I started configuring the bridge is when things went sideways on me.

Our bridge code is simple:
What this is used for is, our Cable Modem is connected to ether1 and has a /29 subnet. We give one IP(statically) from the /29 to the WAN-Bridge. Connecting another host or switch to ether3 we are able to access the unused IPs from the Modem's subnet. Makes perfect sense, right?

The issue is that we also use ether3 in another way. Ether3 can sometimes be connected to a 2nd Cell Modem in which case we have a script which runs that removes ether3 from the bridge, places DHCP-Client on the interface and does a few other setup tasks...

Where we noticed this failing was, we run the intial script which has the code above so ether3 is part of the bridge, the 2nd Cell modem is physically still connected however. We assumed that because the interface was part of the bridge, and we do not have DCHP-client running anywhere at this time, the Cell Modem would simply be ignored.

At this stage, if we try to login and manage the router with winbox the session will drop in about a minute or so. We also see our continuous ping to the device timing out when it is becoming unresponsive.

Disabling ether3 (still part of the bridge, no DHCP) seems to clear the issue, the session returns stable, and there is no ping loss.

Could whatever traffic there may be on ether3 (DHCP coming from the cell modem, whatever) be causing some grief on the WAN-Bridge? Collisions or something? Is there a way that I can have this cell modem attached while ether3 is part of the bridge and things won't go south on me?

Thanks for taking the time to read and reply.

It's possible that proxy arp on the cellular modem might be the culprit.

Consider this chain of events:
ARP entry ages out on cablemodem default GW
Mikrotik sends out ARP query for default GW on the bridge interface
Bridge forwards the request out both ether1 and ether3
Cell modem replies with its MAC address in proxy-arp for the IP of the cablemodem default GW
Mikrotik now has wrong MAC address for default GW.

You could try static-ARP for the cablemodem default GW IP and then run your script again.
If it doesn't go unstable after about double the time it usually takes to go haywire, you have found the culprit.