[BALUG-Admin] IPv4 IP changes coming!
Michael Paoli
Michael.Paoli@cal.berkeley.edu
Fri Dec 13 08:08:42 UTC 2019
And things continue to march (be marched) along.
Some minor glitches, but no blockers.
Minor glitches? Mostly some minor config tweaks needed
that I can't directly do, so likely involves some delayed bits
along the way (e.g. a registrar that doesn't seem to have a way
for customers to update DNS "glue" records for a record they already
created earlier with such "glue", and an ISP where changing "reverse"
DNS isn't something they can simply delegate to customers nor provide
an interface to for customers to change, but involves a manual
request and operation (submitted and awaiting completion). Thus far
otherwise smooth (some DNS slaves may also be catching up on
masters ... but that's not critical ... yet).
Oooh, and fun with multiple IPs on host, multiple ISPs, and routing. :-)
For the interested/curious:
Yummy ;-) ...
Still a work-in-progress, but we can see here (at least in relevant
parts), the BALUG virtual machine host ...
which also hosts (nearly) all* things
BALUG.org,
SF-LUG.org(/SF-LUG.com/SFLUG.org/SFLUG.com/SFLUG.net/SF-LUG.net)
BerkeleyLUG.com(/BerkeleyLUG.org),
*excepting SF-LUG's list & archive (hosted by linuxmafia.com),
and various DNS slaves, etc. ...
So, ISP services from one ISP going away ~2019-12-19,
added another ISP 2019-12-12. So, at present, e.g. this host,
has two Internet addressable IPv4 IPs, at the same time,
and routing configuration such that IPv4 packets to
The Internet, will use the gateway for the appropriate ISP,
based upon source IPv4 address.
Below we see some examples of that.
First there's a pair of traceroute checks,
these using TCP to port 53 (DNS), to an IPv4 of Google public DNS
servers, DNS not only uses UDP, but necessarily also supports TCP.
In the first of these, I explicitly set the source IP address (as
I've not yet configured it to be default source IP).
$ sudo traceroute -nTp 53 -s 96.86.170.229 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 96.86.170.230 1.474 ms 2.911 ms 3.520 ms
2 96.120.88.121 14.617 ms 18.884 ms 20.645 ms
3 68.87.198.45 20.072 ms 19.706 ms 20.017 ms
4 68.86.143.37 19.683 ms 19.965 ms 20.039 ms
5 162.151.78.185 20.156 ms 22.816 ms 27.648 ms
6 162.151.86.57 31.399 ms 37.726 ms 37.409 ms
7 96.112.146.18 37.195 ms 96.112.146.22 31.580 ms 96.112.146.26 26.923 ms
8 209.85.252.251 15.169 ms 72.14.239.43 14.840 ms 72.14.235.1 14.369 ms
9 8.8.8.8 13.882 ms 12.636 ms 16.204 ms
$
In the second, I use the old (still default) IPv4 source IP
198.144.194.238 (it would've also behaved the same if I'd explicitly
specified it).
We see both work from the host, though they (expectedly) go quite
different routes).
$ sudo traceroute -nTp 53 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 198.144.194.233 11.381 ms 12.972 ms 15.115 ms
2 216.131.94.209 17.550 ms 19.727 ms 22.060 ms
3 38.99.44.129 25.030 ms 22.815 ms 25.285 ms
4 154.54.5.233 27.864 ms 29.616 ms 154.54.6.169 31.735 ms
5 * 154.54.43.10 35.475 ms 154.54.43.14 37.156 ms
6 154.54.12.142 46.566 ms 34.548 ms 35.412 ms
7 72.14.198.30 35.582 ms 34.748 ms 35.525 ms
8 108.170.242.225 35.844 ms 34.478 ms 35.360 ms
9 108.170.236.61 34.795 ms 209.85.251.5 34.489 ms 72.14.239.43 34.121 ms
10 8.8.8.8 33.976 ms 32.869 ms 33.344 ms
$
And the relevant IPv4s (showing just that portion):
$ ip -4 a s
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
inet 198.144.194.238/29 brd 198.144.194.239 scope global eth0
valid_lft forever preferred_lft forever
inet 96.86.170.229/29 brd 96.86.170.231 scope global eth0:0
valid_lft forever preferred_lft forever
$
And the routes.
Note that we make use of a routing table and rule,
so that IP traffic from source 96.86.170.229 uses a different default
gateway:
$ ip -4 r s
default via 198.144.194.233 dev eth0 onlink
96.86.170.224/29 dev eth0 proto kernel scope link src 96.86.170.229
192.168.55.0/24 dev eth0 proto kernel scope link src 192.168.55.3
198.144.194.232/29 dev eth0 proto kernel scope link src 198.144.194.238
$ ip rule list table 134
32765: from 96.86.170.229 lookup 134
$ ip r s table 134
default via 96.86.170.230 dev eth0
$
And here's what the relevant bits look like in the
/etc/network/interfaces
file:
allow-hotplug eth0
auto eth0
iface eth0 inet static
address 198.144.194.238
netmask 255.255.255.248
network 198.144.194.232
broadcast 198.144.194.239
gateway 198.144.194.233
iface eth0:0 inet static
address 96.86.170.229
netmask 255.255.255.248
up ip route add table 134 default via 96.86.170.230
up ip rule add from 96.86.170.229 table 134
down ip rule del from 96.86.170.229 table 134
down ip route del table 134 default via 96.86.170.230
In the near future, the relationships of the IPs will essentially flip,
making the new the default, and the old - while it still exists -
also continue to function (until that ISP drops).
> From: "Michael Paoli" <Michael.Paoli@cal.berkeley.edu>
> Subject: Re: [BALUG-Admin] IPv4 IP changes coming!
> Date: Wed, 11 Dec 2019 18:45:11 -0800
> Al, yes thanks for the catch.
>
> My bad, labeled incorrectly 8-O
> That should've read:
> "new" "old"
> 96.86.170.224 198.144.194.232 network
> 96.86.170.225 198.144.194.234
> 96.86.170.226 198.144.194.235
> 96.86.170.227 198.144.194.236
> 96.86.170.228 198.144.194.237
> 96.86.170.229 198.144.194.238 balug.org./[L]UGs
> 96.86.170.230 198.144.194.233 gateway
> 96.86.170.231 198.144.194.239 broadcast
>
> Also note that they're not quite in sequence
> (as one has gateway at start of "usable" range,
> and the other has gateway at end of "usable" range).
>
> I'll also be updating:
> https://www.balug.org/wiki/doku.php?id=system:ip_addresses
> it's grossly out-of-date.
> Likewise:
> http://www.balug.org/dns/ and https://www.balug.org/dns/
> ... which I'll probably just have redirect to:
> https://www.balug.org/wiki/doku.php?id=system:ip_addresses
> ... at least when I get around to it.
>
>> From: Al <awbalug@sunnyside.com>
>> Subject: Re: [BALUG-Admin] IPv4 IP changes coming!
>> Date: Wed, 11 Dec 2019 09:38:55 -0800
>
>> Michael,
>> I think you switched old and new.
>> Since I am set up to slave 5 domains at the 198.144.194.238
>> address, I suggest just adding 96.86.170.229 to the definition now,
>> and then removing the .238 address when the .229 address is working
>> well. This is in addition to the three IPv6 addresses for various
>> domains.
>>
>> I don't use any of the other addresses.
>> I'll put that up this morning.
>> If for some reason the 96.xxx addresses have to get changed, it's easy.
>> Al
>>
>> On 12/11/2019 08:54, Michael Paoli wrote:
>>> It's anticipated/hoped, that the IPv4 changes will go approximately as
>>> follows:
>>> "old" "new"
>>> 96.86.170.224 198.144.194.232 network
>>> 96.86.170.225 198.144.194.234
>>> 96.86.170.226 198.144.194.235
>>> 96.86.170.227 198.144.194.236
>>> 96.86.170.228 198.144.194.237
>>> 96.86.170.229 198.144.194.238 balug.org./[L]UGs
>>> 96.86.170.230 198.144.194.233 gateway
>>> 96.86.170.231 198.144.194.239 broadcast
>>> The "old" IPv4 IPs will go away >~=2019-12-19, most notably of interest
>>> to BALUG/[L]UGs (,SF-LUG, BerkeleyLUG), the IPs noted as:
>>> balug.org./[L]UGs
>>> Not guaranteed until operational, but expecting likely the "new" IPv4
>>> IPs will start to become operational on or slightly after 2019-12-12,
>>> and will be transitioned to and made fully operational as quickly as
>>> feasible. It's anticipated there will be some overlap period
>>> where both are operational.
>>>
>>> Both operational(?) ... for a bit? Yes, at least that's the plan/theory,
>>> roughly like this:
>>> o new IPs added to hosts
>>> o conditional (from) routing added to hosts (from new to use new gateway)
>>> o DNS slaves updated on status once masters available on new IPs
>>> o new IPs added to DNS (some may go in phases)
>>> o "reverse" DNS updates
>>> o SMTP "tests" / warm-up
>>> o "new" default route; conditional (froms): add "old"; drop "new"
>>> (superseded)
>>> o DNS notify IPv4 source updated
>>> o "old" IPv4s removed from DNS in advance (>=TTLs) of old IPv4
>>> decommissionings
>>>
>>>> From: "Michael Paoli" <Michael.Paoli@cal.berkeley.edu>
>>>> Subject: IPv4 IP changes coming!
>>>> Date: Wed, 13 Nov 2019 05:05:23 -0800
>>>
>>>> So, I'll be changing ISP (at least for IPv4) ...
>>>> that'll mean new IPs for IPv4 ... most notably for these [L]UG domains
>>>> (and in general subdomains thereof):
>>>> balug.org
>>>> sf-lug.org sflug.org sflug.com sflug.net sf-lug.net sf-lug.com
>>>> berkeleylug.com berkeleylug.org
>>>>
>>>> A bit more generally:
>>>>
>>>> By not later than end of 2019-12-19, these IPv4 IPs (range) will be
>>>> "going away"/changing:
>>>> 198.144.194.232/29 198.144.194.232 - 198.144.194.239
>>>> 198.144.194.232
>>>> 198.144.194.233
>>>> 198.144.194.234
>>>> 198.144.194.235
>>>> 198.144.194.236
>>>> 198.144.194.237
>>>> 198.144.194.238
>>>> 198.144.194.239
>>>>
>>>> At present, my IPv6 is provided from another ISP (tunneled via IPv4),
>>>> so I'm expecting the IPv6 IPs will remain the same (at least through
>>>> this transition anyway).
>>>>
>>>> Anyway, hopefully all these changes will happen rather to quite smoothly
>>>> ... but a bit early to say. E.g., as I transition ISPs, there may be
>>>> brief(ish) period between, when temporarily neither is available.
>>>> We shall see. I'll update relevant contatct(s)/lists as/when
>>>> relevant and appropriate and I'm reasonably able to do so.
>>>> Hopefully I can minimize any "user facing" impact ... if I'm
>>>> reasonably lucky, may be able to do it quite seamlessly, with
>>>> essentially no impact to "users" ... we shall see.
>>>>
>>>> references/excerpts:
>>>> http://linuxmafia.com/pipermail/conspire/2019-November/009966.html
More information about the BALUG-Admin
mailing list