[c-nsp] Re-thinking (remembering) how a switch operates

Jeff Kell jeff-kell at utc.edu
Thu Apr 28 00:02:40 EDT 2005


Lincoln Dale wrote:
> At 12:21 PM 28/04/2005, Jeff Kell wrote:
> 
>> To make a long story short, I started checking mac-address-tables (and
>> cam on the lone CatOS Catalyst in the mix).  NOBODY has a mac entry!
> 
> out of interest:
>  - what OS is your syslog server running?

Redhat

>  - why wasn't your syslog server OS either (a) answering 'who-has' arp
> messages or (b) sending out a gratuitous arp every now & again?

(a) it was, but nobody was asking but the router SVI every couple hours,
and (b) it didn't need to talk to anybody.

>  - was the [broadcast] syslog traffic simply 'flooding' - or did it have
> a valid destination mac-address also?

No, a unicast MAC to the NIC of the syslog server.  But since the
switches didn't have the MAC in the L2 mac-address-table, it flooded the
packet out every interface [other than the receiving one].

> i'm wondering if its a bad cable such that you actually have a
> unidirectional link that can receive but not transmit...

No, it was fine.  After 'pinging' it (so that it had to transmit the
reply) the mysterious flooding would stop (for five minutes/300 seconds
until the mac-address-table entry timed out again).

You're making this too hard (like I initially did!).  It's just plain
unicast UDP syslog traffic on plain old switches.  Most of the syslog
senders were on different networks (router loopbacks and PIX, the latter
generating the most syslog traffic logging NATs from our dorms/wireless).

Very simple scenario generating lots of unexpected traffic, just because
switches are doing what they're supposed to, but with an essentially
"receive-only" server in the mix.  TCP wouldn't have this problem.

Jeff


More information about the cisco-nsp mailing list