Cisco – When not to create a SVI for a L2 VLAN

ciscoswitchvlan

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

Best Answer

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
end
R2#show run | include vlan 3
R2#

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.

Related Solutions

Cisco – What causes total output drops on a cisco switch interface

Unless someone is clearing counters you should never see any odometer-type counters (those that increment based on a packet action) decrease, they should always increase. That part sounds like a bug.

As far as what causes output drops in particular, there are so many different causes that it's very difficult to pinpoint it exactly. Sometimes there is congestion inside the switch's backplane and those might show up as output drops on the outgoing interface. In rare circumstances you can also get microbursts that don't show up when polled at 1 minute intervals that quickly overload the interface, but then drop back down very quickly. I would suggest grabbing the SNMP OID for output drops and then graphing that and see how it corresponds to the CLI counter.

Generally speaking, you don't want any output drops as they indicate a packet that did not make it to its destination. But, if you're running your links hot (which you say you're not) they're unavoidable to an extent, mostly due to interior switch buffering, etc.

Cisco – Output Drops on Serial interface: Better queueing or Output queue size

You're right, you wouldn't really see the burstiness easily on SNMP. 1GE can send 1.48Mpps, so it takes very very little time to congest the the 45Mbps, which can handle less than 75kpps.

If your ingress is 1GE and egress is 45Mbps, then obviously the congestion point of 45Mbps will need to drop packets. This is normal and expected. If you increase buffers you'll introduce more delay.
1GE takes 0.45ms to send 40 1500B IP frames, which is right now the amount of burst you can handle. However dequeueing them on the 45Mbps already takes 10ms.

If you don't have any acute problem, I would probably not do anything about it. But if some traffic is more eligible for dropping than other, then you should replace FIFO with class-based queueing. Say maybe you want to prioritize so that more ftp is dropped and less voip.
Then it'll also make more sense to add more buffering on the ftp traffic, as it's not really sensitive to delay.

If you want to try your luck with deeper buffers, something like this should suffice:

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

This would cause 50ms buffers on the Serial1 and would allow you to handle up-to 2.25ms burst from single Gige interface.

Best Answer

Related Solutions

Cisco – What causes total output drops on a cisco switch interface

Cisco – Output Drops on Serial interface: Better queueing or Output queue size

Related Topic