Solved

Sometimes no DHCP reply > switch problem ?

Posted on 2014-04-25
115
381 Views
Last Modified: 2015-08-03
Hi,

Weird problem here ... some of my machines, at times, don't immediately get an IP address after booting (and thus can't find the AD etc). Even if connected to a port on the switch directly! While it works fine, at the same time, for others. I've tried to exclude several things and it *seems* like the switch, or some ports on the switch, are the problem?

I've got the following errors on some ports on the switch (HP ProCurve 4204):

- excessive broadcasts
- high collision or drop rate
- excessive CRC/alignment errors

Could any of those be the cause for those connectivity problems?

Thanks a lot!
0
Comment
Question by:Xeronimo
  • 62
  • 25
  • 23
  • +1
115 Comments
 
LVL 9

Expert Comment

by:Red-King
ID: 40022212
The excessive broadcasts could signify a broadcast storm.
I'd be concerned about the High Collision/Drop Rate. Have you connected directly to the switch using a known good cable and still gotten this error?

I'd suggest running a packet capture from a connected machine and looking at the results. Wireshark is a great tool if you're not aware of it.

Have a look for where all these broadcasts are coming from.
Also, I'd check for a rogue DHCP server (wifi router?) that might be sending out the wrong network details.

It would also be worth going over your cabling if possible and checking for any network loops (though spanning tree should take care of that in most circumstances iirc).
0
 

Author Comment

by:Xeronimo
ID: 40022436
Ok, thanks. I'll have a look at those ... I'll report back later then.
0
 
LVL 44

Expert Comment

by:Darr247
ID: 40025835
I suggest using the 'bootp' Display filter in Wireshark, to limit extraneous broadcasts.
e.g.OPPO BDP-83 DHCP request (click for larger)
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40026250
Do you have storm control enabled on your switch?
0
 

Author Comment

by:Xeronimo
ID: 40026723
On Friday I updated the switch to its newest firmware ... no errors since then ... let's see if it stays this way when more computers are switched on again.
0
 

Author Comment

by:Xeronimo
ID: 40034125
Seems the firmware update has solved the problem!
0
 

Author Comment

by:Xeronimo
ID: 40036588
Noooooo ... the problem has reappeared! Even though there are still no errors in the switch's log. so the problem seems to be on the level of the AD after all ... ?
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40036794
Did you ever get around to checking what's going on with Wireshark?
0
 

Author Comment

by:Xeronimo
ID: 40036820
How exactly would I use Wireshark? Should I run it on the DHCP server? Or a PC? But the problem does not happen at a regular interval ... sometimes it works, sometimes it doesn't. And then suddenly it works again ...
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40037027
Wireshark is essentially a piece of software that looks at the traffic on your network card and shows it to you.
So you run it on your PC you see only what your PC gets. Run it on the DHCP server and you see what the server sees. To get a more complete picture you run it on both at the same time and do a release/renew on the PC.
Of course, that doesn't work when you're booting up the PC ... at least you cant have it running on the PC obviously, only the server. To capture whats happening at booth up you'd need to run a second PC and set up port mirroring on the switch.
If you need a better explanation on that just ask.

So what Id recommend you is do start up a PC and check that it works. If not, check its IP settings and ensure it conforms to your DHCP range.
If it does work, close down as many programs as you can that might be running in the background.
Start Wireshark on both the PC and server.
Select the network connection you're going to monitor and start the trace.
Type bootp into the filter field and hit enter on both machines.
Now, on the PC repeat these 3 steps a bunch of times:
* ipconfig /release
* ipconfig /renew
* ipconfig
Hit Stop on both Wiresharks (otherwise the trace file will eventually fill the available memory and the program will crash)
Now, you should be able  to look back through the DHCP conversation on each end and look for anything strange (such as a a DHCP NAK)

Rory
0
 

Author Comment

by:Xeronimo
ID: 40037043
Thanks but the problem is that if the PC gets an IP address then everything works smoothly and I don't need to use Wireshark?

But if the PC does not get an IP address then I can't use Wireshark either? But it's at that point in time that I'd need to know WHY the PC doesn't get an address?

But the DHCP NAK reminded me of something ... If I look up the stats of my DHCP server then I've got 20478 Acks, 57 Nacks and 2 Declines ... I guess the latter two aren't good?
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40037124
The odd decline or NAK isn't an issue.

As long as you have an enabled and active network connection Wireshark will be able to monitor it.
But the point is to repeatedly do the release and renew of the IP address to try and force the issue to occur and then, if it does occur, that you have the communication captured with Wireshark so that you can review i.e. control the point in time it happens and investigate the 'why'.

I guess we can take this back a few steps and establish some facts;
What is the IP range, router and DNS that your DHCP scope is using?
When the issue occurs, what (if any), are the IP details of your network connection?

Rory
0
 

Author Comment

by:Xeronimo
ID: 40037130
Range: 192.168.2.50-192.168.3.200
Router: 192.168.2.1
DNS: 192.168.1.5, 192.168.1.93
Netmask: 255.255.248.0

When the issue occurs then the network connection gets a default (by Windows?) address ... I don't remember the exact number right now but it's the default and always the same.
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40037268
That's a Link-Local address, starting with 169.254. It's a feature that allows you to connect devices to a network and communicate without the need for a DHCP server. It's a random address assignment.
That rules out another DHCP server on the network such as a wifi router under somebody's desk.

Next I'd look at the DHCP server, check for any errors or warnings in the Event Viewer.
See if there's anything about the scope being full.

One thing to point out about your DHCP scope, You've used a Private Class C Network with a Class B subnet mask.
While this generally shouldn't cause a problem I'd keep it in the back of your mind.
Any address starting 192 up to 223 is a Class C address and is expected to have a subnet mask of 255.255.255.xxx. Some devices might automatically assume the your 192.168.2.x IP address are in a different network to the 192.168.3.x or 192.168.1.x addresses.
This could cause a problem like this: A device in 192.168.2.x might send a packet to the router if it is going to 192.168.3.x. The router see's that the packet was received on the same interface as the destination and so drops the packet. The device with IP 192.168.3.x never receives it's packet and 192.168.2.x tries again before giving a timeout.

