VLAN Troubles

Mailman List Mirror (Read Only)
1

I hope everyone is having a better workday so far than I am.

I am trying to clean up the network for the Hospital I work for, and
part of that is creating two VLAN's for two separate subnets on our
network. Before, it was not separated by VLANs. We are also replacing
our aged Juniper firewall with an ASA.

I'm very new to VLAN's, so I am hoping this is something simple that
you guys can help me out with.

We have two switches that do not seem to be passing VLAN traffic. The
two switches are a Dell Powerconnect 5324 & a Cisco 3560G. The Cisco
switch appears to be functioning fine, but the Dell switch is only
passing traffic to the Cisco that is on the default untagged VLAN1.
Our second VLAN is not getting passed to the Cisco at all, I am not
seeing any packets tagged with the particular vlan in Wireshark.

I have Port 1 on the Dell switch connected to port 29 on the Cisco
switch, and port 1 on the Cisco switch connected to the ASA.

I have the following config on the relevant ports on the Cisco switch:

interface GigabitEthernet0/1
description ASA 5505
switchport trunk encapsulation dot1q
switchport mode trunk

interface GigabitEthernet0/29
description Radiology Switch
switchport trunk encapsulation dot1q
switchport mode trunk

Here is the config for the Dell switch:

interface ethernet g1
speed 1000
duplex full
exit
interface ethernet g2
speed 1000
duplex full
exit
interface ethernet g3
speed 1000
duplex full
exit
interface ethernet g4
speed 1000
duplex full
exit
interface ethernet g5
speed 1000
duplex full
exit
interface ethernet g7
speed 1000
duplex full
exit
interface ethernet g9
speed 1000
duplex full
exit
interface ethernet g10
speed 1000
duplex full
exit
interface ethernet g12
speed 1000
duplex full
exit
interface ethernet g14
speed 1000
duplex full
exit
interface ethernet g15
speed 1000
duplex full
exit
port jumbo-frame
interface ethernet g1
switchport mode trunk
exit
interface ethernet g24
switchport mode trunk
exit
vlan database
vlan 12,22
exit
interface range ethernet g(2,4,7,12,14-15)
switchport access vlan 12
exit
interface vlan 12
name Radiology
exit
interface vlan 22
name Guest
exit
interface vlan 1
exit

Anyone have any ideas or pointers? Is there more information that I
need to provide? Vlan1 works just fine, of course. It is Vlan 12 that
is not working. Everything on the Dell switch is communicating with
each other just fine on the same subnet.

2

Thank you for the suggestions, unfortunately none of them are working.

I have tried with the uplink in general & trunk mode. I have allowed
all vlans and allowed only the specific vlans I am using tagged and
untagged, but it is still not passing vlan 12.

3

Verify what protocol the dell switch uses to tag the traffic(from the
datasheet) , i have seen some switches that wont trunk .1q with cisco

4

yep , verify how dell tags the vlans , it may use a proprietory tagging
method for the trunk.

5

On the cisco, do a 'show interface trunk'. Be sure that it thinks it's supposed to pass those VLANs. Make sure "Vlans allowed on trunk" includes the VLAN. Same for "Vlans allowed and active in management domain". Then the important one is "Vlans in spanning tree forwarding state and not pruned". If it's not there then it's being pruned. Also on your Dell uplink add the following line to the uplink port:

switchport access vlan add 12,22

See what that does for you.

6

Why don't you replace the Dell switches with Cisco 3560s, and that way you
are working with a single implementation of the IEEE 802.1q trunking
standard? I think the very existence of this email thread proves that much
time and effort is wasted in the attempt to seamlessly interoperate devices
from multiple vendors. In this email thread alone I counted 2 CLI's to be
learned, 2 tech support organizations to call, and 2 hardware types to
spare.

David

7

+1 on show interface trunk, which will probably tell you that only vlan 1 is allowed on your trunk interfaces.

I find it easy to forget that a Cisco switch will not pass tagged traffic for a vlan if that vlan isn't created on the switch. Even if you do something like "switchport trunk allow vlan 12" on a trunk port, it won't create the vlan on the switch unless you specifically create it or you add it to an access port like "switchport access vlan 12".

Jason

8

There's Heaven, where IT has an unlimited budget and management understands the reasoning you state below.

And there's reality, where IT is a cost center, has to beg for every penny spent, and often times has to make do with what they have.

Besides, how much fun would it be if everything was clear-cut and easy?

Jason

9

"show vlan" will tell you if the VLAN has been created on the Cisco.

The config to create it is easy (and necessary):

!
vlan 25
name Radiology
!

Aled

10

Just wanted to say a quick thank you to everyone who chimed in. Like I
thought, it turned out to be something very simple and routine. I had
not added the vlan to the Cisco switch. I had added it during testing,
but I removed all testing config from the switch before I went to
vlan's and did not add it back.

