Convergence Delays: SVI vs Routed Interface

There are two general ways in which routed links can be implemented between Cisco multilayer switches. The first option is to designate a VLAN for the routed traffic and create a routed VLAN interface (SVI) on either end of the link for that VLAN. An example configuration for a solution might look like this:

interface Vlan100
 ip address 10.0.0.1 255.255.255.0
!
interface FastEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk

The other option is to configure the physical interfaces as routed interfaces, assigning each an IP address directly:

interface FastEthernet0/1
 no switchport
 ip address 10.0.0.1 255.255.255.0

Both are valid solutions. The latter provides a simpler configuration, while the former allows for a more flexible design. However, a recent discussion on networking-forum.com got me thinking about differences between the two approaches with respect to convergence time.

Slide 24 of the Multilayer Campus Architecture and Design Principles presentation by Cisco referenced in the discussion shows a direct routed link with a routing convergence delay of just ~8 msec. In contrast, the delay of a layer two link with an SVI is estimated to be between 150 and 200 msec. That's a pretty substantial distance, particularly with real-time traffic (e.g. VoIP and video). Let's see if we can replicate their results.

Testing will be performed on a Catalyst 3560-24, connected to a Catalyst 3550-24 at the far end. All but the testing interface will be administratively shutdown. A link fault will be simulated by shutting the remote interface on the 3550. debug ip routing wil be enabled to record modifications to the routing table. As in the reference slide, delay will be calculated using log timestamps. To achieve the desired granularity, the msec argument has been appended to the timestamp service commands.

S1(config)# service timestamps log datetime msec
S1(config)# service timestamps debug datetime msec

We'll implement both configurations in turn and record the delay that occurs between a link failure and update of the routing table. We'll repeat each test three times and take the average delay for each.

SVI Testing

Below is the log output of the first run of the SVI test. The timestamps we're interested in are the line protocol state transition and the interface being removed from the routing table.

Jan 23 18:22:51.315: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/16, changed state to down
Jan 23 18:22:51.324: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan100, changed state to down
Jan 23 18:22:51.324: is_up: 0 state: 4 sub state: 1 line: 0
Jan 23 18:22:51.324: RT: interface Vlan100 removed from routing table
Jan 23 18:22:51.324: RT: del 10.0.0.0/24 via 0.0.0.0, connected metric [0/0]
Jan 23 18:22:51.324: RT: delete subnet route to 10.0.0.0/24
Jan 23 18:22:51.324: RT: delete network route to 10.0.0.0
Jan 23 18:22:52.330: %LINK-3-UPDOWN: Interface FastEthernet0/16, changed state to down

Results

• 9 msec
• 8 msec
• 9 msec

Average delay: 9 msec

Routed Interface Testing

Again, below is the log output from the first run of the test.

Jan 23 18:28:57.671: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/17, changed state to down
Jan 23 18:28:58.669: %LINK-3-UPDOWN: Interface FastEthernet0/17, changed state to down
Jan 23 18:28:58.669: is_up: 0 state: 0 sub state: 1 line: 0
Jan 23 18:28:58.669: RT: interface FastEthernet0/17 removed from routing table
Jan 23 18:28:58.669: RT: del 10.0.1.0/24 via 0.0.0.0, connected metric [0/0]
Jan 23 18:28:58.669: RT: delete subnet route to 10.0.1.0/24
Jan 23 18:28:58.669: RT: delete network route to 10.0.0.0

Results

• 998 msec
• 998 msec
• 998 msec

Average delay: 998 msec

What Does it Mean?

Well, that was unexpected. Our results are quite different from what the slide suggests. We see a mere ~9 msec delay for the switchport/SVI configuration and almost a full second of delay for the routed interface.

It turns out that the default carrier-delay for physical interfaces (2 seconds) is to blame. Looking at the prior page of the presentation PDF, slide 23, suggests that their test was performed with a carrier-delay set to 0 msec. We can configure our 3560 to match using the command carrier-delay under interface configuration.

S1(config-if)# carrier-delay msec 0

Running the routed interface test again, we now see very different results:

Jan 23 18:45:06.316: %LINK-3-UPDOWN: Interface FastEthernet0/17, changed state to down
Jan 23 18:45:06.316: is_up: 0 state: 0 sub state: 1 line: 0
Jan 23 18:45:06.316: RT: interface FastEthernet0/17 removed from routing table
Jan 23 18:45:06.316: RT: del 10.0.1.0/24 via 0.0.0.0, connected metric [0/0]
Jan 23 18:45:06.316: RT: delete subnet route to 10.0.1.0/24
Jan 23 18:45:06.316: RT: delete network route to 10.0.0.0
Jan 23 18:45:07.314: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/17, changed state to down
Jan 23 18:45:07.314: is_up: 0 state: 0 sub state: 1 line: 0

After eliminating the carrier delay, the physical interface is brought down immediately upon detecting a link failure and the routing table is immediately updated. The line protocol transitions to down as well just one millisecond later.

Modifying the carrier-delay appears to have no effect on the SVI convergence delay.

Conclusion

I want to avoid reading too far into these results, for two reasons. First, this lab provides very limited visibility into exactly when a link is considered down. Second, I suspect much of this behavior is platform-dependent.

However, I would like to close with a few points to take away:

• The tests above were limited to simulating direct failures only.
• As we've seen, the switchport/SVI configuration does not necessarily impose a long convergence delay.
• Carrier-delay is a major factor for routed interfaces. It's a good idea to consider lowering it from its default value.
• Don't trust that statistics from slides (or blog posts) will apply to your network. Verify the numbers yourself.