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):
Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.
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 descided 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