1 © 2004 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID EIGRP FOR MANAGED SERVICES FUNCTIONALITY PRESENTATION DONNIE SAVAGE CHETAN.

1© 2004 Cisco Systems, Inc. All rights reserved.

Session NumberPresentation_ID

EIGRP FOR MANAGED SERVICESFUNCTIONALITY PRESENTATIONDONNIE SAVAGECHETAN KHETANISANGITA PANDYA

INTERNET TECHNOLOGIES DIVISION

DECEMBER 2004

222© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID

Agenda

• INTRODUCTION AND TECHNOLOGY OVERVIEW

• Functionality Description

EIGRP Route Propagation Behaviour

EIGRP Changes

Operation

• Scenarios

• Configuration and Troubleshooting



Service Provider Converged Network

VPN for Many Managed Services

MANAGED IPT

MANAGED IPT

MANAGED Routing

MANAGED Extranet

MANAGED Internet Gateway

MANAGED SecurityMANAGED Security

MANAGED CPE

MANAGED CPE

V i r t u a l P r i v a t e N e t w o r k

CustomerBranch

CustomerBranch

VMVM

VPN B

VMVM

Customer HQCustomer HQ

Service Level Agreement for

MANAGED Services


Managed Routing Revenue Opportunity

Over 50% of Cisco Enterprise Customers Deploy IP Routing with EIGRP

IP/MPLS VPN Backbone

EIGRP AS-1

PE-1PE-1

CE-1CE-1

EIGRP AS-1

PE-2PE-2

PE-3PE-3


CE-2CE-2


Robust EIGRP Support

BENEFITS:Service Provider: Simplest point of entry into enterprise’s existing architectureEnterprise: Least disruption to current network design

Cisco Exclusive

VPN A/Site 1

VPN C/Site 2

VPN A/Site 2

VPN B/Site 2

VPN C/Site 1

CEA1

CEB3

CEA3

CEA2

CE1B1

PE1

PE2

PE3

P1

P2

P3

16.1/16

12.1/1612.1/16

16.2/16

16.2/16RIPv2

Static

OSPF

RIPv2

BGP

OSPF

RIPv2

BGP

12.2/1612.2/16

CEB2

Cisco IOS Supports the Industry’s Most Comprehensive and Robust Routing Protocol Support: RIP, OSPF, BGP, ISIS,

Including EIGRP



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)


Technology Overview: MPLS VPN Network

P P

PP

PE

PE

CE

CE

CE

PE

PECE

CE

CE

VPN_AVPN_A

VPN_AVPN_A

VPN_BVPN_B10.3.0.010.3.0.0

10.1.0.0

11.5.0.0

VPN_AVPN_A

VPN_BVPN_B

VPN_BVPN_B

10.1.0.010.1.0.0

10.2.0.010.2.0.0

11.6.0.0

VPN_AVPN_A10.2.0.0

Provider EdgeCustomer Edge Provider Router

VRF Interface

MP-BGP Sessions

LDP

PE-CE Routing ProtocolEIGRP, Static,RIPv2,EBGP,OSPF

CE

MPLS Core


Technology Overview: EIGRP for MPLS VPN PE-CE

VPN A/Site 1

VPN C/Site 2

VPN A/Site 2

VPN B/Site 2

VPN B/Site 1

VPN C/Site 1

CEA1

CEB3

CEA3

CEA2

CE1B1

CE2B1

PE1

PE2

PE3

P1

P2

P3

16.1/16

12.1/1612.1/16

16.2/16

16.1/16 16.2/16

EIGRP

EIGRP

EIGRP

EIGRP

EIGRPBGP

12.2/1612.2/16

CEB2

EIGRP

EIGRP


VPN A/Site 1

VPN C/Site 2

VPN A/Site 2

VPN B/Site 2

VPN B/Site 1

VPN C/Site 1

CEA1

CEB3

CEA3

CEA2

CE1B1

CE2B1

PE1

PE2

PE3

P1

P2

P3

16.1/16

12.1/1612.1/16

16.2/16

16.1/16 16.2/16EIGRP