Now that won't always happen because the manufacturer would need to strictly adhere to the Classful Networking and not allow you to apply CIDR addressing. Just keep in mind that there's the potential for an issue.

For reference: http://en.wikipedia.org/wiki/Classful_address
0
 
LVL 44

Expert Comment

by:Darr247
ID: 40037369
It doesn't matter on which computer (that's connected to the segment; broadcasts are typically filtered at routers) you run Wireshark... bootp messages are broadcasts, so they are 'seen' by every device connected to the LAN segment.

There are a series of 4 free quick-start videos made by Laura Chappell (author of Wireshark Network Analysis) for using Wireshark that you can watch online or download and watch offline.
They're located at https://lcuportal2.com/wireshark101.html
Note the downloadable files are listed in reverse order...  if you download them to watch offline, I suggest renaming them like
1-101placementelements.flv
2-101profilescfilters.flv
3-101coloringrules.flv
4-101chartsgraphs.flv
so they are listed in sequential order when sorted alphabetically.
0
 

Author Comment

by:Xeronimo
ID: 40043704
Red-King: regarding the classes ... I didn't know that. But I also never had problems with it ... and the DHCP problems only appear temporarily, from time to time ... I see now pattern ... except that it's, obviously?, after the (re)booting of a workstation (and seemingly only in one of our three buildings but even there not everyone is 'afflicted') ... I really don't know how to trace or troubleshoot this ...

The scope of the DHCP is not full yet.

The only other weird thing about my DCs is that I sometimes can't connect to them through 'DomainManagement', like right now ('the RCP server is unavailable') ... but I can ping and even remotely connect to them!? Could that be part of the problem?
0
 

Author Comment

by:Xeronimo
ID: 40043828
I'm also testing with Wireshark now ... Everything worked fine with my test laptop, I have to wait now for the others to experience the problem again and then immediately try to trace it on Wireshark.

Will keep you updated.

Thanks so far!
0
 
LVL 44

Expert Comment

by:Darr247
ID: 40045069
> regarding the classes ... I didn't know that.
Classless Inter-Domain Routing (CIDR) was in RFC1519 (which obsoleted the Supernetting described by RFC1338), so classful routing has been obsolete for 20+ years. The only reason classful routing hung around so long was because of Microsoft's broken TCP stacks, which didn't properly honor CIDR until Win7 (and SP1 of Server 2008), even though RFC1519 was published 2 years before the release of Win95 (the first version of windows to come with a TCP stack).
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40045151
Can you provide the switch config, and tell us which port the DHCP server is connected to please?
0
 

Author Comment

by:Xeronimo
ID: 40049597
Hi, here's the config file. What's slightly weird is this line?

dhcp-snooping authorized-server 192.168.1.5
dhcp-snooping authorized-server 192.168.1.93

192.168.1.5 is the only active/current DHCP server. Seems like the 192.168.1.93 is still stuck somewhere though ... ? That might explain the occasional situations where some people don't get an IP address via DHCP?

I can't tell you right now on which port the VMWare host on which the DHCP server runs upon is connected to ... it's on one of the following: D13-D24.
config1.txt
0
 

Author Comment

by:Xeronimo
ID: 40049634
Ok, so for some reason the 192.168.1.93 was still an 'authorized DHCP server'!?
I've unauthorized it (again?) now. Let's see if that helps ...
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40049799
To be honest the dhcp-snooping line doesn't really matter unless the 1.93 DHCP server is giving bad DHCP info out, or the scope is depleted on that server.  Really you should remove the line from the config so that only 1.5 is authorized to pass DHCP info to clients, but it's not going to cause this issue.  The dhcp-snooping authorized-server command only tells the switch which DHCP servers are allowed to give info to clients; it doesn't tell the switch where to send DHCP requests.  That's the job of the ip helper in a L3 switch or router.

Can you post the following outputs please...?

show dhcp-snooping
show dhcp-snooping stats
0
 

Author Comment

by:Xeronimo
ID: 40049922
show dhcp-snooping results in 'No'
show dhcp-snooping stats has '0' in each 'count'
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40049952
Does the DHCP server only have the 192.168.1.5 interface or does it have any other interface?
If the DHCP server has any other IP, that's not listed as a 'dhcp-snooping authorized-server', the switch may be sending a DHCP NAK to your desktops whenever it sees the other IP address.

Rory
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40049969
So DHCP snooping isn't even enabled.  That means all dhcp-snooping config is irrelevant.

I'd doubt it's your switch then.

- What version of Windows Server are you running on your DHCP server?
- How many clients are trying to get an IP address at the same time?
- When a client fails to obtain an IP, how long does it take to successfully receive one?
- Is there anything in the client's system log when the DHCP request fails?
- Does this affect clients who already have a lease?  What I mean is, do clients suddenly get a different lease before their current one has actually expired?

I'm going to go out on a limb here though and suggest that based on...
The only other weird thing about my DCs is that I sometimes can't connect to them through 'DomainManagement', like right now ('the RCP server is unavailable') ... but I can ping and even remotely connect to them!? Could that be part of the problem?
...and...
the VMWare host on which the DHCP server runs upon
...we may be looking at a VMWare networking or resource issue.
0
 

Author Comment

by:Xeronimo
ID: 40050000
Hi craig,

Should I enable dhcp snooping then (regardless of the actual topic of this thread)?

- What version of Windows Server are you running on your DHCP server?
Windows 2008

- How many clients are trying to get an IP address at the same time?
At the same time? Only a handful. We've got 60 workstations at a whole but they don't all start at the same time.

- When a client fails to obtain an IP, how long does it take to successfully receive one?
Up to an hour. Then, suddenly, the client gets one. It seems though that it only affects clients connected to this switch. Or at least it's only them who complain to me about not being able to log on ... But I doubt other people are experiencing the same and not telling me about it.

