Select Page

If you read my previous Kaboom post, you may be wondering why I decided to post on another Dell VRTX. Well, the fact is I’ve still got a few of these out in the field, so they remain relevant to me. This is a another customer’s deployment and I just upgraded them from a single 1Gbps LAN uplink to a dual 10Gb Etherchannel/LAG link via a Cisco Catalyst 4500 standalone fiber switch. Real-world budgetary limitations preclude the possibility of having redundant LAN switches for this deployment.

Creating an Etherchannel/LAG group between the VRTX and a Catalyst switch is really simple – especially in this case since this one was just using access ports in VLAN 1.

I’ll be using LACP as a Dell engineer on the VRTX team was adamant during a previous installation that LACP is the preferred or “best practice” method. I’d personally prefer to hard-code these to ON, but since I already think that VRTX internal switching can be a bit flaky, I won’t rock the boat.  

On the VRTX side, I have the R1-2210 10Gb switch module with 4 10Gb and 2 1Gb ports. I’ll be using ports te0/1 and 2 for this bundle. On the Catalyst side, I’ll be using ports te1/15 and 16.

Here is the config:

vrtx-switch#conf t
vrtx-switch(config)#int range te0/1-2
vrtx-switch(config-if-range)#channel-group 1 mode 
  on                   Add port without LACP
  auto                 Add port with LACP
vrtx-switch(config-if-range)#channel-group 1 mode auto


VH-Core# conf t
VH-Core(config)#int range ten1/15-16
VH-Core(config-if-range)#switchport mode access
VH-Core(config-if-range)#switchport access vlan 1
VH-Core(config-if-range)#channel-group 1 mode ?
   active Enable LACP unconditionally
   auto Enable PAgP only if a PAgP device is detected
   desirable Enable PAgP unconditionally
   on Enable Etherchannel only
   passive Enable LACP only if a LACP device is detected
VH-Core(config-if-range)#channel-group 1 mode active
Creating a port-channel interface Port-channel 1

And that’s about it. The Catalyst ports were configured as trunks for data and voice VLANs, which is why I converted them to access ports in VLAN 1. 

I make it part of my process to administratively shut down any unused ports to prevent the possibility of introducing a loop and for security reasons. 

I don’t know why, but I’ve had these R1-2210s stop forwarding traffic on ALL links for 10-15 seconds if another interface is brought up that would cause STP to block a port. Shoot me a message if you’ve seen this and know the answer. Please.

From the CMC switch view, the status looks like this:

CLI port admin status can be displayed with show interface config  — output is below (after I shut down the 1Gb interfaces but before te0/3-4):