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:

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.