DHCP redundancy

[Kevin_]

Hello all.

I'm currently using IP pools to provide addresses to connecting NC users. I'd like to move to DHCP, but I'm concerned about redundancy. The NC Connection Profiles configuration only allows a single DHCP server to be defined. If this server dies, users can't get an IP. Using pools, if one cluster member dies, the other takes over and can successfully continue to provide addresses from the same pool.

So, what is everyone doing about providing redundancy for DHCP?

Thanks!

[Jickfoo_]

I use the IVE cluster just like you said. Why move to DHCP Server ? What features are you missing out on by using the IVE ?

[Kevin_]

I've got two reasons.

1) You can only specify one WINS server - so that's a single point of failure if that device dies.

2) You can't offer other DHCP options - like a voice server using Option 43 for a softphone.

Unless I hear some great solution, I guess I'll stay with my current config - since I'd rather have a WINS failure than a DHCP failure It's odd, however, why Juniper doesn't recognize and fix something obvious like this.

Thanks Jickfoo !

[Jickfoo_]

It's tough to have dual "real" DHCP Servers for the same scope. You think that Juniper would just allow the IVE to act as a client. Have the IVE Send out a DHCP Discover packet rather then having to specify an actual IP Address. The DHCP discover would just use the first server to respond. I wonder if you'd get an error if you set the DHCP Server address to 255.255.255.255, or maybe leave it blank.

Another thing you could do although its not cheap is cluster your DHCP Server on a hardware level. It would be one IP but if the server failed a backup would take over.

How much WINS are you really doing ? We're trying to get rid of ours.

[Kevin_]

WINS is the gift that keeps on giving ! Every time we think we no longer need WINS, we discover that Microsoft uses it in some new strange way. Good luck to you in eliminating it.

I don't necessarily agree about the difficulty of having two servers offer the same scope. Split scopes are easy, they work, and have been around forever. We use Cisco CNR which can be configured for scope or server redundancy - but each server is independent (not sharing a single IP). Ours are separated over a WAN for DR, GLB, etc.

I like the idea of having the IVE use the helper addresses, but that would limit your ability to specify different DHCP servers per policy. I still like the ability to specify a server in the IVE, I just want them to allow a list of IPs.

[Jickfoo_]

I see your point. Actually, we split up our DHCP scopes as well. We have backup scopes in one of our other offices that I forgot about.

Tough situation, You can file a Enhancement request with your Account Manager and SE. I guess thats your only recourse. Either that or put load balancers in front of your DHCP Servers and send Juniper the bill. (let me know how that one works out.) You're right, they should fix this.

[Yves_]

I'm in the same situation. I use a DHCP server for my IP addresses pools, but I can not provide more than one NETBIOS server to the Network connect client.

I have three Netbios servers configured on my DHCP server. The same configuration as my local network DHCP clients. I selected the DHCP DNS settings option in the nc connect connection profile, but the network connect client receive only one netbios server.

Does someone has an idea to help me solve my problem?

Thanks

Yves

[Jahmal_ · Accepted solution]

You can actually define more than one DHCP server (officially) by separating by a comma. Give it a try.

Jahmal

[Kevin_]

That's great news. I tried it with a comma and space separating the two IPs - and it didn't work. It saves ok, but when you go back into the policy definition the second IP has been chopped off at the comma. Separating the two IPs with a comma saves properly.
I'll give this a try this weekend. Many thanks !

[Jahmal_]

Kevin,

You are correct. You need to put the DHCP servers separated by a comma, but without a space. This essentially works but is not documented not offically supported. In a future release this will be properly documented and supported.