Multiple vlan issue with procurve switch

I have a cisco asa5505 as my rtr/fw(10.1.3.254). I have vlan 1 and vlan 3.

Vlan 1 is my default all access vlan. Vlan 3 is my Guest(dmz) vlan.

I can't seem to get a dhcp ip address when my laptop is plugged into port 42 on my procurve. I have plugged my laptop directly into the firewall and it gets a dhcp ip fine(the firewall is dhcp server). the firewall is plugged into port 41. Only vlan3 needs to go over port 41.

I'm sure I have a bonehead config problem however I'm about ready to pull out what little hair I have left.

    vlan 1
       name "Computers"
       forbid 45
       untagged 1-41,43-44
       ip helper-address 10.1.1.16
       ip address 10.1.1.1 255.255.255.0
       tagged 46-48
       no untagged 42,45
       exit
   vlan 3
       name "Guest Wireless"
       ip helper-address 10.1.3.254
       ip address 10.1.3.1 255.255.255.0
       tagged 41-42,44-48
       exit

Solution 1:

So, you're suffering from the pretty-much-universal newbie confusion between "tagged" and "untagged" traffic. We've all been there.

The term "tagged", as applied to switch ports, means "packets that go out this port for this VLAN will have a 802.1q header saying "this is a packet for VLAN <foo>", and "I will accept packets coming into this port that have an 802.1q header saying "this is a packet for VLAN <foo>". That's great, because it's the only way you can have multiple switches all "know" that packets are on the same VLAN. It's not so great, however, when you're sending packets to a device that isn't expecting it. This most commonly happens when you're plugging in a general-purpose computer, but it can also cause problems when a switch connected to that port doesn't expect the tagged traffic.

An "untagged" VLAN, on the other hand, means "packets that go out this port for this (untagged) VLAN will not have an 802.1q header, and they will look like VLANs never happened", and "packets that come in on this port will be carried on VLAN <untagged>". In effect, this looks identical to the "dumb (VLAN-free) switch" configuration, and is typically what edge devices expect.

The question you've got to ask yourself, when thinking VLANs, is "do both devices at each end of this piece of cable know that they'll be told this traffic is part of this VLAN?". If "yes", you tag it. If not, you don't.

In your case, I'm almost certain the device you've got plugged into port 42 is not expecting VLAN-tagged traffic, and thus it's discarding those packets with a quiet "WTF?" and a raised eyebrow. You can either untag that VLAN on that port, or tell the device that it should be looking at that traffic with a VLAN perspective. End-devices can usually do that, by the way; we use it to tag VLANs all the way into our VPS servers, for instance (and tags VLANs onto Linux-based routers, firewalls, load-balancers, and some end-customer devices).