- Is there anything in the client's system log when the DHCP request fails?
It says that no DCs could be contacted but I guess that's because it didn't get an IP address by the DHCP server?

- Does this affect clients who already have a lease?
No, if you have one already it seems that you're good ...

- What I mean is, do clients suddenly get a different lease before their current one has actually expired?
No, I don't think so.

- ...we may be looking at a VMWare networking or resource issue.
You mean I should try to use a separate virtual network for this server?
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40050036
I would leave DHCP snooping off if it's not enabled - otherwise it'll be hard to troubleshoot.

Ok so a handful of clients should be easily serviceable by a VM even if it's using the bare minimum resources required.

How many switches do you have, and how are they all connected?  Is the DHCP server is connected to the same switch as you're seeing the problem on?

How many guest VMs do you have using the same NIC as the DHCP server?  I would try assigning a dedicated NIC to the DHCP server if you can, but put it on the same virtual network.
0
 

Author Comment

by:Xeronimo
ID: 40050067
I've got 4 different switches (in 4 buildings) they're connected via fiber.

The DHCP server is connected to the same switch as the workstations that sometimes experience DHCP problems. The DHCP server delivers IP addresses to the workstations connected on those other switches too though. But they don't seem to experience the same problems!?

The NIC gets shared by 7 VMs.

I've put the DHCP server on a different vSwitch (which refers to a different NIC) ...
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40050097
I've put the DHCP server on a different vSwitch (which refers to a different NIC) ...
Ok so let's keep an eye on that and see how it goes.
0
 

Author Comment

by:Xeronimo
ID: 40060935
So far, so good ... at least it seems that way right now
0
 

Author Comment

by:Xeronimo
ID: 40063846
Update: still the same problem! :(

And when it happens it seems to usually be between 7 and 8 in the morning (although that's maybe simply because they start their PCs at that time) ... which is kind of annoying since I only start at 8 and can't immediately run a Wireshark scan when the problem happens ...

Any other suggestions as to how I could identify the problem?

And it really seems to only affect people whose PCs are connected to that switch. PCs on different switches (who use the DHCP server on that 'problematic' switch though as well) don't have any login problems ...

I found something weird(?) though in the application event log of the DHCP server: "Certificate enrollment for Local system failed to enroll for a DomainController certificate from serv-test.xxx.local\serv-test.xxx.local (The RPC server is unavailable. 0x800706ba (WIN32: 1722))."

serv-test is not a domain controller though!? or am I misunderstanding something?
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40064253
And when it happens it seems to usually be between 7 and 8 in the morning
Any other suggestions as to how I could identify the problem?
Get to work earlier?? :-)

All jokes aside..

I found something weird(?) though in the application event log of the DHCP server: "Certificate enrollment for Local system failed to enroll for a DomainController certificate from serv-test.xxx.local\serv-test.xxx.local (The RPC server is unavailable. 0x800706ba (WIN32: 1722))."
...just means that serv-test.xxx.local is a CA and the DHCP server is trying to obtain a certificate from that CA.  It's unrelated to this issue in general.

However it begs the question...

If serv-test.xxx.local is a server on your network which couldn't be contacted because the RPC server is unavailable, is there a network issue between these two servers?
0
 

Author Comment

by:Xeronimo
ID: 40064360
Get to work earlier?? :-)
All jokes aside..
I would have to come earlier every day then since the problem does not arise everyday ... ;) But that's not really an option.

As for the RPC thing, I actually have a question regarding it here on EE: http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Windows_Server_2008/Q_28424668.html

Maybe those two problems are actually connected? One of my two DCs is also the DHCP server.
0
 

Author Comment

by:Xeronimo
ID: 40069474
No more comments?
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40070860
I don't think the DHCP and DNS issues are related at first glance of the other question.  A network diagram might help us to understand how things are connected and where they sit.
0
 

Author Comment

by:Xeronimo
ID: 40077291
Update: so the problem appeared today when I was at work. I immediately connected my laptop to that network segment and started Wireshark. I saw that the PC was asking for an IP address but didn't get one. That lasted for about half an hour, resulting in about 30 bootp lines in the log where the PC unsuccessfully requested an address. Then suddenly he got one!?

I saved the Wireshark data but apparently there was a problem because now it tells me that it can't open the data because the file is incomplete or something like that ... also it seems to have saved (or tried to save) all the packets in that file, not just the bootp ones ... Unfortunately I didn't take a screenshot before saving :/

No errors on the server-side (where I had Wireshark running too), at least not in the bootp logs.

Any new ideas ... ? Thanks!
0
 
LVL 44

Expert Comment

by:Darr247
ID: 40079468
Did you bother watching Laura Chappell's videos that I recommended in http:#a40037369 ?

One of the things she covers in the early classes is using multiple capture files, and ring buffers... because the View filters don't stop capture of the other data, and if you capture for any length of time you could end up with a couple GB cap file if you don't use multiple files with a limit on their size.
0
 

Author Comment

by:Xeronimo
ID: 40079820
Not yet ... I'll watch them now.
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40079831
Can you run wireshark on the DHCP server at the same time?  If you're not seeing a response you need to establish whether the DHCP server actually saw the request or not.
0
 

Author Comment

by:Xeronimo
ID: 40079835
I had Wireshark running on the DHCP server at that time ... How would I recognize the request as coming from the PC that apparently doesn't get an answer from the DHCP server?
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40079843
Was there simply no response to the client DHCP packets?
You can filter on MAC address using the filter "eth.addr == 00:00:00:00:00:00"

If you look into the contents of a captured line in Wireshark you can expand the different elements of the packet.
You can then right click on a particular element and choose "Apply as Filter -> Selected"
0
 

Author Comment

by:Xeronimo
ID: 40079846
On a side note: is it possible (and if yes, how) to create a script on a Win7 machine that will do an ipconfig/release and then an ipconfig/renew every 2 minutes or so?
0
 

Author Comment

by:Xeronimo
ID: 40079850
Red-King: you mean 'no response' on the DHCP server's side?

