Switches, Hubs, and Modems
cancel
Showing results for 
Search instead for 
Did you mean: 

VLANs and Trunks on 2524 & 4108gl

Doug Luxem
Occasional Visitor

VLANs and Trunks on 2524 & 4108gl

We recently installed a Netscreen 50 firewall, and configured our HP Procurves for VLANs to seperate internal traffic.

After doing this, we noticed that connectived to devices on other switches was touch and go (especially for printers for some reason). You could ping the device one minute, but then not the next. It didn't matter if you were on the same VLAN or a seperate VLAN going through the firewall. However, if you were on the same switch and VLAN as the problem device, IP connectivity worked just fine.

We are not using tagging, so all ports were configured as "untagged" under one vlan and "no" on the other. Connections between switches had vlan1 as "untagged" and vlan2 as "tagged".

Originally we thought the problem was with the Netscreen, but after debugging the traffic though it, everything looked fine. My guess is that we have something misconfigured with our VLANs and some packets are being lost in the ether.

Configuration (Netscreen 50)-
ethernet1:
vlan1
ethernet2:
vlan2
ethernet3:
[diconnected]
ethernet4:
WAN uplink

Configuration (VLANs)-
vlan1:
ID: 1
Name: INT_VLAN
vlan2:
ID:2
Name: EXT_VLAN
trunks:
VLAN1: untagged
VLAN2: tagged

Any ideas on what might be happening?

Thanks,
Doug
4 REPLIES
Mark Landin
Valued Contributor

Re: VLANs and Trunks on 2524 & 4108gl

Well this may or may not help:

We recently has some connectivity issues on our 4108s that we recently tracked down to something pretty obscure. We had just updated our 4108's to the 7.21 firmware. There are two 4108s in the stack, and we also had two 2524's in the stack. We were seeing problems with Windows XP systems (a particular h/w model from Dell) just locking up and dropping off the network.

In desperation, we took the 2524s out of the stack and things cleared up. Turns out the 2524s had REALLY REALLY old firmware. We suspect this may have caused some stacking problems which in turn caused other problems with the 4108s.

Anyway, if you are are stacking the 2524 with the 4108, at least try removing them from the stack and see if that helps at all. I know it sounds like a real stab in the dark, but it DID work for us!
Doug Luxem
Occasional Visitor

Re: VLANs and Trunks on 2524 & 4108gl

Well, we did have outdated firmware on our 4108 and on two of the 2524's (which were in a stack with the 4108).

Since we don't really using the stacking capability, I'm removing that right now and updating the firmware.

I'll post back on how it goes.

Oddly enough, we had some very odd problems with a Dell Optiplex GX240. It would randomly drop it's link. The cables tested fine, and we tried using the machine on several ports that had been working fine previously. Eventually, we found a place where it worked continuously. Maybe that's realated to what I'm seeing now.
Doug Luxem
Occasional Visitor

Re: VLANs and Trunks on 2524 & 4108gl

Well, that didn't fix my VLAN problem, but now I know exactly what is happening and what is wrong.

The problem is that the 2524's do not track MAC addresses by VLAN. When you have two VLANs connected by a layer 2 device (like my Netscreen firewall), the 2524 sometimes associates a given MAC address with the port the device is attached to (correct), and sometimes it associates it with the uplink port (incorrect) should the packet have travel through the firewall across VLANs.

The 4108gl doesn't have this problem, because it keeps track of which VLAN is sees the MAC address on, and can associate a MAC address to multiple ports (1 per VLAN).

If my firewall were routing traffic (i.e. layer 3), then I don't think I wouldn't have this problem. However, I need the firewall to operate in transparent mode (layer 2).

How to I "fix" my 2524's so that they operate like the 4108?

Thanks,
Doug
Ron Kinner
Honored Contributor

Re: VLANs and Trunks on 2524 & 4108gl

I'm not sure I understand your problem but would it help to assign static MACs?

I have also heard of problems with the arp table expiration time. ONe guy said when he set his to a longer timeout that things started working more reliably.

Ron