IPv6 mit RIPng Gateway of last resort und Passive-Interface

Routing Information Protocol Next Generation (RIPng)
Gateway of last resort und quasi Passive-Interface

<DRUCK-Version>

In diesem Workshop-Teil wollen wir ein Gateway of last resort erzeugen und das propagieren von unnötigen RIPng Paketen an den Loopback-Interfacen unterbinden.
Ziel des Default-Gateways soll ein Abfluss, aller nicht in unserem IPv6 Netzwerk vorhanden IPv6-Präfixe, über das Interface Loopback 1 des Routers in Frankfurt werden.
Als entsprechend folgender Grafik sollen unbekannte IPv6 Pakete in unserem LAB geroutet werden.

Die Basis Konfigurationen für diese Netzwerksimulation befinden sich hier zum Downloaden.
Na dann fangen wir mal auf dem Router in Frankfurt an und erzeugen eine statische Route die unbekannten IPv6 Pakete auf dem Loopback 1 hinaus routet.
FRANKFURT#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
FRANKFURT(config)#ipv6 route ::/0 loopback 1
FRANKFURT(config)#^Z
*Oct 16 13:02:09.387: %SYS-5-CONFIG_I: Configured from console by console
FRANKFURT#

Nun sollte sich in der IPv6 Routingtabelle ein statischer Routingeintrag befinden.
Das kontrollieren wir doch gleich mal.
FRANKFURT#show ipv6 route static
IPv6 Routing Table - 46 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
S   ::/0 [1/0]
     via ::, Loopback1
FRANKFURT#

Da ist der Eintrag auch schon. Jetzt muss dieser IPv6 Routingeintrag nur noch propagiert werden.
Dabei existieren, wie immer, mehrere Wege zum Ziel. Sehen wir uns zuerst den einfachen Weg an.

Variante 1
Wir konfigurieren auf den WAN-Interfacen des Routers in Frankfurt, innerhalb des RIPng-Prozesses, das Verbreiten des IPv6-Präfixes ::/0.

Auf den Interface sieht die Konfiguration des Routers wie folgt aus.
FRANKFURT#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
FRANKFURT(config)#interface serial 1/0
FRANKFURT(config-if)#ipv6 rip IPV6RIP default-information originate
FRANKFURT(config-if)#interface serial 1/1
FRANKFURT(config-if)#ipv6 rip IPV6RIP default-information originate
FRANKFURT(config-if)#interface serial 1/2
FRANKFURT(config-if)#ipv6 rip IPV6RIP default-information originate
FRANKFURT(config-if)#^Z
FRANKFURT#
*Oct 16 13:27:29.491: %SYS-5-CONFIG_I: Configured from console by console
FRANKFURT#

