- The document discusses routing and traffic engineering techniques for inter-autonomous system MPLS VPNs. It describes using route reflectors to exchange routes between sub-autonomous systems and using next-hop-self to modify next-hop attributes. It also covers scaling inter-AS routing with techniques like automatic route filtering and inbound route filtering. Additional topics include downstream route target allocation for filtering, load balancing traffic across multiple inter-AS links, and using redundant PE-ASBR routers.
Note that route/path combination in LFIB requires 168 bytes of memory – with 1000 prefixes this is 164k
Note that you need two export statements or you can use export maps without any route-target export commands within the VRF configuration
Note that this requires Multi-HOP MP-eBGP between PE-ASBR routers. Also note CSCdt70169 as this configuration may be broken in current releases.
Note that local-preference or weight could also be used as a tool at PE-ASBR-2 and PE-ASBR-4.
This slide shows how to load balance across multiple PE-ASBR links but shows that route reflectors cannot be used in this case which 99% of the time is not going to be an acceptable deployment solution – therefore the ability to propagate multiple exit points via the route reflectors is a requirement
Both the above changes will require a slight modification of the BGP update processing path
- Support for imposing RTs on incoming/outgoing updates. This is currently supported for VRF export-maps, but support needs to be extended to BGP inbound/outbound route-maps.
The memory impact of this feature should be insignificant as it modifies the update itself without requiring the
storage of the update. Also, other transient memory requirements are minimal. The performance impact will depend on the length of the route-map. For each update, to perform RT replacement, each extended-community list being used will have to be walked twice, once while matching and once while deleting the RT. The performance impact will depend on the product of the number of updates and the size of the route-map. This is true for any route-map related feature.
The memory impact of this feature should be insignificant as it modifies the update itself without requiring the storage of the update. Also, other transient memory requirements are minimal. The performance impact will depend on the length of the route-map. For each update, to perform RT replacement, each extended-community list being used will have to be walked twice, once while matching and once while deleting the RT. The performance impact will depend on the product of the number of updates and the size of the route-map. This is true for any route-map related feature.
Router# <B&NBSP;STYLE="FONT-WEIGHT:&NBSP;BOLD">show ip bgp vpnv4 all 172.16.17.17 BGP routing table entry for 100:1:172.16.17.17/32, version 6 Paths: (1 available, best #1, no table) Advertised to update-groups: 1 100 300 192.168.1.1 from 192.168.1.1 (172.16.13.13) Origin incomplete, localpref 100, valid, external, best Extended Community: RT:100:1 The following examples verify route target replacement on PE1 and PE2.
Verify route target on PE1:
Router# <B&NBSP;STYLE="FONT-WEIGHT:&NBSP;BOLD">show ip bgp vpnv4 all 172.16.17.17 BGP routing table entry for 100:1:172.16.17.17/32, version 13 Paths: (1 available, best #1, table vpn1) Advertised to update-groups: 1 300 192.168.2.1 (via vpn1) from 192.168.2.1 (172.16.19.19) Origin incomplete, metric 0, localpref 100, valid, external, best Extended Community: RT:200:1 Verify route target on PE2:
Router# <B&NBSP;STYLE="FONT-WEIGHT:&NBSP;BOLD">show ip bgp vpnv4 all 172.16.17.17 BGP routing table entry for 100:1:172.16.17.17/32, version 13 Paths: (1 available, best #1, table vpn1) Advertised to update-groups: 3 100 300 192.168.1.1 (metric 20) from 172.16.16.16 (172.16.16.16) Origin incomplete, localpref 100, valid, internal, best Extended Community: RT:100:1
========================================================