On top of that, right before I saw the message to run sh vlan, I
attempted to upgrade the firmware on the Dell switch and followed
Dell's instructions to the T, but it appears that the switch is now
non-functional. It is in a continuous reboot cycle and I can't even
get anything over the console.

Thankfully I had another switch ready and swapped it out and we are
running strong with vlans.

Again, thank you so much for all of your help, and hopefully one day I
will be at the level to help someone else out on here.

11

It is best to configure the Dell using the Web interface on it.
You will have to use IE to access it , (need less to say it also needs a management interface '[).

I find the CL to be a bit confusing , but that is me....

Speaking only for the Dell Side config.
Comparing your config to some of my Dell Switch setups...

You seem to be missing... (similar)

12

If it's still not working, try capturing traffic from the Dell switches with Wireshark and then send traffic from the Cisco switch and also capture that. Compare the frames and check that the salient parts line up - e.g. Ethertype.

Jonathon

13

He already posted his response of getting it working.

But in general, Dell switches interop just fine with Cisco and Juniper
switches for VLAN trunking. The CLI on the Dell switches is a royal
PIA to use. Tries to be Cisco IOS, but not quite. Different enough to
make you sware at it. And if you want to do something like setup many
VLANs trunked to different port groups, and single ports, your config
will be 1000's of lines long (depending on which switch you
have. Since each of the different revs of each families seems to be
made by a different OEM, or some new code base from a few OEMs).

14

cool!

15

We have two switches that do not seem to be passing VLAN traffic. The
two switches are a Dell Powerconnect 5324& a Cisco 3560G. The Cisco
switch appears to be functioning fine, but the Dell switch is only
passing traffic to the Cisco that is on the default untagged VLAN1.
Our second VLAN is not getting passed to the Cisco at all, I am not
seeing any packets tagged with the particular vlan in Wireshark.

I have Port 1 on the Dell switch connected to port 29 on the Cisco
switch, and port 1 on the Cisco switch connected to the ASA.

I have the following config on the relevant ports on the Cisco switch:

<snipped>

Anyone have any ideas or pointers? Is there more information that I
need to provide? Vlan1 works just fine, of course. It is Vlan 12 that
is not working. Everything on the Dell switch is communicating with
each other just fine on the same subnet.

I can confirm similar issues between our older Dell Poweredge 1655 and a Cisco 3550. Took me a while to figure this one out, considering the aggro trunks weren't working right either. Switching it to etherchannel solved the trunking issue, but I still had some major issues with VLANs even after that.

I have yet to move the 1655 (since we still use it for lab purposes) to the 6503.

I hate to put it this way, but I'd love to know what crack Dell was doing when they decided to use the software/hardware switch stuff they did.

16

I can confirm similar issues between our older Dell Poweredge 1655 and a
Cisco 3550. Took me a while to figure this one out, considering the
aggro trunks weren't working right either. Switching it to etherchannel
solved the trunking issue, but I still had some major issues with VLANs
even after that.

I have yet to move the 1655 (since we still use it for lab purposes) to
the 6503.

I hate to put it this way, but I'd love to know what crack Dell was
doing when they decided to use the software/hardware switch stuff they did.

I don't think the 1655 and the 5324 share ancestry.

Dell does what lots of companies do: they outsourced. The Dell 5_2_24
was a catastrophic device that was based on the same hardware platform
as the Foundry Edgeiron 24G and the SMC 8624T, 3Com's 3824 ... the
only difference in many cases being paint and firmware. All of these
were actually made by Accton, who sold it as the ES4624, and the early
revisions had a catastrophic failure mode that would result in the two
halves of the switch losing communications with each other, or something
like that, hopefully I'll be forgiven for the technical handwaving, and
eventually firmware workarounds "fixed" the switch, but (I think?)
Foundry led the pack on that, and so you'd come across Dell gear with
Foundry firmware or stuff like that, done by people desperate to stop
their switches from going wonky every few weeks.

I don't think I ever did identify the source of the 5324 fully, I think
I concluded that it was somewhat unique to Dell. It lacked most of the
other quirks common to cheap switches like the Accton (broadcast domain
issues, anyone?) and was, at the time, probably one of the best deals in
managed switching. It only had a few goofs that I could complain about,
including the lack of 64-bit interface counters and the Ciscoesque-but-
not-quite syntax. For the most part, I've heard that their newer
products are pretty good too, though usually there are tradeoffs.

obDisclosure: We run a bunch of 5324's, and don't seem to have any
issues with them.

... JG

17

Funny, it's always the Cisco devices that seem to be the cause of
interop problems in my network. They're the only vendor that seems to
think defaulting proprietary protocols is reasonable. Cat 3ks default
to proprietary Rapid-PVST+, proprietary VTP, proprietary DTP,
proprietary HSRP, and proprietary ISL tagging. And Cisco documentation
generally recommends these proprietary protocols or at least documents
them *before* the standard equivalents (wonder why?). Cisco does of
course generally support the IEEE or IETF protocols, but not without
configuration that often requires downtime or at least a spanning-tree/
OSPF event if it was missed before deployment.

