BGP Extended Community

walter1972 · ‎01-30-2009

Hi

Consider an OSPF route advertised over the PE-CE link.

I know this Extended Community is attached to the OSPF route to indicate that it was an OSPF route before being redistributed, but how is this extended community actually created?

I thought BGP extended communities had to be manually configured? Does MP-BGP automatically insert this??

Secondly, lets say the PE-CE routing protocol is RIP - how is this communicated to the remote PE over BGP?

Any references?

Thanks for helping me get my head round this.

Giuseppe Larosa · ‎01-30-2009

Hello Walter,

>> Does MP-BGP automatically insert this??

yes as a result of service provider efforts to emulate an OSPF domain on behalf of the customer

from a configuration point of view the PE node has to redistribute OSPF into BGP address-family ipv4 vrf name, then via vpvn4 address-family the vpnv4 prefix with the extended communities that carry the OSPF data are sent.

The remote PE on accepting the vpnv4 route and importing it in the VRF routing table recognizes that the OSPF domain-id matches and creates an OSPF LSA that represent the route.

The OSPF LSA is then sent to the remote CE that can treat this as an O IA route

b) RIP

RIP is not able to detect different route types so the PE needs to perform redistribution of RIP into BGP address family ipv4 vrf name.

There is no need to carry additional information, remote PE will redistribute into RIP for the remote CE and this is all.

A seed metric is needed for successful redistribution into RIP.

Hope to help

Giuseppe

walter1972 · ‎01-30-2009

Thanks Giuseppe!

So, Extended BGP communities in MP-BGP is different from regular BGP Extended communities from a configuration perspective - ie regular BGP Extended communities is entered through the command line and Extended BGP communities in MP-BGP is an automatic attribute (similar to regular BGP communities attribute?)

Hope you can understand this

Walter

Giuseppe Larosa · ‎01-30-2009

Hello Walter,

MP-BGP extended community are 64 bits integers that can have an aspect:

ASN:value

or

PE-loop-ip-address:value

MP-BGP extended has been introduced to carry Route Targets ( route color(s)) in L3 MPLS VPN.

So some BGP extended communities are manually configured as a result of vrf configuration

for example:

ip vrf csc6762

rd 16232:6001

route-target export 16232:6762

route-target import 16232:6762

!

the Route target is exported in a BGP extended community attribute.

Actually multiple RTs / BGP extended communities can be associated with the same vpnv4 prefix.

When using the configuration to support OSPF on the MPLS superbackbone area 0 additional BGP extended communities are added as explained in previous post.

Now, I show an example of a vpnv4 route that has these additional BGP extended communities from a lab I did:

example:

ferrari#sh ip bgp v a 172.16.60.10

BGP routing table entry for 16232:6001:172.16.60.10/32, version 1706

Paths: (2 available, best #1, table csc6762)

Advertised to update-groups:

1 3

Local

192.168.199.65 (via csc6762) from 0.0.0.0 (172.16.60.1)

Origin incomplete, metric 66, localpref 100, weight 32768, valid, sourced, best

Extended Community: RT:16232:6762 OSPF DOMAIN ID:6762 OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:172.16.60.82:768

Local, (Received from a RR-client), imported path from 16232:6083:172.16.60.10/32

172.16.60.5 (metric 129) from 172.16.60.5 (172.16.60.5)

Origin incomplete, metric 2, localpref 100, valid, internal

Extended Community: RT:16232:6762 OSPF DOMAIN ID:6762 OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:172.16.60.83:768

BGP routing table entry for 16232:6083:172.16.60.10/32, version 1693

Paths: (1 available, best #1, no table)

Advertised to update-groups:

3

Local, (Received from a RR-client)

172.16.60.5 (metric 129) from 172.16.60.5 (172.16.60.5)

Origin incomplete, metric 2, localpref 100, valid, internal, best

Extended Community: RT:16232:6762 OSPF DOMAIN ID:6762 OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:172.16.60.83:768

ferrari#sh ip route vrf csc6762 172.16.60.10

Routing entry for 172.16.60.10/32

Known via "ospf 6762", distance 110, metric 66, type inter area this is the same as happens in the pdf

Redistributing via bgp 16232

Advertised by bgp 16232

Last update from 192.168.199.65 on FastEthernet5/0/0.145, 05:13:14 ago ferrari#sh ip ospf 6762 n

Routing Descriptor Blocks:

* 192.168.199.65, from 172.16.60.10, 05:13:14 ago, via FastEthernet5/0/0.145 Neighbor ID Pri State Dead Time Address Interface

Route metric is 66, traffic share count is 1 172.19.101.1 1 FULL/DR 00:00:31 192.168.199.65 FastEthernet5/0/0.145

ferrari#

as you can see both the manually configured RT and the automatically generated BGP extended community for carrying OSPF information between PE nodes are present

Hope to help

Giuseppe