and right now everything works fine again so I have to wait until it breaks down again to capture the traffic ...
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40080077
Yes, exactly. The client sent the DHCP request and the server never responded at all?
That's the impression I've gotten but I just wanted to be explicit about it for clarity.

You may want to review the DHCP log file located in %windir%\System32\Dhcp of the server.
The log file doesn't tend to be very detailed but it may have something in there.

One other thought that occurred to me is that the server may temporarily stop listening on the IP and TCP ports. This is probably not the issue but worth checking to tick the box.
In the DHCP management console, if you right click the server and select "Add/Remove Bindings..." you'll see IP addresses that the server is listening on marked by a check box.
Now from an admin command line run "netstat -a -p UDP"
You should have 2 lines in the results showing
 UDP    192.168.1.5:67           *:*
 UDP    192.168.1.5:68           *:*

Open in new window

When you get notified of the issue again you can run the command again but this time with the number 1 appended to the end which will reissue the command every second i.e. "netstat -a -p UDP 1"
You want to be sure that the server has ports 67 and 68 open constantly.

Rory
0
 

Author Comment

by:Xeronimo
ID: 40080307
Red-King:

I've checked the dhcp log from yesterday and the only weird stuff I found was stuff like this:

15,05/20/14,07:02:52,NACK,192.168.178.27,,64B9E885F167,,0,6,,,
15,05/20/14,16:52:05,NACK,172.16.10.155,,ACCF5CB8530A,,0,6,,,

Timewise it would fit with the problems though ...

When running the netstat command I get a whole bunch of lines, the ones you mentioned among them. So that's fine?

And is there a way to filter the netstat results for just one IP address? There's a lot of ports getting listed on 0.0.0.0 and 127.0.0.1 ...
0
 

Author Comment

by:Xeronimo
ID: 40080370
Ok, so I had the problem just now ... both a HP laptop (the one doing the constant /release and /renew) and a mac mini lost their IP addresses.

Both of those machines appeared in the Wireshark capture as 'DHCP Request'. They stayed like that for a while and then suddenly DHCP ACK, Discover, Offer, Inform and ACK keep appearing again and the machines have their IP addresses again ... But why didn't they get them immediately!?

screenshotsc
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40080373
If those DHCP log entries correspond to the timing of the issue then it makes sense to follow that line of thought a bit further.
If a NACK is being logged I would have expected to see a packet being sent on the network to tell the client.
Anyhow, I came across the this MS KB article which, in the "More Information" section, has some scenarios regarding when a DHCP server may remain silent after receiving a request. Have a look over through and see if any of these match up to what you're getting.

The netstat results are fine. Your server is listening on the UDP ports 67 and 68. It simply confirms that the dhcp service is listening for the network traffic.
To filter the netstat command you have to pipe the results into a 'find' command.
netstat  -a -p -UDP | find "192.168.1.5"

Open in new window

Piping the result of the repeating netstat command into the find also works which surprised me. It just doesn't update as quickly.

Rory
0
 

Author Comment

by:Xeronimo
ID: 40080401
Red-King: my current subnet mask for my network is 255.255.248.0 ... do you think that could be the problem? It would not really explain though why it's only a problem in one part of my network and not in the rest?

Does something speak against changing the subnet mask to 255.255.0.0? It's not like the addresses outside of .248 are being used.
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40080412
Did you two more NACKs in the log file for that too?
Do you know if the HP and Mac were both assigned the same IPs as before or if they got new ones?
One thing about your screenshot is a little unclear, some ACKs are broadcast and some are unicast.
Unicast ACKs might be sent if the DHCP address was renewed from a client on a network segment that was separated from the server by a router  i.e. you had the "ip helper" or "dhcp relay" defined on the router.
I had a quick look at the switch config above and you don't seem to have that configured there. Do you have another device doing L3 routing?
0
 

Author Comment

by:Xeronimo
ID: 40080430
L3 routing refers to VLANs, right? I've got VLANs on that switch ...

I don't know if they got the same address ... The (virtual) DHCP server is on the same switch as the clients that experience those networking problems from time to time ... clients on other switches (who get IP addresses from the same DHCP server) seem to never experience similar problems!?
0
 

Author Comment

by:Xeronimo
ID: 40080437
And yes, I got NACKs in the log again, from IP ranges other than the main 192.168.2.x one (from the other VLANs?)
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40080475
The 255.255.248.0 subnet gives you an address space of 192.168.0.1 to 192.168.7.254.
I wouldn't expect this to be a problem unless you've a router in the middle where half of that subnet was on one interface and the other half on another interface. I've attached a diagram as an example.
As the router splits up networks the diagram attached would be a problem. The router would see both sides as the same network so when it receives a packet destined for that network it doesn't know which interface to send the packet out on.
Example of incorrect routing configuration
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40080494
A router wouldn't let you configure it like that with those masks.  You'd be looking at something like 192.168.0.1 / 255.255.252.0 on one side of the router and 192.168.4.1 / 255.255.252.0 on the other side.

Out of interest, are you running superscopes on the DHCP server?
0
 

Author Comment

by:Xeronimo
ID: 40080536
Red-King: I don't have a router like that, actually we only got switches

