Digging Into OSPF as a PE-CE Protocol

The default behavior of redistribution of VRF aware OSPF will lead to the MPLS VPN cloud trying to emulate OSPF. This is done using a “Super Backbone” which is hierarchically above area zero. RFC4577 explains in great detail how this should ideally work.

The whole point of this behavior is to mask the VPNv4 BGP from the customer networks. Traditionally if you redistribute any protocol into OSPF it will be created as an LSA type 5 (external). In Cisco’s implementation all LSAs of type 1-3 will be advertised out the egress PE(s) as type 3.

Given the topology below assume that the link from CE1-CE2 is not active (for the moment). All Ethernet links have been set to a network type of point-to-point for simplification.

Looking at the link state database we can see the summary prefixes (type 3) all have the router ID of the nearby PE. This means that the “Super Backbone” is working, converting area zero LSA type 1 into type 3 at the egress PE. It is important to make sure that the process IDs match between PEs. The process ID configured on the PE is attached in the form of an extended community, under the ospf process you can manually set the value to be attached to the ext-community;

OSPF DOMAIN ID:0×0005:0x0000007B0200

router ospf 123 vrf cust
domain-id type 0005 value 000000000123

OSPF DOMAIN ID:0×0005:0×000000000123

An issue which can occur when implementing OSPF as the PE-CE protocol, which I have seen first hand in a production network is that the “Super Backbone” cannot be treated as a transit network as it would in a layer two VPN. I can imagine that enterprises and even the people who design/architect for enterprises (not trying to have a dig a CCIE RS holders) do not take into consideration how OSPF MPLS VPNs actually work. You cannot just make the MPLS VPN cloud a single area, even if all the PE-CE links are in area zero all LSAs will be type three after they have crossed the cloud.

CE1#show ip ospf 123 database router adv 172.0.0.2

OSPF Router with ID (172.0.0.1) (Process ID 123)
Router Link States (Area 0)

Adv Router is not-reachable
LS age: 481
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 172.0.0.2
Advertising Router: 172.0.0.2
LS Seq Number: 80000004
Checksum: 0xD09A
Length: 60
Number of Links: 3

The LSAs (from CE2) are inside the database (on CE1) but they will not ever be able to be used for forwarding because the topology has broken the “Area 0 must be contiguous” rule. CE2 is in fact sending LSA type 1 for both Area0 and Area1 but all LSAs from Area0 are marked “Adv Router is not reachable” above.

Another thing worth noting is that in regular OSPF the “advertising router” for an LSA stays the same within an area and is changed at the border (by an ASBR/ABR). This is consistent with the “ever router must know every other router in the area” concept. This is also applied to the Superbackbone. The “advertising router” for an LSA will be changed as it is advertised out the egress PE. This combined with some of the above shows how the Superbackbone truly does act as an area hierarchically above area zero.