SVI autostate
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 192.168.10.1 255.255.255.0 Switch(config-if)# ^Z Switch# show ip interface brief Interface IP-Address OK? Method Status Protocol Vlan1 unassigned YES unset administratively down down Vlan10 192.168.10.1 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 Switch(config-if)# 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 networking engineer and the maintainer of PacketLife.net. He currently lives in the Raleigh-Durham area of North Carolina. Although employed full-time out of necessity, his true passion lies in improving the field of network engineering around the world. You can contact him by email or follow him on Twitter.
Comments
THNX 4 pointing this out...I am also wondering why the Catalyst switches don't know "no autostate"!
Cool, didn't know about the "port must be in the STP forwarding state" part of the requirement. Thanks Stretch =]
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.
Right?
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.
It is also possible to use the 'suspend vlan' feature if required?
Conf t
vlan 123 state suspend
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.
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.
Excellent
A bit more information on autostate:
http://blog.ioshints.info/2009/07/followup-vlan-interface-status.html
Things can get tricky when you have trunking ports; you can also explicitly remove an interface from autostate computation.