How to force VLAN interface to stay always UP?

[Pavel Bykov]

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?

[amit-singh]

Hi,

We cannot link L2 vlan to a loopback. For the Vlan interface to stay up/up either any device should be connected to it ot trunk has to be UP. when trunk goes down and there are not other device in the particular vlan, the interface will go down.

Dont you have any other device connected to l3 switch, I mean other than any switch. Do you want all Vlan interfaces to stay up/up or only few of those.

regards,

-amit singh

[Pavel Bykov]

No, only this one management VLAN interface has to stay up at all times.

Also i cannot trunk it to some random user port with native vlan being user vlan, because it can go down too, and i want to have all user ports clean, in access. And i cannot trunk it to the uplink interface because there are multiple uplinks, and also the VLANs are reused within management domain, so i want to keep transparent VLANs away from core.

[cstep]

config terminal

!

interface Vlan1

ip address 192.168.0.1 255.255.255.0

no autostate

no shutdown

!

interface Vlan2

ip address 192.168.1.1 255.255.255.0

no autostate

no shutdown

!

interface Vlan3

ip address 192.168.2.1 255.255.255.0

no autostate

no shutdown

!

int range FastEthernet0/1 - 8

switch access vlan 1

switch mode access

no shutdown

!

int range FastEthernet0/9 - 16

switch access vlan 2

switch mode access

no shutdown

!

int range FastEthernet0/17 - 24

switch access vlan 3

switch mode access

no shutdown

!

end

produces the following results with all ports unplugged.

[commodorej]

I was wondering about the same thing while working on my home lab and came accross this discussion posted. The no autostate command doesn't seem to be supported on the 3550 and 2950 switches I have.

3550_MLS1(config-if)#no autostate

                                      ^

% Invalid input detected at '^' marker.

2950_SW2(config-if)#no autostate

                                     ^

% Invalid input detected at '^' marker.

Maybe my switches IOS is just old....?

12.2(44)SE6 - 3550

12.1(12c)EA1 - 2950

[commodorej]

After looking more closely, I think its just STP doing it.

[jason_srpl]

I have an unrelated, but related issue; Where I have an ADSL2+ line with static addresses, and I wanted an external port;

Setting the dialer0 to ip-unnumbered, to a vlan, with the public address of the block, and also adding a single, or any

number of L2 switch ports to the same vlan... when I unplugged the only device on that eth port, it also brought down

the VLAN as an ip routable interface! and with in and outbound NAT traversing that VLAN's ip address (of a /29 network)

nothing worked suddenly. Arghh.. Do i _really_ have to leave something plugged in? as the original poster mentions,

sometimes, you just can't protect against that.

Thanks VERY much for posting your knowledge of "no autostate" - that instantly solved a conundrum where I don't

need the protection of an interface shutting down.

Sorry to Pavlo this didn't solve his original issue however. I hope you found a method.

[vizerei]

Worked perfectly. I've been trying to figure this out for a while, thanks!

-Vic

[douhanm]

how bout no keep alive ? That was on routers at least

Matt

Sent from Cisco Technical Support iPad App

[commodorej]

Dont think so. the hello timers for STP BPDUs can only be modified between 1-10 seconds

[commodorej]

I came accross this in the SWITCH study guide while preping for the exam. I had given up and erased my configs but I'm going to give it another try using this command:

(config-if) switchport autostate exclude

Hope it works. If anyone has any luck with this one... please post!

[weylin.piegorsch]

Unfortunately, switchport autostate exclude only takes that interface out of the autostate calculation - basically it behaves to autostate as if the interface is down.  Boo!

[chris-lawrence]

Weylin,

We seem to have a similar issue but I'm trying to get the SVI up for another reason.

DOT1X Guest VLAN - I've got a SVI defined which is handed out to clients which are not EAP aware. Can't go into the reasons why I am doing this but I use this SVI membership to make them EAP aware - then they pass the EAP and get access to network.

Like you, no members means SVI up/down - This worked great on a CAT3750 but the CAT3850 seems to not like it.

If I add another port into the VLAN not related to EAP, to get the SVI up/up - then it all works. If i could just configure something on the SVI that forces it up/up without members - life would be sweet.

Chris 

[commodorej]

I came accross this in the SWITCH study guide while preping for the exam. I had given up and erased my configs but I'm going to give it another try using this command:

(config-if) switchport autostate exclude

Hope it works. If anyone has any luck with this one... please post!

[m.kafka]

Hi,

unfortunately it won't help in every situation:

If you use a SVI with access-ports only (e.g. no trunk carrying that VLAN, which is in connected state) you will always get a status "down" for the SVI if all access-ports of that VLAN are configured with "autostate exclude": These ports will be ignored for the autostate calculation (whether they are up or down) which means that no port can be found in that VLAN with a state "connected" to calculate the autostate -> no port connected = status down.