RE: Caching a sniffer

["Shawn Jackson" <sjackson () horizonusa com>]

>   I've enjoyed this exchange too, but I think it's coming to 
> the end of its usefulness.

I get that feeling too, all I can hope is that we didn't confuse anyone
else on the list.

>   Some of your mental conceptions of how switches and routers 
> work is at odds with both my experience and the CCNA/CCNP 
> materials I've been studying recently.  (My current CCNA 
> expires in May; I plan to pass my CCNP before it does.)
>   Presumably, this reflects that your experience to date has 
> been different from mine, and there's nothing either of us 
> can do to fix that.  It's like trying to reconcile particle 
> physics with wave physics.

You assume I have mental conceptions :-). My knowledge is based on
protocol
analysis I have done and research in the RFC and IEEE specs. Though I
might
get vender certs in the future, I try and stay as vendor neutral as
possible
with my core knowledge, that could be where are knowledge forks.

>   Probably as a result, your conception of how macoff 
> (macor?) works requires that it force a catastrophic 
> breakdown of the switch functionality at all levels, AND that 
> a switch so totally crashed fall back on operating like a hub.
>   Within the conception of a switch as documented by Cisco (and 
> every other source I've seen), it is sufficient for macoff/macor 
> to fill up a switch's MAC table, and for the switch to stop 
> learning source MAC addresses when the table fills, to achieve 
> its effects -- without any interruption of the other normal switch 
> processes.  This has the obvious advantage of standing some 
> sane chance of working on ANY switch, not just ones afflicted 
> with a particular semi-miraculous bug, and the less obvious 
> advantage of not attracting admin attention by crashing 
> network equipment.

It's MacOf, I always tend to put two f's when I'm not closely paying
attention to what I'm writing. MacOf is part of the dSniff package from
http://naughty.monkey.org/~dugsong/dsniff/. It's been my poor choice of
words/terminology that I'm sure is causing more of the problems
throughout the conversations, for that I apologize. When Cisco switches
are faced with a MAC flood they being to operate like a hub, i.e. they
don't do layer 2 forwarding anymore, instead send all traffic to all
ports. This keeps the network operational and I'm sure keeps the switch
online. The switch returns to normal when the bad MAC entries are 'aged'
out of the table. This was, more of less, what Cisco told me and the
networking/security staff at a bank I did work with a while back, it's
not a bug or anything like that, it's by design. Port-Security solves
that problem and that was Cisco's answer. We tested some other vendors
and had the same results, during that time period.

>   I don't see any way to reconcile our two different 
> conceptions of the networking universe.  Do you?  If not, 
> then maybe it's time to let it rest and talk about something else.

Maybe over drink, but your most likely right. I made my final statement
above and I hope it clarified my position, I tried to write is as clear
as possible, but I'm not very good at writing.

Shawn Jackson
Systems Administrator
Horizon USA
1190 Trademark Dr #107
Reno NV 89521

www.horizonusa.com
Email: sjackson () horizonusa com
Phone: (775) 858-2338
       (800) 325-1199 x338 

---------------------------------------------------------------------------
Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off
any course! All of our class sizes are guaranteed to be 10 students or less
to facilitate one-on-one interaction with one of our expert instructors.
Attend a course taught by an expert instructor with years of in-the-field
pen testing experience in our state of the art hacking lab. Master the skills
of an Ethical Hacker to better assess the security of your organization.
Visit us at:
http://www.infosecinstitute.com/courses/ethical_hacking_training.html
----------------------------------------------------------------------------