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.