VTP pruning - not all it's cracked up to be

Stretch posted yesterday about the routing convergence time of SVIs vs. routed interfaces.

It reminded me of a couple of problems I've seen at customer sites:

Sloppy Trunk Configurations
I've run into at least one instance of bad trunk configuration on almost every customer network.  It can happen so easily, and can have such serious implications on routing convergence, that it seems like reason enough to never run point-to-point routed links on an SVI with an access port.  Sure, if you're careful, this can be done correctly.  But will the guy in the next cubicle be so careful?  What about the network admin who replaces you?

In the best case failure scenario, this sort of mistake will lead to convergence times depending on IGP timers, rather than interface state.  In the worst case scenario, you might find a subnet split into separate broadcast domains between two L3 switches, with both of them advertising the subnet into your IGP.  Not good.  Know the whole L2 topology for every VLAN.

VTP Pruning
I found the other problem more interesting, probably because I wasn't completely sure what to expect. It's something I've only seen done once:  I had a customer who deliberately ran every trunk without a 'switchport trunk allowed vlan' statement.  The customer allowed all 4094 VLANs onto every trunk, and relied on VTP pruning to remove the "extra" VLANs from trunks where they weren't needed.

The VTP pruning mostly* worked.  If only one access switch needed vlan 100, 'show int trunk' revealed that each distribution switch was only forwarding vlan 100 on two interfaces:

• The downlink to the closet switch
• The crosslink to the other distribution switch

Great, right?  Broadcast frames don't get forwarded to places they're not needed.  That's the whole point of VTP pruning.

VTP pruning does not, however, make any promises about quick convergence times.  So what about VLAN 99, which is a /30 routed link to the core, and consists of a single access port?

I labbed it up to find out.

The SVI is up:
Rack2-3550#sho ip int brief | inclu Vlan99
Vlan99                 192.168.99.1    YES manual up                    up      

There's just a single access port assigned to VLAN 99:

Rack2-3550#sho int status | inclu 99

Fa0/12    routed link to core     connected    99         a-half   a-10 10/100BaseTX

VLAN 99 is not forwarding on any trunk links, even through it's allowed there:

Rack2-3550#sho int trunk  

Port        Mode             Encapsulation  Status        Native vlan

Gi0/1       on               802.1q         trunking      1

Gi0/2       on               802.1q         trunking      1

Port        Vlans allowed on trunk

Gi0/1       10-14,99  <- Allowed on Gi0/1

Gi0/2       11-14,99  <- Allowed on Gi0/2

Port        Vlans allowed and active in management domain

Gi0/1       10-14,99  <- Allowed and active on Gi0/1

Gi0/2       11-14,99  <- Allowed and active on Gi0/2

Port        Vlans in spanning tree forwarding state and not pruned

Gi0/1       10-14   <- Pruned from Gi0/1

Gi0/2       none    <- Pruned from (and blocking on) Gi0/2

VLAN 99 effectively consists of a single access port.  What will happen to the SVI if I shut down that port?

Rack2-3550(config)#int fa 0/12

Rack2-3550(config-if)#shut

Rack2-3550(config-if)#do sho ip int br | inclu Vlan99

Vlan99                 192.168.99.1    YES manual up                    up      

Doh!  The SVI survives even through there are now no access ports and no trunks willing to carrying its traffic.  Any routing adjacency established here will survive until the IGP times it out.

This will not be good for your VoIP calls.  Don't do this.

*VTP pruning fell apart wherever non-VTP devices were introduced.  Trunks to vmWare servers, non-Cisco switches and wireless devices weren't able to report their lack of interest in any VLANs.  The result was that these devices and their access switches would up receiving all active VLANs.