XP PCs and VLAN Switching (NOT 802.1x)

[Jamsan]

We've been having a few laptops with issues where if they go to a different floor than their desk, they cannot plug into conference rooms and get network connectivity (different floors are different VLANs). There aren't any routing issues, as all traffic gets routed without issues between the VLANs on almost all occasion, except right after a user switches over.

I think it has something to do with DHCP and the fact the XP client thinking it's still in the different subnet. The DHCP server is in a different VLAN/subnet entirely, and we use helper addresses to resolve that issue. Again, DHCP works fine 99.9% of the time, except when a user switches VLANs. When performing a /release /renew, the laptop continues to get the old IP address it had from the previous VLAN. It seems like the PC is performing a DHCP-REQUEST with the old IP information, which the server is is NACKing, when it should be doing a DHCP-DISCOVERY for an entirely new IP.

Has anyone seen this issue before and what could be the cause of it? I haven't thrown a sniffer to see what the DHCP request looks like coming from the laptops when they have the issues, but will do so if it becomes a more pressing issue.

Thanks.

 

[imagoon]

You may want to use something like wireshark to see what is going on. It sounds like your DHCP server is ACKing even though the request comes from the wrong range and it should be NAKing. Is this windows? Linux? Cisco router? We would need more information to really help you. What are your scopes? Accidental mistypes in the scopes can cause range overlaps.

The computers have no idea if they are on the same range. They will typically attempt to rerequest the same IP if they are still in the lease period. The DHCP server should realize that the machine is out of range, NAK the request which will prompt the computer to start off with a brand new request.

 

[spidey07]

What is the DHCP server, software wise? A packet capture will show you what's going on. It's possible you have a rogue dhcp server?

I've also seen this when you've got one VLAN "bleeding" into another. Think of it as two separate VLANs, well you think they are separate, but somewhere/somehow they are connected to become the same broadcast domain. Could be physically connected or some configuration or native vlan mismatch.

 

[Jamsan]

The DHCP server is a Windows 2003 Server box. There are 4 scopes (one for each VLAN). Looking at the scope configurations, there are no overlaps in the IPs each scope is handing out (all scopes are created properly for the appropriate subnet/VLAN IP scheme).

It looks like I'll need to go the wireshark route to get this resolved, but before I do, I'll give a bit more information to see if anyone has any suggestions.

@ imagoon: There have been 8 NACKs from the DHCP server the past 2 days. I'll go through the logs to see which machines were NACKed to see if that would shed some light. The DHCP lease expiration time is currently set to 5 days. Is that too long of a time frame, possibly causing the issue?

@ spidey: Is there any easy way to check for rogue DHCP servers (besides doing a packet capture and seeing what IP the responses are coming from?). About the VLAN "bleeding" issue, I checked native VLANs on all trunks, and they are all the same. In doing the native VLAN check, I did notice that one of the trunk ports (on the 1st floor switches) has portfast ENABLED (big booboo). I checked the spanning-tree blockedports on this switch, and the trunk port only has blocks enabled on 2 VLANs and not all of them. I think this may be the culprit. I'll disable portfast later today and have spanning-tree re-run to see if this resolves the issue (unless of course, you don't think this is the issue).

Thanks guys.

 

[spidey07]

ipconfig/all will tell you the DHCP server. You could also use the dhcp snooping feature on the switches. I'd still look for some kind of layer2 joining going on between vlans - that will cause what you're seeing.

 

[imagoon]

Typically you want your trunks native vlans to different because what the switch determines to be "mystery packets" for whatever reason will get dumped there. If you have devices on that vlan (1 is pretty common since it is the default) You may want to enable portfast BPDUGaurd on the switches (after you fix the portfast trunks.) If any ports drop out it would indicate a network loop some place.

I would think that a pretty easy way to check for VLAN bleeding would be to ping the broadcast IP (i think windows can do that with a command line switch). Tell ping to throttle itself so you don't send trash everywhere in the process. Then look on another segment with wireshark for those pings. Also another thing to look for is arp requests that don't seem to make sense. IE if something is arping for IPs outside the proper IP network, it is an indication that you have a layer 2 bleed someplace (typically a looped cable in this case as I recall. Spidey may correct me on that one.)

 

[spidey07]

ARPs are a good place to look. Interior routing protcols will show signs as well as the router interfaces receive hellos with a source address that isn't expected - aka EIGRP NOT ON COMMON SUBNET messages or OSPF unknown neighbor. Also looking at mac address tables on switches for router interfaces - you shouldn't have an entry for a router interface on another subnet - if you do that's a sure sign of your broadcast domains not being as separated as you think they are.

vlan bleeding can be very unusual because things will generally work but weirdness shows up, specifically with DHCP or IGMP/PIM/multicast. I also don't know the official term for this, I just made up "vlan bleeding" a long time ago because broadcasts from one "bleed" into the other.

 

[imported_snikt]

From what I understand Windows Server 2003 has a tendency to assign the same DHCP IP address, even with a /release /renew. On our LAN what works to prevent/avoid this is to initiate the /release, shutdown, wait a couple of seconds, and boot back up; 99.9% of the time, the box is given a different IP address. Keep in mind we don't move PCs or laptops that often from floor to floor.

 

[imagoon]

Originally posted by: snikt
From what I understand Windows Server 2003 has a tendency to assign the same DHCP IP address, even with a /release /renew. On our LAN what works to prevent/avoid this is to initiate the /release, shutdown, wait a couple of seconds, and boot back up; 99.9% of the time, the box is given a different IP address. Keep in mind we don't move PCs or laptops that often from floor to floor.

This is by design.

The issue here is that the machines are getting the same IP in another network where the IP is invalid.