On 2022-01-13, Stefan Paetow wrote:
So in the next few months we are moving our Radiator hosts to new IP
addresses. It's unfortunately a necessary evil that needs to be done.
The first host so far has been easy because it literally only
involves an IP change.
Before going into details regarding the different scenarios, would the
following idea work:
Run two instances of Radiator on the new hosts for the required time period:
- instance A has BindAddress and LocalAddress etc. set to the new IP
- instance B has BindAddress and LocalAddress etc. set to the old IP
If the instances A and B log to different files, you can see how the
switchover is going and when instance B (old IPs) can be taken offline.
The other host(s) will need to remain live and working during the
change, so the new host has two NICs with different IP addresses.
When we cut over, the old IP address will be registered to the second
NIC of the new host. Now I want to ensure that during the cut-over
period any traffic will head out on the old IP address. Do I set
LocalAddress for this to make sure it defaults to the old IP until
such time that we switch the old IP address off, or will Radiator be
looking at the BindAddress order to decide which IP it sets as the
source? See below for some scenarios.
Within AuthBy RADIUS, and HASHBALANCE and other related clauses, the
order of preference within the clause is this: AuthBy's LocalAddress, if
configured, before global BindAddress, if configured, before the default
of 0.0.0.0.
When BindAddress contains multiple entries, then the first entry is
used. Multiple LocalAddress entries would make send with SCTP
multihoming, but in Radius case multiple entries are not useful and the
first entry is used.
With 0.0.0.0 the operating system sets the IP address when the request
is forwarded. In this case the origin IP address is the main IP address
of the interface where the traffic heads out. Please note: I haven't
tested this lately but I think this is how it still goes.
With Linux, 'ip rule ...' commands to update routing policy database
could change this.
Note that It's possible to configure BindAddress with specific IPs and
set LocalAddress to 0.0.0.0. Then the automatic IP address selection
would apply to proxied requests while specific addresses are listed on
for the incoming requests.
1. Remote host to old IP -> Radiator sets old IP from destination IP in
received packet as origin in forwarded packet
Never this. It's always one of the configured IP or the default.
2. Remote host to old IP -> Radiator sets LocalAddress as origin in forwarded
packet
When LocalAddress is configured, this is it. In this case it doesn't
matter whether BindAddress is configured or not.
3. Remote host to old IP -> Radiator sets first BindAddress entry as origin in
forwarded packet
Only when LocalAddress is not set. And if BindAddress is not set, then
0.0.0.0, as described above, is used.
4. Remote host to new IP -> Radiator sets new IP from destination IP in
received packet as origin in forwarded packet
Never this. Same as 1 - Radiator does not use IP from incoming requests.
5. Remote host to new IP -> Radiator sets LocalAddress as origin in forwarded
packet
For 5. and 6. the same rules apply as for 2. and 3.
6. Remote host to new IP -> Radiator sets first BindAddress entry as origin in
forwarded packet
7. Remote host to new IP -> Radiator broadcasts two packets to remote host (one
with old, one with new)
Never this either. This wouldn't happen automatically.
8. Remote host to either IP -> Radiator lets the wind decide which IP it sends
from in forwarded packet?
I'd say the only change for this to happen is that when OS network
interfaces are reconfigured and the effective LocalAddress is 0.0.0.0.
Thanks,
Heikki
--
Heikki Vatiainen
OSC, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software
_______________________________________________
radiator mailing list
[email protected]
https://lists.open.com.au/mailman/listinfo/radiator