Craig: I don't think that I'm running superscopes on the DHCP server ... I've only got one scope (192.168.0.0). My firewall is giving out DHCP addresses for a second VLAN though. Is that a problem?
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40080602
Sorry if I'm telling you stuff you already know but just to be sure we're on the same page.
L3 (layer 3) routing refers to delivering packets based on the IP addresses in the packets.  L2 (layer 2) switching refers to delivering frames based on the MAC addresses in the frames. Routers are Layer 3 devices and Switches are Layer 2 devices.
VLANs operate, mostly, at layer 2 such that the VLAN ID is intserted into the ethernet frame. The switch, seeing the VLAN ID, decides with ports it will push the packets out. Generally a switch port can only have a single VLAN ID assigned.
So VLANs prevent computers/servers talking to each other even though they're plugged into the same switch.
In order to get computers/servers that are in different VLANs to talk to each other you need a device that gets the frames for all VLAN IDs. If you configure a port on your switch as a VLAN trunk port, it will receive/transmit all frames regardless of VLAN ID. You would then connect this trunk port to a layer 3 device such as a router which will then route the packets between the VLANs based on the IP addresses.
To make things a little more flexible manufacturers created Layer 3 Switches. What these do is allow a subset of the features of a router to be used on a switch. So your switch could now work at layer 2 and layer 3. In this case you don't need a router anymore to talk between VLANs, it can be done on the switch. (your switch has basic static routing features so its a layer 3 switch)
When creating VLANs in a network it is normal to constrain the VLAN to a single IP subnet.
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40080652
With the VLAN stuff in mind, I've looked back at your config. The following stood out to me
vlan 20 
   name "LAN_MAIN" 
   untagged A1-A24,B1-B16,B18,B22,B24,C1-C24,D1-D24 
   ip address 192.168.2.9 255.255.248.0 
   tagged B23 
   exit 
vlan 30 
   name "FreeWifi" 
   untagged B17,B19 
   tagged B23,D11 
   exit 

Open in new window

You have port B23 tagged for both VLAN 20 and VLAN 30. Also, port D11 is included in the untagged list of VLAN 20 and the tagged list of VLAN 30. It might be worth checking what's connected to ports B23 and D11 as there might be an issue there.
The difference between tagged and untagged is that with a tagged port the VLAN ID is injected into the ethernet frame, for untagged the frame is not ammended.
0
 

Author Comment

by:Xeronimo
ID: 40080671
Red-King: thanks a lot for all of this. I'm going to check these things out.

 I'm, obviously, not a network expert ... I'm actually supposed to do EVERYTHING IT-related here ;) With EE and people like you I would be lost, lol.
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 

Author Comment

by:Xeronimo
ID: 40080691
B23 is a fiber connecting two switches in two different buildings. They're tagged because both VLANs need to use that fiber ... isn't that how to do it?

D11 is a wireless access point with two WLANs, one connected to the one VLAN, the other to the other ... I had trouble getting all of this running ... maybe this WAP is interferring? It would at least explain why the problem is only on clients in this building and not in the other buildings?
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40081136
It's issues like this that make people experts as far as I'm concerned. Otherwise, why would anybody dive into the guts of dhcp ;)
There's no substitute for experience.

For the switch ports on either end of a fiber link you would normally set each as a VLAN Trunk. You would then specify which VLANs are allowed pass over that trunk.
The HP ProCurves seem to use a different terminology here. A trunk in HP terms is an aggregation group (etherchannel in Cisco terms I think) which is 2 ports treated as one for twice the bandwidth and redundancy.
In fact, looking at this site it seems that what you have is correct.

You could be right that the AP is interfering but I can't think of an explanation why this might be.
You could try removing the AP's port, D11, from the VLAN 20 untagged list (assuming you want all wifi traffic to be separated like that)
You could update the untagged line to:
untagged A1-A24,B1-B16,B18,B22,B24,C1-C24,D1-10,D12-D24

Open in new window

0
 
LVL 44

Expert Comment

by:Darr247
ID: 40083396
As I mentioned in http:#a40045069 Microsoft's TCP stacks were broken until SP1 of Server 2008 and SP2 of Vista... do you have at least SP1 on your Server 2008 machine?
If not, it's not using/listening-for the correct broadcast address.

Are you using clients running Windows Vista SP1 or older?
If so, they're not using/listening-for the correct broadcast address.

The only work-around microsoft has ever given for it is to use a 10.x.x.x subnet (instead of 192.168.x.x or 172.16-32.x.x subnets) if you're using masks less than /24.
0
 

Author Comment

by:Xeronimo
ID: 40083504
Darr: I've got SP2 on my 2008 DHCP server.

The clients have updated versions of Windows 7.
0
 

Author Comment

by:Xeronimo
ID: 40092720
Update: the WAP seems not to have been the culprit. It's been disconnected for some days now yet the problems continue to appear. Like right now ... In the DHCP log I'm seeing some NACKs again ... Is the problem related to those then? The IP addresses behind the NACK error are from a different IP range though than the default one ...

Any other ideas as to what I can do?

The situation right now seems to be that, sporadically, some PCs are asking for an IP address via DHCP (which can locally be seen using Wireshark) but it seems like the DHCP server temporarily does not see these requests ... until he does again, at some point, and then gives them addresses ...
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40093176
Would you mind posting a logged NACK error?
The NACK itself might be a symptom rather than the cause.
The IP addresses behind the NACK error are from a different IP range though than the default one
Is this different IP from a scope you have configured or completely unrelated to your config at all?
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40093214
I don't think the NACKs will be an issue.  When a client asks for an IP address it usually asks for the one it had during its last lease.  It may be that the client was on a different network the last time a lease was obtained, therefore you'd see a different IP being requested.  The DHCP server will say it doesn't have an IP to lease in that range, and the client will ask for a new IP.
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40093342
I agree, that's what I'd normally expect to happen. It doesn't seem to be the case in this instance though.
The client machine appears to not receive a renewed IP address from the same DHCP server that it had received it's lease from originally. The normal procedure does not seem to be taking place after the NACK

Xeronimo, if you happen to catch the issue again and can run Wireshark at the time, would you post a screen grab of what Wireshark is showing you (using the 'bootp' filter)? In normal circumstances you'd see the following interaction alternating between the client and server:
Discover->Offer->Request->Ack-Inform->Ack

If the PC is requesting an IP from a different range we'll need to figure out where it's picking that up from.
0
 

Author Comment

by:Xeronimo
ID: 40094906
RedKing and craig:

From the dhcp logfile:
15,05/27/14,08:20:04,NACK,172.16.10.111,,90B9317E65E3,,0,6,,,
15,05/27/14,10:26:53,NACK,10.113.80.229,,B8C75D1B8325,,0,6,,,
15,05/27/14,10:50:12,NACK,172.16.10.192,,D0E782D2C44B,,0,6,,,
15,05/28/14,07:30:59,NACK,192.168.178.22,,CC785FDB255B,,0,6,,,

