EIGRP Deployment in Modern Networks

EIGRP Deployment in Modern Networks BRKRST-2336

Donnie Savage

Don Slice

© 2013 Cisco and/or its affiliates. All rights reserved. BRKRST-2336 Cisco Public

Why EIGRP?

EIGRP is easy to design and support – Faster system design & deployment time

– Easier learning curve for support personnel

– Lower Operational Costs (OpEx)

Optimized for Enterprise and Commercial Networks – Flexible design options

– Sub-second convergence since inception

– Simple for small networks, yet scalable for very large networks

Excellent Campus and Hub-n-Spoke WAN protocol

Excellent Scalability in DMVPN deployments

Proven Deployment – The most widely deployed enterprise routing protocol

– Widely available across Cisco platforms suitable for Enterprise & Commercial

3


EIGRP Moving into the Future

EIGRP Information Draft published to IETF

Announced at Cisco Live London

Competitive Landscape;

– Currently there are at least 4 known companies shipping BEIGRP in Asia and Europe today.

– Current talks with major US based vendors

IPv6 is offering a green-field deployment to customers, and customers are looking at "standards based” solutions.

– Pressure from public/government sectors who have mandates to use Open solutions when available

– Removes the "standards" argument now allows customers to use the technology that best fits their needs.

Development of new features and better scaling are in progress

Cisco is committed to continue offering “best of breed”

2013

Open-EIGRP: draft-savage-eigrp-00

4


Feature Overview

IOS-Classic / IOS-XE IOS-XR NX-OS

BFD Yes Roadmap Yes

IP Fast Reroute 3.7 Roadmap Roadmap

Non-Stop Routing 3.9/3.10 Roadmap Roadmap

UCMP Yes Yes No

EIGRP add-path 3.8 Roadmap Roadmap

VRF-Aware EIGRP Yes Yes Yes

EIGRP PE/CE/Extended Community Yes Yes Yes

EIGRP 6PE/6VPE 3.9 Roadmap Roadmap

EIGRP IPv4/IPv6 MIB Yes/3.7 No/No Yes/No

Route Tag Enhancement Yes No Yes

EIGRP Multi-Instance Yes No Yes

EIGRP Prefix Limit Yes Yes Yes

EIGRP Route Authentication Yes Yes Yes

EIGRP HMAC-SHA-256 Authentication Yes No No

EIGRP Wide Metrics Yes Yes Yes

5


EIGRP Deployment in Modern Networks

Typical enterprise network is built upon multiple levels of switches deployed in three general layers: access (to include WAN Aggregation), distribution and core

Core: – Provides high speed connectivity between aggregation layers - gets traffic from one area of the

network to another.

Distribution: – Provides aggregation of traffic flows from multiple Access layers to the Core. Traffic filtering and

packet policies are typically implemented here. The distribution layer should be the blocking point for Queries (more about this later)

Access: – Provide connectivity to user attachment points for servers, end stations, storage devices, and other

IP devices. Consider use of EIGRP STUBS (more about this later)

WAN Aggregation: – Provides connectivity to the internet and/or remote sites/offices.

6


EIGRP Deployment in Modern Networks

Building 1

Distribution

Access

WAN Aggregation

Application Acceleration

VPN

Building 3

Core

Firewall

Internet Servers

Mail Servers

Core

Building 4 Building 2

Data Center

WAN

Internet

Mobile Worker

Remote Office

Branch Router

Regional Office

Regional Router


7


Address-Family Support

EIGRP Address Family Support for IPv4/IPv6

With the introduction of EIGRP support for Address Families (AFs), EIGRP supports IPv4 and IPv6 under a single router instance

Reduced complexity

– Helps enable IPv4 and IPv6 address families to be supported on a single network infrastructure.

– Can be phased in, or applied in green fields

EIGRP IPv4 and IPv6 can be run concurrently

– Each address family has a separate topology tables

– No Fate Sharing

Design deployment techniques are the same for IPv4 and IPv6

– Minimal differences mean no lengthy training required

– Configuration and Troubleshooting similar

– Same Route Types (Internal, External, Summary)

router eigrp ROCKS

address-family ipv4 autonomous-system 1

network 10.0.0.0 255.0.0.0

!

address-family ipv4 vrf cisco autonomous 4453

network 192.168.0.0

!


af-interface Ethernet0/0

shutdown

exit-af-interface

!

address-family ipv6 vrf cisco autonomous 6473

af-interface default

no shutdown

exit-af-interface

8



Named Mode(multi-address family)

– Can be phased in, or applied in green fields

– Reduced complexity

EIGRP support for IPv6

– Link local routing brings a concept of scalable routing

– Uses IPv6 transport and uses link-local addresses as source address.

EIGRP IPv4 and IPv6 can be run concurrently

– Cisco supports both

– Each address family has a separate topology tables

– No Fate Sharing

Design deployment techniques are the same for IPv4 and IPv6

– Minimal differences mean no lengthy training required

– Configuration and Troubleshooting similar

– Same Route Types (Internal, External, Summary)

IPv4 IPv6

IPv6 IPv4

IPv4 IPv6 IPv4/IPv6

9



Behavior of autonomous-system command under VRFs has changed to address common configurations errors.

router eigrp 1

address-family ipv4 vrf RED

autonomous-system 99

network 10.0.0.0

!

router eigrp 1

address-family ipv4 vrf RED autonomous-system 99

network 10.0.0.0

!

router eigrp 1


autonomous-system 99

network 10.0.0.0

!

router eigrp cl013


network 10.0.0.0

1 The AS must be defined for the address-

family to "start" processing

2 The AS Can be entered on the address-

family or standalone or both

3 The AS will nvgen wherever it is entered,

if configured both ways it nvgens both

ways

4 The standalone keyword can be removed

if the AS is defined on the address-family

command

5 Once configured on address-family the AS

can only be removed by removing the

address-family

10


Address-Family Support — Router Support

Classic mode: Configuring “router eigrp” command with a number.

Named mode: Configuring “router eigrp” command with the virtual-instance-name

Named mode supports both IPv4 and IPv6, and VRF (virtual routing and forwarding) instances

Named mode allows you to create a single Instance of EIGRP which can be used for all family types

Named mode supports multiple VRFs limited only by available system resources

Named mode does not enable EIGRP for IPV4 routing unless configured

router eigrp [virtual-instance-name | asystem]

[no] shutdown

.

.

.

11


Address-Family Support — Family Support

Single place for all commands needed to completely define an instance.

– “show run | section router eigrp”

Defines what you’re routing/distributing “common look and feel”

Provide support for both routing (address-family) and services (service-family)

Can be configured for VRFs

Assure subcommands are clear as to their scope Static neighbors, peer-groups, stub, etc, ..

neighbor, neighbor remote, etc.

router eigrp [virtual-instance-name]

address-family <protocol> [vrf <name>] autonomous-system <#>

…

exit-address-family

service-family <protocol> [vrf <name>] autonomous-system <#>

…

exit-service-family

12


Address-Family Support — Interface Support

EIGRP specific interface properties are configuration in the af-interface mode. for example; authentication, timers, and bandwidth control

“af-interface default” applies to ALL interfaces

– Not all commands are supported

“af-interface <interface>” applies to ONLY one interface

– Only “eigrp” specific commands are available

– Properties which are Interface specific, such as delay and bandwidth, are still configured under the interface


address-family <protocol> autonomous-system <#>


…

exit-af-interface

af-interface <interface>

…

exit-af-interface

exit-address-family

13


Address-Family Support — Topology Support

Topology specific configuration such as; default-metric

event-log-size

external-client

metric config

timers config

redistribution

Applies to global, or default, routing table


address-family <protocol> autonomous-system <#>

topology base

…

exit-topology

exit-address-family

14


Address-Family Support – IOS Changes

The auto-summary command is a relic from the days of classful routing. It was enabled by default in pre-release 5 images.

The auto-summarization feature is no longer widely used and 'no auto-summary' has since become the prevailing configuration.

CSCso20666 changed auto-summary behavior to disabled by default.

Because 'no auto-summary' is the factory default setting it will not nvgen -- auto-summary will now only nvgen if it is explicitly enabled.

default nvgen behavior IOS Version (eigrp version)

auto-summary 'auto-summary' : does not nvgen

'no auto-summary' : nvgens

12.2SR(rel2), 12.2SX(rel3), 12.2SG(rel4)

auto-summary 'auto-summary' : nvgens

'no auto-summary' : nvgens

12.2S(rel1), 12.4T(rel1), 12.2SB(rel1)

no auto-summary 'auto-summary' : nvgens

'no auto-summary' : does not nvgen

15.0(rel5), 15.0T(rel5), 12SRE(rel5),

122XNE(rel5) 122XNF(rel5_1),

122(55)SG(rel5_2)

15


Address-Family Support – IPv6 Support

Internet Protocol Version 6 (IPv6)

EIGRP supports Internet Protocol Version 6 (IPv6)

Same EIGRP protocol, just IPv6 enabled

A familiar Look and Feel means incumbent EIGRP Operational expertise can be leveraged

DUAL performs route computations for IPv6 without modifications

Provides feature parity with most IPv4 Features

EIGRP IPv6 MIBS

EIGRP IPv6 NSF/SSO

EIGRP IPv6 VRF-aware

EIGRP IPv6 BFD support

Etc.

ipv6 unicast-routing ! interface TenGig0/0/0/1 ip address 192.168.1.1 255.255.255.0 ipv6 enable ! router eigrp ROCKS !

address-family ipv6 autonomous-system 1 af-interface Ethernet0/0 no shutdown exit-af-interface

! address-family ipv6 vrf cisco autonomous 6473 af-interface default no shutdown exit-af-interface

16


ipv6 unicast-routing ! interface Ethernet0/0 ipv6 address 2001:DB8::1/64 ipv6 enable ipv6 eigrp 6473

! interface Ethernet0/1 ipv6 enable ipv6 eigrp 6473

!

ipv6 router eigrp 6473 router-id 10.10.10.1 no shutdown

classic router configuration

Router-ID is require and selected

① from highest loopback IPv4 address

② from first IPv4 address found on any physical interface.

If no IPv4 address is available, a 32-bit router-id can be configured manually using the router-id command

eigrp named mode configuration

ipv6 unicast-routing ! interface Ethernet0/0 ipv6 address 2001:DB8::1/64 ipv6 enable

! interface Ethernet0/1 ipv6 enable

! router eigrp CSCO address-family ipv6 autonomous-system 6473 router-id 10.10.10.1 af-interface default no shutdown topology base

IPv6 Configuration Primer

17


IPv6 — Primer

An IPv6 address is an extended 128-bit / 16 bytes address that gives

– 2128 possible addresses (3.4 x 1038)

IPv6 addresses

– 64 bits for the subnet ID, 64 bits for the interface ID

– Separated into 8 * 16-bit Hexadecimal numbers

– Each block is separated by a colon :

– :: can replaced leading, trailing or consecutive zeros

– :: can only appear once

EIGRP IPv6 Multicast transport

– FF02:0:0:0:0:0:0:A or abbreviated to FF02::A

Examples:

2003:0000:130F:0000:0000:087C:876B:140B

2003:0:130F::87C:876B:140B

18


A IPv6 Link-local address is used by EIGRP to source Hello packets and establish an adjacency

IPv6 Link-local address is never routed

IPv6 packet forwarding and must be configured first under global configuration

They are auto assigned when you enable the interface

You can configure this manually on an interface

An IPv6 link-local is prefixed by fe80 and has a prefix length of /10

ipv6 address ?

X:X:X:X::X IPv6 link-local address

X:X:X:X::X/<0-128> IPv6 prefix

……

ipv6 unicast

interface Ethernet1/0

ipv6 enable

IPv6 Link-Local Address

19


show eigrp address-family ipv6 topology

