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
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
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
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
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
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
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
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
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
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
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
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)
: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.