[RADIATOR] Use of Radiator during IP address switch

[Stefan Paetow]

Hi Heikki, 

Thank you very much. I'll evaluate the below and we'll see what works best. 

With kind regards

Stefan Paetow
Federated Roaming Technical Specialist

t: +44 (0)1235 822 125
e-mail/teams: stefan.paetow at jisc.ac.uk
gpg: 0x3FCE5142
On Wednesdays and Fridays, I am not available between 12:00 noon and 15:00.
In line with government advice, at Jisc we’re now working from home and our offices are currently closed. Read our statement on coronavirus <https://www.jisc.ac.uk/about/corporate/coronavirus-statement>.

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
 

On 17/01/2022, 13:40, "radiator on behalf of Heikki Vatiainen" <radiator-bounces at lists.open.com.au on behalf of hvn at open.com.au> wrote:

    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
    radiator at lists.open.com.au
    https://lists.open.com.au/mailman/listinfo/radiator