Showing results for 
Search instead for 
Did you mean: 

How to force VLAN interface to stay always UP?

I haven't tested this, but in theory...You could always put an ethernet loopback in port and trunk it. Spanning tree will block the loop created, but it should keep the SVIs up...


Unfortunately, for an SVI to

Unfortunately, for an SVI to go up/up, three requirements must be met on at least one physical interface:

  1. VLAN configured on that interface, either as an access port or trunk port
  2. that interface is up/up
  3. that interface is in STP forwarding mode for that VLAN

If you install a physical loopback, STPO blocks and the SVI goes down/down.  I figured this out from actually trying it :(

I'm running into this too,

I'm running into this too, where I have a 2-year project that will require a successive series of VLANs/subnets (about 600 VLANs and 450 subnets altogether) across my 12 IGP-connected routers (nine Cat6509 / Sup720-10G, one Sup2T and two Nexus 7010s), and I'd like to pre-stage the VLANs on the final destination routers so that the subnets populate the routing table.  That way I can test on a remote router in the AS, if I've either (a) fat-fingered something or (b) erred on my subnet assignment plan.

Unfortunately, in the 10 years since this post was first opened - as of 15.1(2)SY4a, Cisco seems to have taken out the "no autostate" command from the 6509's SVI configuration.  Grr.....

I've tried a few things so far:

  1. I can plug a "switchport mode trunk" interface on the 6509 to my out-of-band switch and apply the VLANs to it, but i'm trying to do this without burning-up a port on my patch panel since they're at something of a premium these days based on my connection density.
  2. I tried doing this with a loopback fiber cord, but that put the port into STP blocking (oops) and so VLAN stayed down/down.
  3. I guess I can plug two SFPs into the Gig ports on my Sup, one will go blocking and the other will go forwarding, but for political and cultural reasons that will be a hard sell to my boss.
  4. I could just do STP BDPU Filter with the physical loop installed on the port, but I'm not anticipating removing the VLANs from this interface until the project completes.  Since these VLANs will have active traffic on them, any broadcast will appear twice on the network (takes a minute to think that one through).
  5. I thought about SPAN and VACL capture on the physical loopback combined with some sort of STP trick like BPDU FIlter or something like that, but I can't figure out how to abuse the configuration to make that work without introducing a broadcast loop and again causing those same massive broadcast storms.
  6. I'm hesitant to apply these VLANs to an existing trunk.  The remote-end won't have the VLANs configured so the traffic won't appear on the other end, but I'm a bit concerned that by the end of the 2 years, the devices that will be activated on these VLANs will be sending out enough broadcast traffic that it'll eat-up a fair bit of bandwidth going to the down-stream device.

Any other ideas?

So... I haven't tried this,

So... I haven't tried this, and at this point when I'm now nearly completed the project I started two years ago, I no longer have impetus to try, but for the sake of those stumbling their way hgere from a Google search I may as well post it.

  1. Insert a loopback into an unused interface
  2. configure the interface as a switchport with the appropriate VLAN(s)
  3. apply a MAC ACL to drop all frames
    mac access-list extended drop-all
     deny any any
    interface <intf>
     mac access-group drop-all in
  4. no shut the interface

In theory, that should work.  STP will go through it's normal states and eventually bring the interface into a forwarding state, since it never hears it's own BPDU.  There's a loop, but broadcast storms are prevented since it literally drops ALL ingress traffic.  Even if UDLD is configured, shouldn't be a problem since again, it drops ALL traffic including the UDLD PDUs.

Anyway... that's all in theory.  I don't have time to try it, but that should work.  I'd love to hear someone's experiences in testing out this approach.

And if someone has ideas on how to do this without needing to use up a physical interface, I'd still love to hear it.


On my C3560 with IOS Version

On my C3560 with IOS Version 12.2(55)SE10 I created trunk with a new VLAN and I had to name the VLAN to bring it up, ie:

conf t
vlan 4
name VLAN0004

What I did (a lot of lines removed):

conf t
interface vlan 4
ip address
show ip interface brief
Interface IP-Address OK? Method Status Protocol
Vlan4 YES manual down down show vlan VLAN Name Status Ports ---- -------------------------------- ----- -------------------------- 1 default active ..... conf t vlan 4 name VLAN0004 end show vlan VLAN Name Status Ports
---- -------------------------------- --------- ------------------ 1 default active ... 4 VLAN0004 active
Success rate is 100 percent
show ip interface brief
Interface              IP-Address      OK? Method Status    Protocol
Vlan1             YES NVRAM  up          up
Vlan4                YES manual up          up

Hi milan,

Hi milan,

I think you might be mis-reading your indications.  For an SVI to activate and populate as a "connected" route in the RIB/FIB, you need to meet certain criteria.  Specifically in this case, the VLAN needs to be created (VLAN 1 exists by default, VLANs 2-4094 default to nonexistant).

I thought I could find this referenced in the configuration guide, but surprisingly it's not there (at least, not readily visible in a 3 minute search).  But, see here, which does at least allude to it.

Anyway, a VLAN *always* has a name, even if a default one.  What I believe actually brought the SVI up/up, is not the application of a name, but rather the command "vlan 4".  Had you merely entered "VLAN 4" followed by "exit", you would have seen "applying VLAN configuration changes, please wait a moment" and you would have been able to see the interface VLAN 4 in an up/up state.



I tried it and you are right.

I tried it and you are right. The VLAN is up (able to ping it) from the moment:

conf t
vlan 4

So no need to use "name VLAN0004" (it was named automagically).

The problem is that if someone takes switch configuration (ie saved running-config) and copy it to the another Cisco switch, it does not work. The command "vlan NUM" is required to insert manually for every VLAN used (it is not present in the saved running-config). I think this is a bug, probably "widely known bug". The running-config has only those entries:

interface Vlan 4
ip address

Thank you for pointing this out.

Hi Milan,

Hi Milan,

I suspect this is off-topic, but I'll tackle...

Is VTP mode either "server" or "client?"  If so, that's expected behavior.  (If "client," then no need to worry about it anyway.)  If VTP is either "transparent" or "off," that's confusing behavior.

If your concern is about doing backup of a VTP "server" L3 switch doing some kind of routing (even if just IVR and static/default routing), and you want to be able to restore from backup after a switch crash, then see this article:

And, by the way, if this is in fact a VTP server, you should be doing VTP version 3 if possible, and thereby reducing the concern by having a standby VTP server (among a myriad of other benefits of VTP v3).  Though, to do things "properly," you should still do VLAN database backups.


Ah, found it: http://www

Ah, found it:

For an SVI ("interface VLAN") to go up/up, three requirements need to be met:

  1. VLAN configured on that interface, either as an access port or trunk port
  2. that interface is up/up
  3. that interface is in STP forwarding mode for that VLAN

By default, a VLAN does not exist, except for VLAN 1 which cannot be deleted.  Since the VLAN does not exist, there is no STP process for that VLAN.  Since there is no STP process, it cannot be in forwarding mode.

When you create the VLAN, the STP process is started.  After STP is activated, if there is a physical interface configured for that VLAN (either an access port, or a trunk port with that VLAN in the allowed list), once the interface transitions to STP state "FWD" the VLAN should come up.  So really, the list above could be simplified by boiling it down to #3 since #1 and #2 are also prerequisites to #3.

Anyway, that's why you need to create the VLAN, but don't need to name it.  And, it's why your SVI didn't come up until you activated the VLAN.

Now, if only we could figure out a way to meet those three requirements without actually needing to apply it to a *physical* interface.


Simpel solution if you have a

Simple solution if you have a layer 3 switch.

Create a port as a router port, so no switchport and configure an IP address on it.

Create a port with access port in vlan you want to have up.

Connect both ports to each other with a standard CAT5 or 6 cable.

Spanning tree loops cannot occur because only one port is a layer two port.

The VLAN interface will come up and running.


Re: Simpel solution if you have a

That works!   You don't even have to assign the L3 interface an IP, just enter "no switchport" to one of the two looped interfaces.  It is a shame you have to burn two interfaces on a single switch just to keep the management VLAN interface up.


Re: How to force VLAN interface to stay always UP?

This is an old thread but I had the same problem but found the solution. First my switch was running IOS 12.4. My management vlan that I wanted to always be up was vlan 2. I do NOT have any ports in vlan 2 but I needed to be able to reach this SVI at all times. I made sure my trunk port was set to allow vlan 2 as well as all the other vlans I needed.


Switch# Conf t
Switch(config)# int vlan 2
Switch(config-if)# ip add ###.###.###.###
Switch(config-if)# exit
Switch(config)# vlan 2
Switch(config-vlan)# state active
Switch(config-vlan)# end
Switch# wr mem


That set the VLAN to always be active and brought the SVI with the IP address I assigned to an up/up state.

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards