 Geschrieben von Beat Rubischon (Link) am
Samstag, 17. November 2007, 23:32
aus dem *big-setup* dept.
Wie reagieren Hosts, wenn plötzlich zwei IPv6 Prefixes in einem LAN announct werden? Eine interessante Frage, auf die es nur eine Antwort gibt: Ausprobieren!
Nebst meinem nativen IPv6 Uplink über PPPoA habe ich mir einen Tunnel bei SixXS eingerichtet. So standen mir auf dem Router die beiden Prefixes 2001:8e0:1006::/48 und 2001:7b8:3c1::/48 zur Verfügung. Laut Dokumentation sollte der Router IPv6 Policy Based Routing beherrschen.
Ich machte folgende Anpassungen. Erst einmal beide Defaultrouten eintragen, damit das ipv6 verify unicast reverse-path noch funktioniert:
ipv6 route ::/0 Tunnel0 80
ipv6 route ::/0 Dialer1
Für eine Route Map braucht es erst einmal eine Access Liste, damit ich bestimmen kann, für welche Pakete sie gilt. Das Folgende ist nicht der erste Entwurf - eher das Resultat mehrerer Pings und Traceroutes:
ipv6 access-list altuplink
remark Alternative IPv6 Range
deny ipv6 any 2001:8E0:1006::/48
deny ipv6 any 2002::/16
permit ipv6 2001:7B8:3C1::/48 any
Alle Pakete, die eine Absenderadresse aus dem SixXS Prefix haben, aber nicht zum Interway Prefix oder zu einer 6to4 Adresse gehen, sollen matchen. Diese ACL kommt nun in einer Route Map zum Zug:
route-map altuplink permit 10
description Alternative IPv6 Range
match ipv6 address altuplink
set interface Tunnel0
Damit die Pakete auch in diese Regeln fallen, muss das Policy based Routing auf den Ethernet Interfaces aktiviert werden:
interface Ethernet0
ipv6 policy route-map altuplink
!
interface Ethernet2
ipv6 policy route-map altuplink
Das war es schon. Damit weiss der Router, dass die beiden Uplinks aufgrund der Quellenip geroutet werden sollen. Das soll übrigens so auch unter IPv4 gehen, habe ich aber nicht ausprobiert.
Nun muss der neue Prefix noch announct werden. Die Adresse zu den Interfaces hinzufügen ist eigentlich schon genug, ich schraube aber noch etwas am Router Advertisement herum:
interface Ethernet0
ipv6 address 2001:7B8:3C1::/64 eui-64
ipv6 address 2001:8E0:1006::/64 eui-64
ipv6 nd suppress-ra
!
interface Ethernet2
ipv6 address 2001:7B8:3C1:1::/64 eui-64
ipv6 address 2001:8E0:1006:1::/64 eui-64
ipv6 nd prefix 2001:7B8:3C1:1::/64 3600 900
ipv6 nd prefix 2001:8E0:1006:1::/64 3600 900
Noch bevor die Konfig im NVRAM war, hatte meine melone bereits zwei IPv6 Adressen:
en1: flags=8863 mtu 1500
inet6 fe80::211:24ff:fea8:6b9%en1 prefixlen 64 scopeid 0x5
inet6 2001:7b8:3c1:1:211:24ff:fea8:6b9 prefixlen 64 autoconf
inet6 2001:8e0:1006:1:211:24ff:fea8:6b9 prefixlen 64 autoconf
Nun begann der Spass! Schnell stellte sich heraus, das "benachbarte" Ranges bevorzugt werden. So gehen Verbindungen zu Interway eher über 2001:8e0:1006::/48 raus, Verbindungen zur Switch oder dem FreeBSD FTP Server über 2001:7b8:3c1::/48. Ganz ähnlich verhaltet sich auch aktuelle Linux 2.6er Kernels - RFC 3484, welches dieses Verhalten definiert, ist weitgehenst implementiert. Im Gegensatz dazu macht der 2.4er Kernel ein stures die letzte Adresse zählt.
Nächster Test war noch die Reaktion der typischen Adress Verifikationsroutinen. Die libwrap macht beispielsweise erst eine Anfrage welcher Name gehört zu dieser Adresse und anschliessend eine Anfrage welche Adresse gehört zu diesem Namen bevor ein eingetragener Name akzeptiert wird. Und tatsächlich kommt die libwrap mit mehreren Adressen zurecht.
Dummerweise befinden sich beide Prefixes am "oberen Ende" des derzeitigen Internets. Der native Uplink ist zudem noch etwas höher als der Tunnel - damit werden überdurchschnittlich viele Verbindungen über den Tunnel geroutet. Eigentlich nicht das, was man sich als Besitzer eines "echten" IPv6 Uplinkes wünscht - entsprechend habe ich mir den Prefix wieder aus dem Announcement genommen:
interface Ethernet2
ipv6 nd prefix 2001:7B8:3C1:1::/64 no-advertise
ipv6 nd prefix 2001:8E0:1006:1::/64 3600 900
Beim statischen Routing mag es etwas anders aussehen. ip -6 route add hat die nette Option src, mit welcher sich die Absenderadresse setzen lässt. Doch habe ich (noch) nur einen 2.4er Kernel da, wo ich statische IPs einsetze - und der nimmt stur die letzte globale IP Adresse als Quelle.
Zum Schluss noch zwei Traceroutes. Erst die Switch:
max:~# traceroute6 mirror.switch.ch
traceroute to moon.switch.ch
from 2001:8e0:1006::2, 30 hops max, 16 byte packets
1 rt-1.0x1b.ch 1.771 ms 2.165 ms 1.991 ms
2 2001:8e0:0:ffff::b 20.681 ms 17.019 ms 19.452 ms
3 f0-0.zelja.zh.ipv6.as8758.net 16.935 ms 94.324 ms 21.046 ms
4 2001:7f8:24::34 21.01 ms 19.35 ms 19.507 ms
5 swiEZ2-10GE-5-4.switch.ch 21.546 ms 19.127 ms 20.426 ms
6 swiCS3-10GE-1-1.switch.ch 22.412 ms 17.54 ms 19.832 ms
7 moon.switch.ch 19.965 ms 19.443 ms 19.977 ms
max:~# traceroute6 -s 2001:7b8:3c1::2 mirror.switch.ch
traceroute to moon.switch.ch
from 2001:7b8:3c1::2, 30 hops max, 16 byte packets
1 rt-1.0x1b.ch 3.743 ms 2.714 ms 2.453 ms
2 gw-379.ede-01.nl.sixxs.net 30.458 ms 35.206 ms 35.084 ms
3 sixxs-gw.ipv6.network.bit.nl 34.648 ms 35.378 ms 35.422 ms
4 2001:7b8::219:e200:10c:3000 35.236 ms 35.17 ms 30.89 ms
5 zpr2.amt.cw.net 36.611 ms 34.256 ms 35.966 ms
6 so-0-0-0-dcr2.fra.cw.net 47.124 ms 46.856 ms 49.945 ms
7 so-5-0-0-bcr2.fra.cw.net 47.663 ms 46.326 ms 48.157 ms
8 ge-1-3-0-iar1.fra.cw.net 49.979 ms 49.998 ms 52.214 ms
9 2001:5001:200:6::2 74.304 ms 71.91 ms 72.185 ms
10 2001:2000:3010::2 72.277 ms 77.523 ms 72.393 ms
11 telia-v6.rt1.lon.uk.geant2.net 72.951 ms 73.368 ms 73.335 ms
12 so-4-0-0.rt1.par.fr.geant2.net 83.242 ms 83.708 ms 80.576 ms
13 so-7-3-0.rt1.gen.ch.geant2.net 96.833 ms 96.142 ms 98.408 ms
14 switch-gw.rt1.gen.ch.geant2.net 88.909 ms 85.221 ms 83.386 ms
15 swiLS2-10GE-1-3.switch.ch 90.269 ms 89.326 ms 85.736 ms
16 swiEZ2-10GE-1-1.switch.ch 88.625 ms 91.027 ms 91.521 ms
17 swiCS3-10GE-1-1.switch.ch 91.756 ms 89.214 ms 89.788 ms
18 moon.switch.ch 92.795 ms 90.335 ms 90.322 ms
Und der FreeBSD FTP Server:
max:~# traceroute6 ftp.freebsd.org
traceroute to ftp.freebsd.org
from 2001:8e0:1006::2, 30 hops max, 16 byte packets
1 rt-1.0x1b.ch 3.876 ms 3.243 ms 2.369 ms
2 2001:8e0:0:ffff::b 20.404 ms 20.453 ms 18.976 ms
3 eth0-1-1.ghayda.glb.ipv6.as8758.net 22.501 ms 19.403 ms 20.195 ms
4 f0-0.zelja.zh.ipv6.as8758.net 20.483 ms 18.974 ms 20.379 ms
5 2001:7f8:c:8235:194:42:48:75 22.014 ms 21.601 ms 31.528 ms
6 ip-1-3-0-2.sltnxj2.inet6.tele.dk 71.97 ms 67.454 ms 69.908 ms
7 tun6.r149.ipv6.opa.tdk.net 72.713 ms 67.234 ms 71.038 ms
8 tun6.r149.ipv6.opa.tdk.net 72.013 ms !S 68.89 ms !S 72.982 ms !S
max:~# traceroute6 -s 2001:7b8:3c1::2 ftp.freebsd.org
traceroute to ftp.freebsd.org
from 2001:7b8:3c1::2, 30 hops max, 16 byte packets
1 rt-1.0x1b.ch 4.009 ms 2.468 ms 2.652 ms
2 gw-379.ede-01.nl.sixxs.net 32.567 ms 31.771 ms 32.975 ms
3 sixxs-gw.ipv6.network.bit.nl 32.152 ms 35.341 ms 34.24 ms
4 2001:7b8::219:e200:10c:3000 35.332 ms 32.719 ms 35.909 ms
5 ge-1-11.r01.amstnl02.nl.bb.gin.ntt.net 36.127 ms 33.545 ms 34.841 ms
6 xe-2-0-0.r23.amstnl02.nl.bb.gin.ntt.net 35.392 ms 36.284 ms 37.362 ms
7 xe-0-2-0.r22.amstnl02.nl.bb.gin.ntt.net 34.932 ms 32.751 ms 34.986 ms
8 p64-2-0-0.r23.londen03.uk.bb.gin.ntt.net 61.91 ms 43.137 ms 43.772 ms
9 xe-4-4.r00.londen03.uk.bb.gin.ntt.net 40.801 ms 42.865 ms *
10 fa-0-0.r00.londen03.uk.b6.gin.ntt.net 44.61 ms 42.978 ms 42.978 ms
11 tu-0.teledanmark.londen03.uk.b6.gin.ntt.net 82.333 ms 79.32 ms 81 ms
12 fe0-0-460.100M.sltnxt99.ip.tele.dk 77.322 ms 78.773 ms 84.295 ms
13 tun6.r149.ipv6.opa.tdk.net 77.073 ms 81.013 ms 79.339 ms
14 tun6.r149.ipv6.opa.tdk.net 79.753 ms !S 77.683 ms !S 81.528 ms !S
Beides wunderbare Beispiele, die aufgrund der RFC3484 Entscheidung über den "teureren" Link gehen.
Vielleicht eben doch "richtiges" Multihoming, wie wir es von IPv4 kennen? Dafür ist es wahrscheinlich schon zu spät. Ein /48 gilt als Micro Allocation und ist bis auf wenige Ausnahmen nicht mehr legitim.
Permalink
|
Re: Multihomed