failing over better with multiple prefixes?

[Benedikt Stockebrand]

Hi Dave and list,

Dave Taht <d at teklibre.org> writes:

> Q1) Is there a "best (and cheap) way" to get a dedicated, independent
> IPv6 address space and BGP AS number that people are willing to route?

I don't know, but...

> Note that I am in the third world

... you'd best ask around locally.

Out of curiosity: Where are you?

> So joe has a dedicated IPv4 address and uses the resultant 2002
> network to add IPv6 to their net.
> [snip]

Don't use 6to4 in production environments: If the public relay you use
causes trouble you may not even know who to contact -- or how.  And if
the tunnel routers in the reverse direction don't work the situation
is even worse.

If I understand your setup correctly, then you are quite likely best
off to use tunnels (HE or whatever else you like and can get) until
your ISPs start to offer you native IPv6.

You can then route these adresses through your dedicated links as
needed.

As for the failover issue: Yes, you can advertise addresses both from
your direkt upstream and your main office in all sites, but keep the
fallback addresses deprecated until something nasty happens.  As long
as you are using tunnels to HE, consider moving your tunnel end point
to wherever there is working connectivity.  Once you have native IPv6
connectivity and a cooperative provider, use a tunnel from them
through another connection as a fallback -- yes, this requires
cooperation from your ISP.

> There are also dedicated links between the offices, in more or less of
> a wireless mountainous mesh, many of which have their own real IPv4 IP
> gateway from various providers as well, as well as a few that are
> stuck behind NAT from less wealthy providers, for which they use a
> hurricane electric tunnel currently. So it's a huge waste of very
> limited bandwidth to backhaul everything to the main office...

Will an AS and possibly PI addresses actually help in that case?

> Every machine ends up with one IPv6 address per (IPv4 or tunnel)
> gateway. This is kind of unwieldy, particularly if you want to wedge
> all this into DNS, too...

First of all, unless the situation in your setup is way beyond what
I'd consider reasonably reliable, you can normally limit yourself to
two or three addresses.

As far as the DNS issue goes: That's what scripts are there for.

> Still, this works pretty good when everything is working.

It's always good when everything is working -- the headaches come from
not thinking in time about how to keep it that way:-)

> Q2a) It's unclear, that once you start assigning multiple 2002: or
> 2001: tunnel prefixes how to make the local 2002 or 2001 gateway
> prefix be the primary source address prefix. The routers are all
> running a reasonably recent version of linux (2.6.26 at minimum), and
> have ip rules tables installed for source routing (ipv4 only at the
> moment) where needed...

You can't really do that on the routers.  Check RFC 3484 for the
details on how address selection works.  Unfortunately, at least last
time I checked Linux didn't have a configurable address selection
table -- but then, you'd have to do this on the hosts as well, so it
is pretty much out of an option.

The pragmatic way to deal with this is through the preferred lifetime
mechanism.

> Q2b) It's really unclear how IPv6 interacts with the linux RPDB these
> days...

I'd actually rather avoid using any Linux- or whatever-specific stuff
for this.

> Q3) When an external link goes down they'd like the offices to
> fail-over to routing internally to the next best gateway. But if the
> source address is 2002:the-local-office, sending stuff out
> 2002:some-other-office's-gateway isn't going to work very well.

That's another reason why you don't want to use 6to4.

> Now, I don't really want to talk about NAT. What I would like to have
> happen, is when an external tunnel goes down, that the IPv6 addresses
> derived from it become deprecated and aren't used for future
> connections, and when it goes back up they get undeprecated....
>
> It's not clear to me how to do this aside from rewriting the
> radvd.conf file and restarting radvd, and even then, there doesn't
> appear to be syntax to "deprecate" an address only (thus eliminating
> the need to remove it from DNS)

Yes, just set the preferred lifetime to 0.

> Is there something that I could use other than radvd?

The problem is not so much with radvd but with the router
advertisement protocol as such.

> it's not clear how to deprecate static addresses either (for example,
> on a DNS server or a virtual machine).

I don't have a Linux box up and running right now, so YMMV, but:

- Yes, rewrite your radvd.conf.  Setting the preferred lifetime to 0
  while keeping the valid lifetime up should do the trick.  If you do
  this in advance and/or script things, then it shouldn't be much of
  an issue.

- Using ip or ifconfig or whatever it should be possible to set the
  preferred lifetime on statically configured interfaces, too.

> Q4) This is maybe just a syntax problem with the "ip" tool
>
> For example, I can rid myself of an address by:
>
> ip addr change 2001:470:b9d7:e::1/64 dev eth1 valid_lft 1 preferred_lft 1
>
> But INTERNALLY that IPv6 address is fine, so what I really want to do
> is deprecate the address so it's not used for future external
> communication and I don't mess up any on-going internal
> communications. So, somehow, I need to "hear" from userspace, that my
> default gateway for this prefix is toast and then (for example)

So, keep the valid lifetime up but set the preferred lifetime to 0.

> ip addr change 2001:470:b9d7:e::1/64 dev eth1 deprecated
> Error: either "local" is duplicate, or "deprecated" is a garbage.
>
> (whenever this happens I can also remove the IP address from DNS via
> nsupdate)
>
> I've been fiddling with the syntax of this ip command for a while to
> no avail. (linux 2.6.32) It doesn't accept any of the other documented
> flags (primary, secondary, etc) either.

Yes, I love it, too.  At least they managed to get some sort of
documentation done by now.

> And for dynamically configured clients to able to "hear" a deprecated
> IPv6 prefix via some normal method that windows and linux clients
> would respond to without any scripting would be nice.

Just rewrite the radvd.conf and set the preferred lifetime to 0.
Somehow I have the feeling I'm repeating myself:-)

> Q5) Taking a prefix to a tunnel up or down is somewhat
> problematic. For example, right now, (what prompted this mail), my HE
> tunnel is down (external gateway is down), but it says it's up:
>
> 9: he-ipv6: <POINTOPOINT,NOARP,UP>
>      inet6 2001:470:1f0e:34a::2/64 scope global
>      inet6 fe80::c0a8:702/128 scope link
>
> So the only way I know to test the tunnel is via pinging the other
> side of it 2001:470:1f0e:34a::1,
> and if that fails, rewrite the radvd file...

Yes, that's what it boils down to, at least when the problem is on the
HE side.  In most other cases dynamic routing can do the trick, but it
would take some effort on the other side of the tunnel to do this
properly.

However, if the problem is not with HE, your script could
alternatively start a new tunnel for that prefix from elsewhere (like
your main office) and you could then re-route your traffic through
there.


Cheers,

    Ben

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.