(Embedded image (Embedded image moved to file: pic16972.pcx)
moved to file: ALAERTE GLADSTON VIDALI ALAERTE
pic06654.pcx) (Embedded image moved to file: pic14369.pcx)
25/02/2003 12:10:42
(Embedded image moved to file: pic22532.pcx)
Para: "Priscilla Oppenheimer"
cc:
Assunto: RE: Flooding Problem [7:63622] (Document link: ALAERTE
GLADSTON VIDALI ALAERTE)
Thanks for the reply and sorry to answer a little late.
>What is the timer for the CAM table?
Five minutes. I had some window on the weekend, so I could change it to 10
minutes. It helped.
>Did you find this one already?
>
http://www.cisco.com/en/US/tech/tk648/tk365/technologies_tech_note09186a0080094
>afd.shtml#t8
No. I will check, thanks
>I guess that's why you mentioned that you are looking at the MAC
addresses to see if they are valid
Yes, I am concerning if it is a attack. It will take us a time because
there are more than 2500 stations.
>Port security could solve this problem,
>though it's a hassle. But you could make sure that only the legitimate MAC
>address is allowed into each port (or at least suspect ports).
There is a good feature to block flooding to specif ports, but it is
available only on CATOS 7.5.
>By the way, how do you know flooding is happening?
With Sniffer. I would like to send the pictures, but it may cause some
problem on the receivers email servers. It shows there are 'conversations'
between stations sent to a interface, 6/4, where there is just a server.
"Priscilla Oppenheimer" @groupstudy.com em
24/02/2003 15:51:06
Favor responder a "Priscilla Oppenheimer"
Enviado Por: [EMAIL PROTECTED]
Para: [EMAIL PROTECTED]
cc:
Assunto: RE: Flooding Problem [7:63622]
What is the timer for the CAM table? Is it still set to 5 minutes, the
default? If so and you really do have asymmetric routing, then unicast
packets might indeed get flooded. With asymmetric routing a switch can lose
track of which port to use for a MAC address. This happens when replies
come
back in via a router interface but requests have the ability to go out a
switch interface.
One fix is to simply make the CAM table age less often.
Some of the white papers that discuss this situation on Cisco's Web site
are
incomprehensible, but some of them are good. Did you find this one already?
http://www.cisco.com/en/US/tech/tk648/tk365/technologies_tech_note09186a0080094afd.shtml#t8
My first reaction to your e-mail wasn't to worry about asymmetric routing,
though. My first reaction was that you might be under attack. How good is
your security? How about protection from Trojan horses. An nice little hack
would be a Trojan horse that sends huge amounts of traffic with different
MAC addresses, causing the CAM table to fill up, which will result in some
flooding. I guess that's why you mentioned that you are looking at the MAC
addresses to see if they are valid. Port security could solve this problem,
though it's a hassle. But you could make sure that only the legitimate MAC
address is allowed into each port (or at least suspect ports).
By the way, how do you know flooding is happening? The information below
doesn't tell us anything other than that the number of entries in the CAM
table is changing which is normal, especially with a default 5-minute timer
for how long an entry remains in the table.
_______________________________
Priscilla Oppenheimer
www.troubleshootingnetworks.com
www.priscilla.com
[EMAIL PROTECTED] wrote:
>
> Every 1 minute and 30 seconds the switches (6509 and 5500) are
> flooding
> traffic.
>
> The CAM agingtime content is changing more than the expected.
>
> The Spanning Tree are stable. There is minimum TCNs on the
> network.
>
> We are looking at some of the MAC addresses to see if they are
> valid
> stations.
>
> Other point that we are working on is asymetric routing.
>
> Any thoughts on that?
>
> SWITCH> (enable) sh time
> Mon Feb 24 2003, 09:31:01 GMT-3
> SWITCH> (enable) sh time
> Mon Feb 24 2003, 09:31:16 GMT-3
> SWITCH> (enable) sh cam count dy
> Total Matching CAM Entries = 2855
> SWITCH> (enable) sh cam count dy
> Total Matching CAM Entries = 2879
> SWITCH> (enable) sh cam count dy
> Total Matching CAM Entries = 3617
> SWITCH> (enable) sh cam count dy
> Total Matching CAM Entries = 3637
> SWITCH> (enable)
> SWITCH> (enable) sh time
> Mon Feb 24 2003, 09:33:37 GMT-3
> SWITCH> (enable) sh time
> Mon Feb 24 2003, 09:33:41 GMT-3
> SWITCH> (enable) sh cam count dy
> Total Matching CAM Entries = 3670
> SWITCH> (enable) sh cam count dy
> Total Matching CAM Entries = 3674
> SWITCH> (enable) sh cam count dy
> Total Matching CAM Entries = 3679
> SWITCH> (enable) sh cam count dy
> Total Matching CAM Entries = 3683
> SWITCH> (enable) sh cam count dy
> Total Matching CAM Entries = 3686
> SWITCH> (enable) sh cam count dy
> Total Matching CAM Entries = 3694
> SWITCH> (enable) sh cam count dy
> Total Matching CAM Entries = 1286
> SWITCH> (enable) sh time
> Mon Feb 24 2003, 09:34:47 GMT-3
> SWITCH> (enable) sh time
> Mon Feb 24 2003, 09:34:48 GMT-3
> SWITCH> (enable)
[GroupStudy removed an attachment of type application/octet-stream which had
a name of pic06654.pcx]
[GroupStudy removed an attachment of type application/octet-stream which had
a name of pic16972.pcx]
[GroupStudy removed an attachment of type application/octet-stream which had
a name of pic14369.pcx]
[GroupStudy removed an attachment of type application/octet-stream which had
a name of pic22532.pcx]
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=63740&t=63622
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
