1 / 43

INTER-AUTONOMOUS SYSTEM MPLS VPN: ADVANCED CONCEPTS

lev
Download Presentation

INTER-AUTONOMOUS SYSTEM MPLS VPN: ADVANCED CONCEPTS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. INTER-AUTONOMOUS SYSTEM MPLS VPN: ADVANCED CONCEPTS December 2003

    2. Agenda

    4. Separate IGPs Each sub-confederations runs a single IGP Route-reflectors are used as peering points between sub-confederations for better scaling Next-hop self done by border routers on eBGP and iBGP sessions towards intra-confederation peers

    7. Route reflectors exchange routes Using Route reflectors is a natural approach since they already have all VPN routes Next-hop-self choices Option-1: eBGP only Option-2: eBGP and iBGP on border routers When next-hop self is used on both iBGP and eBGP sessions (in CEBGP-1 and CEBGP-2) the topology is similar to a Multi-provider-VPN topology

    8. CEBGP-1 and CEBGP-2 each need to be known in both IGPs CEBGP-1 and CEBGP-2 use interface addresses for their BGP session Label has to be bound on peer address; single label is used between sub-confederations Neighbor route needs to be known either a static router, or by using PPP neighbor-route discovery Implementation will create a neighbor route for the BGP peer address

    10. PE-ASBR Memory Consumption

    11. PE-ASBR Memory Scaling

    12. ARF with Local VRF Import

    13. ARF with Local VRF Import (Cont.)

    14. ARF Disabled With Inbound Filtering

    15. ARF Disabled With Inbound Filtering (Cont.)

    16. Next-Hop-Self Effect On LFIB Note that route/path combination in LFIB requires 168 bytes of memory – with 1000 prefixes this is 164kNote that route/path combination in LFIB requires 168 bytes of memory – with 1000 prefixes this is 164k

    18. Various Filtering Points In Inter-AS

    19. Inbound Filtering On PE-ASBR

    20. Outbound Filtering On PE-ASBR

    21. Downstream RT Allocation

    22. Downstream RT Allocation (Cont.) Note that you need two export statements or you can use export maps without any route-target export commands within the VRF configurationNote that you need two export statements or you can use export maps without any route-target export commands within the VRF configuration

    24. Load Balancing Between Backbones

    25. VPN Client Traffic Flow

    26. Load Balancing Between PE-ASBRs 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 this requires Multi-HOP MP-eBGP between PE-ASBR routers. Also note CSCdt70169 as this configuration may be broken in current releases.

    27. Redundant PE-ASBR Connections Note that local-preference or weight could also be used as a tool at PE-ASBR-2 and PE-ASBR-4.Note that local-preference or weight could also be used as a tool at PE-ASBR-2 and PE-ASBR-4.

    28. Redundant PE-ASBR Load Balancing 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 requirementThis 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

    30. RT Rewrite RTs identify the VRF routing tables into which the prefix carried by the update is to be imported Carried as extended community attributes in bgp-vpnv4 updates RT Rewrites Supported for VRF export-maps Allow the replacement of route-targets on incoming and outgoing BGP updates Enables Service Providers to customize Route Targets within their network RT replacement can be performed at ASBRs exchanging VPNv4 prefixes RTs can also be replaced by PEs or RRs 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. 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.

    31. RT Rewrite Memory and Performance Impact 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.

    32. RT Rewrite Sample Configuration Replace RT X with Y

    33. RT Rewrite Verification Commands 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 ======================================================== 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 ========================================================

    35. Supported Shared Services in Inter-AS

    37. CSC versus Inter-AS

    38. CSC versus Inter-AS (Cont.)

    40. Inter-AS Summary

    41. Inter-AS Summary (Cont.)

    42. Inter-AS Summary (Cont.)

    43. References

More Related