OSPF Domain-ID || Domain-Tag

OSPF Domain ID

When OSPF is used as the routing protocol on a provider edge to customer edge (PE-CE) link in a multiprotocol label switching (MPLS) VPN. PE routers mark OSPF routes with the domain attribute derived from the OSPF process number to indicate whether the route originated within the same OSPF domain or from outside it.

Importance of Domain-ID

In MPLS-VPN network ISP cloud is treated as a super backbone area, and PEs are considered as ABRs or ASBRs depending on the domain-id value, then routes redistributed to CEs would be OSPF inter- area routes or would be OSPF external routes.

Why would we care to have OIA or E or O routes in our OSPF database?

The answer is simply that OSPF prefers intra-area routes then inter-area routes and finally external routes to be installed in routing table. And we don’t want to come in to the case that routes are leaked from a back door in then being redistributed to the ISP cloud creating a loop in the network and disrupting traffic.

So if we had a different processes on our PEs then so we have to explicitly configure the domain-id value under the OSPF process.

OSPF loop prevention in PE-CE routing

• DN bit

o    When a type 3 LSA is sent from a PE router to a CE router, the DN bit [OSPF-DN] in the LSA Options field MUST be set. This is used to ensure that if any CE router sends this type 3 LSA to a PE router, the PE router will not redistribute it further.

• Domain-Tag

o   PE routers originate Type 5 LSAs reporting the extra-domain routes as AS-external routes. Each such Type 5 LSA MUST contain an OSPF route tag. This tag identifies the route as having come from a PE router. The VPN Route Tag MUST be used to ensure that a Type 5 LSA originated by a PE router is not redistributed through the OSPF area to another PE router.

Case study

We had our customer VPN-A reporting that his DMVPN through TEdata is down and while diagnosing the issue, all branches’ CPEs loopback IPs along with WAN subnets was found to be sourced from MHNDSN PE as per below

BABLOUK#show ip rou vrf VPN-A 172.29.254.20
Routing Table: VPN-A
Routing entry for 172.29.254.20/30
Known via “bgp 8452”, distance 200, metric 0, type internal
Redistributing via ospf 60
Advertised by ospf 60 subnets
Last update from 163.121.170.105 23:55:22 ago
Routing Descriptor Blocks:
* 163.121.170.105 (default), from 163.121.*.*, 00:00:22 ago
Route metric is 0, traffic share count is 1

MHNDSN#show ip route vrf VPN-A ospf

O E1 172.29.254.20/30
[110/4664] via 172.29.254.46, 00:00:02, ATM*/*/*.*
O E1 172.29.254.24/30
[110/4664] via 172.29.254.46, 00:00:02, ATM*/*/*.*

MHNDSN#show ip ospf 62 database

Link ID                  ADV Router      Age            Seq#            Checksum          Tag

172.29.254.20   172.29.254.50     1640    0x80000991       0x005EEF    3489669380
172.29.254.24    172.29.254.50    2455    0x8000001D       0x003A8D    3489669380

 

And after checking Customer configuration on MHNDSN

MHNDSN#show run vrf VPN-A | s ospf

router ospf 62 vrf VPN-A

domain-id 1.1.1.1

domain-tag 777

log-adjacency-changes

redistribute bgp 8452

network 172.29.254.0 0.0.0.255 area 0

So we concluded that BGP routes are redistributed to 172.29.254.50  which then flood the network with type 5 LSA that’s not tagged with domain-tag configured under VPN-A vrf “777”  and these routes is getting redistributed again to our cloud and get preferred over IBGP received routes on MHNDSN which is somehow is preferred in our cloud to be the next hop for all the branches and we got a huge black hole in our network.

After checking Zamalek Configs.

ZAMALEK> show configuration routing-instances VPN-A protocols

ospf {

export VPN-A-import;

area 0.0.0.0 {

interface ge-0/2/5.1136 {

interface-type p2p;

 

Then our solution was to configure the domain-id and the domain tag values on the Zamalek PE in order to prevent LSAs(3,5) to get flooded through customer network then gets flooded again to our network.

ZAMALEK>show configuration routing-instances VPN-A protocols

        domain-id 1.1.1.1:512;

        domain-vpn-tag 777;

export VPN-A-import;

area 0.0.0.0 {

interface ge-0/2/*.*** {

interface-type p2p;

 

after applying A/M configurations we found that  routes are getting in ospf database as external routes tagged with the correct domain tag but routes are not installed in the vrf routing table

MHNDSN#show ip ospf 62 database

Link ID                  ADV Router      Age            Seq#            Checksum        Tag

172.29.254.20    172.29.254.50     1640    0x80000991       0x005EEF    777
172.29.254.24    172.29.254.50    2455    0x8000001D       0x003A8D    777

MHNDSN-R01C-GZ-EG#show ip route vrf VPN-A | i 172.29.254.24

B        172.29.254.24/30 [200/0] via 163.121.1*.*, 1d21h >>> Original Source

 

What solved the problem here is actually the domain tag not the domain id as for some reason that I don’t know yet, there’s a problem in interpreting domain id value between Cisco and Juniper as routes are encoded with different domain-id type and whenever you try to adjust it on the juniper it’s seen with a different value on Cisco devices.

 

MHNDSN#show ip bgp vpnv4 vrf VPN-A 172.29.254.24 | i OSPF >>> a route coming from a Cisco PE

OSPF DOMAIN ID:0x0005:0x010101010200 OSPF RT:0.0.0.0:2:0

OSPF ROUTER ID:172.29.254.25:0

MHNDSN#show ip bgp vpnv4 vrf VPN-A 172.29.254.45 | i OSPF >>>a route coming from a Juniper PE

Extended Community: RT:8452:674 OSPF DOMAIN ID:0x0105:0x010101010200

OSPF RT:0.0.0.0:1:0