EIGRPEIGRP

EIGRP

EIGRP

EIGRP

BGP

12.2/1612.2/16

CEB2

Technology Overview: MPLS VPN Routes Distribution

Step 2Step 2Step 4Step 4Step 1Step 1 Step 3Step 3

Step 5Step 5

EIGRP


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)


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

SERVICE PROVIDER

SITE 1

SITE 2

A

B

C

D

VPN

EXTERNAL



• 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

SERVICE PROVIDER

SITE 1

SITE 2

A

B

C

D

VPN

INTERNAL


SERVICE PROVIDER

SITE 1

SITE 2

A

B

C

D

VPN

INTERNAL


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

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


SERVICE PROVIDER

SITE 1

SITE 2

A

B

C

D

VPN

NO BACKDOOR LINK


• 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

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080154db3.html





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

SITE 1

SITE 2

A

B

C

D

VPN


SERVICE PROVIDER

SITE 1

SITE 2

A

B

C

D

VPN

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

....


Technology Overview: EIGRP MIB Support

• EIGRP Traffic StatisticsAS Number

Hellos Sent/Received

Updates Sent/Received

Queries Sent/Received

Replies Sent/Received

• EIGRP Topology DataDestination Net/Mask

Active State

Feasible Successors

Origin Type

Distance

Reported Distance

• EIGRP Interface DataPeer Count

Reliable/Unreliable Queues

Pacing

Pending Routes

Hello Interval

• EIGRP Neighbor DataPeer Address

Peer Interface

Hold Time

Up Time

SRTT/RTO

Version

AND MANY MORE…


BGP/MPLS VPNWith EIGRP between PE-CE

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

• 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]]

CECE

CECE

CE

CE

CE

CE

CE CECE

CE

CE

CE

CECE

PE1PE

PE PE

PEPE

VRF1

VRF2

VRFL

VRFL+1

…

VRF3


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 Changes

Operation

• Scenarios




EIGRP Route Propagation Behavior

MPLS VPN Backbone

AS-1

AS-2

AS-1

10.2.x.x

10.1.x.x10.3.x.x


MPLS VPN Backbone

AS-1

AS-2

AS-1

10.2.x.x

10.1.x.x10.3.x.x


EIGRP Routes Are Advertised into BGP Backbone Preserving the EIGRP Route Type and Metric Information in the BGPExtended Community Attribute

EIGRP Internal EIGRP

Internal

EIGRP Internal


MPLS VPN Backbone

AS-1

AS-2

AS-1

10.2.x.x

10.1.x.x10.3.x.x

BGP Redistributes Routes into EIGRP Using Route Type and Metric Information Extracted from BGP Extended Community Information


EIGRP AS1: Internal

EIGRP AS2: External

EIGRP AS1: External

EIGRP AS1: Internal

EIGRP AS2: External


MPLS-VPN Backbone

EIGRP AS-1

PE-1

CE-1

EIGRP AS-1

PE-2

CE-2

PE-3

Route Redistribution and Avoiding Routing Loop

VPN-IPv4 UpdateRD:Net-1, Next-hop=PE-1RT=xxx:xxxEIGRP-Route-Type= internalEIGRP-VecMetric=B,L,D,R.M,H

EIGRP redistributes into BGP:EIGRP-Route-Type= internalEIGRP-VecMetric=B,L,D,R.M,H

EIGRP originates as Internal Route with initialBW, Load, Delay, Reliability, MTU, Hop



MPLS-VPN Backbone

EIGRP AS-1

CE-1

EIGRP AS-1

CE-2

BGP redistributes into EIGRP :EIGRP-Route-Type= internalEIGRP-VecMetric=B,L,D,R.M,H

PE-2

PE-1PE-3


MPLS-VPN Backbone

EIGRP AS-1

CE-1

EIGRP AS-1

CE-2


PE-2

PE-1

EIGRP computes new VecMetric:EIGRP-Route-Type= internalEIGRP-VecMetric=B,L,D,R.M,H

EIGRP installs Route as:Internal, BW, Load, Delay, Reliability, MTU, Hop