EIGRP-IPv6 VR(cl013) Topology Table for AS(6473)/ID(1.1.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status

P 2040:3333::31:113:0/112 , 1 successors, FD is 281600

via FE80::A8BB:CCFF:FE00:200 (281600/256), Ethernet0/0

P 2040:3333::31:114:0/112, 1 successors, FD is 281600

via FE80::A8BB:CCFF:FE00:200 (281600/256), Ethernet0/0

The Topology show commands are congruent with IPv4

The next-hop is the Neighbor’s link-local address

EIGRP IPv6 Topology Table

20


The information source and next-hop 128-bit address

show eigrp address-family ipv6 topology 2040:3333::31:113:0/112

EIGRP-IPv6 VR(cl013) Topology entry for AS(6473)/ID(1.1.1.1) for 2040:3333::31:113:0/112

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281600

Routing Descriptor Blocks:

FE80::A8BB:CCFF:FE00:200 (Ethernet0/0), from FE80::A8BB:CCFF:FE00:200, Send flag is 0x0

Composite metric is (281600/256), Route is External

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 1000 microseconds

Reliability is 0/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

External data:

Originating router is 2.2.2.2

AS number of route is 0

External protocol is Static, external metric is 0

Administrator tag is 0 (0x00000000)

EIGRP IPv6 Topology Table

21


interface Ethernet0/0 ipv6 summary-address eigrp 6473 ?


router eigrp cl013-ipv6

address-family ipv6 auto 6473 af-interface Ethernet0/0 summary-address ?


IPv6 Route Summarization

EIGRP supports summarization of IPv6 Routes

No “auto-summary” configuration available in IPv6; IPv6 is essentially classless

Manual summarization is supported, as it is with EIGRP IPv4

Summaries can be configured at any point in the network

classic router configuration eigrp named configuration

IPv6 Route Summarization

22


debug eigrp ?

fsm EIGRP Dual Finite State Machine events/actions

neighbors EIGRP neighbors

nsf EIGRP Non-Stop Forwarding events/actions

packets EIGRP packets

transmit EIGRP transmission events

debug eigrp packets

EIGRP Packets debugging is on

(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

00:52:47: EIGRP: Received HELLO on Ethernet1/0 nbr FE80::A8BB:CCFF:FE00:401

00:52:47: AS 6473, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

EIGRP IPv6 information in existing debugs

IPv6 Event logs and Debugs Supported

23


EIGRP IPv6 Event Log

EIGRP IPv6 Specific Debugging

show eigrp address-family ipv6 event

1 06:27:52.115 Change queue emptied, entries: 1

2 06:27:52.115 Metric set: 2040:3333::31:113:0/112 281600

3 06:27:52.115 Update reason, delay: new if 4294967295

4 06:27:52.115 Update sent, RD: 2040:3333::31:113:0/112 4294967295

5 06:27:52.115 Update reason, delay: metric chg 4294967295

6 06:27:52.115 Update sent, RD: 2040:3333::31:113:0/112 4294967295

debug eigrp address-family ipv6 ?

<1-65536> Autonomous System

neighbor EIGRP neighbor debugging

notifications EIGRP event notifications

summary EIGRP summary route processing

<cr>

IPv6 Event logs and Debugs Supported

24


EIGRP IPv6 vs. IPv4

• Provides feature parity with IPv4 Features (stubs, scaling, summarization, etc.)

• Uses the same Reliable Multicast Transport protocol used by IPv4

• 2 new TLVs used for both IPv4 and IPv6;

INTERNAL_TYPE (0X0602), EXTERNAL_TYPE (0X0603)

• Same Metrics used by IPv6 and IPv4

Similar Concepts

• IPv6 Link-local address are used to establish an adjacency (FF02::A (all EIGRP routers); neighbors do not have to share the same global prefix (with exception of static neighbors where traffic is unicasted)

• Does not support the “default-information” command as there is no support in IPv6 for the configuration of default networks other than ::/0

• Does not support the “auto-summary” command

• No split-horizon in the default for IPv6 (as IPv6 supports multiple prefixes per interface)

• RouterID which must be explicitly configured if no IPv4 address

Differences

25


Address-Family Support – Security

Hash-based Message Authentication Code (HMAC)

EIGRP offers Secure Hash Algorithms SHA2-256 bit Algorithms

The addition of SHA2-256 HMAC authentication to EIGRP packets ensures that your routers only accept routing updates from other routers that know the same pre-shared key.

This prevents someone from purposely or accidentally adding another router to the network and causing a problem.

The SHA2 key is a concatenation of the user-configured shared secret key along with the IPv4/IPv6 address from which this particular packet is sent. This prevents Hello Packet DOS replay attacks with a spoofed source address.

Simpler configuration mode using a common ‘password’

Keychain support when additional security is needed

A

B C

26



HMAC SHA2 256bit Authentication

MD5 has been has been cracked and a number of tools exist on various sites to crack MD5 hash

With new peering options in development will allow for multi-hop remote peers, a new method is needed

SHA1 was considered, but SHA-1 is not collision free and can be broken in 2^69 attempts instead of 2^80. While this It was still a nontrivial problem, it could be done so we wanted to consider ‘better’ options.

SHA2 seems to be the best available and has been shown to be very secure. Block sizes of 512 vs. 256 did not show much difference in security for the additional processing requirements

27


• Simple configuration using only one password

• Additional security can be added with key-chains

router eigrp DC012-md5

address-family ipv4 auto 4453


authentication key-chain DC012-CHAIN

exit-af-interface

af-interface Ethernet0

authentication mode hmac-sha-256 ADMIN

exit-af-interface


authentication mode hmac-sha-256 CAMPAS

exit-af-interface


authentication mode hmac-sha-256 LAB

authentication key-chain DC012-LAB

exit-af-interface

router eigrp ROCKS



authentication mode hmac-sha-256 my-password

exit-af-interface

key chain DC012-CHAIN

key 1

key-string securetraffic

!

router eigrp ROCKS



authentication mode hmac-sha-256 my-password

authentication key-chain DC012-CHAIN

exit-af-interface

• Interface inheritance can simplify configuration


28


IOS-Classic / IOS-XE IOS-XR NX-OS

EIGRP IPv6 MIB 3.7 No No

Route Tag Enhancement Yes No Yes

EIGRP Multi-Instance Yes No Yes

EIGRP HMAC-SHA-256 Authentication Yes No No

EIGRP Wide Metrics Yes Yes Yes

Stubs/Stub Leaking Yes/Yes No/No Yes/No

Summary/Summary Leaking Yes/Yes Yes/No Yes/No

VRF-Lite Yes Yes Yes

PE/CE Support/Extended Community SoO 3.9/Yes No/No No/No

EIGRP Prefix Limit Yes No No

BFD Yes Planned Roadmap

Performance Routing(PfR) No No No

3rd Party Next Hop/AddPATH Yes No No

Non-Stop Routing(NSR) Yes No No

IPv6 Feature Overview

29


Routing Basics

EIGRP only knows prefix and next-hop information

Topology information beyond the next hop is naturally hidden in distance vector protocols

B and C only advertise that they can reach 10.1.1.0/24, not that they are connected to D, which is then connected to 10.1.1.0/24

B

10.1.1.0/24

D I can reach

10.1.1.0/24 I can reach

10.1.1.0/24

I can reach

10.1.1.0/24

I can reach

10.1.1.0/24

A

C

30


10.1.3.0/24

10.1.1.0/24

10.1.2.0/24

Routing Basics

Hiding topology information hides information about changes in the topology

C advertises reachability to 10.1.1.0/24

– If the F to G link fails, C can still reach 10.1.1.0/24 (although the metric might change)

– If B can still use C to reach 10.1.1.0/24, does B need to know about the F to G link failure?

– No!

What's the issue if C advertises reachability to 10.1.1.0/24?

– When the F to G link fails, C will send an update to B

– B may then go active and potentially query its peers

– This increases CPU, memory, and convergence time for a path B can not reach

G

D

E F

C can reach

10.1.1.0/24

Hide

topology

here

C

A B

31

2

2

1

1


Routing Basics

When EIGRP goes active, it sends a Query to its peers looking for the lost route.

The Query is bounded by:

Local knowledge of an alternate loop-free path not learned through the peer the query was received from

No local knowledge of the route because of filtering

No local knowledge of the route because of summarization

No peers to query

10.1.1.0/24

Local Knowledge of

an alternate path, So

Reply

Fil

ter

No Knowledge of

Route, So Reply

Su

mm

ary

No Knowledge of

Route, So Reply

No peers,

So Reply

C

D

A

E

F

G

B

32


Routing Enhancements—SNMP

Simple Network Management Protocol (SNMP)

EIGRP supports 68 MIB objects in 4 major tables

eigrpRouteSIA and eigrpAuthFailure can trigger SNMP traps

EIGRP Traffic Statistics

‒ AS Number

‒ Number of Hellos, Updates,

‒ Queries, and 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

‒ Pending Routes

‒ Hello Interval

EIGRP Peer Data

‒ Peer Address, Interface

‒ Hold Time, Up Time

‒ SRTT/RTO

‒ Version

Additional CCO information

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

http://www.cisco.com/go/mibs

ftp://ftp.cisco.com/pub/mibs/oid/

33




http://www.cisco.com/go/mibs

ftp://ftp.cisco.com/pub/mibs/oid/


Routing Enhancements—MANET

Mobile Ad-hoc Network (MANET)

Cisco supports RFC4938bis and Dynamic Cost Routing via using EIGRP

The fundamental requirement for MANET applications is effective integration of routing and radio technologies

Effective routing requires immediate recognition of topology changes, the ability to respond to radio link quality fluctuations, and a means by which routers can receive and act upon feedback from a radio network

New Virtual Multipoint Interface (VMI) and L2L3 API connects Layer 2 RF network with layer 3

Mobile EIGRP

Router Mobile Radio Mobile EIGRP

Router Mobile Radio

PPPoE PPPoE

PPP Sessions

RF

34


Routing Enhancements—PfR

Performance Routing (PfR)

Cisco IOS Performance Routing (PfR) supports Route control using EIGRP

Monitors traffic performance for prefixes passively with NetFlow and/or actively using IP SLA probes

Chooses best performing path to a given destination

Delay, MOS

Load Balancing

For prefix, traffic-class and application


http://www.cisco.com/go/pfr

35

http://www.cisco.com/go/pix


Core

Building 1 Building 2 Building 4

Data Center

WAN

Mobile Worker

Remote Office

Branch Router

Regional Office

Regional Router

WAN Aggregation



VPN

Core

Firewall

Internet Servers

Mail Servers

Core

Internet

Building 3

Distribution

Access

36


Core

Hierarchical Designs

– 2 Layer

– 3 Layer

– More

Reliability

– Graceful Restart(GR)

– Non-Stop Forwarding(NSF)

– Non-Stop Routing(NSR)

37


Hierarchy and the Core

Unlimited Network Hierarchy

EIGRP supports unlimited hierarchy though summarization

The depth of the hierarchy doesn’t alter the way EIGRP is deployed; there are no “hard edges”

– “Core”, “Distribution”, and “Access” are flexible terms that may, or may not, fit your topology

– EIGRP does not force these boundaries

Divide complexity with summarization points

Summarize at every boundary where possible

– Aggregate reachability information

– Aggregate topology information

– Aggregate traffic flows

A place to apply traffic policy

Summarize

Distribution

Access

Core

High Degree

of Density

High Degree

of Complexity

38


Hierarchical Design

No imposed limit on levels of hierarchy – a key design advantage.

No “areas” or other restrictions on dividing a network

Topology information can be hidden at any hop in the network anyway

In an EIGRP network, the hierarchy is created through summarization, rather than through a “protocol defined” boundary

Proper addressing is a must to insure you can summarize

With the logical boundary point behind the lower routers, based on the divisional structure, there’s no place to summarize

No

summarization

10

.1.0

.0/2

4

10

.1.2

.0/2

4

10

.2.0

.0/2

4

10

.2.2

.0/2

4

10

.1.1

.0/2

4

10

.1.3

.0/2

4

10

.2.1

.0/2

4

10

.2.3

.0/2

4

Sales Marketing

Logistics Engineering

Logical

boundary

points

39


Hierarchical Design

The logical network structure no longer follows the corporate departments

We now have a point at which we can summarize routes!

Logical

boundary

point 10.1.0.0/22

10.2.0.0/22

What Happens if We Move the Logical Boundary Point Up One Layer?

10

.1.0

.0/2

4

10

.1.2

.0/2

4

10

.2.0

.0/2

4

10

.2.2

.0/2

4

10

.1.1

.0/2

4

10

.1.3

.0/2

4

10

.2.1

.0/2

4

10

.2.3

.0/2

4

Sales Marketing

Logistics Engineering

40


Hierarchical Design

In this case, moving the logical boundary point down one layer can be used to improve summarization

For EIGRP, it’s just a matter of configuring summaries in the best possible locations

Logical

boundary

point

10

.1.0

.0/2

4

10

.1.2

.0/2

4

10

.1.1

.0/2

4

10

.1.3

.0/2

4

10

.2.1

.0/2

4

10

.2.3

.0/2

4

10

.2.0

.0/2

4

10

.2.2

.0/2

4

41


Two Layer Hierarchy

The core gets traffic from one topological area of the network to another

– High Speed Switching is the focus

Within the core, avoid

– Policy within the core

– Reachability and topology aggregation (summarization)

Core routers should summarize routing information towards the access/aggregation layers

Routing policy may also be implemented at the core edge

Core

Access

Policy

Summary

42


Core

Access

Two Layer Hierarchy

The aggregation layer provides user attachment points

Information hiding

– Edge routes should be ‘hidden’ from the core

– Summarize routes towards the core

Policy should be placed at the edge of the network

– Traffic acceptance (based on load and traffic type)

– Filtering unwanted traffic

– Security policy

Layer 2 and Layer 3 filters apply at the edge

Summarize

Policy

43


Customers

Two Layer Hierarchy

ISP networks are often modeled on a two layer hierarchy as well

The core is often mesh or a set of rings, with each POP modeled as a ring or a two layer hierarchy

Topology information is summarized between the POPs and the network core

Address summarization is generally from the core towards the POPs

Core

POP

POP

POP

POP

POP

44


Three Layer Hierarchy

The core gets traffic from one topological area of the network to another

High Speed Switching is the focus

Within the core, avoid

– Policy within the core

– Reachability and topology aggregation (summarization)

Core routers should summarize routing information towards the distribution layers

Deeper hierarchy does not change EIGRP’s fundamental design concepts

Core

Distribution

Access

45



Address summarization and aggregation occur at the distribution layer

Address Summarization

At the distribution layer edge and the core

At the distribution layer edge and the access layer

At both edges of the distribution layer

The distribution layer should be the blocking point for Queries

– Provide minimal information toward the core

– Provide minimal information toward the access

Access layer routers should be considered for configuration as “stubs”

Core

Distribution

Access

Tra

ffic

ag

gre

ga

tio

n

46


Core

Distribution

Access


The distribution layer is where most of the policy in a three layer network should reside

Traffic Engineering

Directing traffic into the best core entry point

Access layer failover

Traffic filters

Should take all the policy load off the network core

Routing Policy

Routes accepted from the access layer

Routes will be passed from the core into the access layer

Filtering unwanted traffic at Layer 2 and Layer 3

Security policy

Policy

47



Summarization should be avoided between distribution layer routers!

This can cause a lot of odd and hard to troubleshoot problems within the network

Focus summarization and policy up and down the layers, rather than along the layers

No s

um

marization! Core

Distribution

Access

48


1000 routes

1000 routes

1000 routes

1000 routes

4000+100 routes

400+100 routes

Impact of Hierarchy to Core

Assessing the Impact

1000 routes each failing once/month means 4100/30 = 136.7 state changes per day in the core of this network

Summarizing each 1000 route zone into 100 routes reduces the core to 500, rather than 4100 routes

Summarization hides individual route changes, so we only see the 100 “core” routes change: 100/30 = 3.3 state changes per day in the core of this network

49


Core

Hierarchical Designs

– 2 Layer

– 3 Layer

– More

Reliability

– Graceful Restart(GR)

– Non-Stop Forwarding(NSF)

– Non-Stop Routing(NSR)

50


Graceful Restart (GR) / Nonstop Forwarding (NSF)

Graceful Restart (GR) / Nonstop Forwarding (NSF)

GR/NSF are redundancy mechanisms for intra-chassis route processor failover

Graceful Restart (GR) is a way to rebuild forwarding information in routing protocols when the control plane has recovered from a failure

Nonstop Forwarding (NSF) is a way to continue forwarding packets while the control plane is recovering from a failure

– Newly active redundant route processor continues forwarding traffic using synchronized HW forwarding tables

– NSF capable routing protocol (e.g.: EIGRP) requests graceful neighbor restart

– Routing neighbors reform with no traffic loss

– NSF and fast hellos/BFD do not go well and should be avoided

– NSF makes more sense in a singly homed edge devices

Control Data

no reset

Control Data

A

B

51

The fundamental premise of GR/NSF is to route through temporary failures, rather than around them!


Data Center

Building 1 Building 2 Building 3 Building 4

Core

WAN

Internet

Mobile Worker

Remote Office

Branch Router

Regional Office

Regional Router

WAN Aggregation



VPN Firewall

Internet Servers

Mail Servers

Core Data Center

Distribution

Access

52


Data Center

Fast(er) Convergence

– Detection

– Repair

– IP FRR

Redundancy

– Redundant Links

– Controlling Redundancy

– Full Mesh

High Speed Links

– Load Sharing

– Wide Metrics

53


Data Center

Data Centers are at the core of your business activity

Video, voice or other rich media traffic is placing ever-increasing demands on the physical layer

The Core can be used as the data center core. Consider the following items when determining the right core solution:

– 10GigE density—Will there be enough 10GigE ports on the core switch pair to support both the campus distribution as well as the data center aggregation modules?

– Administrative domains and policies—Separate cores help to isolate campus distribution layers from data center aggregation layers in terms of troubleshooting, administration, and policies (QoS, ACLs, troubleshooting, and maintenance).

– Future anticipation—The impact that can result from implementing a separate data center core layer at a later date might make it worthwhile to install it at the beginning.

A robust infrastructure is needed to handle these demands

54


Fast(er) Network Convergence

EIGRP Fast Convergence EIGRP support for FAST Convergence already part of the standard

Customers have been using EIGRP to achieve sub-second convergence for years

• Bad or no network design leads to bad or no Convergence

Proper network design is a must Design to use address summarization to limit query scope

Design to use link redundancy properly

Design to provide at least one feasible successor

• We can sort typical convergence times: EIGRP with a feasible successor

Link state protocols

✗ EIGRP without a feasible successor

55


Convergence Comparative Data

EIGRP with feasible successors

IS-IS with tuned timers

OSPF with tuned timers

EIGRP without feasible successors

OSPF with default timers

IS-IS with default timers

0

7000

6000

5000

4000

3000

2000

1000

1000

2000

3000

40

00

5000

Route

Generator

A

B C

D

Routes

Mil

lis

ec

on

ds

IPv4 IGP Convergence Data We can sort typical convergence times into three groups

56


Fast(er) Network Convergence

For paths with feasible successors convergence time is in the milliseconds – The existence of feasible successors is dependent on the

network design

For paths without feasible successors, convergence time is dependent on the number of routers that have to handle and reply to the query – Queries are blocked one hop beyond aggregation and route filters – so SUMMARIZE

– Query range is dependent on network design – so SUMMARIZE

Good design is the key to fast convergence in an EIGRP network

57


Improving Convergence — Detection

EIGRP Aggressive Timers (Fast Hellos) EIGRP supports aggressive timers to decrease link failure detection

– Aggressive Timers does not provide sub-second failure detection

– Timers can be tuned to a minimum of 1 second

– Interface dampening is recommended with fast hello timers

Additional information There are reasons for not recommending this and also for us not offering such low values; for example, depending on the number of interfaces, 1 sec rates can become CPU intensive and lead to spikes in processing/memory requirements

interface GigabitEthernet1/1

dampening

!

router eigrp ROCKS



hello-interval ?

<1-65535> Seconds between hello transmissions

58


Improving Convergence — Detection

Bidirectional Forwarding Detection (BFD)

Cisco IOS Bidirectional Forwarding Detection (BFD) is a fast Hello at Layer 2.5

– BFD exhibits lower overhead than aggressive hellos

– BFD is a heartbeat at Layer 2.5, provides sub-second failure detection

– BFD can provide reaction time close to 50 milliseconds

EIGRP use BFD facilities which send extremely fast keep-alives between routers

– BFD and the Routing Protocol works together, with Routing Protocol as the upper layer protocol

– BFD relies on the Routing Protocol to tell it about Neighbors

– Notifications occur quickly when changes occur in Layer 2 state


http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-02.txt

http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-05.txt

59
























Improving Convergence — Repair

EIGRP Loop Free Fast Reroute (IP-FRR)

Support for IP Fast Reroute (IP-FRR)

IP-FRR is a mechanism that reduces traffic disruption to 10s of milliseconds in event of link or node failure

Uses existing Feasible Successors, so no additional computational load

Automatically enabled on all interfaces covered by the protocol

Repair paths can be equal or unequal cost (though variance command)

Repair paths are computed for all prefixes though not all prefixes may have a FS (repair path)

But…..

It runs at the process level

Does not guarantee time limit

Performance depends on tuning and platform implementation

Primary Path Repair Path

Primary Next-Hop Protecting Node

A B

C

60


Enabling EIGRP IP-FRR

IOS implements per-prefix IP-FRR

Per-prefix IP-FRR enabled for all areas unless explicitly specified

IP-FRR automatically enabled on EIGRP interfaces

Repair paths are computed for all prefixes though not all prefixes may have repair paths

router eigrp ROCKS


network 10.0.0.0 255.255.255.255

topology base

fast-reroute per-prefix all

. . .

A

61


Data Center


– Detection

– Repair

– IP FRR

Redundancy

– Redundant Links


– Full Mesh

High Speed Links

– Load Sharing

– Wide Metrics

62


Redundancy

The simplest path to increased resiliency is adding redundancy... – Adds network resiliency

– Can provide optimal routing to resources

– Adds additional bandwidth in congested areas of the network

But not so fast!

Adding Links doesn’t always add resiliency General EIGRP rule of thumb: There should be no more paths in the topology table than are allowed to be installed in the routing table

The second link also adds moderate complexity, and more information, into the network

(show ip eigrp topology all vs. show ip protocol, look for maximum path)

A

10.1.1.0/24

B

63


Redundancy

Adding a third link almost always approaches the point of diminishing returns, and adds much more network complexity

When considering adding more redundancy, always balance the increased resiliency against the added complexity – Increased network convergence times

– Increased management effort

– Increased troubleshooting times

64


2.5

0 10000

Se

co

nds

Routes

Feasible successor

Redundancy

The impact of greater levels of redundancy on convergence times can be seen in routing protocol scalability testing

Using EIGRP, with a single backup path, it takes about 1.3 seconds for a router with 10,000 routes to converge when the best path fails

Best path

fails

65


Redundancy

The impact of greater levels of redundancy on convergence times can be seen in routing protocol scalability testing

Using EIGRP, with a single backup path, it takes about 1.3 seconds for a router with 10,000 routes to converge when the best path fails

Adding the third path increases convergence time to 2 seconds

Adding the fourth path increases convergence time to 2.25 seconds

2.5

0 10000

Se

co

nds

Routes

Best path

fails

66


Redundancy

High availability studies also show the impact of adding the third link is not all that great

Adding a second link will increase reliability significantly

Adding a third link approaches the point of diminishing returns

Combined with the impact of slower convergence times, higher management costs, and slower troubleshooting, the total downtime in a network may actually increase with the addition of large amounts of redundancy

99.50

99.60

99.70

99.80

99.90

100.00

1 link 2 links 3 links 4 links

Relia

bili

ty

67


Controlling Redundancy

Consider using Layer 2 interface bundling - EtherChannel®, MLPPP(Multilink PPP)

Increases redundancy

Increases bandwidth

Reduces Layer 3 complexity

But be aware of issues such as

– processor utilization due to bundling overhead

– troubleshooting complexity, etc. Link bundle

68


Full Mesh

Is this sufficient redundancy, or excessive?

There are potentially 64 paths between these two hosts, 26

2 routers == 1 link

3 routers == 3 links




– ...

adjacencies = nodes(nodes-1)/2

Not just physical links, VPLS also creates this scenario

69


Full Mesh

Routes must be advertised between every pair of peers in the mesh so each router has the correct next hop and routing information

Address the links so they can be summarized

Single advertisement at the edge is best

Address the links so the link information can be filtered out at the edge

Summarize

70


Full Mesh

Consider High Availability ring topologies, such as SRP, SONET rings, and others as an alternative to full mesh high speed networks in POPs and other enclosed networks

This can provide resiliency against a single failure in the network, and simplify the topology from the perspective of routing dramatically

71


Ring Topologies

If the A->C link fails, A must query B to find the alternate path

If the B->C link fails, no queries will be transmitted to converge

The maximum query range is one hop

5

5 5

1 Hop Query

No Query

A B

C

72


Ring Topologies

If the A->C link fails

A must query B to find the alternate path

B must query D to find the alternate path

The maximum query range is two hops

5 5

5

5 A B

C

D

2 Hop Query

73


Ring Topologies

If the A->C link fails A must query B to find the alternate path

B must query E to find the alternate path

E must query D to find the alternate path

The maximum query range is three hops

Typically the network will watershed

Rings are a challenging topology for EIGRP The maximum query range will always be the size of the ring minus one

Average is ring size divided by 2

If at all possible, design in triangles, not rings!

5

5 5

5

5 A B

C

D

3 Hop Query

E

74


Data Center


– Detection

– Repair

– IP FRR

Redundancy

– Redundant Links


– Full Mesh

High Speed Links

– Load Sharing

– Wide Metrics

75


Unequal Cost Load Sharing

All routing protocols can load share over equal cost links

Can you load share across the two available paths between A and D, if they are not equal cost?

Yes, EIGRP is unique in this respect

Variance allows unequal cost paths to be used as long as the paths are loop free

56K 56K

500K 1000K

A

B C

D

76



Given the metrics for the following paths:

D through C Distance: 560128

Reported Distance: 557568

D through B Distance: 1069568

Reported Distance: 557568

The best path is through C, so C is the successor

The reported distance through B is lower than the best path through C, so this path is loop free

B is the feasible successor (FS) or backup path 56K

2000ms

56K

2000ms

56K

2000ms

1000K

10ms

A

B C

D

77



Configure variance on router A with a value high enough to include both paths

Variance is a multiplier, so it has to be a number which, when multiplied by the lower metric, is higher than or equal to the highest metric

Any route with a metric less that the variance metric, will be include in the load sharing

A

B C

D

Metric

1069568

Metric

560128

lowest metric * variance ≥ metric of other path

78



Both paths are installed in the routing table

The higher metric is then divided by each lower metric to determine the load share count: 1069568/560128≈2

From this point, the actual load sharing of traffic is up to the switching engine being used to forward packets

For process switching, each packet forwarded through B will be matched by 2 packets forwarded through C

A

B C

D

Metric

1069568

Metric

560128

router-a(config)#router eigrp 100

router-a(config-rtr)#variance 2

router-a(config-rtr)#end

79


EIGRP Classic Metric Formula

With the simplified EIGRP Formula:

The path has a minimum bandwidth of 100,000 kbps (from R4)

The path though the Ten Gigabit Bundle has a total delay of 120 microseconds

But so does the path through the Gigabit Ethernet!

80

metric =107

min bandwidth( )+ delayså

é

ëêê

ù

ûúú*256

Router1#show eigrp addr ipv4 topology 10.1.1.0/24

IP-EIGRP (AS 1): Topology entry for 10.1.1.0/24



10.4.4.2 (TenGigabitEthernet2/0), from 10.4.4.2, Send flag is 0x0

Composite metric is (28672/28416), Route is Internal

Vector metric:




Load is 1/255

Minimum MTU is 1500

Hop count is 2

10.5.5.3 (GigabitEthernet3/0), from 10.5.5.3, Send flag is 0x0


Vector metric:




Load is 1/255

Minimum MTU is 1500

Hop count is 2

B: 10,000,000

D: 10

B: 10,000,000

D: 10

B: 1,000,000

D: 10 B: 1,000,000

D: 10

10.1.1.0/24

B: 100,000

D: 100


Computing Classic Metrics

EIGRP’s calculated metric is called the composite metric

Its computed from individual metrics called vector metrics - minimum bandwidth, total delay, load, reliability

Interface metrics are converted before use

– bandwidth (in kilobits per second): 107 / Interface bandwidth

– delay (in 10s of microseconds): interface delay / 10ms

– load, reliability: converted to range of 0-255

Constants (K1 through K5) are used to control the computation – Default K values are: K1 == K3 == 1 and K2 == K4 == K5 == 0

– When K5 is equal to 0 then [K5/( K4 + reliability)] is defined to be 1

81

metric = [(K1 bandwidth

+

K2 bandwidth + (K3 Delay))

K5 ] 256

256 – Load K4 + Reliability


( )256*

min

107

úû

ùêë

é+ ådelays

bandwidth

Classic and Wide Metrics

Router A advertises 1.1.1.0/24 to B – Bandwidth is set to 1000

– Delay is set to 100

Router B

– Compares current bandwidth to bandwidth of link to A; sets bandwidth to 100

– Adds delay along link to A, for a total of 1100

Router C

– Compares current bandwidth to bandwidth of link to B; sets bandwidth to 56

– Adds delay along link to B, for a total of 3100

82

Computing Metrics

1.1.1.0/24

BW: 1000

Delay: 100

BW: 100

Delay: 1100

BW: 56

Delay: 3100 Minimum

Added Together

BW: 100

Delay: 1000

BW: 56

Delay: 2000

A

B

C


( )256*

min

107

úû

ùêë

é+ ådelays

bandwidth

Computing Classic Metrics

Router C uses the formula to compute a composite metric - This isn’t what the router computes,

though—why?

- The router drops the remainder after the first step!

Why the 256?

– EIGRP uses a 32-bit metric space

– IGRP used a 24-bit metric space

– To convert between the two, multiply or divide by 256!

83

?

107

56=178571

æ

èç

ö

ø÷

(178571+3100)*256 = 46507776

46507885256*310056

107

=úû

ùêë

é+


latency = delay*106éë

ùûOR

1013

bandwidth

é

ëê

ù

ûú

throughput =6.5536*1011

bandwidth

é

ëê

ù

ûú

metric = min throughput( ) + latencyåéë

ùû

Wide Metric Support: New Formula

With the Existing EIGRP Formula:

Wide Metrics enables us to; Configure delay values in pico-seconds

Pass raw delay/bandwidth values between peers

Composite metric is computed correctly for high-speed interfaces

RIB Metric still in 32bit form

Router# show eigrp address-family ipv4 topology

EIGRP-IPv4 VR(WideMetric) Topology Entry for AS(4453)/ID(3.3.3.3) for 10.1.1.0/16

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 262144, RIB is 2048

Descriptor Blocks:

10.4.4.2 (TenGigabitEthernet2/0), from 10.4.4.2, Send flag is 0x0

Composite metric is (262144/196608), route is Internal

Vector metric:


Total delay is 3000000 picoseconds


Load is 1/255

Minimum MTU is 1500

Hop count is 2

Originating router is 100.1.1.1

B: 10,000,000

D: 10

B: 10,000,000

D: 10

B: 1,000,000

D: 10 B: 1,000,000

D: 10

10.1.1.0/24

B: 100,000

D: 100

84


Computing Wide Metrics

EIGRP still uses vector metrics, but they are not scaled, and are processed differently

New vector metrics are derived from values reported by router Throughput – derived from interface bandwidth

Latency – derived from interface delay

Load – derived from interface load

Reliability – derived from interface reliability

Extended Metrics – derived from router and/or configuration

Constants (K1 through K6) are used to control the computation – Default K values are: K1 == K3 == 1 and K2 == K4 == K5 == K6 == 0

[(K1 Throughput + { K2 Throughput

}) + (K3 Latency) + (K6 Ext Metrics) ]

K5

256 - Load K4 + Reliability

85


Computing Wide Metrics

By default, EIGRP computes throughput using the maximum theoretical throughput

The formula for the conversion for max-throughput value directly from the interface without consideration of congestion-based effects is as follows:

If K2 is used, the effect of congestion, as a measure of load reported by the interface, will be used to simulate the available throughput, by adjusting the maximum throughput according to the formula:

This inversion of bandwidth value results in a larger number (more time), ultimately generating a worse metric.

The inverted value is used only by the local router, the original bandwidth value is send to its neighbors

Max-Throughput = (K1 EIGRP_BANDWIDTH EIGRP_WIDE_SCALE

) Bandwidth

Net-Throughput = [Max-Throughput + ( K2 Max-Throughput

)] 256 - Load

86


Classic and Wide Metrics

K3 is used to allow latency-based path selection. Latency and delay are similar terms that refer to the amount of time it takes a bit to be transmitted to an adjacent peer. EIGRP uses one-way based latency values provided either by IOS interfaces or computed as a factor of the links bandwidth

For IOS interfaces that do not exceed 1 gigabit, this value will be derived from the reported interface delay, converted to picoseconds

For IOS interfaces beyond 1 gigabit, IOS does not report delays properly, therefore a computed delay value will be used

Delay = ( Interface Delay EIGRP_DELAY_PICO )

Delay = ( EIGRP_BANDWIDTH EIGRP_DELAY_PICO

) Interface Bandwidth

Latency = (K3 Delay EIGRP_WIDE_SCALE

) EIGRP_DELAY_PICO

87


Distribution and Access

Core

Data Center

WAN

Internet

Mobile Worker

Remote Office

Branch Router

Regional Office

Regional Router

WAN Aggregation



VPN Firewall

Internet Servers

Mail Servers

Core


Distribution Distribution

Access

88



Distribution (aggregation point for access)

– Summarization

Summary Metrics

Summary Leak-maps

– Filtering

Route Map Support

Route Tag Enhancement

Access (STUB and edge features)

– Managing alternate paths

Passive interfaces

– Hub and Spoke

Scaling

Enhancements

Leak-maps

89


Route Summarization

Route Summarization

EIGRP supports summarization at any point in the network

EIGRP chooses the metric of the lowest cost component route as the summary metric

What happens if the summary metric changes?

If the component the metric was taken from changes, the summary changes as well!

You’re using the summary to hide reachability information, but it’s passing metric information through

Routers beyond the summary are still working to keep up with the changes

10.1.0.0/23

Metric 10

10.2.0.0/23

Metric 20

10.1.0.0/23

Metric 30

10.2.0.0/23

Metric 20

10

.1.0

.0/2

4

Me

tric

30

10

.1.1

.0/2

4

Me

tric

10

10

.1.0

.0/2

4

Me

tric

30

10

.1.1

.0/2

4

Me

tric

10

A

B C

10

.2.0

.0/2

4

Me

tric

30

10

.2.1

.0/2

4

Me

tric

20

90


Route Summarization

Use a loopback interface to force the metric to remain constant

Create a loopback interface within the summary address range with a lower metric than any other component

Generally best to use a /32 for the prefix and use delay to force the metric value

The summary will use the metric of the loopback, which doesn’t ever go down

You can sometimes use a route-map to force the summary’s metric to always be the same

A static route to null0 on the summarizing router can also be used

A

B

10.1

.0.0

/24

Metr

ic 1

0

10.1

.1.0

/24

Metr

ic 2

0

10.1.0.0/23

Metric 1

loopback 0

ip address 10.1.1.1 255.255.255.255

delay 1

10.1.0.0/23

1

91


Summary Metrics

Route Summary Static Metrics

EIGRP summarization efficiency is greatly improved by predefining a summary’s metric

Could use a loopback interface or define a static route to null0

✗Metric will be constant, eliminating update

✗ EIGRP still scans component routes for changes

✗ EIGRP will never withdraw summary

A better solution is to use the summary-metric command which established a constant metric value thereby:

Eliminate the updates

Eliminate re-computing the summary metric when components change

Allows the summary to be withdrawn when all comments are lost

router eigrp ROCKS


network 10.0.0.0


summary-address 10.1.0.0/23

exit-af-interface

topology base

summary-metric 10.1.0.0/23 10000 1 255 1 1500

10

.1.0

.0/

24

Me

tric

10

10

.1.1

.0/

24

Me

tric

20

10.1.0.0/23

Metric 1

10.1.0.0/23

A

B

92


Overlapping Summaries

EIGRP allows overlapping summaries

Set the administrative distance on the longer prefix so it is not installed...

Admin Distance of 255 is needed if the more specific summary actually matches a "real" prefix

interface serial 0/0 .... ip summary-address eigrp 1 10.1.0.0 255.255.0.0 ip summary-address eigrp 1 10.1.1.0 255.255.255.0 255

Interface serial 0/0 .... ip summary-address eigrp 1 10.1.0.0 255.255.0.0 ip summary-address eigrp 1 10.1.2.0 255.255.255.0 255

10.1.1.0/24 10.1.2.0/24

10.1.0.0/16

10

.1.0

.0/1

6

10

.1.0

.0/1

6

A B

C

10

.1.1

.0/2

4

10

.1.2

.0/2

4

93



If two routing protocols provide a route to the same destination, how do we choose between them? – Their metrics are not comparable

– An administrative distance is added to each route learned based on the protocol installing the route

Static routes can be configured with a distance – This can create a floating static

– The route will not be used unless the dynamic protocols have no route to that destination

R1#show ip eigrp topology

P 10.0.1.0/24, 1 successors, FD is 2681856

via 10.1.1.1 (2681856/2169856)

R1(config)#ip route 10.0.1.0 255.255.255.0 null0

R1(config)#ip route 10.0.1.0 255.255.255.0 null0 200

distance 90

distance 1

distance 200

The static

route wins

The EIGRP

route wins

94



EIGRP can leak more specific routes through a summary – 12.3(11.01)T and later

route-map LeakList permit 10

match ip address 1

!

access-list 1 permit 10.1.2.0

!

interface Serial0/0

ip summary-address eigrp 1 10.1.0.0 255.255.0.0 leak-map LeakList

10.1.1.0/24 10.1.2.0/24

10.1.0.0/16

10

.1.0

.0/1

6

10

.1.0

.0/1

6

A B

C

10

.1.1

.0/2

4

10

.1.2

.0/2

4


match ip address 1

!


!

interface Serial0/0

ip summary-address eigrp 1 10.1.0.0 255.255.0.0 leak-map LeakList

95


Full routing information


Avoid creating summary black holes

Solution: have a link between the summarizing routers across which they share full routing information

10.1.1.0/24 10.1.2.0/24

10.1.0.0/16

A B

C

10

.1.0

.0/1

6

10

.1.0

.0/1

6

96


Summary Routing Leaking

Route Summary Leaking

EIGRP allows user definable summary components to leak past the summary boundary

For optimal routing, we would like C to be able to receive as few routes as possible, but still optimally route to 10.1.1.0/24 and 10.1.2.0/24 dynamically

Combination of static routes and could be used but its difficult to maintain

The simplest way is to configure a leak-map on the summary route

10.1.1.0/24 10.1.2.0/24

10.1.0.0/16

10

.1.0

.0/1

6

10

.1.0

.0/1

6


match ip address 1

!


!

router eigrp ROCKS


af-interface Serial0/0

summary-address 10.1.0.0 255.255.0.0 leak-map LeakList

A B

C

97


Route-Map Support

EIGRP Route-Map Support

EIGRP supports Enhanced Route-Maps

Enhanced support of route maps allows EIGRP to use a route map to prefer one path over another

Route-maps can now be applied on the distribute-list in/out statement

Filters can be applied even before the prefix hits the topology table

route-map setmetric permit 10

match interface serial 0/0

set metric 1000 1 255 1 1500

route-map setmetric permit 20

match interface serial 0/1

set metric 2000 1 255 1 1500

....

router eigrp ROCKS


topology base

distribute-list route-map setmetric in

98


Enhanced Routing Tagging

EIGRP Enhanced Route Tags

EIGRP has been extended to support a more flexible route tag method

Dotted-Decimal notation easer to read

Support mask for multiple tag matching

Supports IPv4 and IPv6

Classic Route Tag route-map current-route-tag-usage permit 10

match tag 451580 451597 451614 451631

set metric 1100

!

Router# show ip route tag

Enhanced Route Tag ip access-list standard route-tag-mask

permit 100.160.60.60 0.0.3.3

!

route-map enhanced-route-tag permit 10

match ip address tag route-tag-mask

set metric 1100

!

Router# show ip route tag 100.160.61.60 0.0.3.3

Assigning routes a default tag router eigrp ROCKS

address-family ipv4 vrf tagit autonomous-system 4452

topology base

route-tag 100.160.61.61

99



Distribution (aggregation point for access)

– Summarization

Summary Metrics

Summary Leak-maps

– Filtering

Route Map Support

Route Tag Enhancement

Access (STUB and edge features)

– Managing alternate paths

Passive interfaces

– Hub and Spoke

Scaling

Enhancements

Leak-maps

100


Managing Wiring Closets

Alternative paths are a good thing….. Right?

Not if they are excessive OR undesired!

Alternative paths that exist in the network that provide little if any real benefit of improved reliability, and are often unplanned and unexpected.

In this example, the four Ethernets on the left are there to provide users with access to the network.

There are two routers connected to each VLAN in order to provide redundancy (probably via HSRP) so that the users will have failover capability if there is a problem.

1.1.1.0/24

A

B

101


RtrA#show eigrp address-family ipv4 topo all | begin 1.1.1.0

P 1.1.1.0/24, 1 successors, FD is 128256, serno 2673915

via Connected, Loopback1

via 10.0.19.2 (9690112/9173248), FastEthernet6/0.19














….snip….


Unfortunately, the designer may have created a network topology a little different than what was intended…

Wow, where did all

of these alternative paths

come from! for

a connected Route!

RtrA#show ip route | begin 1.1.1.0

C 1.1.1.0 is directly connected, Loopback1

….snip….

RtrA#show eigrp address-family ipv4 topo | begin 1.1.1.0


via Connected, Loopback1


….snip….

B

1.1.1.0/24

A

B

102


1.1.1.0/24

A

B

Each user segments will be treated as a possible alternative path!

Generally network designers generally do not have these user segments as transit paths

Each user segments is in the query path, causing EIGRP to do a lot of work by including these extra links.

Extra work means shower convergence.

A simple solution is provided with the use of

the “passive-interface” command.


router eigrp 100

passive-interface fastethernet 0/0




....

-or- router eigrp 100

passive-interface default

no passive-interface fastethernet 1/0

....

B

1.1.1.0/24

A

B

103


Hub and Spoke (STUBs)

EIGRP Hub and Spoke (STUBs)

EIGRP offers the best scaling performance of all IGPs

If these spokes are remote sites, they have two connections for resiliency, not so they can transit traffic between A and B

A should never use the spokes as a path to anything, so there’s no reason to learn about, or query for, routes through these spokes

What happens when a route or link is lost?

→ EIGRP query's ALL neighbors

→ Each neighbors using it to reach the destination will also query their neighbors

B A

Don’t Use These Paths

B A

10.1

.1.0

/24

104



Marking the spokes as stubs allows the STUBs to signal A and B that they are not valid transit paths

A will not query stubs, reducing the total number of queries in this example to one

Marking the remotes as stubs also reduces the complexity of this topology

Router B now believes it only has one path to 10.1.1.0/24 (through A), rather than five

B B A

10.1

.1.0

/24

router#config t

router(config)#router eigrp 100

router(config-router)#eigrp stub connected

router(config-router)#

105



If stub connected is configured

– B will advertise 10.1.2.0/24 to A

– B will not advertise 10.1.2.0/23, 10.1.3.0/23, or 10.1.4.0/24

If stub summary is configured



ip route 10.1.4.0 255.255.255.0 10.1.1.10

!

interface serial 0

ip summary-address eigrp 10.1.2.0 255.255.254.0 5

!

router eigrp 100

redistribute static metric 1000 1 255 1 1500

network 10.2.2.2 0.0.0.1

network 10.1.2.0 0.0.0.255

eigrp stub connected

eigrp stub summary

10.1.2.0/24

10.2.2.2/31

10

.1.3

.0/2

4

A

B

106



If stub static is configured



If stub receive-only is configured

B won’t advertise anything to A, so A needs to have a static route to the networks behind B to reach them

ip route 10.1.4.0 255.255.255.0 10.1.1.10

!

interface serial 0

ip summary-address eigrp 10.1.2.0 255.255.254.0

!

router eigrp 100

redistribute static 1000 1 255 1 1500

network 10.2.2.2 0.0.0.1

network 10.1.2.0 0.0.0.255

eigrp stub receive-only

eigrp stub static

10.1.2.0/24

10.2.2.2/31

10

.1.3

.0/2

4

A

B

107



If Stub Redistributed Is Configured

B will advertise 10.1.4.0/24 to A

B will not advertise 10.1.2.0/24, 10.1.2.0/23, or 10.1.3.0/24

ip route 10.1.4.0 255.255.255.0 10.1.1.10

!

interface serial 0

ip summary-address eigrp 10.1.2.0 255.255.254.0

!

router eigrp 100

redistribute static 1000 1 255 1 1500

network 10.2.2.2 0.0.0.1

network 10.1.2.0 0.0.0.255

eigrp stub redistributed

10.1.2.0/24

10.2.2.2/31

10

.1.3

.0/2

4

A

B

108



At A, you can tell B is a stub using show ip eigrp neighbor detail

router-a#show ip eigrp neighbor detail

IP-EIGRP neighbors for process 100

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

0 10.2.2.3 Se0 13 00:00:15 9 200 0 9

Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1

Stub Peer Advertising ( CONNECTED ) Routes

Suppressing queries

10.1.2.0/24

10.2.2.2/31

10

.1.3

.0/2

4

A

B

109



At B, you can see that the EIGRP process for AS 100 is running as a stub using show ip protocols

router-b#show ip protocols

Routing Protocol is "eigrp 100"

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Default networks flagged in outgoing updates

Default networks accepted from incoming updates

EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

EIGRP maximum hopcount 100

EIGRP maximum metric variance 1

EIGRP stub, connected

Redistributing: static, eigrp 100

.

.

10.1.2.0/24

10.2.2.2/31

10

.1.3

.0/2

4

A

B

110



Any combination of the route types can be specified on the eigrp stub statement, except receive-only, which cannot be used with any other option

For example: – eigrp stub connected summary redistributed

If eigrp stub is specified without any options, it will enable – eigrp stub connected summary

111


Hub and Spoke Scaling

Most EIGRP Neighbors Seen

– 800 deployed in live, working networks

– 3500 is the largest number ever tested in a lab environment

Key Strategy for achieving scalability is design!

– Stub for EIGRP hub and spoke environments is a must

– Minimize advertisements to spokes

– Using summaries at the hubs with the new static summary metric option should increase scaling further still.

112


Hub and Spoke Scaling

The blue line shows the rate at which the convergence time increases as EIGRP neighbors are added to hub routers and does not pass 500

The red line shows the convergence time if the neighbors added are all configured as EIGRP stub routers and scales to over 1000 peers

Measure initial bring up convergence until all neighbors are established and queues empty

Dual Homed Remotes, NPE-G1 with 1G RAM, 3000 prefixes advertised to each spoke

2

5

9

0 500 1000 1500

Number of Neighbors

Test performed with 12.3(14)T1

Non-Stub

EIGRP Stub

Tim

e (

min

ute

s)

113


Hub and Spoke Failover

The blue line with the steep slope shows the rate at which the failover convergence time increases as EIGRP neighbors are added to a single hub router

The red line shows the failover convergence time if the neighbors added are all configured as EIGRP stub routers and is extremely linear in behavior

Primary Hub failed, time measured for EIGRP to complete failover convergence

Dual Homed Remotes, NPE-G1 with 1G RAM, 3000 prefixes advertised to each spoke

0

1

60

0 200 400 600 800 1000 1200 1400 1600

Number of Neighbors

Tim

e (

min

ute

s)

Test performed with 12.3(14)T1 15

EIGRP Stub

Non-Stub

114


Stub Enhancements

Multipoint interface Enhancements

EIGRP Enhances Multi-point interface stability

When bringing up an interface with hundreds of neighbors, EIGRP may converge slowly, symptoms include;

→ Continuous neighbor resets

→ Packet retransmission timeout

→ Stuck-in-Actives

→ Hold time expirations

EIGRP uses the bandwidth on the main interface divided by the number of neighbors on that interface to get the bandwidth available per neighbor

Multipoint

tunnel

interface

Hub

Spoke-1 Spoke-n Spoke-2

…

115


Stub Enhancements

Hub and spoke networks are often built over point-to-multipoint networks

If the hub is configured to treat the entire point-to-multipoint network as a single interface, it can transmit multicast and broadcast packets which are received by all spoke routers

Layer 3 on the hub router will not notice a single circuit failure

interface s0/0

ip address 10.1.1.1 255.255.255.0

Packets transmitted

here are received

only by the hub router

Packets transmitted

here are received

by all spokes

116


Stub Enhancements

The hub router can also be configured to treat each spoke’s circuit as an individual point-to-point circuit on a sub-interface

If end-to-end signaling is in use, a failed circuit will cause the sub-interface to fail

Packets transmitted

here are received

by one spoke

Packets transmitted

here are received

only by the hub router

interface s0/0.1 point-to-point

ip address 10.1.1.0 255.255.255.254

....


ip address 10.1.1.2 255.255.255.254

....


ip address 10.1.1.4 255.255.255.254

interface s0.1 point-to-point

ip address 10.1.1.x 255.255.255.254

....

117


Stub Enhancements

Interface type may appear to EIGRP to be a shared interface but underlying network may not match up with the bandwidth defined on the interface.

The minimum packet pacing interval can be lowered to a minimum value of 1 ms by using the bandwidth or bandwidth percentage commands

Improvements to EIGRP transport to speedup convergence and increase neighbor scaling

On a fast interface or a tunnel interface which has unreliable pacing value, EIGRP packet transmissions can also be driven using the neighbor acknowledgements (ACK-driven)

Startup Update Packets exchanged at neighbor startup may now be sent using multicast

router(config-if)#ip bandwidth-percent eigrp 4453...

118


Routing Leaking thru STUBs

EIGRP Hub and Spoke Stub Route Leaking

EIGRP offers additional control over routes advertised by Stubs

Some deployments have a single remote site with two routers and we want to mark the entire site as a “stub site”

Normally stubs C and D won’t advertise learned routes to each other, to override this, add the “leak-map” configuration

0.0.0.0/0 0.0.0.0/0

No A

dve

rtis

em

ents


match ip address 1

match interface e0/0


match ip address 2


!



!

router eigrp ROCKS


eigrp stub leak-map LeakList

10.1.1.0/24 Remote Site

A B

C

D

119



A B

C

D


If the B to D link fails─

10.1.1.0/24 can not be reached from A

–Since C is a stub, C is not advertising 10.1.1.0/24 to A

D can not reach A, or anything behind A

–Since C is a stub, C is not advertising the default route to D

120



The solution is for C and D to advertise a subset of their learned routes, even though they are both stubs

This is exactly what stub leaking does

router eigrp 100

eigrp stub leak-map LeakList


match ip address 1



match ip address 2




e0

/0


A B

C

D

121



A B

C

D


If the B to D link fails─

D is advertising 10.1.1.0/24 to C, and C to A, so 10.1.1.0/24 is still reachable

C is leaking the default route to D, so D can still reach the rest of the network through C

A and B will still not query towards the remote site, since C and D are stubs

Stub leaking is available in 12.3(10.02)T

Leak 10.1.1.0/24 and 0/0

122


Hub and Spoke Summarization

Summarize towards the core

– Number the remote links out of the same address space as the remote networks, if possible

– Consider using /31’s to conserve address space for point-to-points

Send the remotes a default only

If you can’t address the links out of the summary address space, then use a distribute list to filter them from being advertised back into the core of the network

0.0.0.0/0

Summary only

192.168.1.0/24 192.168.2.0/24

192.168.3.0/24

access-list 10 deny 192.168.0.0 0.0.0.255

access-list 10 permit any

....

router eigrp 100

distribute-list 10 out

123



All the same principles apply to dual homed hub and spoke networks

– Summarize or filter the links to the remotes

– Consider using /31’s on point-to-points to conserve address space

Provide as little information as possible to the remotes

– Something more than a default route may be required to provide optimal routing

Avoid Summary Black Holes!

0.0.0.0/0

Summary only

192.168.1.0/24

192.168.2.0/24

192.168.3.0/24

B A

124



EIGRP can run over either a multipoint interface at the hub router or point-to-point sub-interfaces

A single multipoint interface is easier to configure, but consider – Don’t oversubscribe EIGRP’s use of bandwidth

– Multipoint can be harder to troubleshoot

Use summarization at the hub routers to reduce information into the network core

– Provide as little information to the remotes as possible

– Declare the remote routers as stubs

0.0.0.0/0

Summary

only

192.168.1.0/24 192.168.2.0/24

192.168.2.0/24

Single multipoint or

several point-to-points

router eigrp 100

eigrp stub connected

....

125



The route generated by the summary is called a discard route

What would happen if this route isn’t created? – Configure two routers back to back with overlapping

summaries

– Generate a packet towards 10.1.2.1 from either router

– At A, the best path is through 10.1.0.0/16 to B

– At B, the best path is through 10.0.0.0/8 to A

– Routing Loop

10

.0.0

.0/8

10

.1.0

.0/1

6

ip summary-address eigrp 1 10.0.0.0 255.0.0.0

ip summary-address eigrp 1 10.1.0.0 255.255.0.0

10.1.1.0/24

10.2.1.0/24

A

B

10.1.2.1

126


WAN Aggregation


Core

Data Center

Firewall

Internet Servers

Mail Servers

Core

WAN

Internet

Mobile Worker

Remote Office

Branch Router

Regional Office

Regional Router


WAN Aggregation


VPN

Distribution

Access

127


WAN Aggregation

Security Enhancements

DMVPN

– Dual Home

– Scaling

– Enhancements

PE-CE

– Backdoor Links w/SoO

WAN Transparency – OTP

– Point-to-Point

– Route Reflector

128



Adaptive Security Appliances (ASA) Firewall

• The Cisco ASA 5500 series offers EIGRP support

• Common portable EIGRP core code with a platform dependent OS-shim

• Supports EIGRP stub and other key features

• Newer platforms supported


http://www.cisco.com/go/asa

129

http://www.cisco.com/go/pix


WAN Aggregation


DMVPN

– Dual Home

– Scaling

– Enhancements

PE-CE



– Point-to-Point

– Route Reflector

130


EIGRP DMVPN - Dual Home / Dual Provider

EIGRP Dual Hub DMVPN, Dual Domain DMVPN

EIGRP has been enhanced to handle Dual Hub and Dual DMVPN domains

Stub Co-Existence Allows for Dual Hubs

– Support for dual Hubs for redundancy

– Load-balancing

Dual DMVPN Domains – Enables load-balancing for dual DMVPN domain

– Spoke to spoke load balancing and redundancy

– EIGRP honors the ‘no next-hop self’ command on the hub sites

131

DMVPN

Domain 1

DMVPN

Domain 2

Hub 1 Hub 2

SP 1 SP 2

Site1 Site2


Physical: (Dynamic)

Tunnel0: 10.0.0.12

192.168.12.0/24

.1

192.168.11.0/24

.1

192.168.0.0/24

.2

Spoke A

Spoke B

. . . . . . . . . . . . . Web

.37

PC

.25

EIGRP DMVPN

Single DMVPN Hub

Single mGRE tunnel on all nodes

132

Physical: 172.17.0.5

Tunnel0: 10.0.0.2

Physical: (Dynamic)

Tunnel0: 10.0.0.11


192.168.12.0/24

.1

192.168.11.0/24

.1

192.168.0.0/24

.2 .1

Physical: 172.17.0.1

Tunnel0: 10.0.0.1 Physical: 172.17.0.5

Tunnel0: 10.0.0.2

Spoke A

Spoke B .37

.25

EIGRP DMVPN

Dual DMVPN Hub

Single mGRE tunnel on all nodes

Mixed Stub Types on Shared

Media 12.2(35.01)S 12.4(7)

Web

PC

133

Physical: (Dynamic)

Tunnel0: 10.0.0.11

Physical: (Dynamic)

Tunnel0: 10.0.0.12

. . . . . . . . . . . . .


EIGRP DMVPN

How many neighbors can we have on a single tunnel?

Currently, the practical maximum is 600 while advertising no more than 5k prefixes

0

100

200

300

400

500

600

700

800

900

Co

nve

rgen

ce

Tim

e (

sec

on

ds

)

Peer Count, Prefixes

100 344

400 175 311 368 645

500 805

600 541 863

100 1000 5000 8000 10000 20000

134


EIGRP DMVPN

What about dual hubs, single DMVPN?

Currently, the practical maximum is 600 while advertising no more than 5k prefixes

Routes 40000 20000 15000 10000 8000 5000

Convergence (seconds)

613 622 778 652 650 549

Co

nverg

en

ce T

ime

10

0 P

ee

rs

20

0 P

ee

rs

30

0 P

ee

rs

40

0 P

ee

rs

50

0 P

ee

rs

60

0 P

ee

rs

135


EIGRP DMVPN Enhancements

Initial convergence testing was done with 400 peers with 10,000 prefixes to each peer

Measure initial bring up convergence until all neighbors are established and queues empty – EIGRP DMVPN “Phase 0” (prior to 12.4(7))

– EIGRP DMVPN Phase I (12.4(7))

– EIGRP DMVPN Phase II (12.4(9) and later)

Co

nve

rge

nc

e T

ime

Phase II Phase I Phase 0

5

10

15

20

25

30 33 min

11 min

3 min

136


EIGRP DMVPN Customer Experience

Current Max Recommended is 800 peers on a single tunnel, chassis

8,000 peers on the whole network, terminating on 10 hub routers to distribute the load

Typical to have each spoke advertise between 2–5 prefixes to the hubs

Convergence time 3–5 seconds during a failover

Another network is scaling to 400 peers and 10,000 prefixes (specific routes needed for spoke-to-spoke capability)

137


EIGRP DMVPN Scaling

Testing Based on 12.4(7) for EIGRP (Phase I)

– Big Improvements for EIGRP went into this release!

Study performed to analyze the impact of increasing Prefix count and compare that to increasing Peer counts to find the bottlenecks

Data for Single Hub and Dual Hub essentially equivalent

Peers were fixed at 500, prefixes were increased from 0–20k

Prefixes were fixed at 5k, peers were increased from 100–700

138


EIGRP DMVPN Scaling

Effect of Prefix Count on Scaling

Varying Prefix Count, 500 Peers Convergence Measurement

0

200

400

600

800

1000

1200

1400

1600

0 2000 4000 6000 8000 10000 12000 14000 16000 18000 20000

Prefixes

Tim

e (

se

c)

139


EIGRP DMVPN Scaling

Effect of Prefix Count on Scaling

Varying Peer Count, 5k Prefixes on Convergence

0

500

1000

1500

2000

2500

3000

3500

100 200 300 400 500 600 700

Peer Count

Tim

e (

se

c)

140


EIGRP DMVPN Scaling

Peer Count is the bottleneck

– Peer count is the dominate variable

– There is a combined impact with Prefix count

– Active development is underway to increase scale

Further enhancements are currently being investigated – Focused on increasing Peer count significantly

– Continued increase of Prefix count

– Combined impact targeting overall significant reduction in convergence

More to come on DMVPN!!

141


3rd Party Next Hop

EIGRP Support for 3rd Party Next Hops

EIGRP offers 3rd Party next hop support at LAN redistribution points;

Example, A, B and C share the same broadcast segment

– A redistributes OSPF into EIGRP

– B isn’t running OSPF

– C isn’t running EIGRP

For redistributed OSPF routes B normally shows A as next hop despite a direct connection to C

A now sends updates to B with C as the next-hop

EIGRP Preserves the next hop in redistribution from broadcast networks EIGRP-IPv4 VR(ROCKS) Topology Table for AS(4453)/ID(10.0.0.1)

....

P 10.1.1.0/24, 1 successors

via 10.1.2.1

A

B C

10.1.1.0/24

EIGRP

.1 .2

.3

OSPF

router eigrp ROCKS



no next-hop-self

142


3rd Party Next Hop: Add-Path

EIGRP DMVPN, MultiPath, AddPath

EIGRP has been enhanced to carry multiple next-hops

Equal Cost MultiPath (15.2(3)T, 15.2(1)S) – Destination network is reachable via more than one DMVPN (mGRE

tunnel) and the ip next-hop needs to be preserved over both paths

Add-path (15.3(1)S)

– Spoke site has multiple DMVPN spoke routers and want to be able to load-balance spoke-spoke tunnels going into this spoke site

Up to 4 additional Nexthops addresses (5 total)

Hub 1

SP 1 SP 2

Hub 2

Site1 Site2

DMVPN

Domain

143


WAN Aggregation


DMVPN

– Dual Home

– Scaling

– Enhancements

PE-CE



– Point-to-Point

– Route Reflector

144


PE-CE Goals

145

Allow customers to segment their network using an MPLS VPN backbone

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 Site-of-Origin(SoO) route tag functionality

– Customer sites may be same or different Autonomous Systems

– Customer sites may consist of multiple connections to the MPLS VPN backbone

– Customer sites may consist of one or more connections not part of the MPLS VPN backbone (“backdoor” links)

PE1 PE2

CE1 CE2

MPLS VPN

Cloud

Site 2 Site 1

Customer sites belonging to

same EIGRP AS


PE-CE: Operation

CE runs EIGRP as before where as PE runs EIGRP-VRF process per VRF/AS

EIGRP routes are distributed to sites customer via MP-iBGP on the MPLS-VPN backbone

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)

146


PE-CE EIGRP Extended Community

Define a set up BGP Extended Community values to carry EIGRP route information

Cost Community attribute can be applied at various points in the MP-BGP best-path calculation

Type Usage Value

8800 EIGRP General Route Information Flags + Tag

8801 EIGRP Route Metric Information + AS AS + Delay

8802 EIGRP Route Metric Information Reliability + Hop + BW

8803 EIGRP Route Metric Information Reserve + Load + MTU

8804 EIGRP Ext. Route Information Remote AS + Remote ID

8805 EIGRP Ext. Route Information Remote Protocol+ Remote Metric

147



Value 128 represents that route is originated internal to EIGRP domain

We see that EIGRP Attributes of Delay + BW + Hop Count + Reliability

+ MTU are carried via MP-BGP Extended Community

Looking for Cost Communities PE11#show ip bgp vpnv4 all 1.1.1.1

BGP routing table entry for 11:1:1.0.0.0/8, version 7

Paths: (1 available, best #1, table EIGRP-Same-AS)

140.0.0.1 (via EIGRP-Same-AS) from 0.0.0.0 (11.11.11.11)

Origin incomplete, metric 1889792, localpref 100, weight 32768, valid, sourced, best

Extended Community: RT:1:1

Cost:pre-bestpath:128:1889792 (default-2145593855) 0x8800:32768:0

0x8801:1:640000 0x8802:65281:1249792 0x8803:65281:1500

148



If the route is external to EIGRP AS, we see a value of 129, and we

also see two additional pieces of information in the Cost

Community value:

0x8804 includes External-AS + External Originator ID

0x8805 includes External Protocol + External Metric

PE11#show ip bgp vpnv4 all 111.0.0.0

BGP routing table entry for 11:1:111.0.0.0/8, version 25

Paths: (1 available, best #1, table EIGRP-Same-AS)

12.12.12.12 (metric 10) from 12.12.12.12 (12.12.12.12)

Origin incomplete, metric 2274048, localpref 100, valid, internal, best

Extended Community: RT:1:1

Cost:pre-bestpath:129:2274048 (default-2145209599) 0x8800:0:0

0x8801:1:1024256 0x8802:65281:1249792 0x8803:65281:1500

0x8804:0:1684300900 0x8805:4:1

149


Customer Sites in the Same EIGRP AS

150

PE1 PE2

CE1 CE2

MPLS VPN

Cloud

Site 2

EIGRP

AS 1

Site 1

EIGRP

AS 1


same EIGRP AS

AS CE-Sites are in the same-AS, routes will be learned with normal EIGRP attributes

MP-BGP will carry the EIGRP attributes natively as part of the BGP update (EIGRP AS

#, EIGRP Metrics)

Customer sites will see remote sites as part of their normal EIGRP domain



CE1#show ip route 2.2.2.2

Routing entry for 2.2.2.2/32

Known via "eigrp 1", distance 90, metric 2913792, type internal

Last update from 140.0.0.2 on Serial2/0, 00:00:13 ago

Loading 1/255, Hops 2

CE2#show ip route 1.1.1.1

Routing entry for 1.1.1.1/32

Known via "eigrp 1", distance 90, metric 2401792, type internal

Last update from 140.0.0.202 on Serial2/0, 00:03:43 ago

Loading 1/255, Hops 2

Remote Site routes are being on the Local PE routers with

Internal EIGRP Admin Distance of 90 and with Hop Count of 2

151


Customer Sites in the Same EIGRP AS PE11#show ip eigrp vrf EIGRP-Same-AS topology 1.1.1.1 255.255.255.255

IP-EIGRP topology entry for 1.1.1.1/32



140.0.0.1 (Serial2/0), from 140.0.0.1, Send flag is 0x0


Vector metric:




Load is 1/255

Minimum MTU is 1500

Hop count is 1

PE11#show ip eigrp vrf EIGRP-Same-AS topology 2.2.2.2 255.255.255.255

IP-EIGRP topology entry for 2.2.2.2/32



0.0.0.0, from 0.0.0.0, Send flag is 0x0

Composite metric is (2401792/0), Route is Internal (VPNv4 Sourced)

Vector metric:




Load is 1/255

Minimum MTU is 1500

Hop count is 1

1.1.1.1/32 is locally learned via

EIGRP from CE1

2.2.2.2/32 is learned via MP-BGP

from remote-PE and

redistributed into the EIGRP-VRF

on local Router

152



ip vrf EIGRP-Same-AS

rd 11:1

route-target export 1:1

route-target import 1:1

!

router eigrp 100

address-family ipv4 vrf EIGRP-Same-AS

redistribute bgp 65000 metric 10000 1 255 1 1500

network 140.0.0.0

no auto-summary

autonomous-system 1

exit-address-family

!

router bgp 65000

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 12.12.12.12 remote-as 65000

neighbor 12.12.12.12 update-source Loopback0

!

address-family vpnv4

neighbor 12.12.12.12 activate

neighbor 12.12.12.12 send-community extended

exit-address-family

!


redistribute eigrp 1

no synchronization

exit-address-family

PE 1 ip vrf EIGRP-Same-AS

rd 12:1

route-target export 1:1

route-target import 1:1

!

router eigrp 100


redistribute bgp 65000 metric 10000 1 255 1 1500

network 140.0.0.0

no auto-summary

autonomous-system 1

exit-address-family

!

router bgp 65000

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 11.11.11.11 remote-as 65000

neighbor 11.11.11.11 update-source Loopback0

!

address-family vpnv4

neighbor 11.11.11.11 activate

neighbor 11.11.11.11 send-community extended

exit-address-family

!


redistribute eigrp 1

no synchronization

exit-address-family

PE 2

153


Customer Sites in Different EIGRP AS

154

Customer sites are in different EIGRP AS

CE Sites will learn the remote-CE-site routes as EXTERNAL routes

This is normal behavior due to the different EIGRP AS

MP-BGP on the PE routers will carry the EIGRP routes with their normal attributes

PE1 PE2

CE1 CE2

MPLS VPN

Cloud

Site 2

EIGRP

AS 2

Site 1

EIGRP

AS 1


different EIGRP AS



CE1#show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via "eigrp 1", distance 170, metric 1762048, type external Last update from 140.0.0.2 on Serial2/0, 00:00:22 ago Loading 1/255, Hops 1

CE2#show ip route 1.1.1.1 Routing entry for 1.1.1.1/32 Known via "eigrp 2", distance 170, metric 1762048, type external Last update from 140.0.0.202 on Serial2/0, 00:00:16 ago Loading 1/255, Hops 1

Remote Site routes are being on the Local PE routers with External EIGRP Admin Distance of 170 and with Hop Count of 1

155


Customer Sites in Different EIGRP AS PE11#show ip eigrp vrf EIGRP-Diff-AS topology 1.1.1.1 255.255.255.255 IP-EIGRP topology entry for 1.1.1.1/32 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1889792 Routing Descriptor Blocks: 140.0.0.1 (Serial2/0), from 140.0.0.1, Send flag is 0x0 Composite metric is (1889792/128256), Route is Internal Vector metric: Minimum bandwidth is 2048 Kbit Total delay is 25000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1

PE11# show ip eigrp vrf EIGRP-Diff-AS topology 2.2.2.2 255.255.255.255 IP-EIGRP topology entry for 2.2.2.2/32 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256256 Routing Descriptor Blocks: 0.0.0.0, from Redistributed, Send flag is 0x0 Composite metric is (256256/0), Route is External Vector metric: Minimum bandwidth is 10000 Kbit Total delay is 10 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 0 External data: Originating router is 140.0.0.2 (this system) AS number of route is 65000 External protocol is BGP, external metric is 2401792 Administrator tag is 0 (0x00000000)

1.1.1.1/32 is locally learned via EIGRP from CE1 2.2.2.2/32 is learned via MP-BGP from remote-PE and redistributed into the EIGRP-VRF on local Router. This is an external route from the EIGRP domain and as we the info. carried in the EIGRP-VRF topology.

156



ip vrf EIGRP-Diff-AS rd 11:1 route-target export 1:1 route-target import 1:1 ! router eigrp 100 address-family ipv4 vrf EIGRP-Diff-AS redistribute bgp 65000 metric 10000 1 255 1 1500 network 140.0.0.0 autonomous-system 1 exit-address-family ! router bgp 65000 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 12.12.12.12 remote-as 65000 neighbor 12.12.12.12 update-source Loopback0 ! address-family vpnv4 neighbor 12.12.12.12 activate neighbor 12.12.12.12 send-community extended exit-address-family ! address-family ipv4 vrf EIGRP-Diff-AS redistribute eigrp 1 no synchronization exit-address-family

ip vrf EIGRP-Diff-AS rd 12:1 route-target export 1:1 route-target import 1:1 ! router eigrp 100 address-family ipv4 vrf EIGRP-Diff-AS redistribute bgp 65000 metric 10000 1 255 1 1500 network 140.0.0.0 autonomous-system 2 exit-address-family ! router bgp 65000 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 11.11.11.11 remote-as 65000 neighbor 11.11.11.11 update-source Loopback0 ! address-family vpnv4 neighbor 11.11.11.11 activate neighbor 11.11.11.11 send-community extended exit-address-family ! address-family ipv4 vrf EIGRP-Diff-AS redistribute eigrp 2 no synchronization exit-address-family

PE 1 PE 2

157


Customer Sites with Backdoor Links

158

CE1

CE2

C3

C4

PE1 PE2

CE1 CE2

MPLS VPN

Cloud

Site 2

EIGRP

AS 1

Site 1

EIGRP

AS 1

Customer Sites with

Backdoor Links

Customer wants to use the MPLS-VPN core for the Sites connectivity

Use the Back-door links in case of a failure (they usually are low-speed links)

Use EIGRP attributes on backdoor links for the Sites Connectivity (example: delay)

Everything should work as expected in case of a loss of connectivity through

the MPLS-VPN Core


WAN Aggregation


DMVPN

– Dual Home

– Scaling

– Enhancements

PE-CE



– Point-to-Point

– Route Reflector

159


OTP – Overview

Allow customers to segment their network using an MPLS VPN backbone

Impose little requirements or no restrictions on customer networks

Work seamlessly with both traditional managed and non-managed internet connections

EIGRP routes are NOT distributed to MP-iBGP and never show up in the MPLS-VPN backbone

Compliments an L3VPN Any-to-Any architecture (no hair pinning of traffic)

PE/CE

BGP Complexity

Carrier Involvement

Multiple Redistribution

Public & Unsecure

EIGRP OTP

EIGRP Simplicity

Carrier Independence

Zero Redistribution

Private & Secure

160


OTP – Overview

EIGRP Support for WAN Transparency

EIGRP offers OTP support for Transparent CE to CE Routing

Allow customers to segment their network using MPLS VPN backbone, or public network

Impose NO special requirement on ISP

– EIGRP “end-to-end” solution with no route redistribution

– Customer sites may be same or different Autonomous Systems

– CE routers are only routers requiring upgrade

– No routing protocol is needed on CE to PE link

– Customer sites may consist of multiple connections to the MPLS VPN backbone

– Customer sites may consist of one or more connections not part of the MPLS VPN backbone (“backdoor” links)

161

Service Provider

Network

Site

Site

Site

Site

Site


OTP – CE to CE

Service Provider

MPLS VPN

Customer sites belonging to same EIGRP AS

EIGRP AS 4453


ip address 172.1.1.1 255.255.255.0

!

router eigrp ROCKS

address-family ipv4 unicast auto 4453

neighbor 172.2.2.2 Ethernet0/2 remote 10 lisp-encap

network 10.0.0.0


ip address 172.2.2.2 255.255.255.0

!

router eigrp ROCKS


neighbor 172.1.1.1 Ethernet0/2 remote 10 lisp-encap

network 10.0.0.0

CE-

1

CE-

2

Site to Site peering is “Over the ToP” (across) the WAN

– CE-1 and CE-2 form peering and exchange route updates using unicast packets

– CE-1 sends unicast packet to CE-2 public address (172.2.2.2)

– CE-2 sends unicast packet to CE-1 public address (172.1.1.1)

Data is encapsulation happens on the CE routers using LISP encapsulation

EIGRP AS 4453

162

= DP

= CP


OTP –Multiple Branches

Use EIGRP Route-Reflectors when setting up multiple branches

router eigrp ROCKS


remote-neighbors source Serial 0/0 unicast-listen lisp-encap

network 10.0.0.0

RR

Select a CE to function as Route Reflector (RR)

EIGRP-RR preserves the next-hop of the advertising

CE Router when sending update to other CE Routers

Using GETVPN, both Control and Data can optionally

be encrypted for security

Adding additional CE routers does not

require a change to the configuration of

the EIGRP-RR

EIGRP AS 4453

EIGRP AS 4453

EIGRP AS 4453


neighbor 172.2.2.2 Serial 0/2 remote 10 lisp-encap

network 10.0.0.0

exit-address-family

EIGRP AS 4453

= DP

= CP

163


OTP – Backdoor Links

Use MPLS-VPN core for the site-to-site connectivity

Use “back-door” link in case of a failure (these are usually are low-speed links)

164

All prefixes appear are native EIGRP routes (Internals show up in other site as Internals)

Normal EIGRP metric selection and costing will influence path selection

Convergence events in Customer site

- does not depend on MPLS convergence

- does not impact MPLS Core

Everything works as expected in case of a loss of connectivity through the MPLS-VPN Core

Service Provider

MPLS VPN

Backdoor Link

EIGRP AS 4453

EIGRP AS 4453

CE-

1

CE-

2


OTP – Multi-Provider

OTP supports Dual-Providers

Select EIGRP-RR for each provider

Normal EIGRP metric selection and costing will influence path selection

165

Internet

RR

MPLS – L3 VPN

RR

EIGRP AS 4453

EIGRP AS 4453

EIGRP AS 4453

= DP

= CP


EIGRP w/OTP vs. EIGRP w/DMVPN Comparison

! interface lisp0 ip mtu 1400 ! router EIGRP LISP-OTP ! address-family ipv4 unicast autonomous-system 4453 ! neighbor 172.2.2.2 Ethernet0/2 remote 10 lisp-encap network 10.4.132.0 0.0.0.255 network 10.4.163.0 0.0.0.127 exit-address-family ! ip route 20.1.1.1 255.255.255.255 64.73.10.2 ip route 20.1.2.1 255.255.255.255 74.73.10.2 ip route 64.4.128.0 255.255.255.0 64.73.10.2

crypto isakmp policy 15 encr aes 256 authentication pre-share group 2 lifetime 1200 crypto isakmp key c1sco123 address 64.4.128.151 crypto isakmp key c1sco123 address 64.4.129.152 ! crypto gdoi group GETVPN-PUBLIC identity number 65511 server address ipv4 64.4.128.151 server address ipv4 64.4.129.152 ! crypto map GETVPN-MAP 10 gdoi set group GETVPN-PUBLIC ! interface Ethernet0/1 ip address 64.73.10.1 255.255.255.0 crypto map GETVPN-MAP ! interface Ethernet0/2 ip address 74.73.10.1 255.255.255.0 crypto map GETVPN-MAP

166

EIGRP Configuration GETVPN Configuration


ip vrf INET-PUBLIC rd 65512:1 ! crypto keyring DMVPN-KEYRING vrf INET-PUBLIC pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123 ! crypto isakmp policy 10 encr aes 256 authentication pre-share group 2 crypto isakmp keepalive 30 5 crypto isakmp profile FVRF-ISAKMP-INET-PUBLIC keyring DMVPN-KEYRING match identity address 0.0.0.0 INET-PUBLIC ! crypto ipsec transform-set AES256/SHA/TRANSPORT esp-aes 256 esp-sha-hmac mode transport ! crypto ipsec profile DMVPN-PROFILE set security-association lifetime seconds 7200 set transform-set AES256/SHA/TRANSPORT set isakmp-profile FVRF-ISAKMP-INET-PUBLIC ! interface Ethernet0/1 ip vrf forwarding INET-PUBLIC ip address 64.73.10.1 255.255.255.0 ! interface Tunnel10 ip address 10.4.132.201 255.255.255.0 no ip redirects ip mtu 1400 ip nhrp authentication cisco123 ip nhrp map multicast 172.16.130.1 ip nhrp map 10.4.132.1 172.16.130.1 ip nhrp network-id 101 ip nhrp holdtime 600 ip nhrp nhs 10.4.132.1 ip nhrp shortcut tunnel source Ethernet0/1 tunnel mode gre multipoint tunnel vrf INET-PUBLIC tunnel protection ipsec profile DMVPN-PROFILE ! router EIGRP 200 network 10.4.132.0 0.0.0.255 network 10.4.163.0 0.0.0.127 ! ip route vrf INET-PUBLIC 0.0.0.0 0.0.0.0 64.73.10.2

ip vrf INET-PUBLIC-2 rd 65512:2 ! crypto keyring DMVPN-KEYRING-2 vrf INET-PUBLIC-2 pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123 crypto isakmp profile FVRF-ISAKMP-INET-PUBLIC-2 keyring DMVPN-KEYRING-2 match identity address 0.0.0.0 INET-PUBLIC-2 ! crypto ipsec transform-set AES256/SHA/TRANSPORT-2 esp-aes 256 esp-sha-hmac mode transport ! crypto ipsec profile DMVPN-PROFILE-2 set security-association lifetime seconds 7200 set transform-set AES256/SHA/TRANSPORT-2 set isakmp-profile FVRF-ISAKMP-INET-PUBLIC-2 ! interface Ethernet0/2 ip vrf forwarding INET-PUBLIC-2 ip address 74.73.10.1 255.255.255.0 ! interface Tunnel20 ip address 10.4.133.201 255.255.255.0 no ip redirects ip mtu 1400 ip nhrp authentication cisco123 ip nhrp map multicast 172.16.130.2 ip nhrp map 10.4.133.1 172.16.130.2 ip nhrp network-id 102 ip nhrp holdtime 600 ip nhrp nhs 10.4.133.1 ip nhrp shortcut tunnel source Ethernet0/2 tunnel mode gre multipoint tunnel vrf INET-PUBLIC-2 tunnel protection ipsec profile DMVPN-PROFILE-2 ! router EIGRP 200 network 10.4.133.0 0.0.0.255 ip route vrf INET-PUBLIC-2 0.0.0.0 0.0.0.0 74.73.10.2

EIGRP w/OTP vs. EIGRP w/DMVPN Comparison

167


OTP WAN Solution Analysis Overview

EIGRP OTP DMVPN / Internet MPLS VPN MPLS+DMVPN

Control Plane EIGRP IGP/BGP + NHRP;

LAN IGP

eBGP/iBGP;

LAN IGP

IGP/BGP + NHRP;

eBGP; LAN IGP

Data Plane LISP mGRE IP IP + mGRE

Privacy GETVPN IPSec over mGRE GETVPN GETVPN + DMVPN

Routing Policies EIGRP, EIGRP Stub EIGRP Stub Redistribution and route

filtering

EIGRP Stub,

Redistribution, filtering,

Multiple AS

Network Virtualization VRF/EVN to LISP multi-

tenancy

DMVPN VRF-Lite; MPLS o

DMVPN

Multi-VRF CEs and

multiple IP VPNs

Multi-VRF Ces and

DMVPN VRF-Lite

Convergence

Branch/Hub

Branch Fast;

Hub – Fast

Branch Fast;

Hub - Fast

Branch / Hub carrier

dependent

Carrier and DMVPN hub

dependent

Multicast Support Planned PIM Hub-n-Spoke PIM MVPN MVPN + DMVPN Hub-n-

Spoke

Provider Dependence

No No Yes Yes/No

168


Availability and Roadmap

EIGRP OTP Availability ASR1K: IOS-XE 3.10 (June 2013)

ISR G2: IOS 15.4(1)T (Nov 2013)

Planned Future Enhancements Multicast Support

VRF-aware

Security Group Tag (SGT) support

169


Summary: What Have We Learned?

EIGRP is no longer proprietary

Consider deploying EIGRP IPv6 in small scale to see operational differences

Scalability of EIGRP is very important factor in modern networks deployment

Scalability with EIGRP is accomplished with stubs and summaries - see if you can summarize further

Understand EIGRP fast convergence and resiliency techniques

Wide Metrics allows EIGRP to detect links speeds up to 4.2 Terabytes

Look at improving convergence by checking for feasible successor, and start using BFD

EIGRP provides best scaling with DMVPN and hub and spoke environments

Things to consider when deploying EIGRP as a PE CE protocol

WAN deployments are greatly simplified with OTP

170


Recommended Reading for BRKRST-2336

ASIN: 1578701651 ISBN:

0201657732 ISBN 1587051877

Open-EIGRP: draft-savage-eigrp-00

171


Maximize your Cisco Live experience with your

free Cisco Live 365 account. Download session

PDFs, view sessions on-demand and participate in

live activities throughout the year. Click the Enter

Cisco Live 365 button in your Cisco Live portal to

log in.

Complete Your Online Session Evaluation

Give us your feedback and you could win fabulous prizes. Winners announced daily.

Receive 20 Cisco Daily Challenge points for each session evaluation you complete.

Complete your session evaluation online now through either the mobile app or internet kiosk stations.

172


Final Thoughts

Get hands-on experience with the Walk-in Labs located in World of Solutions, booth 1042

Come see demos of many key solutions and products in the main Cisco booth 2924

Visit www.ciscoLive365.com after the event for updated PDFs, on-demand session videos, networking, and more!

Follow Cisco Live! using social media:

– Facebook: https://www.facebook.com/ciscoliveus

– Twitter: https://twitter.com/#!/CiscoLive

– LinkedIn Group: http://linkd.in/CiscoLI

173

http://www.ciscolive365.com/

https://www.facebook.com/ciscoliveus

https://twitter.com/

http://linkd.in/CiscoLI

Documents

EIGRP Deployment in Modern Networks