Liebe Update-Verweigerer …

… eure Zeit ist vorbei. Sowas will ich hier nicht mehr sehen, und werde deshalb mit Hilfe von Browser-Update.org dezente Hinweise einblenden, wenn hier jemand mit einem veralteten Browser vorbei schaut.
Danke an das Rootserver-Blog für den Hinweis.

Advertisements
Liebe Update-Verweigerer …

MacHeist Bundle

Apple OS XVor kurzem gab es die MacBundleBox. Jetzt erschien gerade eine neue Version des MacHeist Bundles. Neun bis dreizehn Anwendungen zum Preis von 39$. Die interessanteste Anwendung für mich ist “Little Snapper”, das ich sowieso kaufen wollte. Da das alleine schon 39$ kosten würde, kann man mit dem Bundle auch nichts verkehrt machen.
Wer sich die Aktion auf der Webseite noch nicht durchgelesen hat, der wundert sich evtl. über das “neun bis dreizehn”. 25% des Umsatzes werden an wohltätige Zwecke gespendet. Wenn mehr Geld dafür zusammen kommt, werden mehr Anwendungen “freigeschaltet”. Und die ersten 25000 Besteller bekommen noch eine Spielesammlung dazu.
Na, wenn das nichts ist!

MacHeist Bundle

Die OSPF Prozess ID beim PE-CE-Routing

router
Wenn OSPF als IGP in einem Netz konfiguriert wird, ist die Prozess-ID nur lokal signifikant. Es ist keine AS-Nummer wie bei EIGRP, und daher funktioniert folgende Konfiguration ohne Probleme:

hostname R1
router ospf 10
 network 10.10.10.1 0.0.0.0 area 0

hostname R2
router ospf 20
 network 10.10.10.2 0.0.0.0 area 0

Etwas anders verhält sich die Sache aber, wenn man OSPF als PE-CE-Routing-Protokoll einsetzt. In den original Kursunterlagen zum Kurs “Implementing Cisco MPLS” kann man folgendes zum Thema nachlesen:

process-id: Internally used identification parameter for an OSPF routing process.
This parameter is locally assigned and can be any positive integer. A unique value is assigned for each OSPF routing process.

Wenn man seine PE-Router aber so konfiguriert, bekommt man nicht das erwartete Ergebnis.
Um das zu verdeutlichen, habe ich die Konfiguration des MPLS-Kurses verwendet:
pe-ce-ospf
Die (relevante) Konfiguration des CE11A:

router ospf 5
 network 10.1.11.17 0.0.0.0 area 0
 network 150.1.11.17 0.0.0.0 area 0

Die (relevante) Konfiguration des CE12A:

router ospf 6
 network 10.1.12.17 0.0.0.0 area 0
 network 150.1.12.17 0.0.0.0 area 0

Die (relevante) Konfiguration des PE11:

router ospf 10 vrf CUST-A
 redistribute bgp 65001 subnets
 network 150.1.11.18 0.0.0.0 area 0

Die (relevante) Konfiguration des PE12:

router ospf 20 vrf CUST-A
 redistribute bgp 65001 subnets
 network 150.1.12.18 0.0.0.0 area 0

Wie man sieht, sind alle Prozess-IDs unterschiedlich, was innerhalb eines AS kein Problem darstellen würde.
Wenn man sich die Routing-Tabelle der CE-Router anschaut, zeigt sich aber folgendes Problem:

CE11A#sh ip route ospf
     10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
O E2    10.1.12.16/28 [110/65] via 150.1.11.18, 00:26:01, Serial1/0.101
     150.1.0.0/28 is subnetted, 2 subnets
O E2    150.1.12.16 [110/1] via 150.1.11.18, 00:26:01, Serial1/0.101

Die Routen werden als External gelernt, anstelle als Inter-Area-Routen, wie es sein sollte.

Eine Möglichkeit, das Problem zu lösen, ist, für jeden Kunden dieselbe Prozess-ID zu benutzen.
Es geht aber auch anders. Innerhalb des PE-OSPF-Prozesses kann die domain-id spezifiziert werden. Wenn diese auf den PE-Routern für jeden Kunden identisch ist, werden die Routen wie gewünscht als IA gelernt.
Die PE12-Konfig wird folgendermaßen angepaßt:

router ospf 20 vrf CUST-A
 domain-id 0.0.0.10
 redistribute bgp 65001 subnets
 network 150.1.12.18 0.0.0.0 area 0

Jetzt passt die Routing-Tabelle auf CE11A:

CE11A#sh ip route ospf
     10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
O IA    10.1.12.16/28 [110/129] via 150.1.11.18, 00:00:35, Serial1/0.101
     150.1.0.0/28 is subnetted, 2 subnets
O IA    150.1.12.16 [110/65] via 150.1.11.18, 00:00:35, Serial1/0.101

Warum das Ganze? Aus der Prozess-ID wird der Domain-Identifier abgeleitet und standardmäßig als extended Community Wert 0005 übertragen (beschrieben im RFC 4577).
Die Domain ID des PE11 kommt also bei PE12 an (ich habe “Extended Community” gegen “ExtCom” abgekürzt, damit es lesbar bleibt):

