MPLS - L3VPN BGP OSPF Redistribution

Under normal circumstances, when we redistribute routes into OSPF those routes appear as external routes, indicated by the O E1 or O E2 designation in the Routing Table. However, in an MPLS scenario where Layer 3 VPNs are used and where OSPF is used between CEs and PEs, routes redistributed into OSPF do not have the external designation of O E1 or O E2, but a designation of O IA which are inter-area prefixes.

The reason for this is multifaceted. First of all, the MPLS network is technically transparent to the customer endpoints. It appears as if the CEs are directly connected and just exchange prefixes. This is how MPLS is intended to function.

The reason behind the fact that the routes appear to be Inter Area routes rather than external (redistributed) routes because of the nature of OSPF and how it classifies such routes. When a route is redistributed into OSPF, it’s classified as an external route. However, in this case, the BGP VPNv4 routes are not being redistributed directly into OSPF. Instead, they’re being imported into the VRF and then redistributed into OSPF.

Take a look at the following MPLS topology: mpls-vpn-pe-ce-ospf.png.pagespeed.ic.XhBhTPjOcO.png

OSPF is being used between the PE and CE routers, and you can see that both CEs are in Area 0 which is the backbone. Take a look at the redistribution commands on PE1 and PE2:

PE1 & PE2 (config)#router ospf 2 vrf CUSTOMER (config-router)#redistribute bgp 234 subnets

Notice the redistribute command is being applied under the router OSPF VRF Customer configuration mode and not directly under the router ospf 2 configuration mode. With such a configuration, as far as OSPF is concerned, there routes are originating from within the VRF.

Another thing to notice here is that Area 0 exists in two sites. That makes the OSPF backbone discontiguous. But by definition this is not allowed. However, based on RFC 4577, there is an exception to this rule, which causes routes learned from the "other" Area 0 to be considered O IA routes.

Thus, in the routing table, they appear as O AI as shown below:

CE1#show ip ospf database | begin Summary Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 1208 0x80000001 0x00C26C 1208 0x80000001 0x00FCB0
CE2#show ip ospf database | begin Summary Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 1223 0x80000001 0x008794 1223 0x80000001 0x007536

This process is described in full detail in the related RFC link below.

A similar issue appears with EIGRP in the same scenario.