|
|
|
|
Hey All,
We are consolidating all subnets on server B and moving to an exisitng failover pair we have, In order to decom server B. I'll need to take the leases file from server B and combine whats there with the leases file on both servers in the failover pair. (doing this to make the failover pair aware of what leases are already out there that were assigned by server B) I'm thinking just a simple cat on both files should be fine to combine the data. And, all 3 servers are running the same verison of dhcp (4.1.1.61) and RHEL so I don't expect and formatting problems. However, since failover pairs have more transitional states with the "binding state" variable, is it possible I will run into any issues doing this? Is there a better, more preferred way of doing this instead of merging the leases file? _______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 29/08/2018 14.28, project722 wrote:
Hey All,
We are consolidating all subnets on server B and moving to an
exisitng failover pair we have, In order to decom server B.
I'll need to take the leases file from server B and combine
whats there with the leases file on both servers in the
failover pair. (doing this to make the failover pair aware of
what leases are already out there that were assigned by server
B)
I am not sure, but I think one other way could be to make server B
part of a failover pair with one of the existing failover servers
for a period of time. That way the remaining server will have all
the information transferred from server B. Later that configuration
could be changed to have the other remaining failover server act as
the peer, that way the servers would transfer the data, probably
with less risk.
Others should confirm or reject this idea.
I'm thinking just a simple cat on both files should be fine to
combine the data. And, all 3 servers are running the same
verison of dhcp (4.1.1.61) and RHEL so I don't expect and
formatting problems.
However, since failover pairs have more transitional states with
the "binding state" variable, is it possible I will run into any
issues doing this? Is there a better, more preferred way of
doing this instead of merging the leases file?
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
On 29/08/2018 14.28, project722 wrote:
Hey All,
We are consolidating all subnets on server B and moving to an
exisitng failover pair we have, In order to decom server B.
I'll need to take the leases file from server B and combine
whats there with the leases file on both servers in the
failover pair. (doing this to make the failover pair aware of
what leases are already out there that were assigned by server
B)
I am not sure, but I think one other way could be to make server B
part of a failover pair with one of the existing failover servers
for a period of time. That way the remaining server will have all
the information transferred from server B. Later that configuration
could be changed to have the other remaining failover server act as
the peer, that way the servers would transfer the data, probably
with less risk.
Others should confirm or reject this idea.
I'm thinking just a simple cat on both files should be fine to
combine the data. And, all 3 servers are running the same
verison of dhcp (4.1.1.61) and RHEL so I don't expect and
formatting problems.
However, since failover pairs have more transitional states with
the "binding state" variable, is it possible I will run into any
issues doing this? Is there a better, more preferred way of
doing this instead of merging the leases file?
The benefit of a failover pair is that we can upgrade/repair/replace one server at a time without any interruption in service. Let's call the failover pair A-master and A-failover. The recommended method is to configure server B as master and the A-failover server as failover for server B's subnets also. Give it some time (watch the failover messages in the logs) to sync the data from B to A-failover. Then move the subnets from B to A-master, and A-master will sync the data from A-failover.
-- Bob Harold _______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Thanks for the feedback guys!
So, in this scenario I'll have 2 masters temporarily - B will become a new master and sync to A-failover, and A-master will still be in the picture as well? If I try this approach, then, I will have to add the subnets for server B to A-failover, then enable failover between B and A-failover? Wouldn't A-master have a problem with A-failover having subnets in its conf file that A-master doesn't?
Also, I'm starting to think aboout ip helper addresses. Seems like the flow would be:
Add an IP helper address on the router for server B's subnets to also point to A-failover
Once they are completely in sync then remove the IP helper for server B altogether and add another for A-master
Does that sound about right?
On 29/08/2018 14.28, project722 wrote:
Hey All,
We are consolidating all subnets on server B and moving to an
exisitng failover pair we have, In order to decom server B.
I'll need to take the leases file from server B and combine
whats there with the leases file on both servers in the
failover pair. (doing this to make the failover pair aware of
what leases are already out there that were assigned by server
B)
I am not sure, but I think one other way could be to make server B
part of a failover pair with one of the existing failover servers
for a period of time. That way the remaining server will have all
the information transferred from server B. Later that configuration
could be changed to have the other remaining failover server act as
the peer, that way the servers would transfer the data, probably
with less risk.
Others should confirm or reject this idea.
I'm thinking just a simple cat on both files should be fine to
combine the data. And, all 3 servers are running the same
verison of dhcp (4.1.1.61) and RHEL so I don't expect and
formatting problems.
However, since failover pairs have more transitional states with
the "binding state" variable, is it possible I will run into any
issues doing this? Is there a better, more preferred way of
doing this instead of merging the leases file?
The benefit of a failover pair is that we can upgrade/repair/replace one server at a time without any interruption in service. Let's call the failover pair A-master and A-failover. The recommended method is to configure server B as master and the A-failover server as failover for server B's subnets also. Give it some time (watch the failover messages in the logs) to sync the data from B to A-failover. Then move the subnets from B to A-master, and A-master will sync the data from A-failover.
-- Bob Harold
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Thanks for the feedback guys!
So, in this scenario I'll have 2 masters temporarily - B will become a new master and sync to A-failover, and A-master will still be in the picture as well? If I try this approach, then, I will have to add the subnets for server B to A-failover, then enable failover between B and A-failover? Wouldn't A-master have a problem with A-failover having subnets in its conf file that A-master doesn't?
Also, I'm starting to think aboout ip helper addresses. Seems like the flow would be:
Add an IP helper address on the router for server B's subnets to also point to A-failover
Once they are completely in sync then remove the IP helper for server B altogether and add another for A-master
Does that sound about right?
That is correct. A DHCP server can be master for some subnets with failover 1, and others with failover 2, and still others with no failover. A DHCP failover server can be failover for some subnets with master 3, others with master 4, and other subnets that are not using failover. The only limitation is that I don't think a server can be master for some subnets and failover for others.
p.s. Here at U of Michigan we currently have 8 pairs, and have some experience moving subnets around :) The trick is to verify that the dhcp forwarding on the routers is really working and that there is no firewall rule or acl somewhere blocking it.
-- Bob Harold
On 29/08/2018 14.28, project722 wrote:
Hey All,
We are consolidating all subnets on server B and moving to an
exisitng failover pair we have, In order to decom server B.
I'll need to take the leases file from server B and combine
whats there with the leases file on both servers in the
failover pair. (doing this to make the failover pair aware of
what leases are already out there that were assigned by server
B)
I am not sure, but I think one other way could be to make server B
part of a failover pair with one of the existing failover servers
for a period of time. That way the remaining server will have all
the information transferred from server B. Later that configuration
could be changed to have the other remaining failover server act as
the peer, that way the servers would transfer the data, probably
with less risk.
Others should confirm or reject this idea.
I'm thinking just a simple cat on both files should be fine to
combine the data. And, all 3 servers are running the same
verison of dhcp (4.1.1.61) and RHEL so I don't expect and
formatting problems.
However, since failover pairs have more transitional states with
the "binding state" variable, is it possible I will run into any
issues doing this? Is there a better, more preferred way of
doing this instead of merging the leases file?
The benefit of a failover pair is that we can upgrade/repair/replace one server at a time without any interruption in service. Let's call the failover pair A-master and A-failover. The recommended method is to configure server B as master and the A-failover server as failover for server B's subnets also. Give it some time (watch the failover messages in the logs) to sync the data from B to A-failover. Then move the subnets from B to A-master, and A-master will sync the data from A-failover.
-- Bob Harold
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Thanks. So would this syntax be correct on the secondary? failover peer "dhcp-failover" { secondary; # declare this to be the secondary server address <server IP address>; port 647; peer address <A-master>; peer address <B-master>; peer port 647; max-response-delay 30; max-unacked-updates 10; load balance max seconds 5; } Thanks for the feedback guys!
So, in this scenario I'll have 2 masters temporarily - B will become a new master and sync to A-failover, and A-master will still be in the picture as well? If I try this approach, then, I will have to add the subnets for server B to A-failover, then enable failover between B and A-failover? Wouldn't A-master have a problem with A-failover having subnets in its conf file that A-master doesn't?
Also, I'm starting to think aboout ip helper addresses. Seems like the flow would be:
Add an IP helper address on the router for server B's subnets to also point to A-failover
Once they are completely in sync then remove the IP helper for server B altogether and add another for A-master
Does that sound about right?
That is correct. A DHCP server can be master for some subnets with failover 1, and others with failover 2, and still others with no failover. A DHCP failover server can be failover for some subnets with master 3, others with master 4, and other subnets that are not using failover. The only limitation is that I don't think a server can be master for some subnets and failover for others.
p.s. Here at U of Michigan we currently have 8 pairs, and have some experience moving subnets around :) The trick is to verify that the dhcp forwarding on the routers is really working and that there is no firewall rule or acl somewhere blocking it.
-- Bob Harold
On 29/08/2018 14.28, project722 wrote:
Hey All,
We are consolidating all subnets on server B and moving to an
exisitng failover pair we have, In order to decom server B.
I'll need to take the leases file from server B and combine
whats there with the leases file on both servers in the
failover pair. (doing this to make the failover pair aware of
what leases are already out there that were assigned by server
B)
I am not sure, but I think one other way could be to make server B
part of a failover pair with one of the existing failover servers
for a period of time. That way the remaining server will have all
the information transferred from server B. Later that configuration
could be changed to have the other remaining failover server act as
the peer, that way the servers would transfer the data, probably
with less risk.
Others should confirm or reject this idea.
I'm thinking just a simple cat on both files should be fine to
combine the data. And, all 3 servers are running the same
verison of dhcp (4.1.1.61) and RHEL so I don't expect and
formatting problems.
However, since failover pairs have more transitional states with
the "binding state" variable, is it possible I will run into any
issues doing this? Is there a better, more preferred way of
doing this instead of merging the leases file?
The benefit of a failover pair is that we can upgrade/repair/replace one server at a time without any interruption in service. Let's call the failover pair A-master and A-failover. The recommended method is to configure server B as master and the A-failover server as failover for server B's subnets also. Give it some time (watch the failover messages in the logs) to sync the data from B to A-failover. Then move the subnets from B to A-master, and A-master will sync the data from A-failover.
-- Bob Harold
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Thanks. So would this syntax be correct on the secondary? failover peer "dhcp-failover" { secondary; # declare this to be the secondary server address <server IP address>; port 647; peer address <A-master>; peer address <B-master>; peer port 647; max-response-delay 30; max-unacked-updates 10; load balance max seconds 5; }
I don't configure by hand any more, we bought IPAM software, but looking at what it produces, I see: On mine the peer port is different than the other port (647 vs 847), and reversed on the other end.
But more importantly, you need a whole separate "failover peer" section for each pairing, with a different name:
failover peer "pairA" { ... }
failover peer "pairB" { ... }
Then in each pool use the correct failover peer name:
subnet 10.0.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; option broadcast-address 10.0.30.255; ddns-rev-domainname "in-addr.arpa."; ddns-updates false; option netbios-node-type 8; option netbios-name-servers 141.211.21.102, 141.211.76.103; option routers 10.0.30.1; pool { failover peer "pairB"; range 10.0.30.128 10.0.30.245; } }
-- Bob Harold
Thanks for the feedback guys!
So, in this scenario I'll have 2 masters temporarily - B will become a new master and sync to A-failover, and A-master will still be in the picture as well? If I try this approach, then, I will have to add the subnets for server B to A-failover, then enable failover between B and A-failover? Wouldn't A-master have a problem with A-failover having subnets in its conf file that A-master doesn't?
Also, I'm starting to think aboout ip helper addresses. Seems like the flow would be:
Add an IP helper address on the router for server B's subnets to also point to A-failover
Once they are completely in sync then remove the IP helper for server B altogether and add another for A-master
Does that sound about right?
That is correct. A DHCP server can be master for some subnets with failover 1, and others with failover 2, and still others with no failover. A DHCP failover server can be failover for some subnets with master 3, others with master 4, and other subnets that are not using failover. The only limitation is that I don't think a server can be master for some subnets and failover for others.
p.s. Here at U of Michigan we currently have 8 pairs, and have some experience moving subnets around :) The trick is to verify that the dhcp forwarding on the routers is really working and that there is no firewall rule or acl somewhere blocking it.
-- Bob Harold
On 29/08/2018 14.28, project722 wrote:
Hey All,
We are consolidating all subnets on server B and moving to an
exisitng failover pair we have, In order to decom server B.
I'll need to take the leases file from server B and combine
whats there with the leases file on both servers in the
failover pair. (doing this to make the failover pair aware of
what leases are already out there that were assigned by server
B)
I am not sure, but I think one other way could be to make server B
part of a failover pair with one of the existing failover servers
for a period of time. That way the remaining server will have all
the information transferred from server B. Later that configuration
could be changed to have the other remaining failover server act as
the peer, that way the servers would transfer the data, probably
with less risk.
Others should confirm or reject this idea.
I'm thinking just a simple cat on both files should be fine to
combine the data. And, all 3 servers are running the same
verison of dhcp (4.1.1.61) and RHEL so I don't expect and
formatting problems.
However, since failover pairs have more transitional states with
the "binding state" variable, is it possible I will run into any
issues doing this? Is there a better, more preferred way of
doing this instead of merging the leases file?
The benefit of a failover pair is that we can upgrade/repair/replace one server at a time without any interruption in service. Let's call the failover pair A-master and A-failover. The recommended method is to configure server B as master and the A-failover server as failover for server B's subnets also. Give it some time (watch the failover messages in the logs) to sync the data from B to A-failover. Then move the subnets from B to A-master, and A-master will sync the data from A-failover.
-- Bob Harold
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
good to know. Ive been searching google much of the day and have yet to find an example of having two pairing on a single secondary server. Thanks so much!
Thanks. So would this syntax be correct on the secondary? failover peer "dhcp-failover" { secondary; # declare this to be the secondary server address <server IP address>; port 647; peer address <A-master>; peer address <B-master>; peer port 647; max-response-delay 30; max-unacked-updates 10; load balance max seconds 5; }
I don't configure by hand any more, we bought IPAM software, but looking at what it produces, I see: On mine the peer port is different than the other port (647 vs 847), and reversed on the other end.
But more importantly, you need a whole separate "failover peer" section for each pairing, with a different name:
failover peer "pairA" { ... }
failover peer "pairB" { ... }
Then in each pool use the correct failover peer name:
subnet 10.0.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; option broadcast-address 10.0.30.255; ddns-rev-domainname "in-addr.arpa."; ddns-updates false; option netbios-node-type 8; option netbios-name-servers 141.211.21.102, 141.211.76.103; option routers 10.0.30.1; pool { failover peer "pairB"; range 10.0.30.128 10.0.30.245; } }
-- Bob Harold
Thanks for the feedback guys!
So, in this scenario I'll have 2 masters temporarily - B will become a new master and sync to A-failover, and A-master will still be in the picture as well? If I try this approach, then, I will have to add the subnets for server B to A-failover, then enable failover between B and A-failover? Wouldn't A-master have a problem with A-failover having subnets in its conf file that A-master doesn't?
Also, I'm starting to think aboout ip helper addresses. Seems like the flow would be:
Add an IP helper address on the router for server B's subnets to also point to A-failover
Once they are completely in sync then remove the IP helper for server B altogether and add another for A-master
Does that sound about right?
That is correct. A DHCP server can be master for some subnets with failover 1, and others with failover 2, and still others with no failover. A DHCP failover server can be failover for some subnets with master 3, others with master 4, and other subnets that are not using failover. The only limitation is that I don't think a server can be master for some subnets and failover for others.
p.s. Here at U of Michigan we currently have 8 pairs, and have some experience moving subnets around :) The trick is to verify that the dhcp forwarding on the routers is really working and that there is no firewall rule or acl somewhere blocking it.
-- Bob Harold
On 29/08/2018 14.28, project722 wrote:
Hey All,
We are consolidating all subnets on server B and moving to an
exisitng failover pair we have, In order to decom server B.
I'll need to take the leases file from server B and combine
whats there with the leases file on both servers in the
failover pair. (doing this to make the failover pair aware of
what leases are already out there that were assigned by server
B)
I am not sure, but I think one other way could be to make server B
part of a failover pair with one of the existing failover servers
for a period of time. That way the remaining server will have all
the information transferred from server B. Later that configuration
could be changed to have the other remaining failover server act as
the peer, that way the servers would transfer the data, probably
with less risk.
Others should confirm or reject this idea.
I'm thinking just a simple cat on both files should be fine to
combine the data. And, all 3 servers are running the same
verison of dhcp (4.1.1.61) and RHEL so I don't expect and
formatting problems.
However, since failover pairs have more transitional states with
the "binding state" variable, is it possible I will run into any
issues doing this? Is there a better, more preferred way of
doing this instead of merging the leases file?
The benefit of a failover pair is that we can upgrade/repair/replace one server at a time without any interruption in service. Let's call the failover pair A-master and A-failover. The recommended method is to configure server B as master and the A-failover server as failover for server B's subnets also. Give it some time (watch the failover messages in the logs) to sync the data from B to A-failover. Then move the subnets from B to A-master, and A-master will sync the data from A-failover.
-- Bob Harold
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
Locked