Was macht unser Router Frankfurt nun daraus? Sehen wir uns die RIPng Pakete mal an, die auf der Verbindung zwischen Frankfurt und Hamburg übermittelt werden.
FRANKFURT#debug ipv6 rip serial 1/0
RIP Routing Protocol debugging is on for interface Serial1/0
FRANKFURT#
*Oct 16 13:31:21.103: RIPng: Sending multicast update on Serial1/0 for IPV6RIP
*Oct 16 13:31:21.103:        src=FE80::C801:9FF:FE38:0
*Oct 16 13:31:21.103:        dst=FF02::9 (Serial1/0)
*Oct 16 13:31:21.103:        sport=521, dport=521, length=552
*Oct 16 13:31:21.103:        command=2, version=1, mbz=0, #rte=27
*Oct 16 13:31:21.103:        tag=0, metric=1, prefix=FC00:0:0:8::/64
*Oct 16 13:31:21.103:        tag=0, metric=1, prefix=FC00:0:0:9::/64
*Oct 16 13:31:21.103:        tag=0, metric=1, prefix=FC00:0:0:10::/64
*Oct 16 13:31:21.103:        tag=0, metric=1, prefix=FC00:0:0:11::/64
*Oct 16 13:31:21.103:        tag=0, metric=1, prefix=FC00:0:0:12::/64
*Oct 16 13:31:21.103:        tag=0, metric=1, prefix=FC00:0:0:13::/64
*Oct 16 13:31:21.103:        tag=0, metric=1, prefix=FC00:0:0:14::/64
*Oct 16 13:31:21.103:        tag=0, metric=3, prefix=FC01:0:0:1::/64
*Oct 16 13:31:21.103:        tag=0, metric=3, prefix=FC01:0:0:2::/64
*Oct 16 13:31:21.103:        tag=0, metric=3, prefix=FC01:0:0:3::/64
*Oct 16 13:31:21.103:        tag=0, metric=3, prefix=FC01:0:0:4::/64
*Oct 16 13:31:21.103:        tag=0, metric=3, prefix=FC01:0:0:5::/64
*Oct 16 13:31:21.103:        tag=0, metric=3, prefix=FC01:0:0:6::/64
*Oct 16 13:31:21.103:        tag=0, metric=3, prefix=FC01:0:0:7::/64
*Oct 16 13:31:21.103:        tag=0, metric=2, prefix=FC01:0:0:8::/64
*Oct 16 13:31:21.103:        tag=0, metric=2, prefix=FC01:0:0:9::/64
*Oct 16 13:31:21.103:        tag=0, metric=2, prefix=FC01:0:0:10::/64
*Oct 16 13:31:21.103:        tag=0, metric=2, prefix=FC01:0:0:11::/64
*Oct 16 13:31:21.103:        tag=0, metric=2, prefix=FC01:0:0:12::/64
*Oct 16 13:31:21.103:        tag=0, metric=2, prefix=FC01:0:0:13::/64
*Oct 16 13:31:21.103:        tag=0, metric=2, prefix=FC01:0:0:14::/64
*Oct 16 13:31:21.103:        tag=0, metric=1, prefix=FDD1:0:0:1::/64
*Oct 16 13:31:21.103:        tag=0, metric=1, prefix=FDD1:0:0:2::/64
*Oct 16 13:31:21.103:        tag=0, metric=1, prefix=FDD 1:0:0:3::/64
*Oct 16 13:31:21.103:        tag=0, metric=2, prefix=FDD1:0:0:4::/64
*Oct 16 13:31:21.103:        tag=0, metric=2, prefix=FDD1:0:0:5::/64
*Oct 16 13:31:21.103:        tag=0, metric=1, prefix=::/0
FRANKFURT#
*Oct 16 13:31:29.951: RIPng: Next RIB walk in 158496
FRANKFURT#undebug all

Ah, er sendet es artig auf dem Interface hinaus. Auf dem Router Hamburg sollte also in der IPv6 Routingtabelle der IPv6-Präfix ::/0 auftauchen.
Das Kontrollieren wir auf dem Router Hamburg mal und prüfen was er bei einem IPv6 Traceroute zu einem unbekannten Ziel macht.
HAMBURG#show ipv6 route ::/0
IPv6 Routing Table - 44 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R   ::/0 [120/2]
     via FE80::C801:9FF:FE38:0, Serial1/0
HAMBURG#traceroute ipv6 1:1:1:1:1:1:1:1

Type escape sequence to abort.
Tracing the route to 1:1:1:1:1:1:1:1

1 FDD1:0:0:1::1 20 msec 36 msec 64 msec
2 FC00:0:0:8::1 48 msec 16 msec 8 msec
3 * * *
4 * * *
(Break mit SHIFT+STRG+6 gefolgt von einem x)
HAMBURG#

Fein, zum IPv6-Ziel 1:1:1:1:1:1:1:1 läuft das Paket von Hamburg nach Frankfurt und dann am Loopback 1 Interface hinaus.
Wie sieht es denn auf dem Router Berlin aus? Der sollte dann ja die IPv6-Pakete erst nach München und dann nach Frankfurt senden.
Prüfen wir mal was der Router Berlin in seiner IPv6-Routingtabelle stehen hat und wohin er, und die Router im Pfad, die Pakete zum Ziel 1:1:1:1:1:1:1:1 übertragen.
BERLIN#show ipv6 route ::/0
IPv6 Routing Table - 44 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R   ::/0 [120/3]
     via FE80::C803:9FF:FE38:0, Serial1/0
