BRKRST 2336

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
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
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
Application
Acceleration
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
!
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 youre 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
!
no shutdown
exit-af-interface
!
no shutdown
exit-af-interface
16
!
interface Ethernet0/0
ipv6 address 2001:DB8::1/64
ipv6 enable
ipv6 eigrp 6473
!
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 address 2001:DB8::1/64
ipv6 enable
!
ipv6 enable
!
router eigrp CSCO
router-id 10.10.10.1
no shutdown
topology base
IPv6 Configuration Primer
17
IPv6 Primer
An IPv6 address is an extended 128-bit / 16 bytes address that gives
2
128
possible addresses (3.4 x 10
38
)
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
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 Neighbors 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
ipv6 summary-address eigrp 6473 ?

router eigrp cl013-ipv6
address-family ipv6 auto 6473
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
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
3
rd
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
F
i
l
t
e
r

No Knowledge of
Route, So Reply
S
u
m
m
a
r
y

No Knowledge of
Route, So Reply
No peers,
So Reply
C
D
A
E
F
G
B
32
Routing EnhancementsSNMP
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
Routing EnhancementsMANET
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 EnhancementsPfR
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
Core
Building 1 Building 2 Building 4
Data Center
WAN
Mobile Worker
Remote Office
Branch
Router
Regional Office
Regional
Router
WAN Aggregation
Application
Acceleration
Application
Acceleration
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 doesnt 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,
theres no place to summarize
No
summarization
1
0
.
1
.
0
.
0
/
2
4

1
0
.
1
.
2
.
0
/
2
4

1
0
.
2
.
0
.
0
/
2
4

1
0
.
2
.
2
.
0
/
2
4

1
0
.
1
.
1
.
0
/
2
4

1
0
.
1
.
3
.
0
/
2
4

1
0
.
2
.
1
.
0
/
2
4

1
0
.
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?
1
0
.
1
.
0
.
0
/
2
4

1
0
.
1
.
2
.
0
/
2
4

1
0
.
2
.
0
.
0
/
2
4

1
0
.
2
.
2
.
0
/
2
4

1
0
.
1
.
1
.
0
/
2
4

1
0
.
1
.
3
.
0
/
2
4

1
0
.
2
.
1
.
0
/
2
4

1
0
.
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, its just a matter of configuring
summaries in the best possible locations
Logical
boundary
point
1
0
.
1
.
0
.
0
/
2
4

1
0
.
1
.
2
.
0
/
2
4

1
0
.
1
.
1
.
0
/
2
4

1
0
.
1
.
3
.
0
/
2
4

1
0
.
2
.
1
.
0
/
2
4

1
0
.
2
.
3
.
0
/
2
4

1
0
.
2
.
0
.
0
/
2
4

1
0
.
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 EIGRPs
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
T
r
a
f
f
i
c

a
g
g
r
e
g
a
t
i
o
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
N
o

s
u
m
m
a
r
i
z
a
t
i
o
n
!
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
Application
Acceleration
Application
Acceleration
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 densityWill 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 policiesSeparate 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 anticipationThe 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
1
0
0
0

2
0
0
0

3
0
0
0

4
0
0
0

5
0
0
0

Route
Generator
A
B C
D
Routes
M
i
l
l
i
s
e
c
o
n
d
s

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 doesnt 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
S
e
c
o
n
d
s

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
S
e
c
o
n
d
s

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
R
e
l
i
a
b
i
l
i
t
y

67
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, 2
6
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/5601282
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
10
7
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
EIGRPs 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): 10
7
/ Interface bandwidth
delay (in 10s of microseconds): interface delay / 10ms
load, reliability: converted to range of 0-255

Constants (K
1
through K
5
) are used to control the computation
Default K values are: K
1
== K
3
== 1 and K
2
== K
4
== K
5
== 0
When K
5
is equal to 0 then [K
5
/( K
4
+ reliability)] is defined to be 1

81
metric = [(K
1
bandwidth
+
K
2
bandwidth
+ (K
3
Delay))

K
5

] 256
256 Load K
4
+ Reliability
( )
256 *
min
10
7
+

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
10
7
+

delays
bandwidth
Computing Classic Metrics
Router C uses the formula to compute a composite metric
- This isnt what the router computes,
thoughwhy?
- 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
?
10
7
56
178571
(178571+3100)*256 46507776
46507885 256 * 3100
56
10
7
+
latency delay*10
6
OR
10
13
bandwidth
throughput
6.5536*10
11
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 (K
1
through K
6
) are used to control the computation
Default K values are: K
1
== K
3
== 1 and K
2
== K
4
== K
5
== K
6
== 0
[(K
1
Throughput + {
K
2
Throughput
}) + (K
3
Latency) + (K
6
Ext Metrics) ]
K
5

