We are a very centralized company with a lots of decentralized business units.
All these decentralized locations are connected to the HQ, but can run their primary business process withouth this connection.
This is also a principle we use, so the "primary" proces must always run, even when the connection to the HQ is down.
Now we're looking for a DDI (DHCP, DNS, IPAM) solution, in all the solutions we have now, the DHCP server is located at the HQ.
This means that when the connection fails and people are rebooting (makes sense when something doesn't work), that they won't gain an IP address.
At the branch locations we have almost always one system, which perfectly can run DHCP (and/or DNS), but it won't register the releases in the IPAM and it also makes management worse.
Also on all the branch locations we have a PA-200.
The idea was to make use of the PA as a DHCP relay, this relay would point to two addresses, one central and one local.
For the local address we make a PBF rule, which points to "NULL" and checks if the central DHCP server is reachable.
So when the connection fails, the PBF rule would be disabled and the DHCP requests will reach the local server.
If the connection is up again, the PBF rule would redirect all the local requests to NULL, so all the requests would only reach the central DHCP server.
Unfortunately the sequence in which the PA handles this relay, wouldn't hit the PBF rule. (at least we didn't get this working).
I was wondering if anyone here has an idea if this problem can be solved by using a Palo Alto, cause this is the constant factor which is available on every location.
What if you bring each site their own dedicated iprange?
This way you can ignore the use of a centralized DHCP server - just make sure you get the logs from each site (like through the PA into a Panorama box on your central location).
For example something like this:
Each site gets 10.0.x.0/24 (or whatever size) as range. This is maintained by the PA device.
In the switches you configure option82, dhcpsnooping and dhcprelay. This way when a client sends a dhcp request the switch will intercept this traffic, add physical location (normally switch name and interface the request arrived at as Option82) and then as a unicast send this request towards the ip for dhcp server (ip of PA at this site).
The PA will log this request and bring the client an ipadress to use.
The option82/dhcpsnooping/dhcprelay stuff can also be configured so only the ip (srcip) as the dhcpserver assigned for this client will be allowed on this physical interface on the switch.
The good thing with above, except for logging and a local solution in case uplink is down, is that this is similar to how ip addresses are handled when using IPv6.
With IPv6 you can use either a dhcp server or let the network equipment (by ND - Network Discovery) let the client know which ip adress to use. The later is more autonomous than having to trust a dhcp server to always be available.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!