Is Layer-3 Switch More than a Router?

Very short answer: no.

You might think that layer-3 switches perform bridging and routing, while routers do only routing. That hasn’t been the case at least since Cisco introduced Integrated Routing and Bridging in IOS release 11.2 more than 15 years ago. However, Simon Gordon raised an interesting point in a tweet: “I thought IP L3 switching includes switching within subnet based on IP address, routing is between subnets only.”

Layer-3 switches and routers definitely have to perform some intra-subnet layer-3 functions, but they’re usually not performing any intra-subnet L3 forwarding.

Let’s start with the intra-subnet functions the layer-3 forwarding devices (whether you call them switches or routers) do:

  • Dynamic neighbor discovery through ARP/ND for packets sent to hosts in directly attached subnets (glean adjacencies in CEF terminology);
  • Generation of host routes based on ARP/ND results (cached adjacencies in CEF terminology);
  • Forwarding of IP packet to directly attached IP hosts based on ARP/ND-generated host routes.

However, if a layer-3 forwarding device performs MAC-based forwarding in combination with IP-based forwarding, it usually uses the destination MAC address to figure out which forwarding method to use:

  • Layer-2 frames sent to router’s own MAC address are passed up the protocol stack into the IP forwarding code (and if the IP packet is sent to router’s IP address, the packet is sent to the control plane for further processing);
  • Layer-2 frames sent to other destination MAC addresses are passed to MAC forwarding code, which performs MAC address table (or TCAM) lookup and forwards, floods or drops the packet.

I haven’t seen a device (yet) that would use IP protocol type (0x0800) in Ethernet header to decide whether to use MAC-based or IP-based forwarding. If you’ve seen one, please write a comment (overzealous DSL concentrators that violate layering by peeking inside PPPoE sessions don’t count).

Summary: There’s no difference in intra-subnet (intra-VLAN) forwarding between a router (layer-3 switch) and a simple bridge (layer-2 switch). However, an IP-aware device (even a more sophisticated layer-2 switch) might support IP-based port access lists or DSCP- or ACL-based QoS.

Layer-2 and Layer-3 interfaces

Some switches have physical layer-2 and layer-3 interfaces. Layer-2 interfaces behave as I described above, with the internal router being connected with one of its interfaces (example: VLAN or SVI interface) to the internal bridge:

A layer-3 switch routing between two VLAN/SVI/BVI interfaces

Physical layer-3 interfaces connect directly to the internal router. If a physical layer-3 interface receives an Ethernet frame sent to a third party MAC address, the frame is dropped.

A layer-3 switch with routed (layer-3) physical interface

Some switches (example: Catalyst 6500) use hidden VLANs to implement layer-3 interfaces. You might think that detail doesn’t matter ... until you run out of VLANs.

Finally, some devices have layer-3 subinterfaces. These interfaces modify the frame forwarding rules on per-VLAN basis: if the parent physical interface receives an Ethernet frame belonging to the subinterface VLAN, the router uses the IP forwarding path (and drops the Ethernet frame on destination MAC mismatch), whereas the destination MAC address selects the forwarding method (L2 or L3) used for frames belonging to other VLANs.

More information

The diagrams used in this post are part of the Data Center 3.0 for Networking Engineers webinar. If you’re interested in modern data center switching solutions, that webinar would be a great place to start, with Data Center Fabric Architectures and Clos Fabrics Explained webinars providing further details. All three webinars are part of the yearly subscription.

If you’d like to discuss various technology options or have a short review of your data center network design, check out the ExpertExpress service.


  1. Does bridging in software based platforms (7200/2600/etc) use interrupts? Is there a 'Bridging CEF' of sorts? I've always held the notion that IRB performance is on par with IP process switching performance, but I've never actually tested it.
    1. It was always my understanding that bridging was fast-switched and used MAC address table as forwarding cache. Use "show interface switching" to verify it is.
  2. I am finding that the terms 'router' and 'switch' are beginning to only designate the primary function the vendor intended them to do. Some features are taken for granted on a 'switch' that are not present or lacking in features on a router. For instance I have a customer who replaced a headend router and switch with an ASR9000. That router is definitely primarily designed for ip routing and mpls and is a bit awkward for the layer2/vlan type stuff. It does no properly do CDP on the sub interfaces and passes CDP traffic from other interfaces in the same bridge group. Also the spanning-tree implementation is not very clear cut or well documented. Am I doing layer2 bridging, yes. Is it a powerful platform, yes. Is it a pain to do some functions that would only take 2-3 commands on a 'normal switch', very much so.
  3. Good post.

    Brouter;) Remember that one?

    Fabswrout - fabric-switch-router;)
  4. I think the main difference between routers and switches comes down to what WAN Interface types it can support.

    Most (not all) switches cannot handle an OC3.
    1. Beyond interfaces (we run all Ethernet WAN connections, so it isn't a concern for me), I think the big thing is routing table size support.

      And routing protocol support on some cheaper L3 switches, or products like Brocade's latest ICX where the base L3 package includes only RIP and OSPF, and you need the advanced L3 package to get BGP.
  5. So, migrating interconnection VLANs to routed ports in order to free VLANs is useless in the 6500? Or do you mean "until you run out of VLAN IDs"?
    1. It is not useless, with routed ports you have a better and fast convergence (.ie carrier-delay to 0, BFD ...) than with a SVI.
  6. I always thought that LSR does recognise MPLS packets by protocol type inspection... don't they?
    So are they switches?
    1. Transit LSRs can only guess what's in the L3 datagrams after the MPLS envelope. Ingress and egress LSRs should know - egress one has assigned the label and ingress one is using it.

      The only time a transit LSR tries to figure out the payload type is when it's trying to send ICMP TTL exceeded.
    2. Completely agree, though my point was that how LSR knows that packet it received is MPLS IPV4 IPV6 etc...
    3. If a transit LSR needs to know the payload type, the only thing it can do is guess based on the first nibble in the payload (4 = ipv4, 6 =ipv6).
    4. LSR is not required to know the mpls payload .Normally ACLs are used to trap specific protocol pkts to CPU.
  7. Shouldn't a physical L3 Interface be independent of Layer2 media .So logically speaking the L2 interface should strip the L2 header (802.11,PPP,ethernet ) and send the IP payload to the L3 interface.
  8. There's another little quirk between a router and a switch in Cisco country. A router by definition has layer 3 interfaces. A switch has layer 2 ports that can be converted to layer 3, but this is done by the control plane (your reference to the hidden VLANs matches this).
    Now, if the control plane takes a hit and crashes due to a bug, a router crashes and goes offline or reboots. However, a switch can start flooding in some sort of 'hub-mode' if the data plane is still working. It means that any frame (data, CDP, BPDU) entering one ports exits all other ports, whether these ports where part of the same VLAN, a trunk, another VLAN access port, or a layer 3 port. It just floods.

    In other words: a layer 3 switch can become a layer 1 failure domain, regardless of the design of the higher layers. I have yet to see that happen to a router.
Add comment