OSPF Backdoor Beats the L3VPN

CE-A has two OSPF-derived paths to 10.20.0.0/16. Via the microwave, the prefix is intra-area (learned from a router in area 0, as a router or network LSA summarised into a normal area path). Via MPLS, it is a type 5 external that PE1 originated, metric 20, which is the seed metric whenever redistribution has no explicit metric. OSPF selects by path type before it compares cost: intra-area beats inter-area beats E1 beats E2. Both paths carry the same administrative distance (110), so the intra-area route wins regardless of how large the microwave cost becomes. Cost only discriminates between routes of the same class - which is why the change did nothing.

The DN bit is not a factor here either. The PE sets it when redistributing MP-BGP into OSPF, and PEs honour it to prevent loops, but CE-A is not a PE and ignores it.

Fixes:

1. Sham link between the two PEs inside VRF CUST. It creates an intra-area adjacency over MPLS so the VPN path competes as intra-area and costs can then decide:

interface Loopback100
 ip vrf forwarding CUST
 ip address 10.255.0.1 255.255.255.255
!
router ospf 1 vrf CUST
 area 0 sham-link 10.255.0.1 10.255.0.2 cost 10

The sham-link endpoints must be advertised as /32 into MP-BGP within the VRF and be reachable over the core. Trade-off: two more addresses to manage and a new dependency on MP-BGP convergence for a path that is supposed to be the primary.

1. Break the path-type tie in the other direction - move the microwave link to a different area (making the VPN path the only intra-area option), or replace it with a static route to 10.20.0.0/16 with an AD above 110 and a low metric, so the OSPF external wins during normal operation. Trade-off: a static does not fail over to the microwave unless it is tracked.

A third option - filtering the type 5 LSA on CE-A - works but is fragile; it removes the only working path if the microwave fails for a reason OSPF does not see.

The symptoms are the classic PMTUD black hole. The handshake completes because small segments fit. The client then sends full-size segments with DF set; the PE imposes two labels, pushing a 1500-byte frame to 1508 bytes, which the core interface cannot carry, so it is dropped. If the ICMP Fragmentation Needed response (type 3, code 4) is filtered anywhere - a very common policy on customer and PE-CE interfaces - the sender never learns to reduce and just retransmits until it gives up. ping -s 1472 succeeding and ping -s 1473 failing on the CE-to-CE path, while the same test through the tunnel fails at a lower size, confirms it.

Remediation, in order of preference:

1. Provide headroom so the labels fit: raise the core-facing MTU (e.g. 1520) and set mpls mtu accordingly on the PE uplinks - this is the clean fix but requires the provider to agree and every core hop to support it.
2. Assume 1500 end to end and clamp TCP on the CE-facing interfaces: ip tcp adjust-mss 1452 on both PE-CE links, so sessions never negotiate a segment larger than the path can carry.
3. Stop filtering ICMP type 3 code 4 on the VRF path, so PMTUD can work for protocols you are not clamping.

The judgement call is option 2: it is within your control, works today, and only costs a small amount of throughput per session. Option 1 is better long-term but leaves you blind whenever a third-party hop is at 1500.