[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