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 10.100.100.1 30
[C1-Vlan-interface1]display this
#
interface Vlan-interface1
ip address 10.100.100.1 255.255.255.252
#
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 10.10.10.1 30
[C1-Ten-GigabitEthernet1/0/49]display this
#
interface Ten-GigabitEthernet1/0/49
port link-mode route
combo enable fiber
ip address 10.10.10.1 255.255.255.252
#
As you can see, you can now assign an IP address directly to the port.
Example
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/ vcloudnine.de/ 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 10.0.0.1
GE1/0/2 UP UP 10.10.0.1
GE2/0/1 UP UP 10.1.0.1
GE2/0/2 UP UP 10.11.0.1
InLoop0 UP UP(s) --
Loop0 UP UP(s) 1.1.1.1
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
----[Port4(GigabitEthernet1/0/3)][DOWN]----
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.