OSPF Domain IDs

The OSPF Domain ID is used when carrying OSPF LSAs between the same or different domains across an MPLS backbone. The domain ID is carried as an extended community within MP-BGP along with an OSPF route-type and OSPF router ID community. The feature allows a PE router to advertise OSPF type 1, 2 and 3 LSAs as summary LSAs to a remote site; type 5 and type 7 LSAs can also be carried over depending on the remote area type, however stub and totally stubby areas do not support this feature whatsoever.

The use of OSPF Domain ID would occur when migrating an OSPF domain onto an MPLS network, due to the flexibility to carry type 3 LSAs over an MPLS core, which essentially means the MPLS core can provide a metrically preferred path instead of using an existing path or connection to a remote site within a legacy OSPF domain.

Routes that are advertised as type 5 will always be carried over as type 5. Routes that are advertised across the MPLS core with a domain ID that’s different from the site they’re being advertised to will always be carried as type 5. LSA type 1, 2 and 3 within the same domain or if no domain is configured will be carried as a type 3 LSA.

The following configuration shows a standard PE to CE connection that uses a BGP export policy to advertise VPN routes into the OSPF process running on the CE. A BGP export policy is also shown o export the LSAs from the VRF. The BGP import policy would just import BGP routes as per normal L3 VPN configuration.

routing-instances {
vpn-a {
instance-type vrf;
interface ge-0/0/0;
route-distinguisher 172.25.0.1:100;
vrf-import vpn-a-import;
vrf-export vpn-a-export;
protocols {
ospf {
export bgp-to-ospf;
area 0.0.0.0 {
interface ge-0/0/0;
}
}
}
}
}
policy-options {
policy-statement bgp-to-ospf {
term 1 {
from protocol bgp;
then accept;
}
}
}
policy-options {
policy-statement vpn-a-export {
term a {
from protocol ospf;
then {
community add vpn-a;
accept;
}
}
term z {
then reject;
}
}
policy-statement vpn-a-import {
term a {
from {
protocol bgp;
community vpn-a;
}
then accept;
}
term z {
then reject;
}
}
}

The following example uses a domain-id within the OSPF configuration. This can be used optionally to match the domain for LSA type 3 generation or for different domains which results in a LSA type 5 generation. A router-id is also added to the VRF so the customer VPN can have a control plane that’s pingable across the VPN; the router ID is taken from customer address space and is independent of the providers control plane; by default the router ID is the interface configured within the VRF.

The route tag is added by default as the providers ASN but can be configured manually. The route tag is used to prevent LSAs from being looped across an MPLS core and then back through a legacy OSPF backdoor link. In most cases this configuration isn’t needed as the OSPF DN bit is set when the LSAs are generated across the MPLS core. The DN bit is similar to the ISIS down bit which prevents the LSA from being advertised to another area or back up to level 2 in ISIS.

One final point to be aware of is that when routing via legacy OSPF backdoor links and over MPLS VPN the OSPF route preference on the PE should be raised to a figure above the BGP preference of 170. This allows the VPN path to be active and preferred on the PE over any LSAs coming via OSPF from the legacy backbone.

routing-instances {
vpn-a {
instance-type vrf;
interface ge-0/0/0;
route-distinguisher 172.25.0.1:100;
vrf-import vpn-a-import;
vrf-export vpn-a-export;
routing-options {
router-id 172.25.2.1;
}
protocols {
ospf {
domain-id 1.1.1.1;
domain-vpn-tag 207169010107;
export bgp-to-ospf;
area 0.0.0.0 {
interface ge-0/0/0;
}
}
}
}
}
policy-options {
policy-statement bgp-to-ospf {
term 1 {
from protocol bgp;
then accept;
}
}
}
policy-options {
policy-statement vpn-a-export {
term a {
from protocol ospf;
then {
community add vpn-a;
accept;
}
}
term z {
then reject;
}
}
policy-statement vpn-a-import {
term a {
from {
protocol bgp;
community vpn-a;
}
then accept;
}
term z {
then reject;
}
}
community vpn-a members [ target:65001:100 domain-id:1.1.1.1:0 ]
}
}

Useful Links :

http://www.juniper.net/techpubs/en_US/junos10.3/topics/example/vpn-ospf-domain-id-for-layer-3-configuring.html
http://forums.juniper.net/t5/Routing/OSPF-Domain-Tag-or-Domain-Id/td-p/57292

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s