BERLIN#traceroute ipv6 1:1:1:1:1:1:1:1

Type escape sequence to abort.
Tracing the route to 1:1:1:1:1:1:1:1

1 FDD1:0:0:5::1 56 msec 32 msec 24 msec
2 FDD1:0:0:3::1 80 msec 60 msec 80 msec
3 FC00:0:0:8::1 48 msec 20 msec 128 msec
4 * *
BERLIN#

Also ist unsere ::/0 auch in Berlin angekommen. An dem genutztem Pfad kann man gut erkennen,
dass die IPv6-Pakete erst nach München wandern um von dort nach Frankfurt übertragen zu werden.
Damit ist Variante eins auch schon beleuchtet. Jetzt löschen wir noch die WAN-Interface-Konfigurationen auf dem Router in Frankfurt und geben dem RIPng Prozess einen Schubs.
FRANKFURT#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
FRANKFURT(config)#interface serial 1/0
FRANKFURT(config-if)#no ipv6 rip IPV6RIP default-information originate
FRANKFURT(config-if)#interface serial 1/1
FRANKFURT(config-if)#no ipv6 rip IPV6RIP default-information originate
FRANKFURT(config-if)#interface serial 1/2
FRANKFURT(config-if)#no ipv6 rip IPV6RIP default-information originate
FRANKFURT(config-if)#^Z
FRANKFURT#
*Oct 16 13:56:35.379: %SYS-5-CONFIG_I: Configured from console by console
FRANKFURT#clear ipv6 rip IPV6RIP
FRANKFURT#

Variante 2
Jetzt wollen wir die bereits existierende statische IPv6-Route in den RIPng Prozess hinein heben.
Das ist ja nun keine Kunst höre ich jetzt den ein oder anderen sagen, stimmt!
Deswegen schieben wir nur diese statische Route durch eine Route-Map hindurch,
geben ihr noch einen TAG mit und setzen die Metrik so, das auf dem Router Berlin die Metrik von 15 in der IPv6 Routingtabelle steht.
Besser? ;-)

Dann werden wir uns mal eine IPv6-Präfixliste auf dem Router Frankfurt konfigurieren.
FRANKFURT#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
FRANKFURT(config)#ipv6 prefix-list DEFPREFIX seq 100 permit ::/0
FRANKFURT(config)#end
FRANKFURT#
*Oct 16 14:18:40.495: %SYS-5-CONFIG_I: Configured from console by console
FRANKFURT#

Wie stellt sich die konfigurierte IPv6-Präfixliste dar?
FRANKFURT#show ipv6 prefix-list
ipv6 prefix-list DEFPREFIX: 1 entries
   seq 100 permit ::/0
FRANKFURT#

Okay, die Präfixliste hätten wir schon mal. Jetzt ist die Route-Map dran.
FRANKFURT#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
FRANKFURT(config)#route-map REDDEFAULT permit 100
FRANKFURT(config-route-map)#match ipv6 address prefix-list DEFPREFIX
FRANKFURT(config-route-map)#set tag 99999999
FRANKFURT(config-route-map)#set metric +13
FRANKFURT(config-route-map)#^Z
FRANKFURT#

Was hat der Router aus unserer Konfiguration gemacht?
Fragen wir den Router Frankfurt mal.
FRANKFURT#show route-map
route-map REDDEFAULT, permit, sequence 100
Match clauses:
     ipv6 address prefix-list DEFPREFIX
Set clauses:
    metric +13
    tag 999
Policy routing matches: 0 packets, 0 bytes
FRANKFURT#

Dann werden wir unserem RIPng Prozess mal unsere statische IPv6-Route mal in seine Datenbank heben und sicherheitshalber dem Prozess einen kleinen Schubs geben.
FRANKFURT#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
FRANKFURT(config)#ipv6 router rip IPV6RIP
FRANKFURT(config-rtr)#redistribute static route-map REDDEFAULT
FRANKFURT(config-rtr)#^Z
*Oct 16 14:28:40.015: %SYS-5-CONFIG_I: Configured from console by console
FRANKFURT#
FRANKFURT#clear ipv6 rip IPV6RIP

Jetzt stellt sich wie immer die Frage, ob der Herr Router uns verstanden hat. Sehen wir uns das zuerst auf dem Router Frankfurt an.
FRANKFURT#show ipv6 protocols
IPv6 Routing Protocol is "connected"
<...snip...>
    Loopback1
Redistribution:
    Redistributing protocol static route-map REDDEFAULT

Das mit dem Redistributieren macht er, sagt er.
Dann sollte durch unsere IPv6-Präfixliste auch von Zeit zu Zeit die Abfrage durchlaufen.
Prüfen wir das mal lieber.
FRANKFURT#show clock
*14:23:34.823 UTC Tue Oct 16 2007
FRANKFURT#sh ipv6 prefix-list detail
Prefix-list with the last deletion/insertion: DEFPREFIX
ipv6 prefix-list DEFPREFIX:
   count: 1, range entries: 0, sequences: 100 - 100, refcount: 3
   seq 100 permit ::/0 (hit count: 130, refcount: 1)
FRANKFURT#
FRANKFURT#show clock
*14:33:46.279 UTC Tue Oct 16 2007
FRANKFURT#sh ipv6 prefix-list detail
Prefix-list with the last deletion/insertion: DEFPREFIX
ipv6 prefix-list DEFPREFIX:
   count: 1, range entries: 0, sequences: 100 - 100, refcount: 3
   seq 100 permit ::/0 (hit count: 140, refcount: 1)
FRANKFURT#

Der Hit-Counter zählt fleißig nach oben, dann sollte unsere Konfiguration eigentlich von Erfolg gekrönt sein.
Hat er unseren TAG auch verstanden? Das sehen wir uns mal mit dem Debugger auf der Verbindung zwischen Frankfurt und München an.
FRANKFURT#debug ipv6 rip serial 1/2
RIP Routing Protocol debugging is on for interface Serial1/2
FRANKFURT#
<...snip...>
FRANKFURT#
*Oct 16 14:38:19.087: RIPng: Sending multicast update on Serial1/2 for IPV6RIP
*Oct 16 14:38:19.087:        src=FE80::C801:9FF:FE38:0
*Oct 16 14:38:19.091:        dst=FF02::9 (Serial1/2)
*Oct 16 14:38:19.091:        sport=521, dport=521, length=372
*Oct 16 14:38:19.091:        command=2, version=1, mbz=0, #rte=18
*Oct 16 14:38:19.095:        tag=0, metric=2, prefix=FC00:0:0:1::/64
*Oct 16 14:38:19.095:        tag=0, metric=2, prefix=FC00:0:0:2::/64
*Oct 16 14:38:19.099:        tag=0, metric=2, prefix=FC00:0:0:3::/64
*Oct 16 14:38:19.099:        tag=0, metric=2, prefix=FC00:0:0:4::/64
*Oct 16 14:38:19.099:        tag=0, metric=2, prefix=FC00:0:0:5::/64
*Oct 16 14:38:19.103:        tag=0, metric=2, prefix=FC00:0:0:6::/64
*Oct 16 14:38:19.103:        tag=0, metric=2, prefix=FC00:0:0:7::/64
*Oct 16 14:38:19.107:        tag=0, metric=1, prefix=FC00:0:0:8::/64
*Oct 16 14:38:19.107:        tag=0, metric=1, prefix=FC00:0:0:9::/64
*Oct 16 14:38:19.111:        tag=0, metric=1, prefix=FC00:0:0:10::/64
*Oct 16 14:38:19.111:        tag=0, metric=1, prefix=FC00:0:0:11::/64
*Oct 16 14:38:19.111:        tag=0, metric=1, prefix=FC00:0:0:12::/64
*Oct 16 14:38:19.115:        tag=0, metric=1, prefix=FC00:0:0:13::/64
*Oct 16 14:38:19.115:        tag=0, metric=1, prefix=FC00:0:0:14::/64
*Oct 16 14:38:19.119:        tag=0, metric=1, prefix=FDD1:0:0:1::/64
*Oct 16 14:38:19.119:        tag=0, metric=1, prefix=FDD1:0:0:2::/64
*Oct 16 14:38:19.119:        tag=0, metric=1, prefix=FDD1:0:0:3::/64
*Oct 16 14:38:19.123:        tag=999, metric=13, prefix=::/0
FRANKFURT#undebug all
All possible debugging has been turned off
FRANKFURT#