Our main network has 192.168.0-7.x addresses.

We've got a separate network, on a different VLAN, for guest Internet access, in the 172.16.10.x range (the devices get their IP address from a DHCP service on the firewall)

As for the Wireshark screengrab, it's from the DHCP server, right? I have to wait for such a moment then ...
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40096195
A client will try and obtain its last known IP address, like I said earlier.  That could have come from home, a coffee shop... anywhere really.  I would be more interested in making sure that when a client obtains an IP from your network, then disconnects and reconnects, does it still try to grab the IP it had on your network, or does it ask for an IP from a different network?

After the NACK the client should just send a DHCPDISCOVER to restart the DHCP process. This time though the client won't include its last known IP address in the broadcast, therefore when a DHCPOFFER is received the client should immediately send back a DHCPREQUEST with the offered IP address in the packet.  If it doesn't receive the DHCPOFFER it will just send a new DHCPDISCOVER, thinking it didn't get an offer.  This is what you're looking for.

Can you verify that your router isn't running DHCP, and that it's not running Proxy-ARP?

Further to that, have you seen this?...

http://blogs.technet.com/b/yongrhee/archive/2012/01/22/list-of-dhcp-related-hotfixes-post-sp1-for-windows-server-2008-r2-sp1.aspx
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40096203
The wire shark screen-grab would be useful from both the client and the DHCP server, but whatever you can get at the time will help.
If you could note the MAC of the client and get the lines from the DHCP log at the same time it will give a more complete picture.

It would help to understand the networking between the wifi vlan and firewall. If we can compare that with the networking used by vlan for the desktops we might be able to spot something there.

From the few lines of log above it seems something, which had an IP from the firewall then tried to renew that IP with the windows DHCP server.
Do you have private wifi for office devices too?
I'm trying to think of how a device on the wifi would be able to request an IP from the windows DHCP. If the wifi Vlan can't talk to the office Vlan then the DHCP server shouldn't see any requests to renew a wifi IP because only wireless NICs should have those IPs in the first place. If there's no internal office wifi then those wireless NICs should never get the chance to talk to the windows DHCP server.
0
 

Author Comment

by:Xeronimo
ID: 40107895
So the weird thing is this: I've got a laptop connected to that network segment that's releasing and renewing its IP address every 5 minutes and logging this into a text file. This has worked fine for days now, no problem at all!

But then I've got a couple of workstation who had the same problem again when they were booted this morning ... :( They had to wait nearly an hour to get an IP address!

The workstation was booted at around 06:35 (see screenshot) and the first occurence of this workstation in the DHCP log is from 07:17 ...

30,06/02/14,07:17:55,DNS Update Request,192.168.2.62,MC33265.xxx.local,,,0,6,,,
10,06/02/14,07:17:55,Assign,192.168.2.62,MC33265.xxx.local,4C72B9D20328,,4276741800,0,,,
32,06/02/14,07:17:55,DNS Update Successful,192.168.2.62,MC33265.xxx.local,,,0,6,,,

Here two screenshots from the event viewer of one of them:
sc2sc1
0
 

Author Comment

by:Xeronimo
ID: 40107937
Red-King:

As for the networking between the wifi vlan and the firewall, I'm not sure what you need to know?

The free-wifi vlan gets its DHCP addresses from the firewall (172.16.10.x). And I've got a rule on my firewall explicitly blocking all communication from the free-wifi vlan to our main vlan (but shouldn't that already be impossible anyway since they're two different VLANs?).
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40108105
Looking up the event IDs and DHCP error code 0x79 has thrown up a few things to try.

As that computer has shown the issue it would be great if your could swap that PC out for another and use that as your test laptop.

Ideally you would try these options one at a time and see if the issue reoccurs. If you try more than one of these solutions at the same time you won't know which one fixed the issue (if any of them do).

Check which NIC has the MAC address 0x4C72B9D20328. Make sure this is the NIC you wish to use to connect to the office LAN and disable any other network connections (Including Wifi and Bluetooth if available)
Try replacing the network cable with a new, tested, cable
Update the driver of the network card with the latest driver from the manufacturer i.e. don't get the one from Dell or HP, go for the Realtek or Intel website or whoever made the NIC
Disable IPv6 on the network adapter
Reset each of the following network components (run a Command Line as an administrator) and reboot the PC afterwards.
Reset WINSOCK entries to installation defaults: netsh winsock reset catalog
Reset IPv4 TCP/IP stack to installation defaults: netsh int ipv4 reset reset.log
Reset IPv6 TCP/IP stack to installation defaults: netsh int ipv6 reset reset.log
0
 

Author Comment

by:Xeronimo
ID: 40108177
Ok, I'll try that. But it's not just the ONE computer! There are a couple (maybe all? just that they were lucky to boot their PC at times where it worked) on that network segment who experience these problems ...
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40108233
As for the networking between the wifi vlan and the firewall, I'm not sure what you need to know?

The free-wifi vlan gets its DHCP addresses from the firewall (172.16.10.x). And I've got a rule on my firewall explicitly blocking all communication from the free-wifi vlan to our main vlan (but shouldn't that already be impossible anyway since they're two different VLANs?).
I'm just trying to understand how your network is connected together and see if there's any chance of a networking issue causing this.
The Wifi Access point, VLAN30, is on switch port B17 and the Firewall is connected to port B19 which is tagged for VLAN30.
You've also got VLAN30 extended to 2 other buildings.
So if you're firewall is connected to VLAN30 on port B19 then you must have a second connection from the switch to the firewall. You mentioned you've a rule on your firewall that prevents the 2 from firewall connections from talking to each other.

I've attached a diagram of how I understand your network to be laid out. Do I have this right?
Network.jpg
0
 

Author Comment

