[c-nsp] Bridge devices - ARP takeover

[Rodney Dunn]

Graham Wooden wrote:
> Yeah, kinda messy - sorry about that.
> 
> It's taking over as when I do a "sh arp ip", instead of seeing the far end
> router's MAC for the other end of the /30, I see the radio's.
> 
> c6509/sup32 -> radio <------------------------> radio -> c2621
> 
> Between the c6509 and c2621 is a routable /30.
> 

ok.

If the radio responds to an arp on refresh you can't stop that on the 
hub side unless you statically map it. The router has no way to know who 
is valid and who isn't.


> I should note that I didn't have this problem when had this setup on a Sup2,
> and ran fine for several months.  Is there a different ARP timeout between
> the two?

Shouldn't be. The timeout is 4 hrs by default.

Have you determined it's 60 seconds prior to the 4 hr default timeout?

You could test it by doing a manual "clear arp" as it does the same 
thing and sends out a unicast refresh.

Can you try sh ip arp, clear arp (with debug arp enabled") and get 'sh 
ip arp' again?


> 
> On 8/13/09 2:08 PM, "Rodney Dunn" <rodunn at cisco.com> 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/
>