I say 30 minutes ... But I just had it occur on less than 5 minutes from having the far end router and radio rebooted. And apparently my attempt to hardcode the MAC addresses on both ends didn't fix it. I am going to start blaming the radios I think ...
On 8/13/09 2:55 PM, "Jeff Fitzwater" <[email protected]> wrote: > It's interesting to note that this occurs at about the default ARP > timeout of 1800 seconds (Is that what the router is configured > for?). That implies that when the arp times out and the router arps > for the other end, it get an ARP REPLY from the wireless device. Is > that what you are saying? This would seem to say that the wireless > device may have some local proxy arp enabled so it responds to arp > requests on the local net. > > > > Jeff Fitzwater > OIT Network Systems > Princeton University > On Aug 13, 2009, at 3:08 PM, Rodney Dunn wrote: > >> I can't follow the problem. >> >> The router should try to defend the mac address it owns but if >> another device simply takes over for it the only way to resolve that >> is fix that device. >> >> How exactly is it taking over? >> What is the topo (ascii diagram would work). >> >> Rodney >> >> >> >> Graham Wooden wrote: >>> Hi there, >>> I have a customer hanging off of my edge router (6509/ >>> Sup32/12.2.33SXI), doing a Point-to-Point wireless shot from the DC >>> to another site. >>> On myside, it's a L3 VLAN doing a /30 to a smaller Cisco router on >>> the other end. I am then statically routing some additional subnets >>> to the far end router. >>> After about 30 minutes of the link being powered up, the MAC >>> address of local Radio appears to take over the /30, and hence all >>> routing breaks. To fix this, seems to that if I hardcode the MAC >>> that belongs to the Cisco router on the far, all seems good and >>> traffic keeps on trucking. The other fix that was being done until >>> the hardcode went into affect, was power cycling the local radio. >>> My question is this: While the hardcoding seems to be the trick to >>> solve this, is there another command, maybe on the interface to >>> achieve this fix too? >>> I have yet to find out from the customer if there are any MAC/ARP >>> settings in his radios and that could be doing take over on purpose. >>> I am hoping that I can curb this type of behaviour without getting >>> him involved. >>> Thoughts to this? Thanks, >>> -graham >>> _______________________________________________ >>> cisco-nsp mailing list [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
