[Contents] [Prev] [Next] [Index] [Report an Error]

Configuring an OSPF Domain ID

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 Typ  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 software 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:

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:

domain-id domain-id;

You can configure the statement at the following hierarchy levels:

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.

You can set a VPN tag for the OSPF or OSPFv3 external routes generated by the PE router. This prevents looping when a domain ID is used as an alternate route preference. By default, this 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:

domain-vpn-tag number;

You can configure the statement at the following hierarchy levels:

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 set the route type, include the route-type-community statement:

route-type-community (iana | vendor);

You can include the statement at the following hierarchy levels:

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:

policy-statement policy-name {
term term-name {
from protocol (ospf | ospf3);
then {
community add community-name;
accept;
}
}
term b {
then reject;
}
}
community community-name members [ target:target-id domain-id:domain-id];

You can include the statement at the following hierarchy levels:

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

community name {
members [ community-ids ];
}

You can include the statement at the following hierarchy levels:

[Contents] [Prev] [Next] [Index] [Report an Error]

Copyright © 2009, Juniper Networks, Inc. All rights reserved. Trademark Notice.