[c-nsp] Bridge devices - ARP takeover

[Graham Wooden]

Hi Rodney,

When the last outage occurred, I did a quick assessment of the output of
those two commands and reviewed it with output while it was working - and
nothing stuck out wrong or incorrect.  I however, didn't do the sh mls cef.
In a haste effort to get this particular customer up, I moved them back over
to the older box and didn't save my vi buffers.
 
I will have to setup a test link, as I can't have this PtP go down again.
I was more/less looking for any input on any known difference between these
two setups.  

Thanks,

-graham

On 8/18/09 9:16 PM, "Rodney Dunn" <rodunn at cisco.com> wrote:

> 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
>>