We can lash together Dell/HP/other switches all day long with near-
default configurations, but every time we have a new Cisco box to
configure it's required to wade though IOS release notes to see what
new proprietary protocol we have to disable.

Cisco makes good gear with lots of features, but can be a royal pain
if you use *anything* non-Cisco. It's not prudent to rely on a single
vendor for anything, and it's not as though IOS is a magically bug-
free bit of code.

I've been told that in at least some high-frequency trading networks,
the redundant switches/routers at each tier are intentionally from
different vendors, so that a software issue in one won't take
everything down. That seems like a good idea at first, but it wouldn't
surprise me to have an interop issue or mis-configuration caused by
unfamiliarity take down both devices. Does anybody out there do this?

18

I don't think the 1655 and the 5324 share ancestry.

I'm pretty sure they don't either, but never know.

Dell does what lots of companies do: they outsourced. The Dell 5_2_24
was a catastrophic device that was based on the same hardware platform
as the Foundry Edgeiron 24G and the SMC 8624T, 3Com's 3824 ... the
only difference in many cases being paint and firmware. All of these
were actually made by Accton, who sold it as the ES4624, and the early
revisions had a catastrophic failure mode that would result in the two
halves of the switch losing communications with each other, or something
like that, hopefully I'll be forgiven for the technical handwaving, and
eventually firmware workarounds "fixed" the switch, but (I think?)
Foundry led the pack on that, and so you'd come across Dell gear with
Foundry firmware or stuff like that, done by people desperate to stop
their switches from going wonky every few weeks.

Ah yes, the EIF24G. I have two of the -A models here and a pallet of them in a warehouse.

I know exactly the failures you are talking about - in our case, we got the switches with QC tags stating "Dead ports". A firmware update and the ports magically came back and started working again. Originally figured an ASIC or similar had gone south and taken out a group of ports.

I'm actually pretty happy with the switches, they're pretty durable and we've got the two at home acting as the 'edge' switches for things like the HTPC, NAS, DirecTV receivers, etc.

Before we needed the extra ports, had the foundry 10GCF which has a similar less then stellar history. Mess of a witch, but it held up well for 2 years until the EIF24G-As came.

I believe both the 10GCF and the EIF24G's are of the same vintage of Accton hardware.

I don't think I ever did identify the source of the 5324 fully, I think
I concluded that it was somewhat unique to Dell. It lacked most of the
other quirks common to cheap switches like the Accton (broadcast domain
issues, anyone?) and was, at the time, probably one of the best deals in
managed switching. It only had a few goofs that I could complain about,
including the lack of 64-bit interface counters and the Ciscoesque-but-
not-quite syntax. For the most part, I've heard that their newer
products are pretty good too, though usually there are tradeoffs.

obDisclosure: We run a bunch of 5324's, and don't seem to have any
issues with them.

I got a bit... frustrated with the switch modules on the 1655 many times. CLI makes me want to puke. Would get into a wonky state, and I had to factory reset it via the web ui. Finally just gave up with the CLI and used the web ui to configure it.

19

I've never had problems setting up multiple VLANs on a link between
Cisco, HP, Dell switches, IBM mainframes, VMWare servers, 3COM/Nortel,
Polycom Phones, Linux servers, etc. If both ends supported 802.1q, it
just worked, if the admin read the manual for both pieces of gear and
knew how to troubleshoot problems.

Sure, one vendor can be nice a lot of the time - even cheaper once
support costs are factored in. But making VLANs work between
different vendor's equipment is a pretty basic networking skill. So
I'm kind of astonished at the "sell what you have and buy new from one
vendor" responses.

I've not used the specific Dell switches mentioned, but I've used
others and have plenty of opinions on the management interface of
them. But for a wiring closet or top of rack switch, I can't say that
I would suggest to replace them with something new just because I
wanted a different management interface (that said, I very well might
write some scripts to manage the uglier interfaces).

20

We have two switches that do not seem to be passing VLAN traffic. The
two switches are a Dell Powerconnect 5324 & a Cisco 3560G. The Cisco
switch appears to be functioning fine, but the Dell switch is only
passing traffic to the Cisco that is on the default untagged VLAN1.
Our second VLAN is not getting passed to the Cisco at all, I am not
seeing any packets tagged with the particular vlan in Wireshark.

I have Port 1 on the Dell switch connected to port 29 on the Cisco
switch, and port 1 on the Cisco switch connected to the ASA.

I have the following config on the relevant ports on the Cisco switch:

interface GigabitEthernet0/1
description ASA 5505
switchport trunk encapsulation dot1q
switchport mode trunk

interface GigabitEthernet0/29
description Radiology Switch
switchport trunk encapsulation dot1q
switchport mode trunk

Have you verified VLANs 12 and 22 are actually defined on the Cisco?

vlan database
vlan 12,22

Antonio Querubin
e-mail: tony@lavanauts.org
xmpp: antonioquerubin@gmail.com