BGP Extended Community Attribute
You have seen already that each PE-router learns routes from across the MPLS/VPN backbone and from attached customer sites. These routes are populated into VPN-specific routing tables. Any routes learned from customers are advertised across the MPLS/VPN backbone through the use of MP-iBGP, and any routes learned via MP-iBGP are placed into the VRFs of interested parties. To achieve this, each PE-router needs information that tells it how to process any routes it receives. This information not only tells the PE-router into which VRF the routes should be imported but also what information it should append to the route when advertising to other PE-routers.
Chapter 8 introduced the concept of a route target and briefly explained how this entity determines which VRF, and thus which VPN sites, should receive the route. Although the route target provides the mechanisms to identify which VRFs should receive the routes, it does not provide a facility that can prevent routing loops. These loops could occur if routes learned from a site are advertised back to that site. To prevent this, the Site of Origin (SOO), another concept in the MPLS/VPN architecture identifies which site originated the route and, therefore, should not receive the route from any PE-routers.
Note
The SOO is not necessary if the MPLS/VPN backbone is repairing a partitioned site. In this case, routes learned from one portion of the site should be advertised to another portion of the site at a different PE location.
The BGP Extended Community attribute applies both of these concepts to the MPLS/VPN architecture. This attribute is described in draft-ramachandra-bgp-ext-communities, which you can find on the IETF Web site at http://www.ietf.org.
This draft defines a new transitive optional BGP attribute, which contains a set of Extended Communities that define the site from where the VPN-IPv4 address was learned (the route origin) and the set of routers to which the route should be exported (the route target). The extended community attribute enables the closed user group functionality and is set by the PE-routers, via configuration, to define the import and export policies on a per site/VRF basis. Before you consider the specific details of this attribute, we should briefly review how it is used within the MPLS/VPN architecture.
Route Target BGP Extended Community
As mentioned, the BGP extended communities draft specifies two new communities defined as the route target and the route origin. The Cisco implementation of the draft uses both of these communities. The route origin, referred to as the SOO by the Cisco implementation, prevents routing loops between sites, and the route target extended community defines the import and export policies that a particular VRF uses.
The extended community is attached to a BGP route the same way standard BGP communities or any other BGP attributes are. The MP-iBGP update propagates the extended community along with other BGP attributes between PE-routers, and its value determines to which VRF or set of VRFs to import the route. Careful definition of the route target extended community values provides the flexibility to provision many different VPN topologies. One such topology, which uses the MPLS/VPN backbone from the case study, helps to show the basic operation of the route target (see Figure 9-5).
Figure 9-5. Route Target BGP Extended Community Usage
Figure 9-5 shows that the SuperCom San Jose PE-router exports routes for the FastFoods VPN with a route target of 100:26 and for the EuroBank VPN with a route target of 100:27. The NYBank VRF on the SuperCom New York router imports routes with a route target of 100:27. This means that it contains only routes for the EuroBank San Francisco site. The FastFoods VRF on the SuperCom Paris router imports routes with a route target of 100:26 and 100:27. This means that it contains routes for the FastFoods San Jose site and for the EuroBank San Francisco site.
Note
Figure 9-5 also shows an interesting example of how one site within a VPN can hold routes that are not contained in another site of the same VPN. The Paris PE-router imports routes with a route target of 100:26 and 100:27. This means that the FastFoods Lyon site has routes that belong to the EuroBank San Francisco site and the FastFoods San Jose site. However, neither the EuroBank or FastFoods VRFs on the San Jose PE-router are configured to import both route target values. They contain only routes that belong to their particular VPN because the Paris PE-router does not re-advertise routes from within its VRF that it learned via iBGP (standard iBGP rules).
Configuration of Import and Export Policies
The last step in the configuration of each VRF is the addition of import and export policies for the VRF to use. These policies are used to populate routes into the VRF and to advertise routes out of the VRF.
The route target BGP Extended Community dictates the policies used by the VRF. The route target must be configured to specify the routes, which contain this specific route target value, that are imported into the VRF, and the route target that is added to the routes that are exported from the VRF. The route-target command, the syntax of which is shown in Example 9-6, controls this within the VRF configuration.
Example 9-6 Route Target VRF Configuration Command
San Jose(config-vrf)#route-target ?
ASN:nn or IP-address:nn Target VPN Extended Community
both Both import and export Target-VPN community
export Export Target-VPN community
import Import Target-VPN community
Use the export and import keywords with the route-target command to specify separately the export and import policies for each VRF. Usually, the default export and import policies are the same so you can specify both using one command, either route-target ASN:nn or route-target both ASN:nn (both commands achieve the same results). This is the case in the sample topology, where both the EuroBank and FastFoods VRFs need to export their routes with a route target that is imported by other members of their organization's VPN.
Example 9-7 shows the relevant configuration of the SuperCom San Jose PE-router, for the EuroBank and FastFoods VPN customer VRFs.
Example 9-7 SuperCom San Jose PE-router Configuration?Import/Export
hostname San Jose ! ip vrf EuroBank rd 1:27 route-target export 100:27 route-target import 100:27 ! ip vrf FastFoods rd 1:26 route-target export 100:26 route-target import 100:26
If you need to add more than one route target to any routes that are exported from the VRF, use the route-target export command multiple times within the VRF configuration. This command defines the set of VPN route target extended communities that can attach to any routes exported from the VRF into VPN-IPv4 NLRIs in MP-BGP updates. Likewise, you can use the route-target import command to specify which routes to import into the VRF. If a received route contains any of the route target values listed in the import list, then that route is eligible for import into the VRF.
Site of Origin BGP Extended Community
The route origin extended community is referred to as the SOO in the Cisco implementation of the MPLS/VPN architecture; therefore, we use this description throughout this book.
The SOO prevents routing loops when a site is multihomed to the MPLS/VPN backbone, and, in addition, that site uses the AS-override feature. This is achieved by identifying the site from where the route was learned, based on its SOO, so that it is not re-advertised back to that site from a PE-router somewhere else in the MPLS/VPN backbone.
Note
Chapter 10 discusses the AS-override feature in more detail.
Note
The SOO is not necessary if the MPLS/VPN backbone is used to repair a partitioned site that is multihomed and uses the AS-override feature. SOO also is used only if BGP is used to achieve the PE to CE connectivity.
Figure 9-6 illustrates this concept, and shows a site connected to two separate PE-routers and the behavior of the PE-router when a route is received that contains a SOO extended community that matches the one configured for the VRF.
Figure 9-6. SOO BGP Extended Community
Figure 9-6 shows that the SuperCom Chelmsford PE-router receives an MP-iBGP update for 193.1.1.0/24 from the New York PE-router. This update contains a SOO of 100:28, which is the one configured for the NYBank VRF on the Chelmsford PE-router. Because of this, the route is not advertised to the NYBank Chelmsford CE-router.
Configuration of the SOO
The SOO extended community is configured using a route-map on each PE-router. Because it is required only in a multihomed environment, you do not need for this chapter's simple intranet case study example or if you run a PE to CE protocol other than BGP.
Example 9-8 shows a configuration for the New York PE-router shown in Figure 9-6. The route-map can be applied to routes learned through a particular VRF, regardless of whether these routes were learned via BGP (they could be learned through redistribution from another protocol into BGP).
Example 9-8 Configuration of the SOO Extended Community
router bgp 1 no synchronization no bgp default ipv4-unicast neighbor 194.22.15.4 remote-as 1 neighbor 194.22.15.4 update-source loopback0 ! address-family ipv4 vrf NYBank neighbor 192.168.65.5 remote-as 250 neighbor 192.168.65.5 activate neighbor 192.168.65.5 route-map setsoo in no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 194.22.15.4 activate neighbor 194.22.15.4 send-community extended no auto-summary exit-address-family ! route-map setsoo permit 10 set extcommunity soo 100:28
Example 9-9 shows that the subnet 193.1.1.0/24, learned from the NYBank New York CE-router by the SuperCom New York PE-router, contains the SOO 100:28.
Example 9-9 SOO Extended Community Example
New York# show ip bgp vpnv4 vrf NYBank 193.1.1.0 BGP routing table entry for 1:27:193.1.1.0/24, version 14 Paths: (1 available, best #1, table NYBank) Advertised to non peer-group peers: 194.22.15.4 2 192.168.65.5 from 192.168.65.5 (195.12.2.1) Origin IGP, metric 0, localpref 100, valid, external, best Extended Community: SoO:100:28 RT:100:27
BGP Extended Community Attribute Format
Now that you know how the BGP extended community attribute is used in the MPLS/VPN architecture, you can learn how this attribute is structured.
Each of the extended community attributes has a defined community type code of 16 and is encoded as an 8-octet value. The first two octets define the attribute type, and the next six octets hold the value of the attribute. Types 0 through 0x7FFF inclusive are assignable by the Internet Assigned Numbers Authority (IANA), and types 0x8000 through 0xFFFF inclusive are vendor-specific.
The route target extended community has a type code of 0x0002 or 0x0102, and the SOO extended community has a type code of 0x0003 or 0x0103. The structure of the value field (and the way the value field is displayed) depends on the high order byte of the type field. See Figure 9-7.
Figure 9-7. BGP Extended Community Attribute Format
A route can carry both the standard BGP Communities attribute as defined in RFC1997 and the extended BGP Communities attribute as defined in draft-ramachandra-bgp-ext-communities. It also can carry multiple community attributes through the use of the additive keyword in the case of standard communities and through the use of route-maps when exporting the VRF routes in the case of extended communities. Cisco IOS 12.1 allows the additive keyword to be used with extended communities.
