BGP Communities: OSPF Domain-ID and OSPF Route Type

I mentioned the BGP communities; OSPF Domain-ID and OSPF RT.

My intention now is to go deeper into these BGP communities and show how we can work with them.

When OSPF is being used as the PE-CE protocol, the PEs needs to inform other PEs how to interpret the routes they are announcing through MP-BGP, so this way they can choose what type of LSA to use when redistributing from MP-BGP back into OSPF. The communities used for that purpose are OSPF Domain-ID and OSPF RT, and they are attached to the prefixes by the original PE when redistributing from OSPF into MP-BGP. Then, the destination PE gets to know which LSA type to use in the redistribution from MP-BGP back into OSPF.

Let’s study the next scenario:

Assume both PEs use the same OSPF process-id, and that there is not domain-id configured. In our case, both PEs will have the same domain-id as this is extracted from the process-id.

In the next output, we see both PEs running OSPF 100 with their respective CEs:

PE1#show ip ospf 100
 Routing Process "ospf 100" with ID 10.10.11.2
   Domain ID type 0x0005, value 0.0.0.100 

PE2#show ip ospf 100
 Routing Process "ospf 100" with ID 10.10.22.1
   Domain ID type 0x0005, value 0.0.0.100  

As we can see, both PEs have the same domain-id 0.0.0.100.

Let’s check how PE1 receives in BGP the loopback of CE2 that was previously redistributed:

