In message <[email protected]>
Brian E Carpenter writes:
> Admittedly 6renum was targetted at enterprise networks, partly because
> of the
> observation that homenets renumber anyway after every power cut. But
> we have spent a lot of cycles on this issue.
>
> http://tools.ietf.org/html/rfc4192
> http://tools.ietf.org/html/rfc5887
> http://tools.ietf.org/html/rfc6866
> http://tools.ietf.org/html/rfc6879
> http://tools.ietf.org/html/rfc7010
> and maybe it's time to revive
> https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines
>
> Brian
Brian,
To summarize my prior inelegantly made point:
Perhaps the emphasis should not be on "network renumbering is hard"
encouraging further whining. The emphasis should not be on "network
renumbering does not need to be hard but can be very hard if certain
bad network management practices are followed".
Through some coincidence or bad karma, my colocation provider arranged
for a quick demo. I was typing through an slogin when I noticed no
response. To make a long story short the colo provider planned
renumbered into a new IPv6 space, sent a mass email which is probably
in my spam folder (to: undiclosed; bcc: ..the world..), and then did
the renumber.
When I called and heard about this it didn't really bother me partly
since it Sunday. IPv4 still worked so I could recover.
First fix all of my stored config files in one shot.
foreach f ( `find * -type f | xargs grep -l 2001:550:3800` )
sed < $f > $f.tmp -e 's,<old>,<new>,g' && mv $f.tmp $f
end
Then push these out to one bhyve host and two VM.
gmake REMOTE_HOST=<host> REMOTE_USER=root SSH_AF_ARG=-4 install
Then slogin to each and compare old and new:
sh build-02-etc-files.sh -cmp | & less
After that check update it
sh build-02-etc-files.sh -destdir / -targethost <host>
Then for the VM with jails check first
foreach j ( <list of jail names> )
sh build-03-jails.sh -cmp -destdir /j0/$j -targethost $j |& less
end
then update
/etc/rc.d/jail stop
foreach j ( <list of jail names> )
sh build-03-jails.sh -config-only -destdir /j0/$j -targethost $j
end
then restart the VMs (old interface was used new one is shown):
/etc/bhyve/rc.d/<host> restart
Done with everything at the colo site.
Then figure out (very easily, look in a file) who is running a caching
nameserver with DNS secondaries configured to the old addresses.
if it is not a jail:
gmake REMOTE_HOST=<host> REMOTE_USER=root SSH_AF_ARG=-4 install
if it is a jail then on the supporting host:
sh build-03-jails.sh -config-only -destdir /j0/<host> -targethost <host>
then
ssh <host> -l root /usr/local/etc/rc.d/named stop
ssh <host> -l root rm -f /etc/named/s/*
ssh <host> -l root /usr/local/etc/rc.d/named start
Done with all hosts
Now just fix DNS glue records at the registrar and done.
The whole thing was under two hours including adding the SSH_AF_ARG
support to a bunch of gmake .mk files.
2 rackmount servers
1 destop (DNS only)
4 VM on the 3 rackmounts
16 jails on the 4 VMs
rebuild zone files, named.conf (part of the gmake)
update sendmail config files
all system files such as rc.conf and sshd_config
web server config including virtual host configs
unaffected were kdc and svn server (no fixed addresses).
This was all done remotely (since I still had working IPv4).
Not terribly painful. But it could have been. Not planned, but a
quick demo of renummbering something that looks a bit more like an
enterprise network than a homenet (because it is).
Curtis
ps- and no these gmake files and perl and shell stuff is not yet
available anywhere. Sorry.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
