[c-nsp] Bridge devices - ARP takeover

[Graham Wooden]

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" <jfitz at Princeton.EDU> 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  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>