OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
updates
- rfc-4364 — BGP/MPLS IP Virtual Private Networks (VPNs)
Extracted elements (25)
PE routers are treated as OSPF area 0 (backbone) routers, allowing them to distribute inter-area routes via type 3 LSAs to CE routers in non-zero areas, and allowing multiple disconnected legacy OSPF backbone segments to remain interconnected during a phased migration to the VPN service.
Sham links are treated as OSPF Demand Circuits to suppress periodic refresh traffic, since as long as a backdoor link is up, periodic LSA flooding over the sham link serves no purpose. However, synchronization must still be maintained so that if the backdoor fails, the sites can immediately exchange LSA databases.
Standard BGP/OSPF interaction would cause VPN routes from one site to be delivered to another as type 5 LSAs (AS-external routes). RFC 4577 uses type 3 LSAs instead, so that VPN-internal routes appear as inter-area routes and can be distinguished from genuine AS-external routes; this also enables OSPF backdoor links to function correctly during legacy backbone transitions.
The Site of Origin attribute is made optional for OSPF-learned routes. Omitting it enables automatic repair of partitioned multi-homed sites (traffic reroutes via VPN backbone), while including it reduces unnecessary overhead from re-injecting intra-site routes. The trade-off is left to operator configuration.
Deployed implementations may use OSPF Route Tags (VPN Route Tag) instead of the DN bit for loop prevention in type 5 LSAs. To maintain backward compatibility, all conforming implementations MUST by default support both mechanisms; the VPN Route Tag may be disabled by configuration when no longer needed.
For the OSPF Domain Identifier attribute, type 8005 MUST be treated as equivalent to type 0005 for backward compatibility. For OSPF Route Type, type 8000 SHOULD be accepted and treated as type 0306. For OSPF Router ID, type 8001 SHOULD be accepted and treated as type 0107.
If two OSPF instances both have the NULL Domain Identifier, it is impossible to determine from the Domain Identifier alone whether they are in the same OSPF domain; routes from one may incorrectly appear as intra-network routes in the other. Operators should assign non-NULL identifiers to distinguish domains.
A PE router that attaches to more than one OSPF domain MUST run an independent instance of OSPF for each domain, and each such instance MUST be associated with a single VRF. OSPF instances for different VPNs must not leak routes to each other.
All implementations MUST by default support the VPN Route Tag procedures for backward compatibility with deployed implementations that do not set the DN bit in type 5 LSAs. The VPN Route Tag value MUST be configurable and distinct from any OSPF Route Tag used within the OSPF domain.
Each OSPF instance MUST be associated with one or more Domain Identifiers; this MUST be configurable, and the default value SHOULD be NULL. If an instance has multiple Domain Identifiers, the NULL Domain Identifier MUST NOT be one of them.
If a PE determines that the next-hop interface for a route is a sham link, then the PE SHOULD NOT redistribute that route into BGP as a VPN-IPv4 route. However, packets whose preferred route uses the sham link as next hop MUST be forwarded according to the corresponding BGP route.
If the OSPF domain has any area 0 routers other than PE routers, at least one of those MUST be a CE router and MUST have an area 0 link (possibly virtual) to at least one PE router, ensuring inter-area and AS-external routes can be exchanged.
OSPF cryptographic authentication SHOULD be used between a PE and a CE router on the PE/CE link. It MUST be implemented on each PE to guard against spoofed OSPF messages that could compromise VPN routing or enable denial-of-service attacks.
Routes received in type 4 LSAs from a CE MUST NOT be redistributed into BGP.
The Sham Link Endpoint Address MUST be configurable, MUST be distributed by BGP as a VPN-IPv4 route with a 32-bit prefix, and MUST NOT be advertised by OSPF. It MUST NOT be used as the endpoint address of an OSPF Virtual Link.
When a PE router receives any LSA from a CE router with the DN bit set, the information from that LSA MUST NOT be used in route calculation. Similarly, if a Type 5 LSA from a CE carries the VPN Route Tag value, it MUST NOT be used in route calculation.
When a type 3 LSA or type 5 LSA is sent from a PE router to a CE router, the DN bit MUST be set to prevent the CE from re-advertising the LSA to another PE, which would cause routing loops.
A sham link is a manually configured, unnumbered point-to-point intra-area OSPF link between two PE routers, advertised as a type 1 link in a type 1 LSA, that makes the VPN backbone appear as an intra-area link to CE routers in the same OSPF area. Sham links are an OPTIONAL feature and SHOULD be treated as OSPF Demand Circuits.
OSPF protocol packets sent on a sham link MUST use the Sham Link Endpoint Address as IP source and destination, travel over the VPN backbone via MPLS, and are recognized only when arriving as an MPLS packet delivered to the local sham link endpoint address with matching source and destination addresses.
The OSPF Domain Identifier is an eight-byte BGP Extended Communities attribute (types 0005, 0105, 0205, or legacy 8005) that identifies the OSPF domain of a VPN-IPv4 route. It allows receiving PEs to determine whether a route should be redistributed as an inter-area or AS-external route.
The OSPF Router ID Extended Communities attribute (type 0107, legacy 8001) is an optional attribute carrying the OSPF Router ID of the PE in the OSPF instance that installed the route, encoded in the first 4 bytes of the value field.
This document assigns BGP Extended Communities Extended Type Field values under IANA's First Come First Served policy: OSPF Domain Identifier (0005, 0105, 0205), OSPF Route Type (0306), and OSPF Router ID (0107). Legacy types 8005, 8000, and 8001 are accepted for backward compatibility.
A PE may simultaneously run OSPF as the SP backbone IGP and as the IGP for one or more VPNs. These MUST be independent OSPF instances to prevent inadvertent route leakage between the backbone and any VPN, and between VPNs. Without authentication, an attacker could inject spoofed OSPF messages to corrupt VPN routing or launch a denial-of-service attack.
The OSPF Route Type Extended Communities attribute (type 0306) carries six bytes of data: Area Number (4 bytes, 0 for external routes), Route Type (1 byte: 1/2 for intra-area, 3 for inter-area, 5 for external, 7 for NSSA), and Options (1 byte, LSB indicates type 2 metric for route types 5 and 7).
The VPN Route Tag for a two-byte AS is a 32-bit field with bits 31-30 set to 1 (Automatic=1, Complete=1), bit 29 clear (PathLength=01), an arbitrary 13-bit tag, and the 16-bit Autonomous System number in the low-order bytes. For four-byte AS numbers, the value MUST be manually configured.