580 likes | 776 Views
EIGRP FOR MANAGED SERVICES FUNCTIONALITY PRESENTATION. DONNIE SAVAGE CHETAN KHETANI SANGITA PANDYA INTERNET TECHNOLOGIES DIVISION DECEMBER 2004. Agenda. INTRODUCTION AND TECHNOLOGY OVERVIEW Functionality Description EIGRP Route Propagation Behaviour EIGRP Changes Operation Scenarios
E N D
EIGRP FOR MANAGED SERVICESFUNCTIONALITY PRESENTATION DONNIE SAVAGECHETAN KHETANISANGITA PANDYA INTERNET TECHNOLOGIES DIVISION DECEMBER 2004
Agenda • INTRODUCTION AND TECHNOLOGY OVERVIEW • Functionality Description • EIGRP Route Propagation Behaviour • EIGRP Changes • Operation • Scenarios • Configuration and Troubleshooting Presentation_ID 2 2 2 © 2004 Cisco Systems, Inc. All rights reserved.
MANAGEDExtranet MANAGEDCPE MANAGED IPT VM VM MANAGED Internet Gateway VPN for Many Managed Services V i r t u a l P r i v a t e N e t w o r k MANAGED Routing MANAGED Security Service Level Agreement for MANAGED Services Service Provider Converged Network VPN B Customer Branch Customer HQ
Managed Routing Revenue Opportunity Over 50% of Cisco Enterprise Customers Deploy IP Routing with EIGRP IP/MPLS VPN Backbone PE-3 PE-1 PE-2 CE-1 CE-2 EIGRP AS-1 EIGRP AS-1 Presentation_ID 4 4 4 © 2004 Cisco Systems, Inc. All rights reserved.
Robust EIGRP Support Cisco Exclusive Cisco IOSSupports the Industry’s Most Comprehensive and Robust Routing Protocol Support: RIP, OSPF, BGP, ISIS, Including EIGRP VPN C/Site 2 CEA2 12.1/16 Static CEB2 CE1B1 16.2/16 RIPv2 RIPv2 P1 PE2 VPN B/Site 2 BGP PE1 RIPv2 P2 CEA3 OSPF OSPF 16.2/16 CEA1 P3 PE3 BGP VPN A/Site 2 CEB3 VPN A/Site 1 16.1/16 VPN C/Site 1 12.2/16 • BENEFITS: • Service Provider: Simplest point of entry into enterprise’s existing architecture • Enterprise: Least disruption to current network design Presentation_ID 5 5 5 5 5 © 2004 Cisco Systems, Inc. All rights reserved.
Managed EIGRP Benefits for SPs and Enterprises: • Impose little requirements or no restrictions on customer networks • CE and C routers are NOT required to run newer code • (CE/C upgrades recommended for full SoO functionality) • Customer sites may be same or different Autonomous Systems • Customer sites may consist of several connections to the MPLS VPN backbone • Customer sites may consist of one or more connections not part of the MPLS VPN backbone (“backdoor” links)
PE-CE Routing Protocol EIGRP, Static,RIPv2,EBGP,OSPF VRF Interface LDP MP-BGP Sessions Customer Edge Provider Router Provider Edge Technology Overview: MPLS VPN Network VPN_A VPN_A MPLS Core 10.2.0.0 11.5.0.0 CE CE VPN_A VPN_B 10.2.0.0 10.1.0.0 P P CE PE CE PE VPN_A P P 11.6.0.0 CE VPN_B 10.3.0.0 CE PE PE VPN_B 10.1.0.0 CE
Technology Overview: EIGRP for MPLS VPN PE-CE VPN C/Site 2 CEA2 12.1/16 VPN B/Site 1 EIGRP CEB2 CE1B1 16.2/16 16.1/16 EIGRP EIGRP P1 PE2 VPN B/Site 2 CE2B1 BGP PE1 EIGRP P2 CEA3 EIGRP EIGRP 16.2/16 CEA1 P3 PE3 EIGRP VPN A/Site 2 CEB3 16.1/16 VPN C/Site 1 12.2/16 VPN A/Site 1
Step 3 Step 1 Step 5 Technology Overview: MPLS VPN Routes Distribution VPN C/Site 2 CEA2 12.1/16 VPN B/Site 1 EIGRP CEB2 CE1B1 16.2/16 16.1/16 EIGRP EIGRP P1 PE2 VPN B/Site 2 CE2B1 BGP EIGRP PE1 P2 CEA3 Step 4 EIGRP EIGRP Step 2 16.2/16 CEA1 P3 PE3 EIGRP VPN A/Site 2 CEB3 16.1/16 VPN C/Site 1 12.2/16 VPN A/Site 1
Technology Overview:Routing Information Distribution • Step 1: From site (CE) to service provider (PE) • E.g. EIGRP, RIPv2, OSPF, or BGP (or static routing on PE) • Step 2: Export to provider’s BGP at ingress PE • Step 3: Within/across service provider(s) (among PEs): • Via MP-IBGP • Step 4: Import from provider’s BGP at egress PE • Step 5: From service provider (PE) to site (CE) • E.g. EIGRP, RIPv2, OSPF, or BGP (or static routing on PE)
SERVICE PROVIDER VPN B C A SITE 1 D SITE 2 Technology Overview: EIGRP PE/CE Deployment • In this network, we have two corporate sites, connected by a leased line and VPN through a service provider • EIGRP routes redistributed into BGP at B, and back into EIGRP at C, appear as external routes at Site 2 • We want them to appear as internal routes EXTERNAL
SERVICE PROVIDER VPN B C A SITE 1 D SITE 2 Technology Overview: EIGRP PE/CE Deployment • As routes are redistributed into BGP as B, extended communities containing the EIGRP metrics are attached to them • As routes are redistributed back into EIGRP at C, these extended communities are used to reconstruct the routes as internals • The VPN is considered a 0 cost link in this configuration INTERNAL
SERVICE PROVIDER VPN B C A SITE 1 D SITE 2 Technology Overview: EIGRP PE/CE Deployment ip vrf VRF-RED rd 172.16.0.1:20exit....router eigrp 1 address-family ipv4 vrf VRF-RED autonomous-system 101 network 172.16.0.0 255.255.0.0 redistribute BGP 101 metric 10000 100 255 1 1500 exit-address-family router-c#show ip eigrp vrf VRF-RED topologyIP-EIGRP Topology Table for AS(1)/ID(192.168.10.1) Routing Table:VRF-PINK P 10.17.17.0/24, 1 successors, FD is 409600 via 50.10.10.2 (409600/128256), Ethernet3/0P 172.16.19.0/24, 1 successors, FD is 409600 INTERNAL
SERVICE PROVIDER VPN B C A SITE 1 D SITE 2 Technology Overview: EIGRP PE/CE Deployment • 12.0(27)SV 12.0(21.1)SY2 12.0(21.1)S2 • Backdoor links were not supported • http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080154db3.html NO BACKDOOR LINK
SERVICE PROVIDER VPN B C A SITE 1 D SITE 2 Technology Overview: EIGRP PE/CE Backdoor Links • The biggest danger with backdoor links is possible routing loops • Site1 advertises a network through the back door to site 2 • C prefers this route, and redistributes it into BGP • B prefers the BGP route, and redistributes it into EIGRP, forming a loop • The solution is to automatically tag all the routes originating in site 1 so they will be rejected by C • This tag is called the Site of Origin (SoO)
SERVICE PROVIDER VPN B C A SITE 1 D SITE 2 Technology Overview: EIGRP PE/CE Backdoor Links • The SoO is set on all PE routers on the interface connecting to the PE, and on backdoor link routers • The CE will always reject the marked EIGRP learned routes, and prefer the BGP learned routes • You can then set the backdoor link so the path through the VPN is always preferred over the backdoor link route-map SoOrigin permit 10 set extcommunity soo 100:1 .... interface FastEthernet 0/0 ip vrf sitemap SoOrigin ....
EIGRP Traffic Statistics AS Number Hellos Sent/Received Updates Sent/Received Queries Sent/Received Replies Sent/Received EIGRP Topology Data Destination Net/Mask Active State Feasible Successors Origin Type Distance Reported Distance EIGRP Interface Data Peer Count Reliable/Unreliable Queues Pacing Pending Routes Hello Interval EIGRP Neighbor Data Peer Address Peer Interface Hold Time Up Time SRTT/RTO Version Technology Overview: EIGRP MIB Support AND MANY MORE…
Technology Overview: EIGRP PE/CE Prefix Limits • Generic Redistribution: To limit the number of redistributed routes/prefixes • MPLS VPN PE-CE: To limit the number of prefixes on a given PE router as follows: • For the whole VPN or • For individual CEs/neighbors CE CE CE CE CE CE CE PE CE PE BGP/MPLS VPN With EIGRP between PE-CE CE PE CE PE1 PE PE CE CE VRF1 CE … VRF2 VRFL+1 CE CE CE VRF3 VRFL • neighbor maximum-prefix <maximum> [<threshold>] [warning-only] [[restart <restart interval>][restart-count <count>][reset-time <reset interval>][dampened]] • redistribute maximum-prefix <maximum> [<threshold>] [warning-only][[restart <restart interval>] [restart-count <count>] [reset-time <reset interval>][dampened]]
Summary • Native EIGRP on PE to CE links • Avoids translating all EIGRP routes to external routes • Redistribution of EIGRP metrics preserved across BGP cloud though use of Extended Community attributes • Impose little requirements or no restrictions on customer networks • CE and C routers are NOT required to run newer code • (CE/C upgrades recommended for full SoO functionality) • Customer sites may be same or different Autonomous Systems • Customer sites may consist of several connections to the MPLS VPN backbone • Customer sites may consist of one or more connections not part of the MPLS VPN backbone (“backdoor” links) Note: Backdoor links—EIGRP Site of Origin is not supported in the initial release; this support was added in 12.3(8)T and 12.0.27S
Summary (Cont.) • EIGRP Route Type and Metric Preservation • The MPLS VPN backbone is running BGP; Normal redistribution of EIGRP into BGP and vice versa on the PE’s results in intersite EIGRP routes appearing as external routes resulting in all routes traversing the MPLS VPN backbone becoming less preferable than the routes that do not traverse the MPLS VPN backbone • To solve this; • If the sites are non-EIGRP: PE’s originate External EIGRP routes using the configured default metric; if no default metric is configured, the routes will not be redistributed into EIGRP • If the sites are in different EIGRP Autonomous System: PE’s originate External EIGRP routes using the configured default metric; if no default metric is configured, the routes will not be redistributed into EIGRP • if the sites are in the same EIGRP Autonomous System: PE’s originate EIGRP routes using the originating EIGRP metrics and route types from the originating EIGRP AS
Agenda • Introduction and Technology Overview • FUNCTIONALITY DESCRIPTION • EIGRP Route Propagation Behaviour • EIGRP Changes • Operation • Scenarios • Configuration and Troubleshooting Presentation_ID 21 21 21 © 2004 Cisco Systems, Inc. All rights reserved.
EIGRP Route Propagation Behavior MPLS VPN Backbone AS-1 AS-1 10.1.x.x 10.3.x.x AS-2 10.2.x.x
EIGRP Route Propagation Behavior MPLS VPN Backbone EIGRP Internal EIGRP Internal AS-1 EIGRP Routes Are Advertised into BGP Backbone Preserving the EIGRP Route Type and Metric Information in the BGP Extended Community Attribute AS-1 10.1.x.x EIGRP Internal 10.3.x.x AS-2 10.2.x.x
EIGRP Route Propagation Behavior EIGRP AS1: Internal EIGRP AS2: External EIGRP AS1: Internal EIGRP AS2: External MPLS VPN Backbone AS-1 AS-1 10.1.x.x 10.3.x.x EIGRP AS1: External AS-2 10.2.x.x BGP Redistributes Routes into EIGRP Using Route Type and Metric Information Extracted from BGP Extended Community Information
VPN-IPv4 Update RD:Net-1, Next-hop=PE-1RT=xxx:xxx EIGRP-Route-Type= internalEIGRP-VecMetric=B,L,D,R.M,H PE-3 EIGRP redistributes into BGP: EIGRP-Route-Type= internalEIGRP-VecMetric=B,L,D,R.M,H EIGRP originates as Internal Route with initial BW, Load, Delay, Reliability, MTU, Hop Route Redistribution and Avoiding Routing Loop MPLS-VPN Backbone PE-1 PE-2 CE-1 CE-2 EIGRP AS-1 EIGRP AS-1
BGP redistributes into EIGRP : EIGRP-Route-Type= internalEIGRP-VecMetric=B,L,D,R.M,H PE-3 PE-1 PE-2 Route Redistribution and Avoiding Routing Loop MPLS-VPN Backbone CE-1 CE-2 EIGRP AS-1 EIGRP AS-1
EIGRP computes new VecMetric: EIGRP-Route-Type= internalEIGRP-VecMetric=B,L,D,R.M,H PE-3 PE-1 PE-2 EIGRP installs Route as: Internal, BW, Load, Delay, Reliability, MTU, Hop Route Redistribution and Avoiding Routing Loop MPLS-VPN Backbone CE-1 CE-2 EIGRP AS-1 EIGRP AS-1
CE-2 uses split horizon to prevent route reflection to PE-3 PE-3 PE-1 PE-2 PE-2 sees higher cost from CE-2 than PE-1 so will not redistribute route back into BGP Route Redistribution and Avoiding Routing Loop MPLS-VPN Backbone CE-1 CE-2 EIGRP AS-1 EIGRP AS-1
Operation: General • CE runs EIGRP as before • PE runs an EIGRP-VRF process per vrf/AS • EIGRP routes are distributed to sites customer via MP-iBGP on the MPLS-VPN backbone • Each EIGRP-VRF process needs to be redistributed into MP-iBGP and vice-versa • MP-iBGP will carry extended community information across the MPLS-VPN backbone to other customer sites • BGP Basic Configuration • Address-family vpnv4 • neighbor x.x.x.x activate • neighbor x.x.x.x send-community extended • Address-family ipv4 vrf <vrf-name> • redistribute EIGRP <AS> • no auto-summary • no synchronization • exit-address-family
New Extended Communities • MPLS/VPN backbone is MP-BGP • There are no EIGRP adjacencies or EIGRP updates in MPLS/VPN backbone • EIGRP information is carried across MPLS/VPN backbone by MP-BGP in new extended communities (set and used by PE’s)
New Extended Communities: EIGRP Information • Type 0x8800 • Usage: EIGRP Route Metric information Appended • Values: Flags + TAG
New Extended Communities: EIGRP Metric Information • Type 0x8801 • Usage: EIGRP Route Metric information Appended • Values: AS + Delay • Type 0x8802 • Usage: EIGRP Route Metric Information • Values: Reliability + Hop + BW • Type 0x8803 • Usage: EIGRP Route Metric Information • Values: Reserve +Load + MTU
New Extended Communities: EIGRP External Information • Type 0x8804 • Usage: EIGRP Ext Route Information • Values: Remote AS + Remote ID • Type 0x8805 • Usage: EIGRP Ext Route Information • Values: Remote Protocol + Remote Metric
New Extended Communities:EIGRP External Protocol • External Protocol—Defines the external protocol that this route was learned by; the following values are assigned: • IGRP-1 OSPF-6 • EGRP-2 IS-IS-7 • Static-3 EGP-8 • RIP-4 BGP-9 • HELLO-5 IDRP-10
Operation: PE—Metric Preservation • EIGRP metric can be set on the PE by the command: • redistribute BGP <as> metric B D R L M • Used to set the metric for BGP routes redistributed into EIGRP • EIGRP will look for BGP extended community information, and if found, use BGP extended community information to recreate the original EIGRP route; if the extended community information is missing, the metric values provided will be used for the external route created • default-metric B D R L M • Used to set the metric for any non-eigrp route being redistributed into EIGRP • If the Route is BGP, EIGRP will look for BGP extended community information, and if found, use BGP extended community information to recreate the original EIGRP route; if the extended community information is missing, the metric values provided will be used for the external route created • B=Bandwidth D=Delay R=Reliability L=Load M=MTU
Operation: PE—Non-EIGRP Routes • If a route is received via BGP, and the route has no extended community information for EIGRP: • The route will be advertised to the CE as an external EIGRP route using the metric supplied on the redistribution or default-metric statement; if no metric is configured, the route will not be advertised to the CE
Operation: PE—Same AS • If a route is received via BGP with extended community information for EIGRP and the AS number matches: • The route is advertised to the CE as the same type of route (Int/Ext) as it was in the originating site • The Extended Community information will be used to set the metric with the VPN itself appearing as a zero-cost link • Recreated External routes will also contain all of the external data associated with the route in the originating site (originating router, originating protocol, etc.)
Operation: PE—Different AS • If a route is received via BGP with extended community information for EIGRP and the AS number doesn’t match: • The route is advertised to the CE as an external EIGRP route; the route will *NOT* use the Extended Community information as it did not originate from the same AS
Agenda • Introduction and Technology Overview • Functionality Description • EIGRP Route Propagation Behaviour • EIGRP Changes • Operation • SCENARIOS • Configuration and Troubleshooting Presentation_ID 39 39 39 © 2004 Cisco Systems, Inc. All rights reserved.
Scenarios • Customer sites all belong to the same EIGRP autonomous system • Customer sites have “BACKDOOR” links • Customer sites belong to different EIGRP autonomous systems • Customer sites contain one or more non-EIGRP site
Operation: Single AS Scenario • Routes are redistributed from EIGRP into MP-BGP on the sending PE, with the route information encoded in the Extended Community attributes • Routes are recreated by receiving PE and sent to the CE as an EIGRP route; the same route type and metric as the original route will be used to recreate the EIGRP route • The recreated route will be sent to the CE from the receiving PE with the same metric it contained on the sending PE • Note: the MPLS/VPN link looks like it has Zero metric
VPNv4 Route Internal or External Internal or External Operation: Single AS Scenario MPLS VPN Super Backbone Original Route recreated PE PE Network X VPN Red VPN Red AS-1 AS-1
Operation: Single AS with “Backdoor” Link Scenario • Routes are redistributed from EIGRP into MP-BGP on the sending PE, with the route information encoded in the Extended Community attributes • Routes are recreated by receiving PE and sent to the CE as an EIGRP route; the same route type and metric as the original route will be used to recreate the EIGRP route • The recreated route will be sent to the CE from the receiving PE with the same metric it contained on the sending PE • Note: the MPLS/VPN link looks like it has Zero metric • The path each site will use to reach prefixes belonging to the other site will be based on metric • The backdoor link can be only as a failover by increasing its metric
VPNv4 Route Internal or External Internal or External Internal or External Internal or External Internal or External Operation: Single AS with “Backdoor” Link Scenario MPLS VPN Super Backbone PE Original Route recreated PE Network X VPN Red VPN Red AS-1 AS-1 Backdoor Link
Operation: Multiple AS Scenario • Routes are redistributed from EIGRP into MP-BGP on the sending PE, with the route information encoded in the Extended Community attributes • On PEs running the same EIGRP AS, the routes are recreated and sent to the CE as an EIGRP route • The same route type and metric as the original route will be used to recreate the EIGRP route • The recreated route will be sent to the CE from the receiving PE with the same metric it contained on the sending PE • On PEs running a different EIGRP AS, the routes are redistributed into EIGRP as External routes (originating protocol = BGP) • The redistribution metric will be used for these routes
VPNv4 Route Internal External Internal Operation: Multiple AS Scenario MPLS VPN Super Backbone PE PE PE PE Network X VPN Red VPN Red VPN Red AS-1 AS-1 Route Created as External using configured default metric AS-2 Route Recreated As Internal
Operation: Non-EIGRP Scenario • Routes are redistributed from some other protocol into MP-BGP on the sending PE, without the Extended Community attributes • Since there are no Extended Community attributes, the routes are redistributed into EIGRP on the receiving PE as External routes, with the originating protocol appearing as BGP • The redistribution metric defined on the “redistribute bgp” or “default-metric” statement will be used to determine the metric on the redistributed External routes
External VPNv4 Route Redistributed into BGP Operation: Non-EIGRP Scenario MPLS VPN Super Backbone PE PE Route Created as External using configured default metric Network X VPN Red VPN Red OSPF EIGRP AS1
Agenda • Introduction and Technology Overview • Functionality Description • EIGRP route propagation behavior • EIGRP changes • Operation • Scenarios • CONFIGURATION AND TROUBLESHOOTING Presentation_ID 49 49 49 © 2004 Cisco Systems, Inc. All rights reserved.
Configuration • New config commands: • Support for address-family syntax added • One EIGRP Router process can support multiple EIGRP-VRF processes • The number of EIGRP-VRF processes is limited to the available system resources and the number of supported VRFs on a given platform • For example: • router EIGRP 1 • address-family ipv4 vrf vrf-red • autonomous-system 69 • There is always an EIGRP-VRF process created for the default routing table EIGRP Router Process EIGRP-VRF Process