As promised, some details that got cut from "The Art Of
Debugging" webcast. I can talk for hours about this stuff, and
the original thought from Microsoft was to give me half an hour
... maybe 45 minutes. In the end, I managed to cut out enough to
give you an hour of hopefully very enlightening meat without all
the potatoes. There are entire careers built on networking. My
goal was to give anyone listening an idea of some of what is
capable and hopefully get you sniffing and learning about
networks at that low level.
Please let me know what you might have liked, disliked,
wanted more of, or wanted less of.
The Art of Debugging webcast-Click Here
That said, onto more of the meat that got cut!
Network hubs VS network switches
A network switch is intelligent -- it tries to send packets
out to only the ports that are listening for that kind of
packet. If a packet is meant for every system on the network,
called a "broadcast packet", then the switch sends the packet
out every port. If the packet is supposed to go to one system
only which is identified by its MAC address, AKA: A Unicast
Packet, the switch will do
one of two things:
If the switch knows what port that MAC address is connected to,
then it sends the packet out just that port.
If the switch does not know what port that system is
connected to, it sends that packet out every port.
When a packet comes into a port, the switch remembers what
MAC addresses it sees from each system coming into each port of
the switch. That way when a packet is supposed to go out to a
system, it can lookup that MAC address in a table that
(hopefully) tells the switch which port would be interested in
hearing about that packet. This is very similar to what a
"Network Bridge" does when it bridges two network segments
together. Modern switches have 48 or more logical bridges, one
for each port, all connected to a common backbone inside the
On the other hand, a hub is more like a piece of coaxial
cable that allowed Cat-5 wiring to replace coaxial networks. A hub
sends every packet out every port no matter what. A hub is dumb,
whereas a switch is smart.
In this way, a switch utilizes the available bandwidth more
efficiently than a hub does.
Unfortunately, hubs are becoming harder and harder to find,
which makes sniffing data a bit more challenging. Smarter
switches can configure a "SPAN" port, or a "Monitor" port, or
some other name. Briefly, that configuration tweak tells the
switch to replicate every packet going out port #<whatever> out
onto port #<whatever-B>. So if you are interested in the traffic
on port #5, you can connect your sniffer to port #8, tell the
switch to monitor port #5 onto port #8, and sniff away.
However, not all switches can configure any port to span any
other port. Plus, sometimes not every packet gets forwarded. So
that is why my choice is a hub -- plain old stupid network hub.
When I'm hubbed into a network connection, I know I'm seeing
every packet in or out of that port.
How to tell if you've got a switch or a hub
You can test your hub to be certain it is stupid as follows:
Plug two systems in ports #1 and #2, then ping between those two
systems. Plug your sniffer into port #3 and capture data. You
should see all the pings and replies between #1 and #2; if you
don't, you've really got a switch and not a hub. This is not an
uncommon occurrence! Hubs are getting harder to find as cheap
switch integrated circuits are deemed better than hubs, and who
would want a hub anyway when a switch is better for networks?
Links contained in the presentation you might want to
reference, and some other items of interest:
Task Force: http://ietf.org --
lookup the following RFCs for more information on some of the
RFC 1180 - A TCP/IP
RFC 2821 - Simple
Mail Transfer Protocol
RFC 2045 -
Multipurpose Internet Mail Extensions
RFC 0793 -
Transmission Control Protocol [TCP]
The Cable Guy – July
2004: Path Maximum Transmission Unit (PMTU) Black Hole Routers
networking books by Douglas Comer, read about them on Amazon or
A downloadable PDF of The
Art of Debuggin Presentation can be found by clicking here
I'm not sure how much
feedback I'll get from any of the Microsoft surveys regarding
the webcast, so if you viewed it (and I know I asked it earlier,
but unless you've done one of these you have no idea just how
many hours of effort it takes) please let me know. I'd like it to be as good
as it possibly can be, and for that I need your help!
So I'd love
to hear from you! Please tell me what you might like to see in a future webcast!