[c-nsp] Re-thinking (remembering) how a switch operates
Network.Security
Network.Security at target.com
Thu Apr 28 08:40:03 EDT 2005
I second that...funny things happen when you have 1) asymmetric routing
(HSRP in the mix); 2) IPMP is not set up right on big bad Unix server;
3) the system that has been fat-fingered is gig and 4) all other poor
servers 100mb on same vlan...flooding occurs. L3 ARP=L2 MAC timer = no
more issues on network gear, even if the fat-finger occurs. There is a
pseudo-Cisco Best Practice white paper on this.
Brad Swanson
Target Corp.
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David J. Hughes
Sent: Thursday, April 28, 2005 12:04 AM
To: Lincoln Dale
Cc: 'cisco-nsp'
Subject: Re: [c-nsp] Re-thinking (remembering) how a switch operates
> i'm wondering if its a bad cable such that you actually have a
> unidirectional link that can receive but not transmit...
Nahh, just a side effect of people running longer arp caches than cam
table timers. We reconfigure the mac timeout to match the arp timeout
to ensure this doesn't happen.
David
...
_______________________________________________
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/
More information about the cisco-nsp
mailing list