This topic has been going on for a while and there are some important points that need to be made regarding "switch jamming" and "port mirroring". Port Mirroring -------------- This is a feature-set provided by a switch vendor to allow the ability to mirror the TX, RX or TX/RX port buffers of any port on the switch to a designated port. Cisco calls this feature SPAN, Port Monitor, and VACL's capture. The feature differs depending on your switch type and hardware capabilities. The main idea here is that an network analyzer needs to get in the middle of full-duplex traffic and the idea of physically tapping each station cable is unattractive. Declarations when provisioning this type of feature on all vendors has the administrator describing the SOURCE as ALL TRAFFIC YOU WOULD LIKE TO SEE and the DEST as WHERE TO SEND THIS STUFF. The SOURCE and DEST parameters have many constraints depending on make and model. It is common that you would have criteria for SOURCE that describes VLANs or Ports in a contiguous or discontiguous manner. It is common that you would have criteria for the DEST that is a port and you can choose to get just the TX, RX or both of your SOURCE. Your millage will vary even within a single vendor. "Switch Jamming" ----------------- This has nothing to do with a feature, it is all about resource exhaustion. It also mutually exclusive to any type of arp-poisoning since it is about CAM table exhaustion which is strictly a L1/L2 problem. arp-poisoning is a L2/L3 issue. This "hub-mode" that was talked about in the starting of this thread is something that needs to be clarified. A switch is nothing more than a Ethernet Bridge. The "switching" takes place because of learned knowledge called a CAM table. The CAM table contains 48bit MAC addrs that are associated with physical ports. It is a physical_port<->MACaddr mapping (L1/L2) (there are feature sets that vendors provide to do fancy things with the CAM table but I'll address them later) This CAM (content addressable memory) table is only so many entries deep. This is where the exhaustion occurs. The rule on how the CAM table is populated dynamically goes something like this: 1) If you get a Frame and you don't know the DEST, send it out all ports and record (to the CAM table) the SRC. The CAM now has an entry of MAC that lives downstream from that port. 2) If you get a Frame and you do know the DEST MAC, send it out that port. CAM table match. There are other rules but we dont need them to understand the exhaustion condition. If the CAM table is 20000 entries deep, and you have the proper kernel mods and libs, you can put together a simple util that would send 20000 uniquely addressed frames thus filling up the table. At this point, the behavior is un-deterministic on make, model and os-rev. The only thing you can be sure of is that deterministic behavior of the switch is lost. un-deterministic profiles range from going in to a "hub-mode" where because there is no room for another CAM entry, send out all ports to rebooting and even ports losing link status causing Spanning Tree to recalc. Hope this helps. -blast problem.
This archive was generated by hypermail 2b30 : Thu Jan 31 2002 - 10:05:21 PST