On Thu, Dec 19, 2002 at 10:34:30AM +0100, Christian Schild wrote:
> Am Mittwoch, 18. Dezember 2002 22:34 schrieb Mark Doll:
> > W�re es nicht sinnvoller statt eines /112er eine dedizierte Host-Route
> > auf das Gegen�ber plus eine /112er Unreachable-Route zu setzen?
>
> Wir haben uns entschlossen fuer jeden unserer Kunden ein /112-Subnetz
> zu definieren und zu reservieren. Wir haben dies zur Vereinheitlichung
> fuer jeden Kunden gemacht, _manchmal_ benoetigt man das zwingend (IBGP).
> Ausserdem habe wir die /48-Routen bei uns auf diese Interfaceadresse und
> nicht auf das Tunnelinterface gelegt. Dies ist ebenfalls zur
> Vereinheitlichung, bei nativen PtP-Verbindungen ist dies notwendig.
> Weiterer Vorteil ist, das der Kunde 'gezwungen' ist, die von uns gewuenschte
> Adresse auf das Verbindungsinterface zu legen, und wir so zuverlaessig und
> einheitlich die Verbindung ueberwachen koennen.
>
> > Als Beispiel unter Linux hier unser 6WiN-Uplink:
> >
> > Anstatt also wie bisher
> >
> > ip tunnel add 6win mode sit remote 193.174.75.249 local 141.3.70.6 ttl 64
> > ip link set 6win up
> > ip addr add 2001:638:0:300::204:2/112 dev 6win
> > [...]
> >
> > zu setzen, nicht lieber so:
> >
> > ip tunnel add 6win mode sit remote 193.174.75.249 local 141.3.70.6 ttl 64
> > ip link set 6win up
> > ip addr add 2001:638:0:300::204:2 dev 6win
> > ip route add 2001:638:0:300::204:1 dev 6win
> > ip route add unreachable 2001:638:0:300::204:0/112
Das produziert gegen�ber von Einzel-IPs nur weitere Routingeintr�ge,
die bei Einzel-IPs gar nciht erst n�tig gewesen w�ren.
> Der entscheidende Punkt hier ist, das es sich um ein Tunnel-Interface
> handelt. Bei einer nativen Verbindung waere dies so nicht moeglich.
Nein - das Entscheidende ist, da� es sich um ein PtP Interface handelt.
Ob das jetzt �ber eine Seriele oder einen Tunnel geht ist ein anderer
Layer.
Bei einer Broadcastverbindung ist das was anderes, da kann es mehr als
2 Endstellen geben und zudem ist das mit den ungenutzten IPs auch kein
so gro�es Problem.
> Von unserer Seite aus behandeln wir aber alle Kundenverbindungen gleich,
> also wie eine native Verbindung.
>
> Tatsaechlich koennte man das so auf einem Tunnelinterface machen. Generell
> besteht bei einem Tunnel keine Notwendigkeit fuer die /112 Route (von
> Kundenseite aus). Ich hab mich neulich schon mal mit jemandem darueber
> gestritten, auch bei BSD ginge das aehnlich, dort kann man offenbar 'ueber'
> den V4-Tunnel einfach einen V6-Tunnel (mit den beiden /128-Adressen, die
> dann auch Routingeintrage bekommen) legen.
Sorry, wenn das als �streiten� aufkam - ich wollte es nur verstehen.
Nein - ich vergeben einfach nur dem Tunnel IP-Addressen.
Das ist jetzt der aktuelle Tunnel zum JOIN:
[59]srv1.cosmo-project.de# ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet 213.83.6.106 --> 128.176.191.82
inet6 fe80::2d0:b7ff:fe0a:b170%gif1 prefixlen 64 scopeid 0x4
inet6 3ffe:401:1::8d0:2 prefixlen 112
Diese hingegen der Tunnel zu einer anderen Endstelle:
[62]srv1.cosmo-project.de# ifconfig gif3
gif3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet 213.83.6.106 --> 194.77.111.182
inet6 fe80::2d0:b7ff:fe0a:b170%gif3 prefixlen 64 scopeid 0x6
inet6 3ffe:400:8d0:101::4 --> 3ffe:400:8d0:200::1 prefixlen 128
Der einzige Unterschied ist, das jetzt beim JOIN Tunnel ein Netz
draufliegt und bei dem anderen zwei Einzel-IPs.
Das hat uberhaupt nichts mit verschachtelten Tunneln zu tun.
Routingtechnisch gibt es f�r die benutzten IPs keinen Unterschied:
[71]srv1.cosmo-project.de# route get -inet6 3ffe:401:1::8d0:1
route to: 3ffe:401:1::8d0:1
destination: 3ffe:401:1::8d0:1
interface: gif1
flags: <UP,HOST,DONE,LLINFO,WASCLONED>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 1280 0
[72]srv1.cosmo-project.de# route get -inet6 3ffe:400:8d0:200::1
route to: 3ffe:400:8d0:200::1
destination: 3ffe:400:8d0:200::1
interface: gif3
flags: <UP,HOST,DONE>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 1280 0
Der Unterschied ist hier nur, da� die Route zur JOIN Gegenstelle erst
von der /112 Netzroute abgeleitet wurde - deshalb die anderen Flags.
Auch die lokalen sind bekannt:
[73]srv1.cosmo-project.de# route get -inet6 3ffe:401:1::8d0:2
route to: 3ffe:401:1::8d0:2
destination: 3ffe:401:1::8d0:2
interface: lo0
flags: <UP,HOST,DONE,LLINFO,LOCAL>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 1280 0
[74]srv1.cosmo-project.de# route get -inet6 3ffe:400:8d0:101::4
route to: gif-2pk.cosmo-project.de
destination: gif-2pk.cosmo-project.de
interface: lo0
flags: <UP,HOST,DONE,LLINFO,LOCAL>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 1280 0
Es gibt einige Vorteile von Einzel-IPs:
Zum einen habe ich die M�glichkeit an jedem Standort nur lokale IPs
zu vergeben, was Vorteile bei Ausf�llen hat, da man das Reversemapping
mit gr��erer Wahrscheinlichkeit noch aufl�sen kann.
Zum anderen gibt es keine IPs f�r die sich keiner Zust�ndig f�hlt und
damit Ping Pong spielen k�nnen.
Mehr als zwei IPs k�nnen ja auch im Normalfall auf eine PtP Interface
nicht sinnvoll benutzt werden.
Die Vorteile von einem Netz sind mir leider immer noch nicht klar.
Bis auf den Verdacht, da� Ihr wohl mit kaputen PtP Implementierungen
zu k�mpfen habt, die mit Einzel IPs nicht zurecht kommen.
--
B.Walter COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
_______________________________________________
ipv6 mailing list
[EMAIL PROTECTED]
http://listserv.uni-muenster.de/mailman/listinfo/ipv6
