When creating VLANs for just L2 on a switch -- routing will be handled by a device within that VLAN such as a load-balancer -- it isn't necessary to create the vlan interface. As a matter of habit, I always create the interface anyway-- no IP address - so I get all the interface bits and packet stats in "sh interface".

Are there any negatives to what I think is a best practice to just create the L2 interface?

When do you create or not create the interface for a L2 VLAN?

I am looking for answers that discuss only L2 VLANs, not the merits and use cases for L3 VLAN SVIs.

Cisco reports a L2 interface as EtherSVI on my 6500 -- no IP address. Is it correct or incorrect to still think of a L2 interface as an SVI though the we all know the usual use-case is to have an IP address for routing? The question is only about whether or not I should have this L2 interface in the first place. You can see only the L2 counters are incremented, but still giving some value.

s-oc4-n2-agg1#sh int vl281
Vlan281 is up, line protocol is up
  Hardware is EtherSVI, address is 0019.a925.2000 (bia 0019.a925.2000)
  Description: svi.SLB-FE-Web-Servers
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not supported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:02, output 00:00:10, output hang never
  Last clearing of "show interface" counters 1d12h
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  L2 Switched: ucast: 1138722618 pkt, 1070173012274 bytes - mcast: 76471 pkt, 8482399 bytes
  L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
  L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
     74604 packets input, 8350307 bytes, 0 no buffer
     Received 74604 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     218 packets output, 17658 bytes, 0 underruns
     0 output errors, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
  • 1
    I know most everyone considers that an SVI means we have a interface with an IP address. A L2 interface is still reported as an SVI by Cisco (EtherSVI). Am I wrong to use the term SVI for both L3 and L2 interfaces? Commented May 22, 2013 at 19:18
  • 1
    Why do you create the L2 SVI in the first place (out of curiosity)? If this device doesn't have a L3 interface in this VLAN, where do the stats in your sh int vl281 command output above come from? Has this device in your question processed 74604 Ethernet frames across all layer 2 ports in the VLAN then? What can you tell from that output? I am assuming you create these L2 SVIs for statistic gathering and debugging/troubleshooting. Do you create them for use with pseudowires, briding and xconnects instead then?
    – Baldrick
    Commented May 22, 2013 at 20:20
  • 2
    I primarily create L2 SVIs for statistical reporting (though limited as it is) and visibility on the switch as well as for a SNMP interface walk for Cacti (RRDTool graphs). The 74604 packets under L3 are just broadcasts shown by the next line "Received 74604 broadcasts". No other reason to create them except for comfort in having all interfaces defined whether L2 or L3. Commented May 22, 2013 at 20:37

8 Answers 8


You might not want to make a L2 SVI if you use VTP pruning. If pruning is on, an unused VLAN will be pruned from the trunk, resulting in less unnecessary broadcast/flooding traffic. However, creating an SVI, creates an "active" interface on your switch. A quick check in GNS3 gives the following:

R1#show vlan-switch

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa1/1, Fa1/2, Fa1/3, Fa1/4
                                                Fa1/5, Fa1/6, Fa1/7, Fa1/8
                                                Fa1/9, Fa1/10, Fa1/11, Fa1/12
                                                Fa1/13, Fa1/14, Fa1/15
3    VLAN0003                         active
4    VLAN0004                         active
[output omitted]

R1#show interfaces trunk

Port      Mode         Encapsulation  Status        Native vlan
Fa1/0     on           802.1q         trunking      1

Port      Vlans allowed on trunk
Fa1/0     1-4094

Port      Vlans allowed and active in management domain
Fa1/0     1,3-4

Port      Vlans in spanning tree forwarding state and not pruned
Fa1/0     1

Now, if I go to R2, connected to Fa1/0 and type R2(config)#int vlan 3, we will see the following:

R2#show run interface vlan 3
Building configuration...

Current configuration : 38 bytes
interface Vlan3
 no ip address
R2#show run | include vlan 3

As you can see, no interfaces in VLAN 3, except the SVI. And back on R1:

R1#show interfaces trunk

Port      Mode         Encapsulation  Status        Native vlan
Fa1/0     on           802.1q         trunking      1

Port      Vlans allowed on trunk
Fa1/0     1-4094

Port      Vlans allowed and active in management domain
Fa1/0     1,3-4

Port      Vlans in spanning tree forwarding state and not pruned
Fa1/0     1,3

As you can see, VLAN 3 just came up on the trunk, adding to the traffic levels on your trunks.