PE-3


PE-3

MPLS-VPN Backbone

EIGRP AS-1

CE-1

EIGRP AS-1

CE-2

PE-2

PE-1


PE-2 sees higher cost from CE-2 than PE-1 so will not redistribute route back into BGP

CE-2 uses split horizon to prevent route reflection to PE-3


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 ConfigurationAddress-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




EIGRP Changes

Operation

• SCENARIOS




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


Operation: Single AS Scenario

MPLS VPN Super Backbone

AS-1 AS-1

VPN Red VPN Red

PEPE

Network X

Internal or External

VPNv4 RouteInternal or External

OriginalRouterecreated


Operation: Single AS with “Backdoor” Link Scenario


• 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


Operation: Single AS with “Backdoor” Link Scenario


AS-1 AS-1

VPN Red VPN Red

Backdoor Link

PEPE

Network X





OriginalRouterecreated


VPNv4 Route


Operation: Multiple AS Scenario


• 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


Operation: Multiple AS Scenario


AS-1AS-1 AS-2

VPN RedVPN Red VPN Red

Network X

PEInternal

VPNv4 Route

Route Created as External using configured default metric

PE

PE PE

Internal External

RouteRecreatedAs 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


Operation: Non-EIGRP Scenario


OSPF EIGRP AS1VPN Red VPN Red

PE PE

Network X

Redistributed into BGP

VPNv4 Route

ExternalRoute Created as External using configured default metric


Agenda



EIGRP route propagation behavior

EIGRP changes

Operation

• Scenarios

• CONFIGURATION AND TROUBLESHOOTING



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


Configuration

• The AS used by a given EIGRP-VRF process is bounded to the scope of the VRF it is configured for

• For example:

router EIGRP 42



address-family ipv4 vrf vrf-green


• All of the three EIGRP-VRF processes are unique and will NOT share neighbors, routing information, or topology information


Configuration Single Instance

router EIGRP 1

network 10.0.0.0


network 42.0.0.0


redistribute BGP 100 metric 10000 100 255 1 1500

exit-address-family


network 49.0.0.0

antonymous-system 99

redistribute BGP 101 metric metric 10000 100 255 1 1500

exit-address-family

no eigrp log-neighbor-changes

Commands for Default Routing Table

Commands for vrf-red

Commands for vrf-green



Configuration Multiple Instance

router EIGRP 1


network 42.0.0.0



exit-address-family


router EIGRP 2


network 49.0.0.0



exit-address-family



Commands for vrf-red

Commands for vrf-green




Troubleshooting

• Show commands

show ip EIGRP <VRF vrf-name> <AS> event

show ip EIGRP <VRF vrf-name> <AS> neighbor

show ip EIGRP <VRF vrf-name> <AS> interface

show ip EIGRP <VRF vrf-name> <AS> topology

show ip protocol <VRF vrf-name>

• Note:

use “ * ” as the vrf-name to specify all vrfs


Troubleshooting

• Clear commands

clear ip EIGRP <VRF vrf-name> <AS> event

clear ip EIGRP <VRF vrf-name> <AS> neighbor

*clear ip EIGRP <VRF vrf-name> <AS> topology

• Note:

Hidden command

use “ * ” as the vrf-name to specify all vrfs


Troubleshooting

• Debug commands

debug ip EIGRP <VRF vrf-name> <AS>

debug ip EIGRP <VRF vrf-name> <AS> neighbor

debug ip EIGRP <VRF vrf-name> <AS> notifications

debug ip EIGRP <VRF vrf-name> <AS> summary

• Note:

use “ * ” as the vrf-name to specify all vrfs use


1 © 2004 Cisco Systems, Inc. All rights reserved. Session Number Presentation_ID EIGRP FOR MANAGED SERVICES FUNCTIONALITY PRESENTATION DONNIE SAVAGE CHETAN.

Documents

mpls vpn pece vpn asite

vpn csite

vpn bsite

id vpn asite

cisco systems

ce a1 ce b3 ce a3 ce

id eigrp

ce b2 eigrp slide