Ethernet-Bridging über MPLS
Der Cisco MPLS-Kurs ist zwar im großen und ganzen recht “rund”, beschränkt sich aber fast ausschließlich auf MPLS-VPNs für IPv4. Das man auch andere Protokolle transportieren kann ist nur am Rande erwähnt. Dafür habe ich hier ein kleines Beispiel wie man mit AToM (AnyTransport over MPLS) zwei Standorte per Bridging über das MPLS verbindet:
Als Router kommen mal wieder 7200er (im GNS3) mit IOS 15.0(1)M4 zum Einsatz:
Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 15.0(1)M4, RELEASE SOFTWARE (fc1)
Die fa0/0-Interfaces der Router C1 und C2 sollen sich dabei in einem IP-Netz (hier in einem IPv6-Netz) befinden und sich ohne eine Routing-Instanz erreichen können.
hostname C1 ! interface FastEthernet0/0 description Link zum CE1 no ip address ipv6 address 2001:DB8:1111::1/64
hostname C2 ! interface FastEthernet0/0 description Link zum CE2 no ip address ipv6 address 2001:DB8:1111::2/64
Die CE-Router müssen dafür IPv6 transparent bridgen. Das kann über eine traditionelle Bridge-Group erreicht werden:
bridge irb ! interface FastEthernet0/0 description Link zum C1 no ip address bridge-group 1 ! interface FastEthernet0/1 description Link zum PE1 no ip address bridge-group 1 ! bridge 1 protocol ieee
Die PE-Router haben eine normale MPLS-Konfiguration, verwenden aber für AToM keine MPLS-VPNs, sondern sogenannte “Pseudo-Wires“. Daher werden auch keine VRF- oder BGP-Instanzen benötigt. Das ist im einfachsten Fall wie ein virtuelles Kabel zwischen zwei PE-Routern zu verstehen. Die Pseudo-Wires werden mit dem Befehl xconnect zwischen den Loopback-Adressen der PE-Router konfiguriert:
hostname PE1 ! interface Loopback0 ip address 10.10.10.1 255.255.255.255 ip ospf 1 area 0 ! interface FastEthernet0/1 description Link zum CE1 no ip address xconnect 10.10.10.2 100 encapsulation mpls !
Auf dem PE 1 wird also ein Pseudowire mit der Virtual Circuit-ID von 100 vom aktuellen Router zur Loopback des PE2 (10.10.10.2) aufgebaut. Der Transport läuft über das schon vorhandene MPLS.
Da diese Pseudo-Wire unidirektional arbeiten, wird das gleiche auch auf dem PE2 konfiguriert:
hostname PE2 ! interface Loopback0 ip address 10.10.10.2 255.255.255.255 ip ospf 1 area 0 ! interface FastEthernet0/1 description Link zum CE2 no ip address xconnect 10.10.10.1 100 encapsulation mpls !
Die PE-Router verwenden für den Austausch des VC-Labels eine gerichtete LDP-Sitzung:
PE1#sh mpls ldp neighbor 10.10.10.2
Peer LDP Ident: 10.10.10.2:0; Local LDP Ident 10.10.10.1:0
TCP connection: 10.10.10.2.45592 - 10.10.10.1.646
State: Oper; Msgs sent/rcvd: 117/118; Downstream
Up time: 01:33:43
LDP discovery sources:
Targeted Hello 10.10.10.1 -> 10.10.10.2, active, passive
Addresses bound to peer LDP Ident:
10.10.2.1 10.10.10.2
In meinem Setup hat der PE1 dem PE2 ein VC-Label von 1100 angekündigt, und ein VC-Label von 1200 erhalten:
PE1#sh mpls l2transport binding
Destination Address: 10.10.10.2, VC ID: 100
Local Label: 1100
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: Link zum CE1
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
Remote Label: 1200
Cbit: 1, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: Link zum CE2
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
Die Eigenschaften des Virtual Circuits:
PE1#sh mpls l2transport vc
Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Fa0/1 Ethernet 10.10.10.2 100 UP
PE1#
PE1#
PE1#sh mpls l2transport vc 100 detail
Local interface: Fa0/1 up, line protocol up, Ethernet up
Destination address: 10.10.10.2, VC ID: 100, VC status: up
Output interface: Se1/0, imposed label stack {1000 1200}
Preferred path: not configured
Default path: active
Next hop: point2point
Create time: 00:10:27, last status change time: 00:09:58
Signaling protocol: LDP, peer 10.10.10.2:0 up
Targeted Hello: 10.10.10.1(LDP Id) -> 10.10.10.2
Status TLV support (local/remote) : enabled/supported
Label/status state machine : established, LruRru
Last local dataplane status rcvd: no fault
Last local SSS circuit status rcvd: no fault
Last local SSS circuit status sent: no fault
Last local LDP TLV status sent: no fault
Last remote LDP TLV status rcvd: no fault
MPLS VC labels: local 1100, remote 1200
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description: Link zum CE2
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 377, send 76
byte totals: receive 25754, send 8835
packet drops: receive 0, seq error 0, send 0
Nachdem alles konfiguriert wurde kann die Verbindung getestet werden:
C1#ping ipv6 2001:DB8:1111::2 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 2001:DB8:1111::2, timeout is 2 seconds: ! Success rate is 100 percent (1/1), round-trip min/avg/max = 36/36/36 ms C1#
C2# *Apr 12 14:59:25.659: ICMPv6: Received echo request, Src=2001:DB8:1111::1, Dst=2001:DB8:1111::2 *Apr 12 14:59:25.663: ICMPv6: Sent echo reply, Src=2001:DB8:1111::2, Dst=2001:DB8:1111::1 C2#
Im Capture auf dem Link zwischen PE1 und PE kann man die zwei Label und den darüber transportierten Ethernet-Frame sehen:
No. Time Source Destination Protocol Info
299 146.171341 2001:db8:1111::1 2001:db8:1111::2 ICMPv6 Echo (ping) request id=0x0fc4, seq=0
Frame 299: 130 bytes on wire (1040 bits), 130 bytes captured (1040 bits)
Cisco HDLC
MultiProtocol Label Switching Header, Label: 1000, Exp: 0, S: 0, TTL: 255
MultiProtocol Label Switching Header, Label: 1200, Exp: 0, S: 1, TTL: 255
PW Ethernet Control Word
Ethernet II, Src: ca:05:ac:17:00:08 (ca:05:ac:17:00:08), Dst: ca:06:ac:18:00:08 (ca:06:ac:18:00:08)
Internet Protocol Version 6, Src: 2001:db8:1111::1 (2001:db8:1111::1), Dst: 2001:db8:1111::2 (2001:db8:1111::2)
Internet Control Message Protocol v6
Das äußere Label (1000) ist das vom P-Router generierte Transport-Label zum PE2, das innere Label (1200) ist das vom PE2 generierte VC-Label.
Bleibt zu klären, warum ich bei diesem Beispiel entgegen meiner früheren Ankündigung das SP-Netz mit IPv4 anstelle IPv6 aufgebaut habe. Das liegt daran, das LDP noch nicht über IPv6 laufen kann.
Die OSPF Prozess ID beim PE-CE-Routing
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 0Etwas 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:
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 0Die (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 0Jetzt 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/11107Die “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.
Es gibt kein Experimental-Field mehr im MPLS
Das EXP-Field im MPLS-Header war eigentlich nie ein solches sondern wurde für “Class of Service” verwendet. Um alle Unklarheiten zu beseitigen, wurde dieses Feld jetzt in “Traffic Class” umbenannt:
Hier der Header mit den aktuellen Bezeichnungen:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label Value, 20 bits
TC: Traffic Class field, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time to Live, 8 bitsTraining Implementing Cisco MPLS
Besucher des Kurses Implementing Cisco MPLS, die nach dem Training noch mehr üben möchten, können das problemlos mit Dynamips/GNS3 machen. Die “Fleißarbeit” dazu habe ich schon einmal gemacht und die .net-Datei, sowie die Startkonfigurationen der Router angefertigt.
Dieses Labor beinhaltet 17 Router, die aber nicht alle gleichzeitig laufen müssen. Die Konfiguration benutzt 7200er mit einem AdvEnterprise 12.4(15)T8-Image. Die Pfade in der mpls22.net müssen natürlich an die eigene Umgebung angepasst werden.
Die physikalische Topologie benutzt — wie beim Original-Training — einen FR-Switch, über den alle Router seriell angeschlossen sind:
Die gewünschten Verbindungen werden per PVC hergestellt, so daß logisch die folgende Topologie hergestellt wird:
Wenn in der .net-Datei oder in den Startkonfigurationen noch Fehler enthalten sein sollten, dann sagt bitte Bescheid, damit ich die korrigieren kann. Auch wenn jemand von euch einen besseren IdlePC-Wert herausfindet, würde ich mich über einen Kommentar freuen. Viel Spaß beim Üben.
Update 29.2.: Da MPLS ohne Backdoor-Links keinen Spaß macht, habe ich diese in der Konfiguration hinzugefügt.
Update 3.4.: Jetzt auch wieder mit .NET-Datei zum Download.