by:Xeronimo
ID: 40108247
Yes, the only thing missing are two more switches (in building 2 & 3), they're connected to the 'main' switch via fiber.
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40108270
This might sound like a bit of an awkward request, but can you try this using a Windows client with NO updates or service packs applied?
0
 

Author Comment

by:Xeronimo
ID: 40108278
craig: a 'naked' Windows 7? That's a bit difficult to arrange ... also, I've got a fully updated Windows 7 laptop that continuously gets an IP address from the DHCP server ... so I don't think it's a matter of a flawed update?
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40108317
I understand what you're saying, and it would make complete sense, but this was happening to us on machines which had all of the same updates/software/drivers/etc.  It was completely unexplained.  All I'm saying is don't rule it out.

We also saw an issue with W2K server which caused lots of random clients to stop receiving IP addresses, while others worked fine.  That was due to a DLL file being replaced on the server during a service pack installation.
0
 

Author Comment

by:Xeronimo
ID: 40108344
Ok, I'm gonna check to see if there are some similarities between the machines where it doesn't work
0
 

Author Comment

by:Xeronimo
ID: 40116766
Update:

So the problem is occurring right now again :/

On the laptop who doesn't get an IP address I'm seeing only (in Wireshark) 'DCHP Discover'
As for the DHCP server it shows a bunch och DHCP Inform, ACK and Requests ...

What I've also noticed:

I had this laptop running for a week and having it /release and /renew constantly. Not one error during all that time! Now, as a test, I removed the actual Ethernet cable and put it back in: it doesn't get a new IP address!

At the same time I've now disconnected and reconnected a second laptop in a different network segment: no problem at all! It immediately gets its IP address (from the SAME DHCP server, which is connected to the OTHER, problematic network segment!?)

Any other ideas ... ?
0
 
LVL 9

Accepted Solution

by:
Red-King earned 500 total points
ID: 40116813
As for the DHCP server it shows a bunch och DHCP Inform, ACK and Requests ...
Are these server side Inform, ACK and Requests related to the laptop that is now showing the issue?
I expect they are not, as you're only seeing the discover on the laptop.

Are you now able to replicate the issue? If you were to pull the cable from the second laptop and replace it will the issue reoccur?

If the DHCP server is not seeing the DHCP Discover packet from the laptop, which is exhibiting the problem, then this points to a networking issue.

You can filter the Wireshark trace on the DHCP server to show only the packets from the problem laptop by using that laptops mac address. An example of this filter is:
eth.addr == 44:8a:5b:52:34:3d
You should now be able to see if the DHCP server receives the Discover packet and if it responds.
0
 

Author Comment

by:Xeronimo
ID: 40116830
No, they're not related to that laptop.

The issue will NOT occur on the second laptop as long as it's in the second network segment, not the first (with the DHCP server being in the first though!).

I've filtered on the MAC address, there's nothing in the DHCP server's Wireshark capture of it ... so the DHCP server receives no packets from that laptop at all.

It's also been going on really long this time now!?
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40116838
Ok, the packet from the laptop is being dropped somewhere along the route to the DHCP server.
If I remember correctly your network path is: Laptop -> Switch -> ESX Server -> VMware vSwitch -> DHCP Server VM

The next step I'd suggest is that you plug the second laptop directly into the switch and start up Wireshark.
Check to see if you see the Discover packet from the first laptop. Its a broadcast so all devices connected to the switch should see it.

The next step would be to try and do the same for the vSwitch.
0
 

Author Comment

by:Xeronimo
ID: 40116935
Yes, that is the path. Right now I can't do any tests anymore since it's working again ... See the screenshot from the laptop that wasn't able to get an IP address for a while:

screenshot from laptop
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40116951
If you pull and re-seat the network cable on the first laptop does it show up again?
0
 

Author Comment

by:Xeronimo
ID: 40116961
No, it does not show up again. Right now it works again as it should.
0
 

Author Comment

by:Xeronimo
ID: 40116968
And all the other PCs in that building who didn't have an IP address yet before the 'breakdown' got one too now.
0
 

Author Comment

by:Xeronimo
ID: 40117021
And for what it's worth, it took the laptop (whose Ethernet cable is disconnected and reconnected) from 11:01 to 12:46 to get a new IP address! The outage was even longer for those other PCs who got booted after the outage had started (I think it was around 10:00).
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40117404
Did anything happen around 10:00? Did the other incidents start around the same time? Are there any scheduled tasks that you can think of? Any backups? Antivirus scans? Did somebody maybe plug something in?
If you know the time it happened you should be able to find some pattern that might point back to where the problem is i.e. all VMs couldn't be reached so there must be something about connecting to VMware server.

Some monitoring tools would be really useful too if you had them such as
http://cacti.net/
http://www.nagios.com/products/nagioscore
http://www.spiceworks.com/downloads/

Cacti and Nagios can be a bit of a challenge to set up if you're not familiar with Linux but Spiceworks can be installed on a Windows Server quite quickly. Spiceworks is more management than monitoring but could help in identifying devices with issues.
0
 

Author Comment

by:Xeronimo
ID: 40117425
It happens at different times, sometimes around 7:00, sometimes around 10:00, haven't identified a pattern yet.

As for someone plugging something in, that was also my suspicion but I haven't found anything yet ... No scheduled tasks I can think of.

And what's weird is that it ONLY affects computers on that switch (if they've not had an IP address yet before the 'outage'), not the computers on other switches. Those continue to get IP address when booted etc!?

I've got Spiceworks. But I'm not really at ease with Linux ...

I'll see if I can identify some more things/patterns next week when the outage occurs again. Thanks so far again! :)
0
 

Author Comment

by:Xeronimo
ID: 40124273
Things are getting even weirder!

So the problem is occurring again, right now. But the weird thing is that ONE workstation (A), attached to that network segment, GETS an IP address while 3 other workstations (which I have booted at the same time as the other one) do not!

The only difference I see so far is that workstation A is connected to a little 'in-office' switch while the other workstations are directly connected to Ethernet ports in the wall.

