[RADIATOR] Use of Radiator during IP address switch

[Heikki Vatiainen]

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