Back to Basics — CAM Table Population

At the office, we reprovision servers like it’s going out of style.  It happens so often that my cabling documentation rarely matches what’s actually out in field, which is a pretty big problem when you’re trying to find to what switch port a server is connected.  I finally relegated myself to asking for the MAC address of the server, having the admin ping something, and then tracing it down through the CAM table entries of the switches.  It works, but the guys really don’t know how a switch populates its CAM table, so they always say “Why can’t you just look on the switch?  I shouldn’t have to ping anything.”  Here’s one just for the aspiring system admin.

The Content Addressable Memory (CAM) table on a switch keeps track of MAC addresses and on what port they appear, along with some other stuff like age.  When a device that’s plugged into a particular port sends a frame to the switch, the switch makes note of the source MAC and the port and checks the CAM table.  If it’s a new MAC, it adds an entry in the CAM table; if it’s an existing on a different port, it removes the old entry and adds a new one; if it’s an old MAC on the same port, it updates the age.  By default, Cisco switches keep CAM entries for 300 seconds, so they don’t stay there forever.

What about the destination MAC?  Good question.  That’s a pretty important field when sending a packet, but, when generating a CAM entry, the destination MAC is ignored.  If  a host talks, a switch knows exactly from where the frame came, but there’s no way to know exactly where it should go without the destination first speaking up.

Let’s set up an example.  You have a Cisco 2950 switch that you’ve just powered on with nothing plugged into it except the console cable. If you do a show mac-address-table, you’ll see the CAM table — a table of MAC addresses that the switch knows; you would think that it would be empty since nothing’s plugge din, but the switch has its own MACs, so it always knows those guys.  There’s not much to see here yet, though, since we haven’t hooked anything up to the switch yet.

Next, let’s plug a Linux desktop up to it.  Once that box has booted, what should you see in the CAM table?  If you guessed the MAC of the Linux box, you may be right; it all depends on if the server sent a frame or not.  There’s lots of things that run on a Linux box that could send frames on startup — DHCP requests, multicast services, network-based storage — so, more than likely, a frame did get sent.  The only way to know it to take a gander.

Ah…it worked. That’s good, but it’s boring with only a single device. Let’s plug in a simply-configured and fully-booted Cisco router and see what happens. More than likely the router won’t speak until spoken to, so the CAM table won’t update, and the switch won’t know where to send the frame, right? Yes, but the frame still gets sent. If the switch doesn’t know where the destination MAC lives (i.e., it’s not in the CAM table), then it floods the frame out every port except the one on which it was received.

When I first learned that this is how it worked, I immediately wondered why LANs weren’t flooded out constantly. I didn’t think long enough to realize that the host being sent the packet will actually respond within several milliseconds (hopefully), so the CAM table will then have an entry for that guy. In reality, it’s even simpler than that. Since most of the world runs TCP/IP, we have this wonderful thing called ARP. When a host needs to talk to another host on the same network segment (IP subnet), it checks its ARP table, and, if it doesn’t know a MAC for that IP, it will actually ask what MAC it should use via a broadcast message. In a well-behaved network, the mystery host will answer with a “Here I am!” type message, which causes the switch to generate a CAM entry. In a “perfect world”, you should only have a few floods on a switch per day/week/month/year/decade.

Here’s a couple items of note.

  • A trunk interface will have a whole bunch of MACs listed as attached to that port.  This is quite normal, so don’t freak out.
  • If someone plugs a switch or hub into one of your ports, you will see multiple CAM entries for the same port.  This is a good way to see who brought in their Linksys hub from home.
  • If a host hasn’t sent a frame in more than 5 minutes, it disappears from the CAM table, so the whole discovery process starts over again.
  • There’s a limit to the size of a CAM table, so it’s possible to fill it up and then every new destination gets flooded.  Wow, I can see your packets.

Have fun.  Be safe.  Practice safe computing.  Lock down your network.

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages.

More Posts

Follow Me:
Twitter

9 comments for “Back to Basics — CAM Table Population

  1. Jajay
    July 28, 2011 at 11:56 pm

    Probably a dumb question from a sales guy but suppose I have 2 routers, R1 and R2 running HSRP plugged into my switch on port 1 and port 2 respectively.
    During normal operation the CAM table will have the HSRP floating MAC address on port 1.
    If R1 fails R2 takes over and the CAM table needs to be updated to allocate the floating MAC address to port 2.
    Generally the router will only speak when spoken so will the switch continue to send packets via port 1 because that is where the CAM table is still showing the MAC address lives.
    Or does HSRP protocaol include R2 sending out a packet(s) imediadialy it becomes the active router so the switch will update the CAM table.
    Or is there a 5 minute outage while the switch continues to send packets to the dead router via port one until CAM entry times out.

    Cheers

  2. July 30, 2011 at 10:14 pm

    Hey, Jajay. When a router becomes the active HSRP router, it sends out a gratuitous ARP so everyone knows there has been a change. This means that the switch will see the HSRP MAC on a new port and update its CAM table appropriately.

  3. sagubar sathik H
    November 14, 2011 at 6:59 am

    it is very useful for me…
    i know how the CAM table is populated.
    can you post me “concepts of VLAN and VTP” to me? to my mail id that i provided.. if you were posted it is very helpful for me..

  4. doubtscom
    March 7, 2012 at 2:10 am

    I have a query, How CAM table overflow causes flood and how one could see all packets?

  5. March 16, 2012 at 8:01 pm

    If the CAM table is full, the switch then starts treating all frames from unknown sources just as it would any other unknown source; it floods it out all ports. That means that, essentially, the switch becomes a hub, and everyone connected to it can see all frames.

  6. Matt K.
    March 21, 2013 at 4:16 pm

    I’ve been googling around for a good explanation but your’n was the first I actually learned something from. Thanks!

  7. khan sarfaraz
    August 20, 2013 at 8:53 am

    Very Good Explanation… cheers
    Please share in same manner for CEF switching…

  8. Stacy S
    February 8, 2015 at 5:49 pm

    I know this is a old post but I was doing a practice test and the question was basically “how would an attacker see all packets on his switch from all VLANs?” The answer was MAC address flooding.

    I got it wrong because my thinking is that a switch does not forward packets out all ports when the CAM table fills up. It only forwards packets from the source VLAN port out all ports in the same VLAN. Am I wrong? If the CAM table fills up, will packets coming from ports in VLAN 2,3 & 4 be forwarded out ports in VLAN 5,6 & 7?

  9. April 22, 2015 at 8:09 pm

    Stacy S : Yes, this an old post. Yes, I took 2.5 months to respond, too. LOL

    As far as I know, the frame will only be flooded out of ports in the source port’s VLAN. A quick Google around showed several articles that said the same thing with no mention of inter-VLAN flooding. If all ports got a frame when the CAM table was full, that would an extremely catastrophic security problem, eh?

Leave a Reply

Your email address will not be published. Required fields are marked *