256 - Load K
4
+ 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 K
2
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 = (K
1

EIGRP_BANDWIDTH EIGRP_WIDE_SCALE
)
Bandwidth
Net-Throughput = [Max-Throughput + (
K
2
Max-Throughput
)]
256 - Load
86
Classic and Wide Metrics
K
3
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 = (K
3

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
Application
Acceleration
Application
Acceleration
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!
Youre using the summary to hide reachability
information, but its 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
1
0
.
1
.
0
.
0
/
2
4

M
e
t
r
i
c

3
0

1
0
.
1
.
1
.
0
/
2
4

M
e
t
r
i
c

1
0

1
0
.
1
.
0
.
0
/
2
4

M
e
t
r
i
c

3
0

1
0
.
1
.
1
.
0
/
2
4

M
e
t
r
i
c

1
0

A
B
C
1
0
.
2
.
0
.
0
/
2
4

M
e
t
r
i
c

3
0

1
0
.
2
.
1
.
0
/
2
4

M
e
t
r
i
c

2
0

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 doesnt
ever go down
You can sometimes use a route-map to force the
summarys metric to always be the same
A static route to null0 on the summarizing router can
also be used

A
B
1
0
.
1
.
0
.
0
/
2
4

M
e
t
r
i
c

1
0

1
0
.
1
.
1
.
0
/
2
4

M
e
t
r
i
c

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 summarys 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
1
0
.
1
.
0
.
0
/
2
4

M
e
t
r
i
c

1
0

1
0
.
1
.
1
.
0
/
2
4

M
e
t
r
i
c

2
0

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.2.0 255.255.255.0 255
10.1.1.0/24 10.1.2.0/24
10.1.0.0/16
1
0
.
1
.
0
.
0
/
1
6

1
0
.
1
.
0
.
0
/
1
6

A
B
C
1
0
.
1
.
1
.
0
/
2
4

1
0
.
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
1
0
.
1
.
0
.
0
/
1
6

1
0
.
1
.
0
.
0
/
1
6

A
B
C
1
0
.
1
.
1
.
0
/
2
4

1
0
.
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
1
0
.
1
.
0
.
0
/
1
6

1
0
.
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
1
0
.
1
.
0
.
0
/
1
6

1
0
.
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 theres 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
Dont Use These Paths
B A
1
0
.
1
.
1
.
0
/
2
4

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
1
0
.
1
.
1
.
0
/
2
4

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
B will not advertise 10.1.2.0/24, 10.1.3.0/24,
or 10.1.4.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 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
1
0
.
1
.
3
.
0
/
2
4

A
B
106
If stub static is configured
B will not advertise 10.1.2.0/24, 10.1.2.0/23, or
10.1.3.0/24

If stub receive-only is configured
B wont 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
1
0
.
1
.
3
.
0
/
2
4

A
B
107
If Stub Redistributed Is Configured
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
1
0
.
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
1
0
.
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
1
0
.
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
T
i
m
e

(
m
i
n
u
t
e
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
T
i
m
e

(
m
i
n
u
t
e
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
spokes 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 wont advertise learned routes
to each other, to override this, add the leak-map
configuration
0.0.0.0/0 0.0.0.0/0
N
o

A
d
v
e
r
t
i
s
e
m
e
n
t
s

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
10.1.1.0/24
Remote Site
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

e
0
/
0

10.1.1.0/24
Remote Site
A B
C
D
121
10.1.1.0/24
Remote Site
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 /31s to conserve address space for point-
to-points
Send the remotes a default only
If you cant 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 /31s 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
Dont oversubscribe EIGRPs 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 isnt 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
1
0
.
0
.
0
.
0
/
8

1
0
.
1
.
0
.
0
/
1
6

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
Application
Acceleration
WAN Aggregation
Application
Acceleration
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
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
Tunnel0: 10.0.0.1
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
C
o
n
v
e
r
g
e
n
c
e

T
i
m
e

(
s
e
c
o
n
d
s
)

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
C
o
n
v
e
r
g
e
n
c
e

T
i
m
e

1
0
0

P
e
e
r
s

2
0
0

P
e
e
r
s

3
0
0

P
e
e
r
s

4
0
0

P
e
e
r
s

5
0
0

P
e
e
r
s

6
0
0

P
e
e
r
s

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)
C
o
n
v
e
r
g
e
n
c
e

T
i
m
e

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 25 prefixes to the hubs
Convergence time 35 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 020k
Prefixes were fixed at 5k, peers were increased from 100700
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
T
i
m
e

(
s
e
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
T
i
m
e

(
s
e
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
3
rd
Party Next Hop
EIGRP Support for 3
rd
Party Next Hops
EIGRP offers 3
rd
Party next hop support at LAN
redistribution points;
Example, A, B and C share the same broadcast segment
A redistributes OSPF into EIGRP
B isnt running OSPF
C isnt 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
3
rd
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 PEs)
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
Known via "eigrp 1", distance 90, metric 2401792, type internal
Remote Site routes are being on the Local PE routers with
Internal EIGRP Admin Distance of 90 and with Hop Count of 2
151
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
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
!
router eigrp 100
network 140.0.0.0
no auto-summary
autonomous-system 1
exit-address-family
!
router bgp 65000
!
exit-address-family
!
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
Known via "eigrp 1", distance 170, metric 1762048, type external
Known via "eigrp 2", distance 170, metric 1762048, type external
Remote Site routes are being on the Local PE routers with External EIGRP Admin
Distance of 170 and with Hop Count of 1
155
PE11#show ip eigrp vrf EIGRP-Diff-AS topology 1.1.1.1 255.255.255.255
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-Diff-AS topology 2.2.2.2 255.255.255.255
0.0.0.0, from Redistributed, Send flag is 0x0
Composite metric is (256256/0), Route is External
Vector metric:
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
!
router eigrp 100
address-family ipv4 vrf EIGRP-Diff-AS
network 140.0.0.0
autonomous-system 1
exit-address-family
!
router bgp 65000
!
exit-address-family
!
no synchronization
exit-address-family
ip vrf EIGRP-Diff-AS
rd 12:1
!
router eigrp 100
network 140.0.0.0
autonomous-system 2
exit-address-family
!
router bgp 65000
!
exit-address-family
!
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
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
!
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
!
ip address 64.73.10.1 255.255.255.0
crypto map GETVPN-MAP
!
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
!
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
!
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

BRKRST 2336

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

BRKRST 2336

Diunggah oleh

Hak Cipta:

Format Tersedia

EIGRP Deployment in Modern Networks

metric min throughput

Wide Metric Support: New Formula

Anda mungkin juga menyukai