Prima, auch den konfigurierten TAG=999 kann der Router interpretieren.
Sollte jemand einen größeren TAG als 57599 eingegeben haben, dann wird er genau 57599 darin finden, auch TAG-Felder sind endlich.
Nun sehen wir uns aber endlich das Resultat unserer Konfiguration auf dem Router in Berlin an.
BERLIN#show ipv6 route ::/0
IPv6 Routing Table - 44 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R   ::/0 [120/15], tag 999
     via FE80::C803:9FF:FE38:0, Serial1/0
BERLIN#

Damit ist fürs Erste genug mit dem Teil der Default-Gateway unter IPv6 mit RIPng,
wenden wir uns jetzt dem leidigen Thema Passiv-Interface unter RIPng zu.
Wie du sicher gemerkt hast, existiert unter RIPng kein Netzwerk-Statement oder Passive-Interface Befehl.
Aus diesem Grunde sprechen die Router auch gleich fleißig RIPng, wenn man ein Interface mit "ipv6 rip IPV6RIP enable" konfiguriert.
Da das nicht immer gewollt ist, kommt man um ein Redistributieren leider nicht herum.
Solltest du einen anderen Weg kennen, schick mir die Lösung oder den Lösungsansatz bitte per eMail:

Okay, gehen wir es mal für den Router in Berlin durch.
Die Loopback-Interface müssen natürlich aus dem RIPng raus genommen werden.
BERLIN#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
BERLIN(config)#interface Loopback1
BERLIN(config-if)#no ipv6 rip IPV6RIP enable
BERLIN(config-if)#interface Loopback2
BERLIN(config-if)#no ipv6 rip IPV6RIP enable
BERLIN(config-if)#interface Loopback3
BERLIN(config-if)#no ipv6 rip IPV6RIP enable
BERLIN(config-if)#interface Loopback4
BERLIN(config-if)#no ipv6 rip IPV6RIP enable
BERLIN(config-if)#interface Loopback5
BERLIN(config-if)#no ipv6 rip IPV6RIP enable
BERLIN(config-if)#interface Loopback6
BERLIN(config-if)#no ipv6 rip IPV6RIP enable
BERLIN(config-if)#interface Loopback7
BERLIN(config-if)#no ipv6 rip IPV6RIP enable
BERLIN(config-if)#end
BERLIN#

Wir wollen dessen direkt angeschlossene Interface in den RIPng-Prozess heben.
Was brauchen wir dafür? Klar, eine IPv6-Präfixliste und eine Route-Map.
Dann bauen wir uns die IPv6-Präfixliste mal auf dem Router Berlin.
BERLIN#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
BERLIN(config)#ipv6 prefix-list LOOPBACKS seq 5 permit FC01::/16 ge 64
BERLIN(config-rtr)#^Z
BERLIN#

Da sollten unsere Loopback IPv6-Präfixe aus Berlin eigentlich durch passen.
Jetzt binden wir die IPv6-Präfixliste in eine Router-Map als Filterkriterium ein.
BERLIN#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
BERLIN(config)#route-map REDLOOP permit 100
BERLIN(config-route-map)#match ipv6 address prefix-list LOOPBACKS
BERLIN(config-route-map)#set metric +0
BERLIN(config-route-map)#end
*Oct 16 16:08:02.395: %SYS-5-CONFIG_I: Configured from console by console
BERLIN#

Die erzeugte Route-Map muss jetzt in den RIPng-Prozess eingehängt werden.
Damit der Routingprozess es auch gleich merkt, geben wir dem RIPng lieber noch einen Schubs.
BERLIN#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
BERLIN(config)#ipv6 router rip IPV6RIP
BERLIN(config-rtr)#redistribute connected route-map REDLOOP
BERLIN(config-rtr)#end
*Oct 16 16:10:38.911: %SYS-5-CONFIG_I: Configured from console by console
BERLIN#
BERLIN#clear ipv6 rip

Nach einer kleinen Kaffeepause, sollten auf dem Nachbar-Router München die IPv6-Präfixe der Loopback-Interface vom Router Berlin auch wieder auftauchen.
Werfen wir mal einen Blick in die RIPng Datenbank.
MUENCHEN#show ipv6 rip database | begin FC01:0:0:1.*
FC01:0:0:1::/64, metric 2, installed
     Serial1/2/FE80::C804:9FF:FE38:0, expires in 171 secs
FC01:0:0:2::/64, metric 2, installed
     Serial1/2/FE80::C804:9FF:FE38:0, expires in 171 secs
FC01:0:0:3::/64, metric 2, installed
     Serial1/2/FE80::C804:9FF:FE38:0, expires in 171 secs
FC01:0:0:4::/64, metric 2, installed
     Serial1/2/FE80::C804:9FF:FE38:0, expires in 171 secs
FC01:0:0:5::/64, metric 2, installed
     Serial1/2/FE80::C804:9FF:FE38:0, expires in 171 secs
FC01:0:0:6::/64, metric 2, installed
     Serial1/2/FE80::C804:9FF:FE38:0, expires in 171 secs
FC01:0:0:7::/64, metric 2, installed
     Serial1/2/FE80::C804:9FF:FE38:0, expires in 171 secs
<...snip...>
::/0, metric 14 tag 999, installed
     Serial1/0/FE80::C801:9FF:FE38:0, expires in 178 secs
MUENCHEN#

In der RIPng Datenbank sind die IPv6-Präfixe gut zu sehen. Dann erwarten wir sie jetzt auch in der Routingtabelle ingress Serial 1/2.
MUENCHEN#show ipv6 route interface serial 1/2
IPv6 Routing Table - 46 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R   FC01:0:0:1::/64 [120/2]
     via FE80::C804:9FF:FE38:0, Serial1/2
R   FC01:0:0:2::/64 [120/2]
     via FE80::C804:9FF:FE38:0, Serial1/2
R   FC01:0:0:3::/64 [120/2]
     via FE80::C804:9FF:FE38:0, Serial1/2
R   FC01:0:0:4::/64 [120/2]
     via FE80::C804:9FF:FE38:0, Serial1/2
R   FC01:0:0:5::/64 [120/2]
     via FE80::C804:9FF:FE38:0, Serial1/2
R   FC01:0:0:6::/64 [120/2]
     via FE80::C804:9FF:FE38:0, Serial1/2
R   FC01:0:0:7::/64 [120/2]
     via FE80::C804:9FF:FE38:0, Serial1/2
C   FDD1:0:0:5::/64 [0/0]
     via ::, Serial1/2
L   FDD1:0:0:5::1/128 [0/0]
     via ::, Serial1/2
MUENCHEN#

