Dedicated IP Addresses for Network Devices

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

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.

jaredhh36 wrote: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.

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.

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.

lajackson wrote: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.

russellhltn wrote: 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.

lajackson wrote: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.

lajackson wrote: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.

Mikerowaved wrote: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.

russellhltn wrote: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.

russellhltn wrote: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.

jaredhh36 wrote: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.

jaredhh36 wrote: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.

danpass wrote: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.

jaredhh36 wrote: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.

lajackson wrote:I have not yet reloaded it but will do so later this week.

No, actually, I won't. I forgot that I have to

travel to the stake center,
power up the Teradek VidiU encoder and
get it functioning on the network,
have the firewall look for it and snag the MAC address (it is not good enough for me to type it in,
although I understand the error avoidance benefit of reading it via the network),
assign the MAC address to a new IP (because it will not come up on the one I will assign),
reboot the encoder to verify that it will be assigned to the correct IP address,
and finally turn off the encoder, go home, and hope it sticks until stake conference.

Or there will be two more extra boots of the encoder to do it again.
And another unplanned trip to the stake center, where I do not attend meetings very regularly.

Just as a point of reference for webcasting, our stake has used Win7+encoder, and then the Teradek for the last 9 years. Additionally, we have 4 bldgs in the stake and rotate the conference origin bldg every 6 months. We have not had any transmitting problems (knock on wood). We have always used un-reserved DHCP address assignment.

CalS201 wrote:We have always used un-reserved DHCP address assignment.

I have done that successfully, also. However, it is much nicer to find the VidiU where it is expected and already have the bookmarks set in the browsers that will be used to control and monitor the webcast. It saves the trouble of drilling down through the box menu to find the IP address where it landed. Of course, we originate from the stake center and do not rotate meetinghouses, so that also makes it easier for us.

I work with some assistants who are very willing and are quick learners, but still do not understand why an IP address even matters, even when I explain it to them using telephone number terminology.

lajackson wrote:

lajackson wrote:I have not yet reloaded it but will do so later this week.

No, actually, I won't. I forgot that I have to

travel to the stake center,
power up the Teradek VidiU encoder and
get it functioning on the network,
have the firewall look for it and snag the MAC address (it is not good enough for me to type it in,
although I understand the error avoidance benefit of reading it via the network),
assign the MAC address to a new IP (because it will not come up on the one I will assign),
reboot the encoder to verify that it will be assigned to the correct IP address,
and finally turn off the encoder, go home, and hope it sticks until stake conference.

Or there will be two more extra boots of the encoder to do it again.
And another unplanned trip to the stake center, where I do not attend meetings very regularly.

Yeah, I had hoped to be able to re-assign IP addresses from home, but discovered that it wasn't possible unless the devices are currently powered up and on the network.

Suggestion to developers:
If you won't allow the manual entry of a MAC address for an IP assignment, why not at least allow past assignments to be reinstated.
TM knows about past IP assignments made, given they can be viewed using the Action History feature. In our case, the history doesn't list assignments that were made prior to October, but it does show one that I added in October, which as I mentioned in an earlier post, has since been lost.

We have a proposed fix to all known bugs/behaviors causing assigned IP reservations to be lost. It is currently planned to go live Friday morning 2/14 (Happy Valentine's!). Please feel free to re-test after that, unless you hear from me otherwise.

Has anyone been able to re-enter their devices into the reserved IP Assignments list? I would love some feedback if you've tried this again.

I put one in on Jan. 9 and it stayed in through our changes on Feb. 14, plus during more changes that we did a week or so later; so we're feeling good about it. Plus we have a few other live networks we tested on and they are working 100%.

Dan - regarding your feedback, I did some research:

danpass wrote:If you won't allow the manual entry of a MAC address for an IP assignment, why not at least allow past assignments to be reinstated.

First, regarding the manual entry of MAC addresses: The main developer told me that TM interacts directly with Meraki's API and we currently do not have a solution to help you/ourselves if a MAC address gets entered incorrectly. So unfortunately for now we cannot take that chance and are only allowing the system to detect and register the MAC address.

Second, regarding the suggestion to pull from history: This should be doable; I'll submit the feature request to our TM dev team and they'll add it to their list of to-do items. Now I'm not sure when it will happen, so for now we'll have to keep with the old way of connecting the device to the network and registering it in TM while it's on and connected.

Thank you for explaining the reason for not allowing manual MAC entry and for considering the suggestion.

I added assignments on Jan 14, Feb 6 and Feb 13. All 3 are still configured. Thanks for your work resolving this issue.

I entered an IP assignment on January 17 that is still showing.