PE12#sh ip bgp vpnv4 all 10.1.11.16
BGP routing table entry for 65001:10:10.1.11.16/28, version 44
Paths: (1 available, best #1, table CUST-A)
  Not advertised to any peer
  Local
    192.168.1.17 (metric 193) from 192.168.1.17 (192.168.1.17)
      Origin incomplete, metric 65, localpref 100, valid, internal, best
      ExtCom: RT:65001:10 OSPF DOMAIN ID:0x0005:0x0000000A0200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:150.1.11.18:0
      mpls labels in/out nolabel/11107

Die “0A” ist in diesem Fall die hexadezimale Form der “10”, die auf PE11 konfiguriert ist. Wenn auf PE11 domain-id 11.12.13.14 konfiguriert wäre, käme bei PE12 folgendes an: OSPF DOMAIN ID:0x0005:0x0B0C0D0E0200

Der Standard sieht jetzt vor, daß eine Route mit abweichender Domain-ID als External importiert wird. Ist die Domain-ID hingegen identisch, wird sie als Inter-Area-Route importiert. Die ganze Sache kann aber noch dadurch erweitert werden, daß es mehr als eine Domain-ID geben kann.

Die OSPF Prozess ID beim PE-CE-Routing

Cisco Catalyst IOS 12.2(50)SE

Mit dem neuen IOS 12.2(50)SE für die Catalysten 3560/3750 und 2960 gibt es ein paar sehr interessante Neuerungen:

  • Etliche Features, die bisher nur im Advanced IP Services Image waren, sind in das IP Base Image gekommen. Das sind z.B. ACLs und DHCP für IPv6 auf dem 3560/3750.
  • EIGRP, OSPF und HSRP für IPv6 sind jetzt im IP Services Image. (3560/3750)
  • Das Adv. IP Services Image gibt es nicht mehr.
  • IS-IS ist im IP Services Image verfügbar (3560/3750). Wenn die ASA das jetzt auch noch lernen würde, dann könnte ich zu Hause umstellen … 😉
  • Dynamic ARP Inspection gibt es jetzt auch auf dem 2960.
Cisco Catalyst IOS 12.2(50)SE

Remote RIP-Routing

IGPs werden normalerweise dazu verwendet, um direkt angeschlossenen Nachbarn Routing-Informationen zu senden. Aber was ist, wenn man einem entfernten Router ein Update senden möchte:

remote-rip

Kann R3 ein RIP-Update an R1 senden wenn R2 kein RIP spricht? Tunnel etc. sind natürlich nicht erlaubt. Ja, es geht. Z.B., indem R3 diesen Traffic direkt per Unicast versendet.
Die Konfiguration von R1 startet mit einer IP auf dem Interface und dem Aktivieren von RIP:

interface FastEthernet0/0
 ip address 10.10.1.1 255.255.255.0
!
router rip
 version 2
 passive-interface default
 network 10.0.0.0
 no auto-summary

Auf R2 werden nur die Interfaces konfiguriert, kein RIP:

interface FastEthernet0/0
 ip address 10.10.1.2 255.255.255.0
!
interface FastEthernet0/1
 ip address 10.10.2.2 255.255.255.0

Router R3 spricht RIP, benutzt R1 als Neighbor und sendet daher diesem seine Updates als Unicast. Alle Interfaces werden passiv gesetzt (auch auf R1), per Multicast sollen keine Nachbarn mehr erreicht werden. Weiterhin benötigt R3 eine Route, um R1 zu erreichen:

interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/1
 ip address 10.10.2.3 255.255.255.0
!         
router rip
 version 2
 passive-interface default
 network 1.0.0.0
 network 10.0.0.0
 neighbor 10.10.1.1
 no auto-summary
!
ip route 0.0.0.0 0.0.0.0 10.10.2.2

Mit dieser Konfig fängt R3 an, seine Updates zu senden:

*Mar  1 00:12:26.291: RIP: sending v2 update to 10.10.1.1 via FastEthernet0/1 (10.10.2.3)
*Mar  1 00:12:26.291: RIP: build update entries
*Mar  1 00:12:26.291:   1.1.1.1/32 via 0.0.0.0, metric 1, tag 0

Diese Updates kommen auch bei R1 an, werden dort aber aufgrund der ungültigen Source-Adresse verworfen:

*Mar  1 00:44:50.767: RIP: ignored v2 update from bad source 10.10.2.3 on FastEthernet0/0

Wenn in der RIP-Konfiguration die Validierung der Source-Adresse abgeschaltet wird, kann die Route von R3 problemlos gelernt werden:

router rip
 version 2
 passive-interface default
 no validate-update-source
 network 10.0.0.0
 no auto-summary
Router#sh ip route rip
     1.0.0.0/32 is subnetted, 1 subnets
R       1.1.1.1 [120/1] via 10.10.2.3, 00:00:21

Wird das für irgendetwas benötigt? Vermutlich nicht, aber interessant ist dieses Verhalten trotzdem … 😉

Remote RIP-Routing