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:
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
vrtx-switch(config-if-range)#
Catalyst:
VH-Core# conf t
VH-Core(config)#
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)#
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
VH-Core(config-if-range)#
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):
Unfortunately I didn’t see that post until at least 18 months later due to time constraints and issues with my web hosting. I mentioend earlier in the post that I thought this internal switch from Dell was “flaky”. Well, after another issue with one of these VRTX switches and another dealing with a failure and making the rounds with Dell support I decided that the VTRX is/was just simply a bad product. Too bad, because it should have been great.
Hi, Great Post, hope i am not too late and you are still checking this port. i believe i am having the issue you are referring to :
stop forwarding traffic on ALL links for 10-15 seconds if another interface is brought up that would cause STP to block a port.
we have the same setup except the Cisco switches are 3780 and the VRTX switch uplinks ports (10 GB) are set to Trunk.
Thank you very much for your help