[ixpmanager] Migration to another IPv4 range

[aleksandr at speed-ix.net]

Hi Nick,

Thank you for your fast reaction and reply.

In total, it's clear how to act on side of the IXP manager and RSs.

The biggest problem from our point of view is the migration of members. As soon as the first member will change their setting to use new IPs (RouteServers, Collectors, etc) they will not be able to exchange traffic with other members and the traffic of this member will be gone from IXP till the rest will do changes. Otherwise, they must keep sessions with old RouteServers till all members will migrate to the new IPs.

With kind regards, Aleksandr Belytskyi

NOC engineer
Speed Internet Exchange
Phone: +31(0)887378399
More: https://speed-ix.net/about-speed-ix/

----------------------------------------
From: "Nick Hilliard (INEX)" <nick at inex.ie>
Sent: 28/10/2021 18:59
To: aleksandr at speed-ix.net, INEX IXP Manager Users Mailing List <ixpmanager at inex.ie>
Subject: Re: [ixpmanager] Migration to another IPv4 range

aleksandr at speed-ix.net wrote on 28/10/2021 14:58:
> We have only one VLAN and we would like to keep it like it is.
> I will be glad to hear any proposal, if not then we will try to find out
> such a migration plan ourselves.

Hi Aleksandr,

INEX did this in 2016, and we temporarily maintained two mysql instances
and two www virtual servers. We announced a change freeze several days
before the migration, and kept the old IP address database as the
customer-visible DB. The new IP address database was manually
synchronised using mysqldump. On the day of the start of the cut-over,
we changed the IXP Manager to be the new DB. When we completed the
migration 5 days later, the old DB was turned off.

Other than that, all INEX services were replicated (i.e. new set of
route servers, route collectors, AS112 all built on new IP ranges). This
also allowed the opportunity to do a full stack upgrade on these (OS,
Bird versions, configurations - e.g. in that window we enabled large BGP
community support on the new route servers).

Handling this in a more automated way would probably require a
substantially more complicated overall systems design.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.inex.ie/pipermail/ixpmanager/attachments/20211029/73d4c824/attachment.htm>