Routing problem - can this be done?
-
@Pete-S said in Routing problem - can this be done?:
They don't have to be per se. It's just that they have to have static IPs since that is how the servers know which one is which.
Clearly here is an example that shows why coding to an IP is a horrible practice. Coding to a hostname would be much better - Best would be some code/number/whatever assigned to the device that exists outside of it's communication method.
-
@Dashrender said in Routing problem - can this be done?:
@Pete-S said in Routing problem - can this be done?:
They don't have to be per se. It's just that they have to have static IPs since that is how the servers know which one is which.
Clearly here is an example that shows why coding to an IP is a horrible practice. Coding to a hostname would be much better - Best would be some code/number/whatever assigned to the device that exists outside of it's communication method.
It's possible to change the server to using hostnames but it will cause other problems instead.
If you define the hosts in the DNS server you still have to use static IPs or you have to use DHCP reservations and set the hostname there and have the DHCP server update the DNS. But if you use DHCP reservations you have to tie the IP to the MAC address which makes the devices not field replaceable.
-
I may have found a solution and that is to skip routing and bridge instead.
I'll bridge together all VPN connections in the data center router. And use OpenVPN in tap mode (= L2 bridge) for the VPN links. Then all devices can share the same subnet. Broadcast traffic goes everywhere and everyone knows where packets should be sent to reach its destination.
Hmm, I have to mull it over.
-
@Pete-S said in Routing problem - can this be done?:
@Dashrender said in Routing problem - can this be done?:
@Pete-S said in Routing problem - can this be done?:
They don't have to be per se. It's just that they have to have static IPs since that is how the servers know which one is which.
Clearly here is an example that shows why coding to an IP is a horrible practice. Coding to a hostname would be much better - Best would be some code/number/whatever assigned to the device that exists outside of it's communication method.
It's possible to change the server to using hostnames but it will cause other problems instead.
If you define the hosts in the DNS server you still have to use static IPs or you have to use DHCP reservations and set the hostname there and have the DHCP server update the DNS. But if you use DHCP reservations you have to tie the IP to the MAC address which makes the devices not field replaceable.
I take it the server reaches out to the devices, not the other way around?
Ubiquiti APs work by the APs reaching out to the server, not the other way, this means the server doesn't really care what the IP address of the AP is, or what it's name is, etc. When you adopt the AP into the server, it's now a known device. The AP checks in with enough frequency that any updates you make at the server are distributed to the APs at a pace admins are happy with.
-
@Pete-S said in Routing problem - can this be done?:
But if you use DHCP reservations you have to tie the IP to the MAC address which makes the devices not field replaceable.
Still field replaceable. In one case the field tech has to set the IP on the device, in the other case their set it on the DHCP server. Same change. But one is more flexible and some changes can be done without a field tech.
-
@scottalanmiller said in Routing problem - can this be done?:
@Pete-S said in Routing problem - can this be done?:
But if you use DHCP reservations you have to tie the IP to the MAC address which makes the devices not field replaceable.
Still field replaceable. In one case the field tech has to set the IP on the device, in the other case their set it on the DHCP server. Same change. But one is more flexible and some changes can be done without a field tech.
But he already said the field tech doesn't have the ability to change DHCP, so that makes change-outs harder as it requires more people to be involved.
-
@Dashrender said in Routing problem - can this be done?:
@scottalanmiller said in Routing problem - can this be done?:
@Pete-S said in Routing problem - can this be done?:
But if you use DHCP reservations you have to tie the IP to the MAC address which makes the devices not field replaceable.
Still field replaceable. In one case the field tech has to set the IP on the device, in the other case their set it on the DHCP server. Same change. But one is more flexible and some changes can be done without a field tech.
But he already said the field tech doesn't have the ability to change DHCP, so that makes change-outs harder as it requires more people to be involved.
Ah, missed that. Field tech COULD change the MAC address, though.
-
@scottalanmiller said in Routing problem - can this be done?:
@Dashrender said in Routing problem - can this be done?:
@scottalanmiller said in Routing problem - can this be done?:
@Pete-S said in Routing problem - can this be done?:
But if you use DHCP reservations you have to tie the IP to the MAC address which makes the devices not field replaceable.
Still field replaceable. In one case the field tech has to set the IP on the device, in the other case their set it on the DHCP server. Same change. But one is more flexible and some changes can be done without a field tech.
But he already said the field tech doesn't have the ability to change DHCP, so that makes change-outs harder as it requires more people to be involved.
Ah, missed that. Field tech COULD change the MAC address, though.
Field techs are technical people but not sysadmins.
The customer has a 24/7 operation so the field techs are on call and will come in within an hour or so and replace stuff in the middle of the night, on weekends, on Christmas Day or whenever it's needed. -
@Dashrender said in Routing problem - can this be done?:
I take it the server reaches out to the devices, not the other way around?
Yes, that's correct. To use the right terminology it's actually the devices that are the servers and the "servers" in the data center are the clients.
-
Anyway, I will go with bridging for now.
I don't think bridging will cause any problems in this case. Traffic is intermittent and low speed so even if there are more broadcast traffic sent over the VPN links, compared to a routing solution, I don't think it will have any impact.
But I'll probably set up some kind of test to make sure before deploying.