Die Konfiguration, die wir jetzt in Berlin getippt haben passt, dank der IPv6-Präfixliste, auch in München.
Portieren wir also den gesamten Konfigurationsvorgang auf dem Router in München.
MUENCHEN#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
MUENCHEN(config)#interface Loopback1
MUENCHEN(config-if)#no ipv6 rip IPV6RIP enable
MUENCHEN(config-if)#interface Loopback2
MUENCHEN(config-if)#no ipv6 rip IPV6RIP enable
MUENCHEN(config-if)#interface Loopback3
MUENCHEN(config-if)#no ipv6 rip IPV6RIP enable
MUENCHEN(config-if)#interface Loopback4
MUENCHEN(config-if)#no ipv6 rip IPV6RIP enable
MUENCHEN(config-if)#interface Loopback5
MUENCHEN(config-if)#no ipv6 rip IPV6RIP enable
MUENCHEN(config-if)#interface Loopback6
MUENCHEN(config-if)#no ipv6 rip IPV6RIP enable
MUENCHEN(config-if)#interface Loopback7
MUENCHEN(config-if)#no ipv6 rip IPV6RIP enable
MUENCHEN(config-if)#ipv6 prefix-list LOOPBACKS seq 5 permit FC01::/16 ge 64
MUENCHEN(config)#route-map REDLOOP permit 100
MUENCHEN(config-route-map)# match ipv6 address prefix-list LOOPBACKS
MUENCHEN(config-route-map)# set metric +0
MUENCHEN(config-route-map)#ipv6 router rip IPV6RIP
MUENCHEN(config-rtr)# redistribute connected route-map REDLOOP
MUENCHEN(config-rtr)#end
*Oct 16 16:26:35.683: %SYS-5-CONFIG_I: Configured from console by console
MUENCHEN#clear ipv6 rip

Das Resultat sollte nach der üblichen RIPng Kaffeepause auf dem Router in Berlin sichtbar sein.
Sehen wir mal in die IPv6 Routingtabelle.
BERLIN#show ipv6 route fc01::/16 longer-prefixes | begin ^R
R   FC01:0:0:8::/64 [120/2]
     via FE80::C803:9FF:FE38:0, Serial1/0
R   FC01:0:0:9::/64 [120/2]
     via FE80::C803:9FF:FE38:0, Serial1/0
R   FC01:0:0:10::/64 [120/2]
     via FE80::C803:9FF:FE38:0, Serial1/0
R   FC01:0:0:11::/64 [120/2]
     via FE80::C803:9FF:FE38:0, Serial1/0
R   FC01:0:0:12::/64 [120/2]
     via FE80::C803:9FF:FE38:0, Serial1/0
R   FC01:0:0:13::/64 [120/2]
     via FE80::C803:9FF:FE38:0, Serial1/0
R   FC01:0:0:14::/64 [120/2]
     via FE80::C803:9FF:FE38:0, Serial1/0
BERLIN#

Auch erledigt.
Dann werden wir die IPv6-Präfixtabelle mal für die Loopback-Interface vom Router in Frankfurt anpassen und den gesamten Portierungsvorgang in Frankfurt wiederholen.
FRANKFURT#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
FRANKFURT(config)#interface Loopback1
FRANKFURT(config-if)#no ipv6 rip IPV6RIP enable
FRANKFURT(config-if)#interface Loopback2
FRANKFURT(config-if)#no ipv6 rip IPV6RIP enable
FRANKFURT(config-if)#interface Loopback3
FRANKFURT(config-if)#no ipv6 rip IPV6RIP enable
FRANKFURT(config-if)#interface Loopback4
FRANKFURT(config-if)#no ipv6 rip IPV6RIP enable
FRANKFURT(config-if)#interface Loopback5
FRANKFURT(config-if)#no ipv6 rip IPV6RIP enable
FRANKFURT(config-if)#interface Loopback6
FRANKFURT(config-if)#no ipv6 rip IPV6RIP enable
FRANKFURT(config-if)#interface Loopback7
FRANKFURT(config-if)#no ipv6 rip IPV6RIP enable
FRANKFURT(config-if)#ipv6 prefix-list LOOPBACKS seq 5 permit FC00::/16 ge 64
FRANKFURT(config)#route-map REDLOOP permit 100
FRANKFURT(config-route-map)# match ipv6 address prefix-list LOOPBACKS
FRANKFURT(config-route-map)# set metric +0
FRANKFURT(config-route-map)#ipv6 router rip IPV6RIP
FRANKFURT(config-rtr)# redistribute connected route-map REDLOOP
FRANKFURT(config-rtr)#end
*Oct 16 16:32:14.547: %SYS-5-CONFIG_I: Configured from console by console
FRANKFURT#clear ipv6 rip

