Re: How to force VLAN interface to stay always UP? - Page 2

Pavel Bykov · ‎05-12-2005

Hello.

We have an addressing plan developed for accessing networking devices. Because not all devices are running in L3 mode (and some of them are L2 by design), Loopback solution cannot be used.

We have all management addresses defined as VLAN interface on the L3 switches and propgated through trunks to L2 switches connected to the L3 switch.

The problem is when there are no L2 switches connected to the L3 switch OR all L2 switches fail, then there are no UP/UP physical interfaces associated with the L2 VLAN number so the L3 VLAN interface is shut down, and the main L3 switch cannot be accessed.

I researched the material and it is required for L3 VLAN interface to synchronize to L2 VLAN, and interface comes up only when at least one interface with the mentioned VLAN is in forwarding state. In older CATOS it was possible to limit (turn off?) this synchronization. But all our devices are running new IOS.

My question is: What can i do to force VLAN interface to always stay up? Can i somehow link L2 VLAN to the loopback?

cstep · ‎11-03-2012

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...

weylin.piegorsch · ‎07-09-2015

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

VLAN configured on that interface, either as an access port or trunk port
that interface is up/up
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 :(

weylin.piegorsch · ‎07-09-2015

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:

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.
I tried doing this with a loopback fiber cord, but that put the port into STP blocking (oops) and so VLAN stayed down/down.
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.
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).
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.
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?

weylin.piegorsch · ‎12-19-2016

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.

Insert a loopback into an unused interface
configure the interface as a switchport with the appropriate VLAN(s)
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
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.

milankerslager · ‎09-24-2016

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
end

What I did (a lot of lines removed):

conf t
interface vlan 4
ip address 10.4.0.1 255.255.0.0
end
ping 10.4.0.1
...nothing...
show ip interface brief
Interface              IP-Address      OK? Method Status Protocol
Vlan4                  10.4.0.1        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

ping 10.4.0.1
Success rate is 100 percent
show ip interface brief 
Interface              IP-Address      OK? Method Status    Protocol
Vlan1                  10.199.0.10     YES NVRAM  up          up
Vlan4                  10.4.0.1        YES manual up          up

weylin.piegorsch · ‎09-24-2016

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. http://www.cisco.com/c/en/us/support/docs/lan-switching/inter-vlan-routing/41260-189.html

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.

weylin

milankerslager · ‎09-25-2016

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 10.4.0.1 255.255.0.0

Thank you for pointing this out.

weylin.piegorsch · ‎09-25-2016

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: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-2940-series-switches/109304-manage-vlandat.html#backup

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.

weylin

weylin.piegorsch · ‎09-24-2016

Ah, found it: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/configuration/guide/3560scg/swint.html#wp2040589

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

VLAN configured on that interface, either as an access port or trunk port
that interface is up/up
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.

weylin

hvangruijthuijsen · ‎03-28-2017

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.

danman32 · ‎11-15-2017

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.

txb1gfr0g · ‎12-31-2017

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 ###.###.###.### 255.255.255.0
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.

bcoverstone · ‎08-31-2022

I may have run into a scenario last night that pertains to this post.

I had a VLAN where all the ports went offline, yet it was still active and I could not shut it down except to issue a "shutdown" in the VLAN interface itself.

I do have the "dampening" command on the vlan interface, so perhaps the line flapped twice before going down, and that prevented any events from dropping for the 15 minute period. Perhaps there is a way to set it to dampen for a very long period of time? I'm not a dampening expert, so this is just a wild idea..

txb1gfr0g · ‎08-31-2022

Check to see if your VLAN was set to state active. See my post right about yours.

Also, if that isn't the problem then let us the make model and IOS version on your switch.

Georg Pauwen · ‎09-01-2022

Hello,

if there are interface flaps, those should be visible using the command:

show interface dampening

Can you post the output of that command ?