Network Management of Customer Links
As with any network solution, the management and provisioning of customer links and of the internal service provider infrastructure are an important part of the deployment. In addition, the configuration and subsequent changes to this configuration are also high on the agenda. We have already discussed the role of the network management NMC in previous chapters, and we have also seen a typical topology that provides this type of activity.
Note
The applications that can provide this type of functionality within an MPLS-enabled VPN environment have not been included in this publication and have not been the focus of the research into this book. However, the Cisco VPN Solutions Center product offering will be available for management and provisioning of an MPLS-enabled VPN network. Refer to the Cisco Systems web site, http://www.cisco.com, for further information on this product offering.
Without the use of specific applications that have been designed to assist in the management and provisioning of the VPN service, it is still possible to manage the network by manipulating the route target attribute of certain VPN-IPv4 routes so that they may be imported by a network management station somewhere within the service provider network. Indeed, even if this type of application is deployed, it really addresses only the PE side of the problem. If a managed network service of CE-routers is a requirement, then manipulation of the route target is necessary. This type of managed network service was discussed in Chapter 7, "Virtual Private Network (VPN) Implementation Options" ; an example is shown in Figure 13-10.
Figure 13-10. Network Management VPN Topology
Although this type of solution may not be appropriate for all deployments?and certainly many customers will utilize SNMP for management of their customer links?it may be of interest in some cases. The techniques described may be useful for other applications of the MPLS/VPN architecture as well.
To be able to provide this type of service through use of the mechanisms that make up the MPLS/VPN architecture, we need to define what problem we are actually trying to overcome. In this case, the ultimate goal is to be able to pick out certain routes as belonging to specific areas of interest, such as identification of customer links for network management purposes. There are many ways to approach this problem?these will be visited in the following sections?and several solutions are available to the network designer.
Advertisement of Routes with Different Extended Communities
Our objective can be summarized as follows: to provide a service in which all customer routes become eligible for import into the Network Management VPN, and to make sure that we can import only the routes that are significant for the network management application. To achieve this objective, a number of options can be used. The first option, and probably the easier to implement, is to advertise all routes from a particular VPN with two separate BGP route target extended communities. You might think that it should be possible to import some routes into one set of VRFs and then to import the others into another set by using this method.
In our example, this would involve the first route target attribute being imported by members of the relevant VPN, and the second route target attribute being imported by the network management stations. If we refer to the example shown in Figure 13-10, we can define the relevant route target attributes as specified within Table 13-1.
|
Customer Name |
VPN Routes RT |
NMC Routes RT |
|---|---|---|
|
FastFoods |
100:26 |
100:94 |
The following example shows a sample configuration that will cause the originating PE-router to send an update for each prefix within the VRF with two separate route target attributes.
Example 13-7 Advertisement of Same Routes with Two Route Targets
ip vrf FastFoods rd 1:26 route-target import 100:26 route-target export 100:26 route-target export 100:94 !
Running debug on the advertising/receiving PE-routers shows that each prefix is advertised only once, but this advertisement contains two separate route target attributes.
Example 13-8 Debug Output for Advertisement of Routes with Two Route Targets
San Jose # debug ip bgp update BGP(1): 194.22.15.1 send UPDATE (format) 1:26:195.12.2.0/24 nexthop 194.22.15.2, metric 0, path, extended community RT:100:26 RT:100:94 Paris # show ip bgp vpnv4 vrf FastFoods 195.12.2.0 BGP routing table entry for 1:26:195.12.2.0/24, version 13 Paths: (1 available, best #1, table FastFoods) Not advertised to any peer Local 194.22.15.2 from 194.22.15.2 (194.22.15.2) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:100:26 RT:100:94
The route targets attached to the BGP routes make every route from the customer VPN eligible for import into customer VRFs and the Network Management VRF. The end result of this setup would be that all customer routes would also end up in the Network Management VRF, which would, in the worst case, hold all the routes of all the VPN customers. Because some customers might have overlapping IP addresses, the resulting routing tables would be even more interesting.
We don't control the export process in this case, so it is necessary to apply import filters (implemented as import maps, which were discussed in detail in Chapter 11, "MPLS/VPN Advanced Topologies" ) so that only the relevant routes are imported into specific VRFs. In our example, the goal is to import the subnets that connect the CE-routers with the PE-router into VRFs that are referenced by Network Management VPNs, and to import all other VPN routes into the relevant customer VPN. Both of these VPNs should not hold routes that belong to the other.
Figure 13-11. Advertisement of Routes with Two Route Targets
Figure 13-11 shows an example of the advertisement of the routes from a VRF using two separate route target attributes. When these routes are received by SuperCom routers Paris and Denver, they must be filtered and imported into the relevant VRFs. This can be achieved through use of import maps.
The import maps can filter based on IP prefix, standard BGP community, or extended community. Extended community support was introduced in Cisco IOS 12.0(7)T. Before IOS 12.0(7)T, no facility was available to filter imported routes based on route target, which meant that you usually had to rely on IP prefix lists (or standard IP access lists) to specify the import filter, and these could become quite large. The solution was obviously very restrictive and not at all scalable.
An example follows to illustrate where this type of filtering may become restrictive. Although this example is exaggerated, it illustrates the problem and shows that the resultant access list could end up with 201 entries. This is not only a headache in terms of configuration, but it is also very restrictive when trying to manage the configuration of the service.
Example 13-9 Route Filtering Using Import Maps Without Extended Community Support
A site is receiving 300 routes; 100 of these routes have a route target of 1:100, a further 100 have a route target of 1:200, and the other 100 have a route target of 1:300. The site requirement is such that only routes with a route target of 1:100 or 1:200 and only one route with a route target of 1:300 can be imported into the site VRF. If the site routes cannot be summarized, then the worst-case scenario is that the access list will require 201 entries. The resultant configuration would be as follows: ip vrf sample route-target import 1:100 route-target import 1:200 route-target import 1:300 import map RouteFilter ! route-map RouteFilter match ip address 1 ! access-list 1 permit 192.1.1.1 255.255.255.0 access-list 1 permit 193.1.1.1 255.255.255.0 …
In the example shown in Figure 13-11, in which we want to import some routes into the Network Management VPN and others into the customer VPN, the necessary configuration to allow each of the VRFs to be populated with the correct routes would be as shown in Example 13-10. Import maps are used to filter each route so that only the correct routes are placed into the VRFs of the PE-router.
Example 13-10 Configuration Example for Import Filtering into VRFs
hostname Paris ! ip vrf FastFoods rd 1:26 route-target import 100:26 import map FastFoodRoutesOnly ! route-map FastFoodRoutesOnly match ip address 1 ! access-list 1 permit 195.12.2.0 255.255.255.0 ! hostname Denver ! ip vrf NetworkManagement rd 1:94 route-target import 100:94 import map NetworkManagement ! route-map NetworkManagement match ip address 2 ! access-list 2 permit 194.1.1.1
This configuration highlights a problem with using two separate route targets with import maps. Because each route carries both route target attributes, it is not possible to pick out the relevant routes through the route import process designed in the MPLS/VPN architecture (extended community attribute route target), so we need to base the route import decision on IP access lists. This means that there is little point in advertising the routes with different route targets within our scenario, and the same route target can be used for all routes.
Note
The advertisement of the same set of routes with different route targets may be useful in certain topologies. For example, if a site wants to import routes from only one other site within its VPN, then it could import a different route target advertised from that site rather than importing the default VPN route target. If it did not do this, then it would need to deploy an extensive import map so that it filtered out all unwanted routes.
Use of Standard BGP Communities for Route Filtering
As an alternative to the previous approach of advertising a set of routes with two separate route target attributes, it is possible to use the same method but with standard BGP communities within the import map filters instead of filtering based on the IP prefix.
This approach has some obvious advantages, primarily the reduction in the amount of entries that are required within the access lists used to implement the filters on the receiving PE-routers. However, we need to understand whether it will allow us to achieve our ultimate goal of picking out specific routes for import into our Network Management VPN in a scalable manner.
Figure 13-12. Route Filtering Using Standard BGP Communities
Figure 13-12 provides an illustration of this method. Using this approach, every customer route is marked with two route targets, as in our previous example: the FastFoods and the Network Management route targets. However, only the routes that are destined for the Network Management VRF are marked with a standard BGP community. This standard BGP community can then be used in the import map for the Network Management VRF. This means that the SuperCom PE-router Denver will import only routes into the Network Management VRF that contain a specific route target (in this case, 100:94) and the configured standard community (defined also as 100:94).
Note
Both route target attributes are necessary because all VPNs will use the same route target to import routes that are pertinent to the Network Management VPN.
Note
Note that the standard and extended communities differ in their format, so care must be taken on the value that is used. Standard communities use a 32-bit format, while extended community use a 64-bit format.
An IP prefix list may also be used to match on a certain prefix or prefix length. In the following example, this facility has been used by the SuperCom Paris router. Also notice that the both keyword is required within the BGP VPNv4 configuration so that the PE-router knows that it must send both standard and extended BGP community attributes. The configurations for all relevant routers in Figure 13-12 are as shown in Example 13-11.
Example 13-11 Use of Standard Communities to Control Route Import into VRF
hostname San Jose ! ip vrf FastFoods rd 1:26 route-target import 100:26 route-target export 100:26 route-target export 100:94 ! router bgp 1 neighbor 194.22.15.3 remote-as 1 neighbor 194.22.15.1 remote-as 1 ! address-family vpnv4 neighbor 194.22.15.3 activate neighbor 194.22.15.3 send-community both neighbor 194.22.15.3 route-map FilterRoutes out neighbor 194.22.15.1 activate neighbor 194.22.15.1 send-community extended ! access-list 1 permit 194.1.1.1 ! route-map FilterRoutes permit 10 match ip address 1 set community 100:94 ! route-map FilterRoutes permit 20 ! hostname Denver ! ip vrf NetManagement rd 1:94 route-target import 100:94 route-target export 100:94 import map NetManagement ! ip community-list 1 permit 100:94 ! route-map NetManagement match community 1 ! hostname Paris ! ip vrf FastFoods rd 1:26 route-target import 100:26 route-target export 100:26 import map FastFoodRoutesOnly ! ip extcommunity-list 1 permit rt 100:26 ! ip prefix-list FastFoods seq 10 permit 195.12.2.0/23 ge 24 ! route-map FastFoodRoutesOnly match extcommunity 1 match ip address prefix-list FastFoods !
This sample configuration shows several things of interest. SuperCom routers Denver and Paris will learn routes from PE-router San Jose with two separate route targets. The Denver router will import only routes that have a route target of 100:94 and a standard BGP community of 100:94. The Paris router will import only routes that have a route target of 100:26 that fall within the range of the prefix-list.
Because prefix 195.12.2.0/24 falls within the permit statement of the prefix list on router Paris, it will be imported into the FastFoods VRF. Notice that this is the only route that will be imported into this VRF, although both routes will be considered for import because they contain the route target of 100:26. (The output from show ip bgp vpnv4 all in Example 13-12 confirms this. Notice how the FastFoods VRF has both routes, but the NetManagement VRF has only one?the route that contains both the standard and extended community attributes.)
To verify the correct import of various customer routes into VRFs on the SuperCom routers, the following example illustrates all the relevant commands showing that the standard BGP community 100:94 is not attached to the route 195.12.2.0/24. The route is therefore not imported into the NetManagement VRF.
Example 13-12 Imported Routes Using Standard BGP Communities
Paris# show ip bgp vpnv4 all Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:26 (default for vrf FastFoods) *>i195.12.2.0/24 194.22.15.2 0 100 0 ? *>i194.1.1.1/32 194.22.15.2 0 100 0 ? Denver# show ip bgp vpnv4 all Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:94 (default for vrf NetManagement) *>i194.1.1.1/32 194.22.15.2 0 100 0 ? Paris# show ip bgp vpnv4 all 195.12.2.0 BGP routing table entry for 1:26:195.12.2.0/24, version 7 Paths: (1 available, best #1, table FastFoods ) Not advertised to any peer Local 194.22.15.2 from 194.22.15.2 (194.22.15.2) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:100:26 RT:100:94 Paris# show ip bgp vpnv4 all 194.1.1.1 BGP routing table entry for 1:26:194.1.1.1/32, version 265 Paths: (1 available, best #1, table NULL) Not advertised to any peer Local 194.22.15.2 from 194.22.15.2 (194.22.15.2) Origin incomplete, metric 0, localpref 100, valid, internal, best Community: 100:94 Extended Community: RT:100:26 RT:100:94 Denver# show ip bgp vpnv4 all 194.1.1.1 BGP routing table entry for 1:94:194.1.1.1/32, version 27 Paths: (1 available, best #1, table NetManagement) Not advertised to any peer Local, imported path from 1:94:194.1.1.1/32 194.22.15.2 from 194.22.15.2 (194.22.15.2) Origin incomplete, metric 0, localpref 100, valid, internal, best Community: 100:94 Extended Community: RT:100:26 RT:100:94 Denver# show ip bgp vpnv4 vrf NetManagement Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:94 (default for vrf NetManagement) *>i194.1.1.1/32 194.22.15.2 0 100 0 ?
The method described in the previous paragraphs enables us to achieve our objective and provides a method of selectively picking certain routes for import into specific VRFs. However, the major drawback to this method is that each PE-router that wants to import selective routes needs to have filters configured to match on the standard community attribute. So, what is really needed is a method that allows us to selectively export routes with specific route targets that can be imported using one statement on any receiving PE-routers.
You might think that to achieve this, we could change the route target extended community attribute in the same way as the standard community attribute in the previous example. However, setting extended community attributes through route maps applied to route redistribution, or to BGP neighbors, is not supported; this type of change must be implemented using export maps, as will be seen in the next section. The following example shows the error that is produced if you try to change the route target through a route map.
Example 13-13 Changing Route Target Using a Route Map
Paris(config-route-)# set extcommunity rt 100:100 % "ExtendedCommOut" used as BGP outbound route-map, set extcommunity rt not supported
Advertisement of Routes with Different Route Targets Using Export Maps
The previous example provided us with a working solution to the CE-router management problem, but the solution was complex and suboptimal (it would be fair to call it a workaround, not a solution). We have not been able to provide the capability to advertise routes with different route target attributes from the originating PE-router.
As previously stated, what is needed is a mechanism by which the originating PE-router can selectively advertise certain routes with a route target that is different than other routes that it is also advertising from the same VRF. This mechanism is provided through the use of export maps within the VRF configuration.
In our SuperCom backbone example, if this feature is used, then we now can advertise our network management routes with one route target and then advertise the rest of our routes with a totally separate route target. This is illustrated in Figure 13-13.
Figure 13-13. Export of Routes with Different Route Targets
Figure 13-13 shows that two routes are advertised from the SuperCom PE-router San Jose, and each of these has a different route target. The SuperCom PE-router Paris is configured to import routes with one of the route targets into the FastFoods VPN, and router Denver is configured to import routes with the other route target into the Network Management VPN. The resultant configurations for all the relevant routers can be seen in Example 13-14.
Example 13-14 Export of Routes with Different Route Targets
hostname San Jose ! ip vrf FastFoods rd 1:26 export map FastFoodsExport route-target import 100:26 ! access-list 1 permit 194.1.1.1 access-list 2 permit any ! route-map FastFoodsExport permit 10 match ip address 1 set extcommunity rt 100:94 ! route-map FastFoodsExport permit 20 match ip address 2 set extcommunity rt 100:26 ! hostname Paris ! ip vrf FastFoods rd 1:26 route-target export 100:26 route-target import 100:26 ! hostname Denver ! ip vrf NetManagement rd 1:94 route-target export 100:94 route-target import 100:94 !
In some networks, the service providers base the connectivity toward their customers on static routes configured on PE-routers. If the customer is a VPN customer, the route would obviously be configured within the context of the customer VRF. To advertise these static routes to other members of the VPN or to other VPNs, they must be redistributed into MP-iBGP. In this environment, the PE-router configuration can be simplified significantly by using a tag that can be associated with the static route to signify the set of VPNs into which the route should be exported.
Ideally, the tags assigned to static routes would be used during their redistribution into MP-iBGP to set the route target of the route. The real solution, however, is slightly more complex because you cannot set route target during route redistribution. In addition, the original route tag is lost at the moment that the route target is set with the export map. The only parameters that can be used in both route maps are standard BGP communities that serve as a link between the tags assigned to static routes and MPLS/VPN route targets.
When the static routes toward the VPN customer are redistributed into MP-iBGP, a route map is used to match the static route tag and to set a corresponding standard BGP community. When the standard BGP community is set, it can then be used to specify which route target should be used for the route when it is exported through MP-iBGP to other PE-routers. Example 13-15 provides a sample configuration that shows a static route for prefix 193.1.1.1/32 being placed into the FastFoods VPN with a standard BGP community of 100:1. When this route is advertised via MP-iBGP, its route target is set to 100:5.
Example 13-15 Tagging Static Routes for Redistribution into MP-iBGP
hostname San Jose
!
ip vrf FastFoods
rd 1:26
export map FastFoodsExport
route-target import 100:26
!
access-list 1 permit 194.1.1.1
access-list 2 permit any
!
ip community-list 101 permit 100:1
!
router bgp 1
!
address-family ipv4 vrf FastFoods
redistribute static route-map static FastFoodStatics
exit address-family
!
ip route vrf FastFoods 193.1.1.1 255.255.255.255 serial 0/1 tag 100
!
route-map FastFoodsExport permit 10
match ip address 1
set extcommunity rt 100:94
!
route-map FastFoodsExport permit 20
match community 101
set extcommunity rt 100:5
!
route-map FastFoodsExport permit 30
match ip address 2
set extcommunity rt 100:26
!
route-map static_FastFoodStatics permit 10
match tag 100
set community 100:1
Note
Notice that within the configuration of the San Jose router, there is no route-target export command within the FastFoods VRF configuration. This is because the default route target for this VRF has been set to 100:26 within the export map. (The third permit statement allows everything that does not match the first two statements.)
If two route target attributes for the same prefix are required, then the default may be configured within the export map by using the set extcommunity rt command and specifying the default plus any other required route targets.
If it is desirable to remove the standard BGP community attributes that were specified in Example 13-15, then the following configuration could be added. This will strip the standard BGP community before it is advertised across the MP-iBGP sessions.
Example 13-16 Removal of Standard BGP Community Attributes Before Advertisement
ip community-list 102 permit 100:1 ! address-family vpnv4 neighbor 194.22.15.1 activate neighbor 194.22.15.1 send-community both neighbor 194.22.15.1 route-map drop community out ! route-map drop_community permit 10 set comm-list 102 delete
