Infrastructure Adventures


Network Virtualization: Beyond VLANs – Part 3: Switch Virtual Interfaces (SVIs)

Filed under: Network, Virtualization — Tags: , , — Joe Keegan @ 9:59 PM

In the last part of this series on network virtualization I covered connecting layer 3 devices, such as routers, to multiple VLANs using subinterfaces. Subinterfaces allow a router to provide inter-VLAN routing with only a single interface. But what if we wanted to ditch the router completely? What about just having the switch do the inter-VLAN routing?

This can be accomplished by configuring the switch with a Switch Virtual Interfaces (SVI) on each of the VLANs. Conceptually you can think of it as running a virtual router inside the switch. This virtual router is automatically configured with a trunk connecting it to all VLANs and the SVIs function as its subinterfaces.

Using SVIs are pretty common nowadays and are usually used by L3 switches at the L2/L3 bounders of networks. Configuring an SVI is pretty simple:

Interface vlan 10
 Ip address
Interface vlan 20
 Ip address

I often see confusion when configuring only a VLAN on a switch vs. configuring both a VLAN and a SVI. I think this often stems from the nebulous boundary between Layer 2 and Layer 3 on a switch. Remember that a VLAN is purely in Layer 2, hosts on one VLAN (L2) cannot talk to host on other VLAN without a router (L3). So if you want the switch to act as the router for a VLAN then you configure an SVI for that VLAN. If you just want the switch to act like a traditional switch for that VLAN then you do not configure an SVI for that VLAN.

Whether the switch acts as a router for a VLAN is made on a VLAN by VLAN basis. A switch can have a SVI on some VLANs, acting as the router for those VLANs, and the same switch can have VLANs which it doesn’t have an SVI, where the switch does not act as a router for those VLAN. Usually a firewall or other non-router L3 devices are used to route packets to or from the VLANs without an SVI.

A situation where it’s common to see switches with SVIs on some VLANs but not others are in a DMZ switch deployment. Consider the following diagram.

In this design we have two switches; switch 1 has VLANs 10, 100 and 200 with a SVI on each and switch 2 with VLANs 100, 110, 120, 200 and 210 with SVIs on VLAN 100, 110 and 120 (switch 2 does not have a SVI on any of the VLANs in the 200 range). A firewall is connected to switch 2 with one interface in VLAN 200 and the other in VLAN 210.

In this design if host 110 wanted to talk to host 120, 110 would send a packet to the SVI on that VLAN and switch 2 would route the packet directly to VLAN 120. This is because switch 2 has SVIs on each of those VLANs and would have directly connected routes for these VLANs.

But what if host 110 wanted to talk to host 210? Again 110 would send a packet to switch 2’s SVI on VLAN 110, but switch 2 could not route the packet directly to VLAN 210. This is because even though VLAN 210 is configured on switch 2, it does not have an SVI for that VLAN. Switch 2 has an L2 connection to that VLAN, but not an L3 connection.

Instead switch 2 would have to route the packet on VLAN 100 via the trunk to switch 1. Switch 1 would then route the packet to VLAN 200 and send the packet to the firewall. The packet would be sent back over the trunk to switch 2, but switch 2 only acts as a normal run of the mill switch for that VLAN, so it only switches (L2) the packet (really the frame) to the port in VLAN 200 connected to the firewall.

The firewall received the packet, and then routes that packet out its interface connected to VLAN 210 on switch 2. Again switch 2 only just switches the packet on VLAN 210 to host 210.

So in this design the packet between host 110 and 210 pass through switch 2 several times, but in some cases switch 2 routes the packets and in other cases switch 2 only switches the packet.

I chose this design to make an example and it’s not the most efficient design. Can you think of any changes to the design to improve the efficiency while keeping host 210 firewalled from the rest of the network?

This is part of a series on network virtualization, see Beyond VLANs, for links to all parts of this series.


Network Virtualization: Beyond VLANs – Part 2: Subinterfaces

Filed under: Network, Virtualization — Tags: , , , — Joe Keegan @ 6:58 PM

As mentioned in part one, hosts in different VLANs cannot talk directly with each other since they are in different broadcast domains/subnets. For hosts on different VLANs to communicate with each other a layer 3 routing device is needed, usually a L3 Switch with an Switch Virtual Interface (SVI), a Router or a Firewall.

The simplest way to route packets between two VLANs is by simply connecting a router with two physical interfaces to the switch. Each interface is connected to an access port on one of the VLANs.

With this method of Inter-VLAN routing you would need a router with a physical interface, cable, and switch port for each of the VLANs you need to connect. In some deployments this could be dozens, YUCK!

Luckily we can use a trunk to allow the router to connect to multiple VLANs using a single port, similar to how two switches can be connected using a trunk.


Since a router is a L3 device it is not configured with VLANs the same way as a switch. Although this can get fuzzy when you are talking about big advance routers or a router with a switch module, but let’s just focus on a regular branch router.

Instead the router’s interface connected to the trunk will need to be configured with a subinterface, one for each VLAN that it is connecting.

So in the following example the router’s interface connected to the switch would be configured with two subinterfaces, one for VLAN Red and one for VLAN Blue. Packets from VLAN Red would be sent up the trunk as tagged frames to the router. The router would see that the frame belongs to VLAN Red via the 802.1q header and would receive the packet on VLAN Red’s subinterface. The router would then route the packet and send it out VLAN Blue’s subinterface, tag the frame and send it back down the cable to the switch.

In this deployment, referred to as a router on a stick (but can be firewall, load balancer, etc on a stick), the packets to or from the router use the same cable regardless of what VLAN the packets are going to or coming from.

The main consideration for this type of design is capacity planning on the single cable. Since each packet transverses the cable twice, it effectively cuts the available bandwidth in half. This can be a serious consideration in larger deployments.

To get around this issue you can use multiple physical interfaces each with a few subinterfaces, such as one interface having subinterfaces for VLANs Red and Blue and a second interfaces having subinterfaces for VLANs Green and Orange.

You could also just look at creating a Link Aggregation Group (LAG) of interfaces to add additional bandwidth to the “stick”, so instead of have VLANs Red & Blue on one interface and Green and Orange on another you can have all four VLANs on a single LAG of two or more interfaces.

Configuring a subinterface on a Cisco router is pretty easy. Say for example that VLAN Red was VLAN number 10 and VLAN Blue was VLAN number 20 then the config would look something like this.

 Description Subinterface for VLAN Red
 ip address
 encapsulation dot1q 10

 Description Subinterface for VLAN Blue
 ip address
 encapsulation dot1q 20

Next we will cover Switch Virtual Interfaces which is sort of like virtualizing the router and bringing the Inter-VLAN routing functionality into the switch.

This is part of a series on network virtualization, see Beyond VLANs, for links to all parts of this series.

The Silver is the New Black Theme. Create a free website or blog at


Get every new post delivered to your Inbox.

Join 38 other followers

%d bloggers like this: