Dedicated IP Addresses for Network Devices

[jaredhh36]

Network Engineering would like to move away from using static IP addresses in meetinghouses, so that we can make network changes without impacting local devices.

We would like this forum's feedback on the following proposal:
* All devices in meetinghouses should use DHCP addressing.
* For devices requiring a dedicated IP address, use Technology Manager (TM) to reserve a dedicated IP address for a device set to DHCP.
* See attached document for how to do this.

Specific questions:
1. Did you try this and did it work as detailed in the document?
2. Can you think of any devices that would not support this proposal?
3. Are there any other reasons we should not move forward with this proposal?

We appreciate your input.

Product Management - Network Engineering

[russellhltn]

I've set up our Teradek video encoder with a static IP in the device. I don't want the unit to have to renew an IP lease in the middle of a broadcast. (call me paranoid) I do reserve an IP for it in TM, but the device itself is not set to DHCP, so it won't know about any changes.

The second issue - who is going to inform FamilySearch about any change in the assigned static IP for the FHC printers? FamilySearch queries the status of FHC printers from time to time to know when to send the FHC a new toner cartridge. They need a fixed/known static IP on the 10.x.x.x. network to do that. In the past, the STS or similar has had to register the printer with them. But it really shouldn't fall on the STS to update that if the network folks decide to change assignments.

In addition, how will the various computers (both FHC and local unit) know about a printer's new IP address? All my setups have been static IP and they're rock solid. I'm not sure as "by name" is that reliable.

[lajackson]

Network Engineering would like to move away from using static IP addresses in meetinghouses, so that we can make network changes without impacting local devices.
...
* All devices in meetinghouses should use DHCP addressing.
...
3. Are there any other reasons we should not move forward with this proposal?

I have assigned a static IP address to the Teradek VidiU encoder using Technology Manager. I left the encoder set to DHCP, although I share the concern of russellhltn that if the encoder goes wandering off for an IP lease renewal during a webcast, we are in deep trouble.

While it is possible to deal with the situation, it is very labor intensive to make the required adjustments when the IP address of the encoder changes. Before we realized the address could be reserved in TM, a good portion of time during the setup of each test and live webcast required finding and obtaining the IP address of the encoder and then programming it into everything else we use to control and monitor the encoder and the webcast.

The problem I have encountered in using only TM to reserve an IP address at the firewall is that every few months the reservation goes away. I have not been able to determine (yet) why this happens, but it nearly cost us a stake conference webcast recently. If I find out about it in time, of course I can establish the reservation again. But I do not believe I should have to do this on a regular basis.

But when the encoder IP address changes, it is not normally discovered until immediately before a test or live webcast when the encoder does not boot up and connect as expected. We have moved checking an unintended IP address change to the top of our troubleshooting list, but whether we accept and deal with the temporary change or switch back to the previously assigned and expected setting, it is a time-consuming process that does not need to take place just before a webcast begins.

I am not familiar with but believe there are some significant issues in the Family History Center that would be affected by the change of IP addresses.

Other than the need to communicate with the Teradek VidiU encoder during our all important stake conference and other webcasts, and however the FHC would be affected, I am not aware of anything else that would be of concern.

Thank you for asking. It would be nice if we were informed that a block of static IP addresses was changing, but I do not hold any expectation that this would ever happen as a part of the process. Just a hunch from years and years of experience beginning with the MIS/FIS days.

[russellhltn]

jaredhh36,

Can you calrify what zone we're talking about? It strikes me as odd that you'd want to make changes to the 192.168.x.x User zone. The 10.x.x.x "SP' or "FAC" zone, I can understand.

If we're not talking about the 196.168.x.x, then I can take the Teradek off the table (at least as far as my stake). Also the printer(s) for the local units. That just leaves FHC printer issues.

One item I did forget: our 4 satellite receivers. They're on the FAC zone and I'm pretty sure Technology Manager has to know their static IP to communicate with them.

[Mikerowaved]

Handling static IP addresses using the firewall/router GUI is my preferred way of doing this at home. I can see all the assignments in one place, and if the assignment falls inside the DHCP IP pool, the router knows how to avoid reassigning that address.

The problem I have encountered in using only TM to reserve an IP address at the firewall is that every few months the reservation goes away. I have not been able to determine (yet) why this happens, but it nearly cost us a stake conference webcast recently. If I find out about it in time, of course I can establish the reservation again. But I do not believe I should have to do this on a regular basis.

I've also made static assignments in TM that have disappeared. Are these (or can these be) uploaded to the church somehow so they survive a firewall reset?

Also, can the church developers PLEASE get away from the practice of putting menu items in obscure places? I'm referring to using the 3-dots and the down triangle next to the DEVICES tab. For that matter, get rid of the DEVICES tab and list each of the 4 items as their own main level tab. It's just not intuitive for the occasional (2-3 times a year) user. As far as the 3-dot button goes, why not give each of the items their own blue button somewhere much further to the left than the 3-dots are now? Easy to see and easy to find.

[jaredhh36]

I don't want the unit to have to renew an IP lease in the middle of a broadcast. (call me paranoid) I do reserve an IP for it in TM, but the device itself is not set to DHCP, so it won't know about any changes.

I share the concern of russellhltn that if the encoder goes wandering off for an IP lease renewal during a webcast, we are in deep trouble.

I think there may be some confusion about how a DHCP reservation works.

First, regardless of reservations, the DHCP protocol is designed specifically to prevent losing connectivity during IP lease renewals. RFC2131 Sec 4.4.5 specifies that a device will attempt to renew its ip address by default at half the server assigned lease time. This is currently set to 30 minutes (because of high turnover on the wireless side), so at 15 minutes prior to the lease expiring, the device will start attempting to renew. What that means is it will never change its IP address unless it cannot contact the DHCP server (the MX64 in this case) for 15 minutes, and the lease expires. But if it cannot reach the router then the stream is dead anyway. For anyone who is has a Teradek using DHCP today, if you have done a broadcast lasting an hour, your device has done at least 3 renewals already without a hiccup.

So unless the network is dead (in which case, you have bigger problems), DHCP lease renewal isn't going to be a problem.

Second, if there is a DHCP reservation for a device, then no other device can get that IP address, and the device it was assigned to will only ever get that particular IP address. This is unlike the non-reservation case where if a client does not renew when a lease expires (probably because it isn't on the network), there is no guarantee that it will get the same IP address when it comes back (though it may try).

So there really isn't a case where a device can wander off in the middle of a broadcast event. Between events and without DHCP reservations, when the devices or perhaps the networks themselves are off for an extended period of time, then yes that is a possibility.

The problem I have encountered in using only TM to reserve an IP address at the firewall is that every few months the reservation goes away. I have not been able to determine (yet) why this happens, but it nearly cost us a stake conference webcast recently. If I find out about it in time, of course I can establish the reservation again. But I do not believe I should have to do this on a regular basis.

I've also made static assignments in TM that have disappeared. Are these (or can these be) uploaded to the church somehow so they survive a firewall reset?

We agree this is concerning. You definitely should not have to do this on a regular or even intermittent basis.

DHCP leases are stored in the Meraki cloud currently and not in TM or in the local router. We are aware of one event where existing DHCP reservations made in TM were lost because of a migration script that failed to take them into account during a large series of Meraki organization splits and migrations. The script will be fixed shortly if it isn't already, so that should not happen again. But each network would only have moved once and so only lost its reservations once.

There are a group of pilot networks that do get moved from time to time that could lose their leases more than once, but if you were part of the pilot group you would know about it and we would have expected to hear about the repeated lost leases sooner. I suspect none of the pilot group is using the DHCP reservation feature.

If it is still happening to you (or if anyone else here sees this again), please open a ticket with the Help Desk as soon as it occurs again so we can find out why.

who is going to inform FamilySearch about any change in the assigned static IP for the FHC printers? FamilySearch queries the status of FHC printers from time to time to know when to send the FHC a new toner cartridge. They need a fixed/known static IP on the 10.x.x.x. network to do that. In the past, the STS or similar has had to register the printer with them. But it really shouldn't fall on the STS to update that if the network folks decide to change assignments.
In addition, how will the various computers (both FHC and local unit) know about a printer's new IP address? All my setups have been static IP and they're rock solid. I'm not sure as "by name" is that reliable.

We are working with FamilySearch on how they are managing their printers and FHCs generally. We are exploring with them changing that printer support model.

In any case, we hope that changing the IP addresses in the DHCP reservations in 10.0.0.0/8 address space will be fairly rare, and we intend to give them a list of old->new mappings when it happens so they can update their own systems. Other DHCP delivered settings (like DNS servers) could change more often, though still somewhat rarely.

For things in the 192.168.108.0/22 space, we expect that will change even more rarely, though we have talked about going to 192.168.104.0/21 to give more space and longer DHCP lease times. That would likely be a one time event, and again we would give more details and guidance at that time.

As far as clients using hardcoded IP addresses for printers, this is something we do need to get away from for exactly the reasons you describe...it is painful to change when we need to.

Can you calrify what zone we're talking about? It strikes me as odd that you'd want to make changes to the 192.168.x.x User zone. The 10.x.x.x "SP' or "FAC" zone, I can understand.

If we're not talking about the 196.168.x.x, then I can take the Teradek off the table (at least as far as my stake). Also the printer(s) for the local units. That just leaves FHC printer issues.

One item I did forget: our 4 satellite receivers. They're on the FAC zone and I'm pretty sure Technology Manager has to know their static IP to communicate with them.

To be clear we are talking about all zones, as just mentioned above.

Regarding satellite receivers, you are correct. These don't do DHCP; these would have to stay static for now (for those that are still being used and if remote network management on them is still desired). Good catch, thanks.

Also, please note that for all of the above, these are our working "plans", but our plans are subject to change. And we'll follow the normal procedures of notifications in advance before any of these "plans" occur.

[russellhltn]

First, regardless of reservations, the DHCP protocol is designed specifically to prevent losing connectivity during IP lease renewals.

I agree that's how it's supposed to work. But in my personal experience with my own home router, I've periodically lost connection for a minute or so when I had a short lease. It disappeared with a longer lease.

Maybe it won't happen with the Teridek and the Cisco. But the key to a successful webcast is by eliminating as many opportunities for Murphy as possible. I'm willing to take a chance of discovering a setup problem caused by going from 192.168.108.0/22 to 192.168.108.0/21 as opposed to dealing why something glitched out mid-broadcast.

[danpass]

DHCP leases are stored in the Meraki cloud currently and not in TM or in the local router. We are aware of one event where existing DHCP reservations made in TM were lost because of a migration script that failed to take them into account during a large series of Meraki organization splits and migrations. The script will be fixed shortly if it isn't already, so that should not happen again. But each network would only have moved once and so only lost its reservations once.

In early August, when testing for our stake conference, I discovered that all of our IP assignments were no longer listed in TM and no longer in effect. I did not add them back at the time. On October 16 I added a single assignment (in the User zone) for the stake clerk office printer. The Action History does show that I did this and the details of the assignment. However, that assignment is no longer listed in the assigned devices list.

So we have lost DHCP reservations twice.

[jaredhh36]

So we have lost DHCP reservations twice.

Thank you for sharing this. After further research, we confirmed another condition where a change on our side caused the TM reservations to be lost. We are working on a fix soon.

[lajackson]

After further research, we confirmed another condition where a change on our side caused the TM reservations to be lost.

Sometime since late September our stake firewall has also lost its assigned IP reservation for our Teradek VidiU encoder. I have not yet reloaded it but will do so later this week.