[c-nsp] Bridge devices - ARP takeover

[Rodney Dunn]

You need to get more data when it's failing for anyone to help.

sh ip arp
sh adj detail
sh mls cef <ip>

as starters.



Graham Wooden wrote:
> Update: I could not keep the link up on the Sup32. Even hardcoding the MAC
> addresses, traffic would flat stop at random times.  However, it's been up
> for 4 days now on a Sup2. Specific interface/vlan config is exactly the
> same. Only differences are the Sups, IOS, and linecard.
> 
> So, does anyone know what could be the issue? I really don't want them to be
> hanging off of this aging hardware...
> 
> Works: 6509 - Sup2 - s222-adventerprisek9_wan-mz.122-18.SXF15a.bin -
> WS-X6248-RJ-45
> 
> Doesn't:  6509 - Sup32 - s3223-advipservicesk9_wan-mz.122-33.SXI1.bin -
> WS-X6348-RJ-45
> 
> On 8/14/09 7:00 AM, "Gert Doering" <gert at greenie.muc.de> wrote:
> 
>> Hi,
>>
>> On Fri, Aug 14, 2009 at 06:57:08AM -0500, Graham Wooden wrote:
>>> Agreed on the ip proxy-arp, but if it makes the link work for the time being
>>> ... 
>> This would be VERY surprising - "ip proxy-arp" makes a difference only
>> if one of the devices sends ARP requests for IP addresses that are
>> off-link (specifically: that the router with "ip proxy-arp" knows to be
>> off-link and has a route for it).
>>
>> Your routers on both sides shouldn't do any ARPing for off-link addresses
>> unless one of them has a static route pointing to the ethernet itself
>> ("ip route 0.0.0.0 0.0.0.0 ethernet0" is a quite typical example).
>>
>> dot1q-tagging the management interface sounds like a good plan, though :)
>>
>> gert
>