Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So the problem is we have a device or host that needs to communicate on a specific VLAN. This VLAN is not new, it is running all throughout our environment and works fine. But the VLAN was recently configured on the switch in question, a Cisco 3750. The DHCP server is handing out addresses on that VLAN with no problem.

I have verified the cable between the host and switch and tried multiple hosts, but none of them can communicate or get an address. I plugged my laptop into an empty port which had a different VLAN assigned and immediately got a DHCP address. When I changed that port to the same VLAN I'm having issues with I got the same problem. The laptop just sits there and tries to DHCP an address but nothing happens.

I double checked the cores and their Layer 3 VLAN config and its fine too. Plus I figured the issue couldn't be with them because the VLAN works fine everywhere else it exists.

So the only other thing I can think of is the switch, but the VLAN exists on the switch and seems to be configured correctly. The trunks appear to be configured just fine as well too.

Anyone have any ideas? I'm lost on this one.

share|improve this question
3  
Please post configuration info for vlan in question. it's hard to troubleshoot without seeing the actual configuration. –  solefald Apr 22 '10 at 16:39
1  
Config of VLAN on both ends was fine. The issue was we have switches daisy chained and I forgot about this, I'm new to this facility, and one of the down stream switches wasn't trunking the VLAN. Another reason to NEVER daisy chain switches together. –  Webs Apr 22 '10 at 17:57
1  
Daisychaining switches can be fine, as long as you remember to set up the right config on the chained ports. –  Tom O'Connor Apr 22 '10 at 18:10
    
i don't see anything wrong with daisy-chaining switches. I had to do that at my old job where the boss refused to spend money on anything larger than 24 ports, yet we had to plug in about 100 machines with 4 interfaces each. –  solefald Apr 22 '10 at 19:09
1  
Daisy Chaining switches is a horrible idea because if the first switch in the chain goes out, all the rest do too. The switch doesn't even have to die, there are others scenarios as well. Not to mention it makes troubleshooting so much more difficult. If you need to track down a troublesome client it can take longer and be more difficult since that client MAC will exist on every access layer switch in the chain. Yes it is more expensive to have a hierarchical model, but there are huge payoffs to having it. Very few professional networks are daisy chained and there is a reason for that. –  Webs Apr 24 '10 at 15:06
add comment

2 Answers

up vote 1 down vote accepted

Problems like these can eat up a lot of time.

(I noticed after I wrote this I was assuming you have one DHCP server on a separate subnet, and therefore DHCP requests are forwarded across a router. Troubleshooting will be simpler if the DHCP server is directly on the new VLAN.)

Off the top of my head, from most- to least-likely:

  • the tagging isn't correct through the switch network
  • the router that connects the VLANs in question doesn't have an IP interface on the new VLAN and/or isn't configured to route packets between them
  • whatever is acting as the router between the dhcp server and the dhcp client doesn't have the 'ip helper-address' or 'udp-helper' parameter set correctly so dhcp requests never make it to the dhcp server
  • the dhcp server doesn't have a route back to the router that acts as the gateway to the VLAN in question, possibly because the dhcp server's default gateway doesn't know how to get to the gateway
  • the dhcp server's configuration file(s) has/have been updated to serve the new VLAN, but the dhcp server wasn't restarted (if you have an ISC (ie linux) dhcpd)
  • something in between the dhcp server and the client on the new VLAN has an ACL which is preventing connectivity

In your case, I would back up a couple of steps:

  • Make an itemized list of all ports on all switches that should be involved in this new VLAN. They are probably mostly trunk ports going switch to switch. Now check the VLAN association and state (tagging, default-VLAN if appropriate) of each of them. Yes I know they are all right but humor me.
  • anything interesting in the dhcp server's logs?
  • plug in a computer on the new VLAN with a static IP address. Can it ping the router? Can it ping the dhcp server? (If you can't -- is the dhcp server firewalled to drop icmp packets?)
  • plug in a dhcp computer on the new VLAN. Snoop the traffic (wireshark or equiv). What does the dhcp conversation look like? Are you seeing any replies back from the dhcp server?
  • snoop the traffic on the dhcp server. What does the conversation look like?

Hopefully while working through a list like this you might trip over what's really wrong.

share|improve this answer
    
Thanks for the answers, but I solved my problem. Check out the comments above. –  Webs Apr 24 '10 at 15:07
    
Daisy chaining... heh. I was right. :) –  David Mackintosh Apr 25 '10 at 1:10
add comment

If you're using VTP to configure the VLAN configuration, make sure that the revision number of the new switch is not higher than the VTP server, as it will ignore VTP updates from the server if it has a higher revision number.

If the switch came from the same production environment and uses the same domain and password, this may be the case, and you could have glanced over the small differences from the configuration the VTP server uses.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.