Any ideas ... ?
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40124374
I would set up a temporary physical DHCP server which is authorized in AD, just to see if it's related to vSwitches, etc.
0
 

Author Comment

by:Xeronimo
ID: 40124401
But if it was related to the vSwitches wouldn't ALL my workstations then be affected? Not just the ones in the building/network segment?

 I don't have a physical server right now to test this ...
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40124440
Maybe it would, but as you say, it's weird so don't discount any possibility.

There could be any number of reasons why a virtual switch would cause intermittent problems.  Even physical switches can cause unpredictable issues.  It could even be down to how many IOPS the drives that host your VMs can handle.

I'm just saying try to rule out the virtual environment by using a physical server... even if it's a spare PC running the server OS; just something to get the DHCP service out of the VMWare environment temporarily.  Push come to shove, install a server OS inside Oracle VirtualBox on a PC.
0
 

Author Comment

by:Xeronimo
ID: 40124608
Ok, but first I'll restart the switch this evening. To rule out that out as well.
0
 

Author Comment

by:Xeronimo
ID: 40126846
I've restarted the switch yesterday evening, this morning everything seemed to work alright ... but I had restarted it before at times so I'm waiting some more to see if it's really stable ... I wouldn't know WHY that would be the case then, except that the switch would have to be rebooted on a regular basis!?

I had a similar problem with smaller switches. Suddenly a port stopped working. After a restart it worked again.
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40127718
I've seen strange behavior from switches before too.
I've H3C (3Com bought out by HP) in the office. I was unable to add a new bridge aggregate group despite having done so numerous times before. After a reboot it started working again and has worked since.
So, a regular reboot might be just what's needed but it would be nice to rule out the other aspects, such as VMWare's vSwitch, before settling for that as a regular maintenance task.
0
 

Author Comment

by:Xeronimo
ID: 40136228
Ok, so it seems the reboot did not help :( For a few days there were no problems and people got their IP addresses but this morning some of them again did not .....

I'm gonna try to install a physical DHCP server then.
0
 

Author Comment

by:Xeronimo
ID: 40138627
So the DHCP server has been running on a physical server since yesterday yet this morning there were still people again who didn't get an IP address :( So seems the problem is not related to the virtual component of the server??
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40138687
Can you use an unmanaged switch to connect a client to the physical DHCP server?
0
 

Author Comment

by:Xeronimo
ID: 40138775
I could do that ... but how would that help?
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40138794
By cutting out your existing network we're testing whether it's a switch issue or not.

A diagram of how your switches are connected would help, and also I know that you've provided a config for one switch but are there any other switches that you haven't shared configs for?
0
 

Author Comment

by:Xeronimo
ID: 40138913
> By cutting out your existing network we're testing whether it's a switch issue or not.

Just to be sure: the DHCP server (connected to the potentially troubled switch, PTS) is constantly giving IP addresses, just like it is supposed to, to workstations NOT connected to the PTS. That's what seems weird, no? The problem only afflicts workstations attached to the PTS. And only for a certain amount of time. Suddenly the DHCP requests get through again ...

The DHCP server is connected to the  PTS with a regular Ethernet cable.
Those other workstations are on other switches which are connected to the PTS via fibre.
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40138949
So connect the physical DHCP server to the switch which appears to be ok and see if clients connected to the PTS get IP addresses.  Disable the virtual DHCP server.
0
 

Author Comment

by:Xeronimo
ID: 40139015
I've already done that: 'So the DHCP server has been running on a physical server since yesterday yet this morning there were still people again who didn't get an IP address :( '

The physical DHCP server was connected to a different switch, not the PTS (and the virtual DHCP had been stopped but not de-authorized). Yet the symptoms and effects were the same ... workstations connected to the PTS who tried to boot at a certain time did not get IP addresses for a while ...
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40139073
Ok so can you swap the PTS with the OK switch?  Are they the same?
0
 

Author Comment

by:Xeronimo
ID: 40139078
No, I can't do that. The switches are in different buildings, rack-mounted.

And as I've said: even if the DHCP server is on the OK switch the workstations on the PTS don't get IP address from time to time ... so it doesn't matter on which switch the server is. Seems the workstations have a problem with the PTS then?
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40139099
Swapping the switches is something I would strongly suggest, or swap out the PTS.
0
 

Author Comment

by:Xeronimo
ID: 40139119
That's not an option right now though ...
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40139162
Well you may have to just live with the fact that your switch doesn't appear to be working then until you can do something about it.  

Can you draw your network and tell us which interfaces connect the switches?  Also, provide the configs for each switch if you can please?

Just a thought, but if you're having problems while clients are connected to the 4204 can you not connect a new switch to the 4204 and connect clients to that instead (much like you're already doing in the other locations)?
0
 

Author Comment

by:Xeronimo
ID: 40139168
You mean connect an additional switch to the PTS (the ProCurve) and connect clients to this new switch?

But I would have to connect the new switch to the PTS via Ethernet, the others switches are connected via fibre but I don't have any fibre left.
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 40139178
It doesn't matter whether they're connected via fibre or copper.  Fibre is generally used where length between switches is an issue.  A 1Gbps fibre provides the same bandwidth as a 1Gbps copper.
0
 

Author Comment

by:Xeronimo
ID: 40153993
Ok, I'll have to think about this then
0
 
LVL 9

Expert Comment

by:Red-King
ID: 40154083
By any chance do you have a current support agreement with HP for this switch?
There might be a known issue or part replacement you are entitled to.
0
 

Author Comment

by:Xeronimo
ID: 40154202
No, the warranty has expired ...
0
 

Author Comment

by:Xeronimo
ID: 40911029
No real solution was found at the time. Problem seems to have disappeared over time 'by itself' ... Request the permission to close or delete this thread.
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

A Cisco router can be configured as a DHCP Server. There are advantages and disadvantages in making your Cisco router work as DHCP Server. Almost all the features for windows DHCP can be configured on Cisco-based DHCP server. Some of the features me…
Resolve DNS query failed errors for Exchange
This video discusses moving either the default database or any database to a new volume.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now