DELL OS10 VLT port-channel configuration examples and expected behavior

Hello,

Firstly VLT is not a stack. It is two independent switches that work in cooperation with one another.

In order for this partnership to occur a few things must be in place:

• Both switches must have the same VLT domain number
• Both switches must have the VLT interconnect (VLTi)
• The VLT backup (heartbeat) should be established.

 

Before I further answer your scenarios questions I feel it is more important to explain what the purpose of VLT is since as I have stated it is not a stack.

If you are familiar with what purpose and the functionality a LAG preforms then this will make more sense.

LAG means Link Agitation Group, also referred to as a port-channel, NIC teaming, binding, ether channel, LACP, ect…

The purpose of a LAG is to cause two physical interfaces to operate and be viewed as a single logical interface.

I often use the analogy of an RJ45 networking cable. The eight tiny copper cables would act as the individual interfaces and the RJ45 cable would represent the LAG.

 

Armed with that information the VLT operates in the exact same manner. You have a physical cable from each VLT switch to form a LAG. Thus spreading the LAG across two physical switches. So you have a logical port-channel (LAG) that has a cable going to two different switches.

The magic of the VLT is when you add the command "vlt-port-channel" to the LAG (port-channel)  on each switch. This command tells the location of the other half of the LAG (port-channel)

 

I'll now go into your scenarios questions:

 

Assuming the 3 scenario's I have as examples below use the same two switches with a VLTi link, what would be the  difference in functionality between these 3 configurations?

1 interface on each switch in VLAN only (no port-channel or vlt-channel)

This is often the recommended practice for duel-homed server NIC. As long as these two separate interfaces are not going to the same upstream networking device then you are fine; spanning-tree will then treat them as two separate devices and will act accordingly.

 

1 interface on each switch on the same port channel but not vlt-channel (or channel group on the interfaces).

The magic of VLT is that the port-channel (channel-group) will act as a single logical interface spread across multiple switches however if you have the need for VLT-Switch#1 to have port-channel 10 going to device-ABC  while also having the need for VLT-Switch#2 to have port-channel 10 going to device-XYZ then that is allowed. Just don't add the command "vlt-port-channel" to the LAG (port-channel)  on each switch.

 

1 interface on each switch on the same port channel, vlt-channel, with channel-group mode active on the interfaces.

I'm not 100% sure I completely follow the question. This sounds like the standard for creating a VLT-port-channel.

 

Do all three scenarios still makes the switches behave as a single switch loop free topology?

Under the VLT domain there is a command to create a dummy MAC address that the VLT pair of switches will present when a VLT-port-channel is utilized. If no dummy VLT-MAC address is created then the Mac address of the primary VLT switch will be used.

If you are not utilizing a VLT-port-channel then each switch will treat that port-channel or standalone interface as a non-VLT interface.

 

Or do you have to assign the VLT channel group?  WHat scenarios might you use for each configuration?

 I think it is at this point that I should mention that the VLTi servers two purposes:

It will allow the two halves of the VLT-port-channel (LAG) to sync their data.

It acts as a standard port-channel for passing orphan port data from VLT-Switch#1 to VLT-Switch#2.

NOTE: any standalone interface or non-VLT-port-channel is considered an orphan port

 

And finally, why does "channel-group active" only work when both interface "lines" are up, as opposed to only one up (vlt port-channel shows as down).  If I change it to "channel-group on", it will work with only one interface plugged in. But im worried to leave it on active and then someone unplugs one of the cables and the whole VLT fails (maybe it just requires both lines to be online to initialize?)

When utilizing the "channel-group mode active" it is set as a dynamic LACP port-channel. That requires the other side of the port-channel (upstream switch I mean) to negotiation the port-channel with LACP PBDU exchanges.

When utilizing the "channel-group mode on" then it is setup as a static LAG. There is no exchange of PBDU nor negotiation from the upstream switch.

In this mode it assumes that the other end of the connection (upstream switch) is set and ready to accept the LAG traffic.

NOTE: there are times when an interoperability issues arises between vendors and the only option is to use a static LAG instead of a dynamic one.

 

 

I probably could have asked my question in a different way...

 Do a pair of switches connected via VLTi only, share layer 2 information with peer switch interfaces that arent in the same VLT Channel group?

Yes

 

And if so, is there really any reason to put these interfaces in a vlt port-channel if they only plan to operate at layer 2?

Yes - switch level redundancy

 

im sorry, I thought of another Question.

I found a few non-oem technical guides where individuals are configuring vrrp on top of vlt with peer routing because they claim it adds an extra redundancy layer. But in my mind peer routing already has that redundancy layer built in because either switch can respond as the other, and it uses one less IP.

Is there something I am missing?

 

In OS9 VLT-peer-routing operated as a replacement for VRRP

In OS10 The VLT-peer-routing will answer to the VLT-peer switch as long as that VLT-peer switch was up and running.

In short VRRP should be utilized over VLT-peer-routing.

NOTE: when you run VRRP on VLT switches the VRRP behavior becomes an active-active state meaning that the backup-VRRP will route traffic for the VRRP-master while the VRRP-master is still up and running.

 

I hope this helps