ok so i'm running out of ideas here.

we have/had 3 managed switches in our server rack and one in a closet; one hp procurve 3500yl 48 port with poe for 2 APs and 2 catalyst 2960s in the bottom of the rack for the proliant blade server and the link to the equallogic datastores.

the one in the closet was another procurve same model i believe.

worked with HPE and came to concur with me that the rack 3500yl is dead (console port intermittent and config commands seemed corrupted/report as invalid)

they next biz day an aruba 3810 and got that setup and cloned a backup of our switch config into it to match the vlans (not a lot just 8 or so plus the default) no special metering or priorities just separating ip pools between departments and building areas.

i can for the life of me not get any of the systems connected to the aruba or the two catalysts to grab a valid dhcp link even though i have a secondary dhcp server up and running on a hardware r230 running server 2012. dns was a vm on the blade server and is running but can only reach the other vms on the blade chassis, switching subnets works between all the vms to get the DC vm to talk to them for at rack RDP but it will not connect to anything outside of the blades even if i set a static ip to what i know is it's valid lease ip (or any other).

i can get to the web management of the new aruba switch from any of the physical systems if i set a static ip in the default vlan range (192.168.100.x) so i know the legs of the network to the aruba is working at least.

any suggestions would be welcome, really scratching my head here not to mention stressing out with this >1yr job and this happens


  • What version of spanning tree are you using? The Cisco switches default to PVST+, but that is not what the Aruba will do. You need to make sure that you are using CST or MST, and that everything is configured with the proper root, etc. Also, you may have had IP helpers configured for DHCP on the failed switch that need to be replicated on the new switch.
    – Ron Maupin
    Aug 13, 2019 at 0:12
  • its using MST and the cisco switches (as far as i cant tell, they were installed and configured before i took the job) dont seem to have been stacked with anything other than themselves. the procurve was root and now so is the aruba the old procurve was stacked with the other procurve in the closet; from what i have in the backup of the old config there wasnt anything configured for helpers just ethernet failure detection settings for (i'm assuming, never used those settings in previous jobs; they'd just have us swap the switch and load a config backup) detecting bad or failed ports/runs Aug 13, 2019 at 6:07
  • Have you tried to sniff the broadcast traffic directly in the network?
    – Elias
    Aug 13, 2019 at 22:27

2 Answers 2


so turns out the reason i couldn't get any DHCP or DNS out of the blade server was that a portion (at least) of the backplane in the blade server went bad resulting in the network module blades being unable to communicate to anything external to the enclosure. (tested buy simply hooking a switch up and trying to ping the other IPs/ports of both the same one network module as well as the other modules in the other bays, all static ips on same subnet)

so ending up having to fast track a VM host hardware upgrade we were already testing and bringing up our Primary controller on the new hosts.

saving grace is all the data files for the vms are offloaded from the hosts and server into a dedicated equallogic so once i can get the hosts hooked into the storage i can just import the DC VM and get everything back online with some fiddling.

kicker is the self diag of the blade enclosure reports (still) green across the board for all the modules and I/O bays.

only thing i can think of that killed the switch is one of the network modules had some kind of surge when the backplane failed and it traveled up the line and killed the switch.

so slowly we are getting things back in order.


Quite possibly, the 3500 config doesn't work in the 3800 in its entirety, or the backup is missing significant changes.

For DHCP to work you need either

  1. connect the DHCP server to each VLAN
  2. set up a DHCP relay in each VLAN towards the DHCP server

For 1., make sure client and server are connected to the same VLAN = the same broadcast domain. Verify by checking the switch's MAC table for both client and server MACs.

For 2., the relay switch requires an IP address inside the VLAN and needs to be able to ping the DHCP server. Whether the relay switch routes to the DHCP server's VLAN or if there's an additional router doesn't matter as long as there's a route.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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