Routed Port vs. Switch Virtual Interface (SVI)

Many years ago, networks consisted of repeaters, bridges and router. Switches are the successors of the bridges. A switch is nothing else than a multiport bridge, and a traditional switch doesn’t know how to pass traffic to a different broadcast domains (VLANs). Passing traffic between different broadcast domains, is a job for a router. A router has an IP interface in each broadcast domain, and the IP interface is used by the clients in the broadcast domain as a gateway.

Switch Virtual Interface

A Switch Virtual Interface, or SVI, is exactly this: An virtual IP interface in a broadcast domain (or VLAN). It’s used by the connected clients in the broadcast domain to send traffic to other broadcast domains.

This is how a SVI is created on HPE Comware 7. It’s similar to other vendors.

[C1]interface Vlan-interface 1
[C1-Vlan-interface1]ip address 30
[C1-Vlan-interface1]display this
interface Vlan-interface1
 ip address

At least one port is assigned to this VLAN, and as soon as at least one port of this VLAN is online, the SVI is also reachable.

What happens, if you connect two switches with a cable? The broadcast domain spans both switches. Layer 2 traffic is transmitted between the switches. And what would happen if you connect a second cable between the same two switches? As long as you are running Spanning Tree Protocol (STP), or another loop detection mechanism, nothing would happen. But one of the two connection would be blocked. No traffic would be able to pass over this connection. If you want to use multiple, active connections between switches, you have to use Link Aggregation Groups (LAG), or things like Multiple Spanning Tree Protocol (MSTP) and Per VLAN Spanning Tree (PVST).

Routers don’t know this. Multiple connections between the same two routers can’t form a loop. Loops and STP (an some other crappy layer 2 stuff) are legacies of the bridges, still alive in modern switches. Loops are a typical “bridge problem”.

Routed Ports

Some switches offer a way, to change the operation mode of a switch port. After changing this operation mode, a switch port doesn’t act like a bridge port anymore. It’s acting like the port of a router, that only handles layer 3 traffic.

This is again a HPE Comware 7 example. I know that Cisco and Alcatel Lucent Enterprise also offer routed ports.

This is a normal switch port. Please note the “port link-mode bridge”.

[C1]int XGE1/0/49
[C1-Ten-GigabitEthernet1/0/49]display this
interface Ten-GigabitEthernet1/0/49
 port link-mode bridge
 combo enable fiber

To “convert” a switch into a routed port, simply change the link-mode of the port.

[C1-Ten-GigabitEthernet1/0/49]port link-mode route
[C1-Ten-GigabitEthernet1/0/49]ip address 30
[C1-Ten-GigabitEthernet1/0/49]display this
interface Ten-GigabitEthernet1/0/49
 port link-mode route
 combo enable fiber
 ip address

As you can see, you can now assign an IP address directly to the port.


Let’s try to make this clear with an example. C1-1 and C1-2 are two HPE Comware based switched, configured as an IRF stack (virtual chassis). These two switches form the core switch C1. S1 and S2 are two access switches, also HPE Comware based. Each access switch has two uplinks: One uplink to C1-1 and another uplink to C1-2, the two chassis that form C1. The 40 GbE Ports between C1-1 and C1-2 are used for IRF. Please ignore them.

The uplinks between the switches, all ports are Gigabit Ethernet (GE) ports, are configured as routed ports.

Without routed ports, the uplinks must be configured as a LAG, or STP would block one of the two uplinks between the core switches and the access switch. But because routed ports are used, no loop is formed. Most layer 2 traffic can’t pass the routed ports (broadcasts, multicasts etc.)

Patrick Terlisten/ Creative Commons CC0

Patrick Terlisten/ Creative Commons CC0

THe Link Layer Discovery Protocol (LLDP) traffic can pass the routed port. This is what the core switch (C1) “sees” over LLDP.

[C1]display lldp neighbor-information list
Chassis ID : * -- -- Nearest nontpmr bridge neighbor
             # -- -- Nearest customer bridge neighbor
             Default -- -- Nearest bridge neighbor
System Name          Local Interface Chassis ID      Port ID
S1                   GE1/0/1         34ce-d3a9-0300  GigabitEthernet1/0/1
S2                   GE1/0/2         34cf-0690-0400  GigabitEthernet1/0/1
S1                   GE2/0/1         34ce-d3a9-0300  GigabitEthernet1/0/2
S2                   GE2/0/2         34cf-0690-0400  GigabitEthernet1/0/2

Each routed port as an IP address assigned. The same applies to the routed ports on the access switches. Each uplink pair (core to access) uses a /30 subnet.

As you can see, the interfaces working in bridge mode start counting at GE1/0/3.

[C1]display interfaces brief
Brief information on interface(s) under route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface            Link Protocol Main IP         Description
GE1/0/1              UP   UP
GE1/0/2              UP   UP
GE2/0/1              UP   UP
GE2/0/2              UP   UP
InLoop0              UP   UP(s)    --
Loop0                UP   UP(s)
MGE0/0/0             DOWN DOWN     --
NULL0                UP   UP(s)    --
REG0                 UP   -- --

Brief information on interface(s) under bridge mode:
Link: ADM - administratively down; Stby - standby
Speed or Duplex: (a)/A - auto; H - half; F - full
Type: A - access; T - trunk; H - hybrid
Interface            Link Speed   Duplex Type PVID Description
FGE1/0/53            UP   40G     F(a)   -- --
FGE1/0/54            UP   40G     F(a)   -- --
FGE2/0/53            UP   40G     F(a)   -- --
FGE2/0/54            UP   40G     F(a)   -- --
GE1/0/3              DOWN auto    A      A    1

The same applies to STP. The ports, that were configured as routed ports, are not listed in the output. STP is not active on these ports.

[C1]display stp
-------[CIST Global Info][Mode MSTP]-------
 Bridge ID           : 0.34a9-6908-0100
 Bridge times        : Hello 2s MaxAge 20s FwdDelay 15s MaxHops 20
 Root ID/ERPC        : 0.34a9-6908-0100, 0
 RegRoot ID/IRPC     : 0.34a9-6908-0100, 0
 RootPort ID         : 0.0
 BPDU-Protection     : Disabled
 Bridge Config-
 Digest-Snooping     : Disabled
 Root type           : Primary root
 TC or TCN received  : 0
 Time since last TC  : 0 days 0h:27m:23s

 Port protocol       : Enabled
 Port role           : Disabled Port
 Port ID             : 128.4
 Port cost(Legacy)   : Config=auto, Active=200000
 Desg.bridge/port    : 0.34a9-6908-0100, 128.4
 Port edged          : Config=disabled, Active=disabled
 Point-to-Point      : Config=auto, Active=false
 Transmit limit      : 10 packets/hello-time
 TC-Restriction      : Disabled
 Role-Restriction    : Disabled
 Protection type     : Config=none, Active=none
 MST BPDU format     : Config=auto, Active=802.1s
 Port Config-
 Digest-Snooping     : Disabled
 Rapid transition    : False
 Num of VLANs mapped : 1
 Port times          : Hello 2s MaxAge 20s FwdDelay 15s MsgAge 0s RemHops 20
 BPDU sent           : 0
          TCN: 0, Config: 0, RST: 0, MST: 0
 BPDU received       : 0
          TCN: 0, Config: 0, RST: 0, MST: 0

What are the implications?

The example shows redundant links between access and core switches. There are no loops, but there’s also no layer 2 connectivity. VLANs are only located on the access switches. There are no VLANs spanning multiple switches. What does this mean? How can a client on S1 reach a server on S2? The answer is simple: You have to route the traffic on the access switches. But that’s a topic for another blog post.