OSPF Route Type Across a VPN: It Is Not Always External

A customer prefix crosses the provider cloud as a BGP VPN route and arrives at the far site looking like an OSPF external route, which is what many engineers expect and not the only possible outcome. What the remote CE sees depends on the OSPF domain the prefix came from and its original route type, both of which travel with the VPN route. Assuming every redistributed prefix turns into Type 5 leads to preference changes that cannot work. Compare the domain identifier first, not the administrative distance.

The PE-CE model carries enough context for the receiving PE to reconstruct an OSPF advertisement rather than invent one.

What Travels With the Route

RFC 4577 defines the OSPF attributes that accompany a VPN route: the domain identifier, the metric and the route type from the originating site. The receiving PE uses them to decide how an eligible prefix should appear to its local OSPF process. Without those attributes the far PE would have no basis for anything except an external redistribution. That is why a route can arrive as an inter-area LSA even though BGP carried it in between.

Area type matters as well. A stub or NSSA area restricts which LSAs may enter, so the same VPN route can be presented differently depending on where the receiving OSPF instance sits. Configured export policy can override the default presentation too, which is a deliberate choice rather than a side effect.

Same Domain, Different Presentation

An intra-area or inter-area route from the same domain normally arrives at the remote site as an inter-area route, a Type 3 LSA. A prefix from another domain, an origin that never spoke OSPF, or an initially external OSPF advertisement takes the external rules instead, which is where Type 5 and its NSSA equivalent appear. Both behaviours are correct; the input differs. Compare domain identifiers and advertised attributes before touching preference values.

Administrative distance chooses between sources on one router. It does not rewrite an LSA type or create the domain relationship that is missing.

When a Sham Link Is the Right Answer

Picture two sites in the same area joined by a direct backdoor link. OSPF keeps that intra-area path rather than the inter-area one offered through the provider, even when configured costs would make the provider path attractive. A sham link represents an intra-area relationship across the VPN so costs can take part in the decision. It exists for that specific path-selection problem, not to make every same-domain route look internal.

A sham link needs reachable endpoints and reciprocal configuration on both PEs. Setting it up on one side produces a relationship that never forms, and the routing table keeps its old preference, which looks like the feature did nothing.

Do Not Break the Loop Protection

The PE-CE model sets the DN bit on routes it distributes so a prefix cannot return through another CE and be redistributed a second time. That protection is what keeps a prefix from looping between sites sharing an OSPF domain. Removing or ignoring it to make a route appear internal can create exactly the loop it was designed to prevent. When a prefix looks wrong, treat the DN bit as information rather than as an obstacle.

The same caution applies to redistribution filters and route maps that strip communities. Each removes context the far side needs, and the resulting advertisement can look plausible while being wrong. Change one attribute at a time and check what the remote CE actually installs.

Then verify from the far site: the LSA type, the advertising router and the path it chose. That evidence answers the question the ticket asked.