PE1#show bgp vpnv4 unicast all 2.2.2.2/32
BGP routing table entry for 1:1:2.2.2.2/32, version 116
Paths: (1 available, best #1, table VPN_A)
  Not advertised to any peer
  Local
    100.100.100.2 (metric 11) from 100.100.100.2 (100.100.100.2)
      Origin incomplete, metric 11, localpref 100, valid, internal, best
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000640200
        OSPF RT:0.0.0.1:2:0 OSPF ROUTER ID:10.10.22.1:0
      mpls labels in/out nolabel/21

The OSPF Domain-ID for this prefix is 0×00000064 (0.0.0.100 in decimal).

Since there are no sham-links configured and both PEs have the same Domain-ID, the prefix will be redistributed as an INTER-AREA prefix (LSA-3).

Let’s check on CE1 if this is true:

CE1#show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
  Known via "ospf 100", distance 110, metric 21, type inter area
  Last update from 10.10.11.2 on FastEthernet0/0, 00:00:00 ago
  Routing Descriptor Blocks:
  * 10.10.11.2, from 10.10.11.2, 00:00:00 ago, via FastEthernet0/0
      Route metric is 21, traffic share count is 1

What will happen if we change the domain-id in PE2?

By specifying the domain-id in the configuration, the OSPF process ID is no longer taken into account when building the domain-id, only the value specified is used.

PE2(config)#router ospf 100 vrf VPN_A
PE2(config-router)#domain-id 100.100.100.2
PE2(config-router)#end

PE1#shw bgp vpnv4 unicast all 2.2.2.2/32
BGP routing table entry for 1:1:2.2.2.2/32, version 126
Paths: (1 available, best #1, table VPN_A)
Flag: 0x820
  Not advertised to any peer
  Local
    100.100.100.2 (metric 11) from 100.100.100.2 (100.100.100.2)
      Origin incomplete, metric 11, localpref 100, valid, internal, best
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x646464020200
        OSPF RT:0.0.0.1:2:0 OSPF ROUTER ID:10.10.22.1:0
      mpls labels in/out nolabel/18

CE1#show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
  Known via "ospf 100", distance 110, metric 11
  Tag Complete, Path Length == 1, AS 65000, , type extern 2, forward metric 10
  Last update from 10.10.11.2 on FastEthernet0/0, 00:00:12 ago
  Routing Descriptor Blocks:
  * 10.10.11.2, from 10.10.11.2, 00:00:12 ago, via FastEthernet0/0
      Route metric is 11, traffic share count is 1
      Route tag 3489725928

Now CE1 sees the prefix as an External prefix (LSA-5). And why is that? Well, by specifying two different domain-id’s in OSPF, the routing process assumes there are two different OSPF instances running inside the VPN. So it’s like if we were redistributing prefixes from one OSPF process to the other. And it’s seen as a LSA-5 Type 2 because that’s the redistributing type by default (if we wanted to change that, we should change the redistribute command under OSPF by specifying into which type of External LSA redistribute: Type 1 or Type 2).

Ok, nice!! But let’s try to play now with the BGP community OSPF RT. Until now, this community hasn’t given any info. But if we configure a sham-link between both PEs (check this post about how to create a sham-link), the values of the community OSPF RT will come into play.

Let’s check how PE1 sees CE2′s Loopback after configuring the sham-link

PE1#show bgp vpnv4 unicast all 2.2.2.2/32
BGP routing table entry for 1:1:2.2.2.2/32, version 138
Paths: (1 available, best #1, table VPN_A, RIB-failure(17))
  Not advertised to any peer
  Local
    100.100.100.2 (metric 11) from 100.100.100.2 (100.100.100.2)
      Origin incomplete, metric 11, localpref 100, valid, internal, best
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x646464020200
        OSPF RT:0.0.0.1:2:0 OSPF ROUTER ID:10.10.22.1:0
      mpls labels in/out nolabel/18

The value of Domain-ID is not taken into account any more because both PEs have a direct adjacency through the sham-link (the routers don’t interpret that there are two different OSPF instances running any more). As we can see, the community OSPF RT has the value 0.0.0.1:2:0.

The first 4 bytes (0.0.0.1) are for the area. In our case, all routers are in Area 1.

The 2 last bytes (:2:0) show which type of LSA must be used when redistributing this prefix into OSPF. The values 1 and 2 mean the LSA to use must be LSA-1 (Intra-Area LSA)

Let’s check on CE1 if the prefix is seen as Intra-Area:

CE1#show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
  Known via "ospf 100", distance 110, metric 22, type intra area
  Last update from 10.10.11.2 on FastEthernet0/0, 00:07:24 ago
  Routing Descriptor Blocks:
  * 10.10.11.2, from 2.2.2.2, 00:07:24 ago, via FastEthernet0/0
      Route metric is 22, traffic share count is 1

Great!! It seems to be right!

Let’s see what happens if CE2 redistributes the prefix 22.22.22.22/32 into OSPF

PE1#sh bgp vpn uni all 22.22.22.22/32
BGP routing table entry for 1:1:22.22.22.22/32, version 32
Paths: (1 available, best #1, table VPN_A, RIB-failure(17))
Flag: 0x820
  Not advertised to any peer
  Local
    100.100.100.2 (metric 11) from 100.100.100.2 (100.100.100.2)
      Origin incomplete, metric 20, localpref 100, valid, internal, best
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x646464020200
        OSPF RT:0.0.0.0:5:1 OSPF ROUTER ID:10.10.22.1:0
      mpls labels in/out nolabel/20

Now the value of the community OSPF RT is 0.0.0.0:5:1. The value of 0.0.0.0 stands for no area (as we already know, external routes are not related to any area). And the value of :5:1 stands for LSA-5 Type 2. Let’s check if CE1 sees this prefix as external type 2 route

CE1#sh ip route 22.22.22.22
Routing entry for 22.22.22.22/32
  Known via "ospf 100", distance 110, metric 20, type extern 2, forward metric 21
  Last update from 10.10.11.2 on FastEthernet0/0, 00:07:28 ago
  Routing Descriptor Blocks:
  * 10.10.11.2, from 2.2.2.2, 00:07:28 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

Ok, it seems to be true!!

So, as we can see, the BGP community OSPF RT tells the PE router which type of LSA to use when redistributing the prefix into OSPF.

The different values for the 2 last bytes of the community are:

      :1:0 or :2:0 - indicating intra-area LSA-1 routes
      :3:0 - indicating inter-area LSA-3 routes
      :5:0 or :5:1 - indicating external LSA-5 routes (type 1 and type 2 respectively)
      :7:0 or :7:1 - indicating NSSA LSA-7 routes (type 1 and type 2 respectively)

And that’s all! I hope this post has been interesting for all of you.