I wouldn't say that it is best practice to create a SVI. However I don't think there will be much of an issue if you do create it. For example Catalyst 3750 supports 1000 SVIs which you will not be likely to hit.

Q. How many SVIs can be created on the Cisco Catalyst 3750 Series Switches? A. Up to 1000 SVIs can be created. However, the maximum number of SVIs is dependent on the number of routes and multicast entries. For example, the switch can support 64 SVIs with 8000 routes and 250 multicast entries.

From my experience the counters on SVIs can't really be trusted.

  • It's a requirement to not have the SVI with an IP. That would create a routing table entry and really mess with routing with the load-balancer. I understand the counters only increment when not hardware switched. Commented May 22, 2013 at 9:03
  • Sorry, what I meant was that I don't think it's best practice to create a SVI but I don't see any harm in doing it either. Edited my answer.
    – Daniel Dib
    Commented May 22, 2013 at 9:07
  • 1
    Translation: it takes up tcam/fib/idb/etc space that could be used for other desirable functions.
    – Ricky
    Commented May 22, 2013 at 18:29

I never create a SVI when there is no special requirement for it. I see no downside, but without adding useless lines you keep your device configuration clean. This can help during troubleshooting sessions.


An SVI is useful when you must provide a Layer3 service to connected ethernet switchports.

SVIs provide an efficient way to attach IP routing services to an ethernet Vlan that already exists on a switch. It effectively saves you from buying an external router just to offer HSRP, or dynamic routing protocols.

When do you not create the SVI for a L2 VLAN?

When you don't want users to have exposure to those features, or you don't want to complicate the configuration. This is just a matter of taste... I never define an SVI, unless I need IP routing services on a Vlan... but I prefer minimal configurations where possible.

  • I clarified question... not looking for L3 answers. Commented May 22, 2013 at 10:20

I wouldn't consider this a best practice, as if you don't want the switch to provide L3 functionality, it isn't needed or useful. Now, I want to preface the rest of this by saying that I never do this unless I want L3 functionality, so I may be wrong.

You mention the counters, but counters shouldn't be incrementing unless traffic is going "in" or "out" of the interface. I suspect that if you span an SVI used as you mention, you won't see the traffic you expect.

I would also have concerns about what the switch would do with certain features, and wouldn't feel comfortable myself with testing them. For example, if you haven't also disabled proxy-arp on the SVI, will it still respond with the SVI MAC address for hosts in other VLANs? I suspect it can and if it does, will it route that traffic to another VLAN?


Adding reachable IP for VLAN is potentially dangerous from security point of view.

It's also an threat from stability point of view, as traffic towards the IP (including ARP, IPv6 ND and so on) hits the to-CPU queue. If you have simple VLAN with L2 only, there's nothing apart from L2 protocols (haha) that can influence the situation of the switch and it's control plane. If you add L3 reachability information, suddenly you're dealing with what's L3 has to offer, including routing protocols, blackholing, limited FIB entries, potentially also different QoS models possible when dealing with L2 vs L3.

In any way, you're adding complexity to the network. Complexity is bad.

As KISS rule says, you DON'T "automatically" add SVI to L2 VLAN. If it's for L2 operation only, I'd even add it to the 'description' of the interface.

  • Everyone's getting hung up on L3 in the SVI. Maybe I'm using the term incorrect. I'm asking about after the vlan x is created, are there merits or negatives of going into interface vlan x which creates the vlan interface, and not configured with an IP. Commented May 22, 2013 at 10:47
  • 3
    In this sense it will all depend on the architecture of the box you're given. With Cisco Catalysts, you're adding logical interface to IDB but not adding route entry (along with TCAM space request). Anyway, operational pro is that you can "stabilize" the SNMP indexes this way, and con is someone at some point may be eager to "fix" the config of some service by adding the IP once he/she sees interface created without IP address. Commented May 22, 2013 at 11:23

There are some platforms like my "favorite" 6500 which can have strong negative reactions to some types or amounts of traffic that is just fine being completely switched through the router becomes a different story once you create a SVI. typically this would be non-ip traffic, but its very hard to predict.


If the VLAN in question is 'private' that is not L3 routed anywhere (say a cluster heartbeat) an SVI on the layer 2 switch will enable your NOC to ping interfaces, and get ARP tables which is a great help in troubleshooting. If you the VLAN in question is routed, there is no great benefit except as a temporary measure to prove that a VLAN is trunked down to that switch (some server guys need proof) by pinging the default gateway for that VLAN from the switch

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.