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" <[email protected]> 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
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
