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


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 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 [vrf ] autonomous-system

exit-address-family

service-family [vrf ] 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 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 autonomous-system


exit-af-interface

af-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 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/ 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 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


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 ?

Autonomous System

neighbor EIGRP neighbor debugging

notifications EIGRP event notifications

summary EIGRP summary route processing

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



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

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, its 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 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

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

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 ?

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


Repair

IP FRR



Full Mesh


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

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



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


Repair

IP FRR



Full Mesh


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

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

Routing Descriptor Blocks:

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

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

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): 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 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

?

107

56=178571

(178571+3100)*256 = 46507776

46507885256*310056

107=

+


latency = delay*106OR

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

Building 4 Building 1 Building 2 Building 3

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

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

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

af-interface Ethernet0/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 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

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 B will advertise 10.1.2.0/23 to A


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 B will advertise 10.1.4.0/24 to A


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

10

.1.3

.0/2

4

A

B

107



If Stub Redistributed Is Configured

B will advertise 10.1.4.0/24 to A


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 tr

Documents

BRKRST-2336