• Supported Platforms
• M Series
• T Series

Configuring OSPF Domain IDs for VPNs

For most OSPF or OSPFv3 configurations involving Layer 3 VPNs, you do not need to configure an OSPF domain ID. However, for a Layer 3 VPN connecting multiple OSPF or OSPFv3 domains, configuring domain IDs can help you control LSA translation (for Type 3 and Type 5 LSAs) between the OSPF domains and back-door paths. The default domain ID is 0.0.0.0. Each VPN routing table in a PE router associated with an OSPF or OSPFv3 instance is configured with the same OSPF domain ID.

Junos OS is fully compliant with Internet draft draft-ietf-l3vpn-ospf-2547-04.txt, OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs.

For more detailed information about configuring VPNs, see the Junos VPNs Configuration Guide.

Without the domain IDs, there is no way to identify which domain the routes originated from after the OSPF or OSPFv3 routes are distributed into BGP routes and advertised across the BGP VPN backbone. Distinguishing which OSPF or OSPFv3 domain a route originated from allows classification of routes as Type 3 LSAs or Type 5 LSAs.

To configure a domain ID, perform the following tasks:

1. Specify a domain ID in the BGP extended community ID.
2. Set a route type.
3. Configure a VRF export policy to explicitly attach the outbound extended community ID to outbound routes.
4. Define a community with members that possess the community ID.

For more information about configuring export policies, see the Junos Policy Framework Configuration Guide.

This extended community ID can then be carried across the BGP VPN backbone. When the route is redistributed back as an OSPF or OSPFv3 route on the PE router and advertised to the CE near the destination, the domain ID identifies which domain the route originated from. The routing instance checks incoming routes for the domain ID. The route is then propagated as either a Type 3 LSA or Type 5 LSA.

When a PE router receives a route, it redistributes and advertises the route as either a Type 3 LSA or a Type 5 LSA, depending on the following:

• If the receiving PE router sees a Type 3 route with a matching domain ID, the route is redistributed and advertised as a Type 3 LSA.
• If the receiving PE router sees a Type 3 route without a domain ID (the extended attribute field of the route’s BGP update does not include a domain ID), the route is redistributed and advertised as a Type 3 LSA.
• If the receiving PE router sees a Type 3 route with a non-matching domain ID, the route is redistributed and advertised as a Type 5 LSA.
• If the receiving PE router sees a Type 3 route with a domain ID, but the router does not have a domain ID configured, the route is redistributed and advertised as a Type 5 LSA.
• If the receiving PE router sees a Type 5 route, the route is redistributed and advertised as a Type 5 LSA, regardless of the domain ID.

On the local PE router, the prefix of the directly connected PE/CE interface is an active direct route. This route is also an OSPF or OSPFv3 route.

In the VRF export policy, the direct prefix is exported to advertise the route to the remote PE. This route is injected as an AS-External-LSA, much as when a direct route is exported into OSPF or OSPFv3.

Domain ID ensures that an originated summary LSA arrives at the remote PE as a summary LSA. Domain ID does not translate AS-external-LSAs into summary LSAs.

To configure an OSPF or OSPFv3 domain ID match condition for incoming Layer 3 VPN routes going into a routing instance, include the domain-id statement:

For domain-id, specify either an IP address or an IP address and a local identifier using the following format: ip-address:local-identifier. If you do not specify a local identifier with the IP address, the identifier is assumed to have a value of 0.

You can configure the statement at the following hierarchy levels:

• [edit routing-instances routing-instance-name protocols (ospf | ospf3)]
• [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)]

If the router ID is not configured in the routing instance, the router ID is derived from an interface address belonging to the routing instance.

To prevent routing loops when a domain ID is used as an alternate route preference for the OSPF or OSPFv3 external routes generated by the PE router, the DN bit of the LSA being distributed by the PE router must be set. If the route is distributed in a Type 5 LSA and the DN bit is not supported by the PE router, the VPN tag is used instead.

By default, the VPN tag is automatically calculated and needs no configuration. To configure the domain VPN tag for Type 5 LSAs, include the domain-vpn-tag number statement:

You can configure the statement at the following hierarchy levels:

• [edit routing-instances routing-instance-name protocols (ospf | ospf3)]
• [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)]

The range is from 1 through 4,294,967,295. If you set VPN tags manually, you must set the same value for all PE routers in the VPN.

To clear the VPN tag when it is no longer needed (when the DN bit is supported on the PE router), include the no-domain-vpn-tag statement:

You can configure the statement at the following hierarchy levels:

• [edit routing-instances routing-instance-name protocols (ospf | ospf3)]
• [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)]

When the VPN tag is cleared, the DN bit is automatically set.

To set the route type, include the route-type-community statement:

You can include the statement at the following hierarchy levels:

• [edit routing-instances routing-instance-name protocols (ospf | ospf3)]
• [edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)]

The domain-id setting in the routing instance is for a match on inbound Layer 3 VPN routes. A VRF export policy must be explicitly set for the outbound extended community domain-id attribute. You must configure an export policy to attach the domain ID to outgoing routes. To configure an export policy to attach the domain ID and route distinguisher to the extended community ID on outbound routes, include the community statement:

You can include the statement at the following hierarchy levels:

• [edit policy-options policy-statement policy-name term term-name then]
• [edit logical-systems logical-system-name policy-options policy-statement policy-name term term-name then]

To define the members of a community, include the community statement:

You can include the statement at the following hierarchy levels:

• [edit policy-options]
• [edit logical-systems logical-system-name policy-options]

Examples: Configuring an OSPF Domain ID

Configure a domain ID as a match condition for inbound Layer 3 VPN routes. Then configure an export policy to tag the extended community ID and the route distinguisher onto outgoing routes:

Leak a noninstance route into the instance routing table: