SVI autostate

By stretch | Monday, November 9, 2009 at 4:21 a.m. UTC

Cisco IOS SVIs, also called VLAN interfaces, exhibit what might be considered an odd behavior: by default, an SVI will show an interface state of up but a line protocol state of down. Consider the following minimal configuration:

Switch(config)# vlan 10
Switch(config-vlan)# interface vlan10
Switch(config-if)# ip address
Switch(config-if)# ^Z
Switch# show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
Vlan1                  unassigned      YES unset  administratively down down    
Vlan10           YES manual up                    down
FastEthernet0/1        unassigned      YES unset  down                  down    
FastEthernet0/2        unassigned      YES unset  down                  down    

This is because an SVI must meet all of the following conditions to transition to the full "up/up" state:

  • Its VLAN must exist and be active in the VLAN database.
  • At least one switched port in the VLAN (access or trunk) must be up.
  • That port must be in the STP forwarding state.

Typically, a newly created VLAN will not yet have been assigned to any ports. Once it is, and provided at least one of those ports is operational, we see the SVI line protocol transition to the up state:

Switch(config)# interface f0/3
Switch(config-if)# switchport access vlan 10
LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to up

Cisco refers to this behavior as autostate. While usually very handy, this behavior might not always be desirable. For example, an engineer might wish for an SVI to always remain up so that a can be reached via its associated IP address even if all ports associated with that VLAN are down (or if the VLAN itself has gone missing).

On some platforms (routers running 12.4T at least, possibly others), Cisco includes the ability to disable the autostate feature with the command no autostate under SVI configuration. Sadly, this command seems only to be available on routers and not Catalyst switches, where one assumes it would be most useful.

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Switching


Ivan Pepelnjak (guest)
November 9, 2009 at 6:22 a.m. UTC

A bit more information on autostate:

Things can get tricky when you have trunking ports; you can also explicitly remove an interface from autostate computation.

November 9, 2009 at 9:04 a.m. UTC

THNX 4 pointing this out...I am also wondering why the Catalyst switches don't know "no autostate"!

Chris (guest)
November 9, 2009 at 10:41 a.m. UTC

Cool, didn't know about the "port must be in the STP forwarding state" part of the requirement. Thanks Stretch =]

Emre Sumengen (guest)
November 9, 2009 at 11:44 a.m. UTC

Hmm, it's nice to know this, but I wonder why someone would want an SVI to stay up, although none of it's members are awake.

If it's for remote reachability or having a static ID-like IP address for the router, loopback interfaces are always there handy.


November 9, 2009 at 1:33 p.m. UTC

Autostate is commonly used by those platforms, such as the Catalyst C6500, that have Modules such as the ACE, FWSM, IDS, Guard/Detector and so on. When these Modules are installed, you can have VLANs that have no physical interfaces used since they only exist between, for example, the FWSM Firewall instance and the ACE load balancing instance.

Because this use case will never have a physical interface in a given VLAN, and the VLAN must be up so that the logical SVI is presented to the Module. Therefore I would draw the conclusion that the feature is only supported on those platforms that have these modules.

These types of Modules are only supported in IOS and not CatOS, probably due to how the backplane is handled in software. So my thinking, is that's why the feature exists in certain hardware only.

Flintstone (guest)
November 15, 2009 at 3:48 p.m. UTC

It is also possible to use the 'suspend vlan' feature if required?

Conf t

vlan 123 state suspend

November 16, 2009 at 11:36 p.m. UTC

On Catalyst switches, you can enter into vlan configuration, by "vlan x" and issue the "state active" command, and your Vlan interface will be up/up.

December 14, 2009 at 4:39 p.m. UTC

I have to say that the as a best practice, the reachability of a device should always be to a loopback and not it's physical interfaces. Obviously in certain topologies it's not a big deal, but often with redundant routes monitoring a device using a physical port or an SVI can slow down troubleshooting efforts.

Estarlin (guest)
October 9, 2011 at 10:45 p.m. UTC


Azeem A (guest)
December 22, 2013 at 11:58 p.m. UTC

We have got another way where we can actullay disable any interace which is definded under a VLAN but does not play any role in defining the status of the SVI. We can use "switchport auto-state exclude" under the interface config mode of any physical interface and then assign it to any VLAN and now this particular interface will not play any role in defining the state of SVI.

Stephen (guest)
February 12, 2014 at 9:10 p.m. UTC

Thanks for this.

Kiel Martin (guest)
May 5, 2015 at 10:54 a.m. UTC

I am not sure why this command is perceived as it is. Using the 'switchport autostate excluded' command will not keep your SVI up and running. If I only had f0/1 in Vlan-10. F0/1 is status and protocol is up, the protocol of the SVI for Vlan-10 goes up. The second I put the autostate excluded command on f0/1, then protocol for interface Vlan-10 will go down, and that connected interface will be removed from the routing table.

The autostate excluded command states this: The interface will not play a factor in determining if the SVI's protocol status will be up or down. Which means, if the interface goes up, it will not bring up the SVI. There is no way for the interface to effect if the SVI goes down, this is why.....

The interface does not effect the SVI at all, so if that is the case, when the interface comes up, nothing happens. That means if this interface is up, the only way for the SVI's protocol to be up is to have another port that is up in that Vlan and does not have the autostate exlcuded command on it.

So this command eliminates a port from effecting the SVI at all. So this command does not allow you to have an SVI up when there are no ports active in that VLAN. If there is multiple ports up in that Vlan, then the SVI's protocol status will remain up until the last port (that does NOT have the autostate command on it) goes down.

Where could I use this? Lets say I have port that is up, in a vlan, and is going to a device that will not be communicating on that vlan (like a monitoring source port). If that port is the only one up, then my interface VLAN protocol is up. Well, I don't want my SVI to be up if this is the last port that is active. Now the SVI is in my routing table, and drawing traffic towards me, and that is not want I want since there are no real communicating interfaces in that Vlan

Rawson Fang (guest)
July 21, 2016 at 12:29 a.m. UTC

It seems Catalyst IOS default to "no autosense" on SVI interface, but Nexus NX-OS default to "autosense".

Working on a pair of Nexus9000 switches, with two 10G trunk links for form a port-channel 1, all the VLAN interfaces are all in down/link-down state.

# sh int vlan23
Vlan23 is down (VLAN/BD is down), line protocol is down, autostate enabled
Vlan123         protocol-down/link-down/admin-up
Vlan124         protocol-down/link-down/admin-up
Vlan125         protocol-down/link-down/admin-up

Put "no autosense" command under the VLAN interface bring up the interface:

interface Vlan22
  description xxxxxxxxxxxx
  no shutdown
  no autostate

cv-core-sw01-new# sh int vlan 22
Vlan22 is up, line protocol is up, autostate disabled
Comments have closed for this article due to its age.