Damit ist der Router in Frankfurt nun auch schweigsam auf seinen Loopback-Interfacen.
Fehlt zu guter Letzt nur noch die Konfiguration auf dem Router in Hamburg.
Da diese identisch zur Konfiguration in Frankfurt ist, werden wir diese wieder benutzen.
HAMBURG#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
HAMBURG(config)#interface Loopback1
HAMBURG(config-if)#no ipv6 rip IPV6RIP enable
HAMBURG(config-if)#interface Loopback2
HAMBURG(config-if)#no ipv6 rip IPV6RIP enable
HAMBURG(config-if)#interface Loopback3
HAMBURG(config-if)#no ipv6 rip IPV6RIP enable
HAMBURG(config-if)#interface Loopback4
HAMBURG(config-if)#no ipv6 rip IPV6RIP enable
HAMBURG(config-if)#interface Loopback5
HAMBURG(config-if)#no ipv6 rip IPV6RIP enable
HAMBURG(config-if)#interface Loopback6
HAMBURG(config-if)#no ipv6 rip IPV6RIP enable
HAMBURG(config-if)#interface Loopback7
HAMBURG(config-if)#no ipv6 rip IPV6RIP enable
HAMBURG(config-if)#ipv6 prefix-list LOOPBACKS seq 5 permit FC00::/16 ge 64
HAMBURG(config)#route-map REDLOOP permit 100
HAMBURG(config-route-map)# match ipv6 address prefix-list LOOPBACKS
HAMBURG(config-route-map)# set metric +0
HAMBURG(config-route-map)#ipv6 router rip IPV6RIP
HAMBURG(config-rtr)# redistribute connected route-map REDLOOP
HAMBURG(config-rtr)#end
*Oct 16 16:35:33.059: %SYS-5-CONFIG_I: Configured from console by console
HAMBURG#clear ipv6 rip
HAMBURG#clear ipv6 route *
HAMBURG#

Zur Qualitätskontrolle sehen wir am Ende dieses Workshops jetzt noch einmal auf dem Router in Dresden nach, ob alle 28 IPv6-Loopback-Präfixe in der IPv6-Routingtabelle stehen.
DRESDEN#show ipv6 route rip | include ^R.*FC0.*
R   FC00:0:0:1::/64 [120/3]
R   FC00:0:0:2::/64 [120/3]
R   FC00:0:0:3::/64 [120/3]
R   FC00:0:0:4::/64 [120/3]
R   FC00:0:0:5::/64 [120/3]
R   FC00:0:0:6::/64 [120/3]
R   FC00:0:0:7::/64 [120/3]
R   FC00:0:0:8::/64 [120/2]
R   FC00:0:0:9::/64 [120/2]
R   FC00:0:0:10::/64 [120/2]
R   FC00:0:0:11::/64 [120/2]
R   FC00:0:0:12::/64 [120/2]
R   FC00:0:0:13::/64 [120/2]
R   FC00:0:0:14::/64 [120/2]
R   FC01:0:0:1::/64 [120/3]
R   FC01:0:0:2::/64 [120/3]
R   FC01:0:0:3::/64 [120/3]
R   FC01:0:0:4::/64 [120/3]
R   FC01:0:0:5::/64 [120/3]
R   FC01:0:0:6::/64 [120/3]
R   FC01:0:0:7::/64 [120/3]
R   FC01:0:0:8::/64 [120/2]
R   FC01:0:0:9::/64 [120/2]
R   FC01:0:0:10::/64 [120/2]
R   FC01:0:0:11::/64 [120/2]
R   FC01:0:0:12::/64 [120/2]
R   FC01:0:0:13::/64 [120/2]
R   FC01:0:0:14::/64 [120/2]
DRESDEN#

Da sind ja alle 28 ;-))
Die oben genannten Aufgaben sind für das Gateway of last resort durch zwei mir bekannte Varianten realisierbar,
für das Passive-Interface ist mir nur dieser Pfad bekannt. Damit ihr euer Resultat vergleichen könnt sind hier wie immer die Konfigurationen aller Router.
Ich hoffe auch dieser Workshop hat euch Spaß gemacht, euer Eric.