EIGRP Deployment - Cursuri Automatica si Calculatoareandrei.clubcisco.ro/cursuri/4prc/deploying/BRKRST-2330.pdf · in the bandwidth or delay causes EIGRP to reread them or when a

© 2006, Cisco Systems, Inc. All rights reserved.Presentation_ID.scr

1

© 2008 Cisco Systems, Inc. All rights reserved. Cisco PublicBRKRST-233014341_04_2008_c1 2

EIGRP Deployment

BRKRST-2330


2

© 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 3BRKRST-233014341_04_2008_c1

EIGRP

EIGRP Operation

Topologies and Techniques

Managing EIGRP


EIGRP Operation


3


EIGRP Operation

Neighbor Formation

Computing Metrics

The Diffusing Update Algorithm

The Active Process

External Routing Information


EIGRP Neighbor Formation

EIGRP uses a three way handshake to prevent neighbor formation along a unidirectional link

When A receives the first multicast hello from B, it places B in the pending state, and transmits a unicast update with the initialization (init) bit set

While B is in this state, A will not send it any queries or routing information

A

B

Mul

ticas

t hel

lo

Uni

cast

Upd

ate

+ In

itB

in P

endi

ng


4



When B receives this update with the init bit set, it sends an update with the init bit set as well

The acknowledgement for A’s initial update is piggybacked onto this packet—it is never transmitted by itself

There is no way for A to receive the acknowledgement for its initial update without also receiving B’s initial update

A

B

Mul

ticas

t hel

lo

Uni

cast

Upd

ate

+ In

itB

in P

endi

ng

Uni

cast

Upd

ate

+ In

it +

Ack



Once the acknowledgement for its initial update is received, A takes B out of the pending state, and begins sending it topology information

If this acknowledgement isn’t ever received, hello’s from B are ignored while A attempts to retransmit the initial update

Eventually, A will time B out, and the process will start over

A

B

Mul

ticas

t hel

lo

Uni

cast

Upd

ate

+ In

itB

in P

endi

ng

Inic

ast U

pdat

e +

Init

+ Ac

k

B O

ut o

f Pen

ding

Uni

cast

Top

olog

y Ta

ble

Info


5



For each route A sends B, B sends a poison reverse

This makes certain the two router’s tables are accurate

When a router finishes sending its table, it sends an end-of-table indicator

A

B

Uni

cast

Top

olog

y Ta

ble

Info

Pois

on R

ever

se U

nica

st R

oute

s

End-

of-T

able


Computing Metrics

EIGRP uses a compound metric

Individual metrics are called component metrics

Five components: bandwidth, delay, load, reliability, and MTU

By default, only bandwidth and delay are actually used

Calculated metric is called the composite metric

( ) 256*min

107

⎥⎦

⎤⎢⎣

⎡+∑delays

bandwidth


6


( ) 256*min

107

⎥⎦

⎤⎢⎣

⎡+∑delays

bandwidth

Computing Metrics

Router A advertises 10.1.1.0/24 to B

Bandwidth is set to 1000

Delay is set to 100

10.1.1.0/24

BW: 1000Delay: 100

BW: 100Delay: 1000

BW: 56Delay: 2000

A

B

CMinimum

Added TogetherRouter CCompares current bandwidth to bandwidth of link to B; sets bandwidth to 56Adds delay along link to B, for a total of 3100

Router B Compares current bandwidth to bandwidth of link to A; sets bandwidth to 100Adds delay along link to A, for a total of 1100


( ) 256*min

107

⎥⎦

⎤⎢⎣

⎡+∑delays

bandwidth

Computing Metrics

Router C uses the formula to compute a composite metric

This isn’t what the router computes, though—why?

The router drops the remainder after the first step!

Why the 256?EIGRP uses a 32-bit metric space

IGRP uses a 24-bit metric space

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

46507885256*310056107

=⎥⎦

⎤⎢⎣

⎡+

??

46507776256*3100178571

17857156107

=+

⎟⎟⎠

⎞⎜⎜⎝

⎛=


7


Computing Metrics

Where does EIGRP get the component metrics?Bandwidth: default bandwidth value or interface level bandwidth command

Delay: default interface value or interface level delay command

Reliability: per interface computed reliability, 0–255

Load: per interface computed load, 0–255

Why not set the K values so the reliability and load are picked up?

Interface level computed metrics are only picked up when a change in the bandwidth or delay causes EIGRP to reread them or when a route changes and we have to recalculate the metric

Effectively, this means these metrics (reliability and load) are not checked on an ongoing basis with stable routes


The Diffusing Update Algorithm (DUAL)

How does EIGRP determine which routes are loop free?

Each of A’s neighbors is reporting reachability to E

B with a cost of 10

C with a cost of 10

D with a cost of 30

These three costs are called reported distance (RD); the distance each neighbor is reporting to a given destination

A

B

C

D

E

1010 30

10 15

15


8



At A, the total cost to reach E is:

20 through B

25 through C

45 through D

The best of these three paths is the path through B, with a cost of 20

This is the feasible distance (FD)

A

B

C

D

E

1010 30

10 15

15



A uses these two pieces of information to determine which paths are loop free

The best path (FD) is used as a benchmark; all paths withRDs lower than the FDcannot contain loops

The algorithm may mark some loop free paths as loops

However, it is guaranteed never to mark a looped path as loop free

A

B

C

D

E

10 30

10 15

15

10


9



At A:The path through B is the best path (FD), at 20

C can reach E with a cost of 10; 10 (RD) is less than 20 (FD), so this path is loop free

D can reach E with a cost of 30; 30 (RD) is not less than 20 (FD), soEIGRP assumes this path is a loop

A

B

C

D

E

1010

10 15

15

30



At A:Question: Why should DUAL consider the 30 (RD) from D as a loop?

Answer: Because, mathematically it could be. As far as A is concerned, the 30 (RD) from D could be the loop we see here

A

B

D

E

10

1030

5

5


10



If the best path fails, through B (the successor), EIGRP will examine the available paths to E

Finding a path which was previously declared loop free (a feasible successor), it begins using it immediately

C now becomes the successor (best path)

A

B

C

D

E

1010

10 15

15

30



Are there any Feasible Successors from Router E’s perspective?

FD is 20

RD from C is 15

RD from D is 15

RD < FD, so it satisfies the Feasibility Condition (FC)

We have two FS!

In order for there to be only one FS, the link A-D or A-C would need to be increased to at least 20

A

B

C

D

E

1010

10 15

15

30


11



A now examines its topology information based on the new successor metric

The reported distance through the remaining neighbor, D, is 30; 30 (RD) is still more than 25 (FD), so this path is still considered a loop

A

B

C

D

E

1010 30

10 15

15



The path through C now fails

A examines its topology information, and finds it has no loop free path to E

However, it does have a neighbor, and that neighbor might have a loop free path

So, it places E in active state and queries D

A

B

C

D

E

1010 30

10 15

15


12



D examines its topology informationSince its best path is not through A, the path it has to E is still valid

D sends a reply to this query, indicating it still has a valid loop free path to EOnce A receives this reply, it begins using the path through D

A

B

C

D

E

1010 30

10 15

15


The Active Process

So what used to happen when A loses its route to 10.1.1.0/24?

No FS, mark route activeSet a three minute active timerQuery all neighbors (B)

B receives A’s queryNo FS, mark route activeSet three minute active timerQuery all neighbors (C)

C receives B’s queryExamine local topology tableNo feasible successorsNo neighbors to query!

A

B

C

10.1.1.0/24

10.1.10/24 Gone; No FS

Active Timer Set Query

Active Timer SetQuery

10.1.10/24 Gone; No FS

10.1.10/24 Gone

Prior to Enhanced Active Processing12.1(4.0.3)T and 12.1(4.1)


13


The Active Process

C has no alternate path to 10.1.1.0/24

Remove from local tables

Reply to querying neighbors

B receives C’s replyNo outstanding queries


Reply to querying neighbors

A receives B’s replyNo outstanding queries


A

B

C

10.1.1.0/24

10.1.10/24 Gone; No FS

Query

Query

10.1.10/24 Gone; No FS

10.1.10/24 Gone

Reply

Reply

Remove 10.1.1.0/24

Remove 10.1.1.0/24

Remove 10.1.1.0/24

Prior to Enhanced Active Processing


The Active Process

If C sends the reply, and B never receives it, what happens?

A’s active timer (three minutes) is still counting down while B and C are trying to get the reply back

When this timer expires, A declares an SIA

The A/B neighbor relationship is reset

A

B

C

10.1.1.0/24

Reply

Remove 10.1.1.0/24

Bad Link, Reply Never Makes It

Why Reset A/B When B/C Is the Problem??

Prior to Enhanced Active Processing

10.1.10/24 Gone; No FS

Query

Query

10.1.10/24 Gone; No FS

10.1.10/24 Gone

Reset Relationship!


14


The Active Process

So now what happens? A queries B when the route goes away; then A sets a sia-retransmit timer to half the configured active time (1.5 minutes, normally)

After this time has passed, A sends an SIA Query

If B sends an SIA Reply to the SIA query, A resets its timer, and the A/B neighbor relationship stays up

A will send the SIA Query 3x, for a total window of 4.5 minutes; even if B replies, after three tries A will reset the neighbor relationship A/B

A

B

C

10.1.1.0/24

10.1.10/24 Gone; No FS

Query

SIA Query

Active Process Enhancement12.1(4.0.3)T and 12.1(4.1),CSCdp33034


The Active Process

If C sends the reply, and B never receives it, what happens now?

If C supports the Active Process Enhancement then when B sends the first SIA Query and receives no reply from C (do to the bad link) B will reset the B/C neighbor relationship

If C does not support the Active Process Enhancement then when B sends the SIA Query and C doesn’t reply to it then the B/C relationship will be reset

A

B

C

10.1.1.0/24

Reply

Remove 10.1.1.0/24


SIA Query

Active Process Enhancement

10.1.10/24 Gone; No FS

Query

Query

10.1.10/24 Gone; No FS

10.1.10/24 Gone


15


The Active Process

C will either reply to the query, which B will then clear back to A, or C will fail to reply at some point and B will reset its relationship with C

Either event clears the query from B’s point of view, which is then cleared back to A minimizing SIA’s considerably

If anything gets reset, its now the “right” neighbor adjacent to the problem router, helping to troubleshoot and identify problem routers easier

A

B

C

10.1.1.0/24

Reply

Remove 10.1.1.0/24


SIA Query

10.1.10/24 Gone; No FS

Query

Query

10.1.10/24 Gone; No FS

10.1.10/24 Gone


The Active Process

Where does the query stop?Router A loses its connection to 10.1.1.0/24

Router A does not consider B a FS, for some reasonRouter A sends B a query

Router B examines its local tables, and finds:

Its current path (successor) doesn’t pass through AIt has a FS that doesn’t pass through A

Router B answersThe query is bounded where there is local knowledge of another loop-free path

10.1.1.0/24

A B

C

D

E

F

G

Local Knowledge of an Alternate Path, So Reply


16


The Active Process

Router C is filtering 10.1.1.0/24 towards D

Router A loses its connection to 10.1.1.0/24

Router A sends C a query

Router C has no FS for 10.1.1.0/24

Router C sends D a query

Router D examines its local tables

No information about 10.1.1.0/24, so send a reply

Query is bounded because D has no information about 10.1.1.0/24

10.1.1.0/24

A B

C

D

E

F

G

Filte

r

No Knowledge of Route, So Reply


The Active Process

Router E is summarizing towards F


Router A sends E a query

Router E has no FS for 10.1.1.0/24

Router E sends F a query

Router F examines its local tables

No information about 10.1.1.0/24, so send a reply

Query is bounded because F has no information about 10.1.1.0/24

10.1.1.0/24

A B

C

D

E

F

GSum

mar

y



17


The Active Process

Router G has no neighbors


Router A sends G a query

Router G examines its local tables

No FS

No neighbors to query, so send a reply

10.1.1.0/24

A B

C

D

E

F

G

No Neighbors, So Reply


The Active Process

The Query is bounded by:Local knowledge of an alternate loop-free path not learned through the neighbor the query was received from

No local knowledge of the route because of filtering or summarization

No neighbors to query

10.1.1.0/24

A B

C

D

E

F

G

Local Knowledge of an Alternate Path, So Reply

Filte

r


Sum

mar

y


No Neighbors, So Reply


18



What is an External Route in EIGRP?

Any route within EIGRP that originated outside of the EIGRP process

Basically, routes redistributed into EIGRP from another protocol, static, or connected routes

Marked in the routing table as D EX to indicate EIGRP owns the route but that it was originated external to EIGRP

router# show ip route[snip…]

D EX 20.1.1.0 [170/2560025856] via 10.1.1.4, 00:07:26, FastEthernet0



What additional information is carried in an external?

Router# show ip eigrp topo 172.31.1.98 255.255.255.255IP-EIGRP topology entry for 172.31.1.98/32State is Passive, Query origin flag is 1, 1 Successor(s), FD is

28160Routing Descriptor Blocks:0.0.0.0, from Redistributed, Send flag is 0x0

Composite metric is (28160/0), Route is ExternalVector metric:

Minimum bandwidth is 100000 KbitTotal delay is 100 microsecondsReliability is 255/255Load is 1/255Minimum MTU is 1500Hop count is 0

External data:Originating router is 172.31.4.100 (this system)AS number of route is 1External protocol is OSPF, external metric is 0Administrator tag is 150 (0x00000096)

Originating Router IDAS #Protocol of OriginExternal MetricAdmin Tags


19



Why is the administrative distance higher on an external?To prefer Internal EIGRP routes over EIGRP Externals

To prefer routing information originating within our AS over that which originated somewhere outside our control

Administrative DistancesRoute Source Default Distance ValuesConnected interface 0Static route 1EIGRP summary route 5eBGP 20Internal EIGRP 90IGRP 100OSPF 110(IS-IS) 115RIP 120On Demand Routing (ODR) 160External EIGRP 170iBGP 200Unknown 255




20



Hub and Spoke Design

EIGRP Stubs

EIGRP DMVPN

Redundancy

Load Sharing

Fast Convergence

Using Bandwidth

Redistribution

Multiple AS



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

Packets Transmitted Here Are Received by All Spokes

Packets TransmittedHere Are Received

Only by the Hub Router

interface s0/0ip address 10.1.1.1 255.255.255.0


21



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

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

Packets Transmitted Here Are Received by One Spoke

Packets TransmittedHere Are ReceivedOnly by the Hub Router

interface s0/0.1 point-to-pointip address 10.1.1.0 255.255.255.254....

interface s0/0.2 point-to-pointip address 10.1.1.2 255.255.255.254....

interface s0/0.3 point-to-pointip address 10.1.1.4 255.255.255.254

interface s0.1 point-to-pointip address 10.1.1.x 255.255.255.254....



Summarize towards the coreNumber the remote links out of the same address space as the remote networks, if possible

Use /31s to conserve address space for point-to-points

Send the remotes a default only

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

0.0.0.0/0

SummaryOnly

192.

168.

0.0/

31

192.168.0.2/31192.168.0.4/31

192.168.1.0/24192.168.2.0/24

192.168.2.0/24

access-list 10 deny 192.168.0.0 0.0.0.255access-list 10 permit any....router eigrp 100distribute-list 10 out


22



In single homed hub and spoke networks, the hub router, spoke routers, and the links themselves are all single points of failure Highly

Available

You can mitigate the single point of failure in the routers using high availability techniques



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

Summarize or filter the links to the remotes

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

SummaryOnly

192.168.1.0/24192.168.2.0/24

192.168.2.0/24


23



How do we limit the amount of information passed down to the remote sites?

You can summarize at A and B towards the remote routers

The summary will generate a local route with an administrative distance of 5

The external default route learned from D will have an administrative distance of 170

What happens?

Internet

EIGRP

A B

C

DExternalDefault Route

D* 0.0.0.0/0 is a summary, 00:08:41, Null0

ip summary-address eigrp 1 0.0.0.0 0.0.0.0

D EX 0.0.0.0/0



In this case, the locally generated discard route wins

The route learned from D will not be installed in the local table

Hosts behind C will not be able to reach destinations on the Internet

There are ways to prevent this discard route from being installed, but we need to be careful with the design

Routing Loops

Routing Black Holes

There is enough rope here to hang yourself!

D* 0.0.0.0/0 is a summary, 00:08:41, Null0


Internet

EIGRP

A B

C

DExternalDefault RouteD EX 0.0.0.0/0


24



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

router#show ip eigrp topologyP 10.0.1.0/24, 1 successors, FD is 2681856

via 10.1.1.1 (2681856/2169856)

router(config)#ip route 10.0.1.0 255.255.255.0 null0

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



The route generated by the summary is called a discard route

What would happen if this route isn’t created?

Configure two routers back to back with overlapping summaries

Generate a packet towards 10.1.2.1 from either router

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

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

Routing Loop


10.0

.0.0

/8

10.1

.0.0

/16


10.1.1.0/24

10.2.1.0/24

A

B

10.1.2.1


25



To remove the discard routeIn EIGRP, add an administrative distance after the ip summary address; make sure this value is greater than 170

C will then learn the 2 External EIGRP routes from A and B

ip summary-address eigrp 1 0.0.0.0 0.0.0.0 200

D* 0.0.0.0/0 [170/409600] via <A>[170/409600] via <B>

External Default Route

Internet

EIGRP

A

C

D

B

D EX 0.0.0.0/0



C will not prefer the internal learned through A over the external learned through B

We have a black hole

ip summary-address eigrp 1 0.0.0.0 0.0.0.0 200

D* 0.0.0.0/0 [170/409600] via <A>[170/409600] via <B>

ExternalDefault Route

D* 0.0.0.0/0 [90/409600] via <A>

Internet

EIGRP

A

C

D

B

D EX 0.0.0.0/0

What happens if A loses its path to D?


26



You can also use floating static routes at the two hub routers and redistribute them into the routing protocol

Distribute list 10 only allows the default route to be advertised to the remotes

Distribute list 20 prevents a default route from being leaked back into the core

This has the same problem if a single link back towards the core and the injected external route both fail

There are other situations under which this also fails

A

C

B

access-list 10 permit host 0.0.0.0access-list 20 deny host 0.0.0.0access-list 20 permit any....ip route 0.0.0.0 0.0.0.0 null0 250....router eigrp 100redistribute staticdistribute-list 10 out <remote 1>distribute-list 10 out <remote 2>distribute-list 10 out <remote 3>distribute-list 20 out <core>


Full Routing Information


One solution is to have a link between the summarizing routers across which they share full routing information

Conditional advertisement of routing information is another possible solution

OSPF can conditionally generate a default route

EIGRP has conditional advertisement as a planned feature

Internet

EIGRP

A B

C

DExternalDefault RouteD EX 0.0.0.0/0


27



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

A single multipoint interface is easier to configure but it can be harder to troubleshoot

P2P subinterfaces allow for more granular failure detection.

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

SummaryOnly

192.168.1.0/24192.168.2.0/24

192.168.2.0/24

Single Multipointor Several Point-to-Points

router eigrp 100eigrp stub connected....


EIGRP Stubs

When a router running EIGRP loses its connection to a network, it first searches for alternate loop free paths

If it finds none, it then sends queries to each of its neighbors, looking for an alternate path

BA

10.1

.1.0

/24

router-a#sho ip eigrp topo

IP-EIGRP Topology Table

....

P 10.1.1.0/24, 1 successors, FD is 281600

via Connected, Ethernet1/2

router-a#show ip eigrp eventsEvent information for AS 100:....

12 Active net/peers: 10.1.1.0/24 1 14 FC not sat Dmin/met: 4294967295 128256 15 Find FS: 10.1.1.0/24 128256 .... 18 Conn rt down: 10.1.1.0/24 Ethernet 3/1


28


EIGRP Stubs

If the neighbor has no path to this destination, it replies

The router then removes all references to this route from its local tables

In large hub and spoke networks, the hub routers have to build queries and process replies from each of the spokes

This impacts scaling!

router-a#show ip eigrp eventsEvent information for AS 100:1 NDB delete: 10.1.1.0/24 1 .... 12 Active net/peers: 10.1.1.0/24 1 14 FC not sat Dmin/met: 4294967295 128256 15 Find FS: 10.1.1.0/24 128256 .... 18 Conn rt down: 10.1.1.0/24 Ethernet 3/1

BA

10.1

.1.0

/24


EIGRP Stubs

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

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

BA

10.1

.1.0

/24

Don’t Use These Paths


29


EIGRP Stubs

To signal A and B that the paths through the spokes should not be used, the spoke routers can be configured as stubs

router#config trouter(config)#router eigrp 100router(config-router)#EIGRP stub connectedrouter(config-router)#

BA

10.1

.1.0

/24


EIGRP Stubs

Marking the spokes as stubs allows them 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; B now believes it only has one path to 10.1.1.0/24, rather than five

Marked

as Stubs

BA

10.1

.1.0

/24


30


EIGRP Stubs

If stub connected is configuredB 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 configuredB 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 0ip summary-address eigrp 10.1.2.0 255.255.254.0 5

!router eigrp 100redistribute static metric 1000 1 255 1 1500network 10.2.2.2 0.0.0.1network 10.1.2.0 0.0.0.255

10.1.2.0/24

A

B

10.2.2.2/31

10.1

.3.0

/24

eigrp stub connected

eigrp stub summary


EIGRP Stubs

If stub static is configured B will advertise 10.1.4.0/24 to A


If stub receive-onlyis configured

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

ip route 10.1.4.0 255.255.255.0 10.1.1.10!interface serial 0ip summary-address eigrp 10.1.2.0 255.255.254.0

!router eigrp 100redistribute static 1000 1 255 1 1500network 10.2.2.2 0.0.0.1network 10.1.2.0 0.0.0.255

eigrp stub receive-only

eigrp stub static

A

B

10.2.2.2/31

10.1

.3.0

/24

10.1.2.0/24


31


EIGRP Stubs

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 0ip summary-address eigrp 10.1.2.0 255.255.254.0

!router eigrp 100redistribute static 1000 1 255 1 1500network 10.2.2.2 0.0.0.1network 10.1.2.0 0.0.0.255

eigrp stub redistributed

A

B

10.2.2.2/31

10.1

.3.0

/24

10.1.2.0/24


EIGRP Stubs

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 actually enable eigrp stub connected summary


32


EIGRP Stubs

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

10.1.2.0/24

A

B

10.2.2.2/31

10.1

.3.0

/24

router-a#show ip eigrp neighbor detailIP-EIGRP neighbors for process 100H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num0 10.2.2.3 Se0 13 00:00:15 9 200 0 9

Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1Stub Peer Advertising ( CONNECTED ) RoutesSuppressing queries


EIGRP Stubs

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

10.1.2.0/24

A

B

10.2.2.2/31

10.1

.3.0

/24

router-b#show ip protocolsRouting Protocol is "eigrp 100"Outgoing update filter list for all interfaces is not setIncoming update filter list for all interfaces is not setDefault networks flagged in outgoing updatesDefault networks accepted from incoming updatesEIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0EIGRP maximum hopcount 100EIGRP maximum metric variance 1EIGRP stub, connectedRedistributing: static, eigrp 100...


33


EIGRP Hub and Spoke

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

Tim

e (M

inut

es)

Test Performed with 12.3(14)T1

Non-Stub

EIGRP Stub

How Many Neighbors?


EIGRP Hub and Spoke

The green 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 (M

inut

es)

Test Performed with 12.3(14)T115

EIGRP Stub

Non-Stub

Failover Time


34


EIGRP Hub and Spoke

Most EIGRP Neighbors Seen800 Deployed in live, working networks

1400 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

Summary


192.168.12.0/24

.1

192.168.11.0/24

.1

192.168.0.0/24.2

Physical: (Dynamic)Tunnel0: 10.0.0.11


Physical: 172.17.0.5Tunnel0: 10.0.0.2

Spoke A

Spoke B

. . .

. . . Web

.37

PC

.25

EIGRP DMVPN

Single DMVPN Hub

Single mGRE tunnel on all nodes


35


192.168.12.0/24

.1

192.168.11.0/24

.1

192.168.0.0/24.2 .1

Physical: 172.17.0.1Tunnel0: 10.0.0.1



Physical: 172.17.0.5Tunnel0: 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 MediaCSCdx74716 12.2(35.01)S 12.4(7)

Web

PC


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

Con

verg

ence

Ti

me

(sec

onds

)

Peer Count, Prefixes

100 344

400 175 311 368 645

500 805

600 541 863

100 1000 5000 8000 10000 20000


36


EIGRP DMVPN

What about dual hubs, single DMVPN?

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

Convergence (seconds)

Routes

549650652778622613

5000800010000150002000040000

Con

verg

ence

Tim

e

100

Peer

s

200

Peer

s

300

Peer

s

400

Peer

s

500

Peer

s

600

Peer

s


EIGRP DMVPN

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

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

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

Convergence time 3–5 seconds during a failover

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

Customer Experience


37


EIGRP DMVPN

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) and later)

EIGRP DMVPN Phase II (CSCei03733)

Con

verg

ence

Tim

e

Phase IIPhase IPhase 0

5

10

15

20

25

30

3533 min

11 min

3 min

EIGRP DMVPN Enhancements


EIGRP DMVPN

Testing Based on 12.4(7) for EIGRP (Phase I)Big Improvements for EIGRP went into this release!

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

Data for Single Hub and Dual Hub essentially equivalent

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

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


38


EIGRP DMVPN

Varying Prefix Count, 500 Peers Convergence Measurement

0

200

400

600

800

1000

1200

1400

1600

0 2000 4000 6000 8000 10000 12000 14000 16000 18000 20000

Prefixes

Tim

e (s

ec)

Effect of Prefix Count on Scaling


EIGRP DMVPN

Varying Peer Count, 5k Prefixes on Convergence

0

500

1000

1500

2000

2500

3000

3500

100 200 300 400 500 600 700

Peer Count

Tim

e (s

ec)

Effect of Peer Count on Scaling


39


EIGRP DMVPN

Currently Phase II is underway to increase these scalability numbers significantly

Focus of Phase II is to increase peer counts, prefix counts, and convergence times—pushing the limits closer to the theoretical maximum of 2000 peers per interface

Preliminary testing of these additional enhancements have verified further scalability and stability, with faster convergence as well

More to come on DMVPN!!


EIGRP DMVPN Scaling

Clearly Peer Count is the bottleneck

There is a combined impact with Prefix count, but Peer count is the dominate variable

Phase II enhancements are currently undergoing testing and review

Focused on increasing Peer count significantly

Continued increase of Prefix count

Combined impact targeting overall significant reduction in convergence

Conclusions


40


Redundancy

There are several reasons for redundancy in a network:To provide multiple attachment points for servers and hosts in case of a link or device failure

To provide alternate links through the network in case of link or device failure

To provide optimal routing to services

To provide load sharing in heavily utilized areas


Redundancy

It’s common to build networks with back-to-back routers for redundancy

The routing protocol sees each of these links as a possible transit path, so each link adds another set of paths the routing protocol must consider when calculating the best path

You want to route to these links, not through them RP Transit

Paths

HSRP Peers


41


Redundancy

The solution to this is passive-interface

Configuring an interface as passive in EIGRP, OSPF, or IS-IS will cause it not to form neighbor relationships across the link

These networks will still be advertised as reachable destinations, but they will never be advertised as transit links

router eigrp 100passive-interface fastethernet 0/0passive-interface fastethernet 0/1passive-interface fastethernet 0/2passive-interface fastethernet 0/3....

router eigrp 100passive-interface defaultno passive-interface fastethernet 1/0....

-or-


Redundancy

It’s common to build out alternate links in a network

Adds network resiliency

Can provide optimal routing to resources

Adds additional bandwidth in congested areas of the network

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

Backup Path

Optimal Routing

Additional Bandwidth


42


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

If Two Is Good…Three Must Be Better… Right? ☺


2.5

0 10000

Seco

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 10000 routes to converge when the best path fails

Best PathFails

1.3


43


2.5

0 10000

Seco

nds

Routes

Redundancy

Adding the third path increases convergence time to 2 seconds

Adding the fourth path increases convergence time to 2.25 seconds

Best PathFails

1.3

2.0

2.25


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

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

Rel

iabi

lity

More Is Not Always Better ☺


44


Redundancy

If you’re adding more links to increase the available bandwidth in a specific place in the network

Summary

Summary

Try to hide this complexity from other parts of the network, if possible

Summarize just the parallel links into a single advertisement at both sides if you’re using a distance vector protocol


Redundancy

Layer 2 bundling (such MLPPP or EtherChannel®) may be useful to reduce the layer 3 complexity when using multiple links to build required bandwidth

But be careful of issues with processor utilization due to bundling overhead, troubleshooting complexity, etc.

Link Bundle


45


Redundancy

Consider using High Availability (HA) techniques to reduce overlapping redundancy

Stateful Switchover/NonStop Forwarding with redundant hardware in the same box may be able to replace redundant connections to network connected devices

Single HighAvailability Device


Redundancy

Balance between complexity and resiliency

Hide the additional complexity created by redundant links where possible

Summarization

Link bundling (but balance against overhead)

Consider High Availability techniques to reduce heavy redundancy for resiliency

99.50

99.60

99.70

99.80

99.90

100.00

1 Link 2 Links 3 Links 4 Links

Rel

iabi

lity


46


Graceful Restart/NSF Fundamentals

Fast Hellos is a way of detecting failures fast and routing around them

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

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


EIGRP Graceful Restart/NSF

Router A loses its control plane for some period of time

It will take some time for Router B to recognize this failure, and react to it

Control Data A

Control Data B

Prior to Graceful Restart/NSF


47



During the time that A has failed, and B has not detected the failure, B will continue forwarding traffic through A

Once the control plane resets, the data plane will reset as well, and this traffic will be dropped

NSF reduces or eliminates the traffic dropped while A’s control plane is down

Control Data A

Reset

Control Data B

Prior to Graceful Restart/NSF



If A is NSF capable, the control plane will not reset the data plane when it restarts

Instead, the forwarding information in the data plane is marked as stale

Any traffic B sends to A will still be switched based on the last known forwarding information

Control Data A

No Reset

Control Data B

Mark ForwardingInformation as Stale

NSF Capable


48



While A’s control plane is down, the routing protocol hold timer on B counts down

A has to come back up and signal B before B’s hold timer expires, or B will route around it

When A comes back up, it signals B that it is still forwarding traffic, and would like to resync

This is the first step in Graceful Restart (GR)

Hold Timer: 1514131211109876

Control Data A

Control Data B

NSF Capable



The signal in EIGRP is an update with the initialization and restart (RS) bits set

A sends its hellos with the restart bit set until GR is complete

B transmits the routing information it knows to A

When B is finished sending information, it sends a special end of table signal so A knows the table is complete

Control Data

Control Data

A

B

Topo

logy

Info

rmat

ion

hello

+ R

esta

rtIn

it +

Res

tart

End

of T

able

Graceful Restart


49



When A receives this end of table marker, it recalculates its topology table, and updates the local routing table

When the local routing table is completely updated, EIGRP notifies CEF

CEF then updates the forwarding tables, and removes all information marked as stale

Control Data A

Control Data B

Graceful Restart



eigrp nsf enables graceful restart

show ip protocols verifies graceful restart is operational

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

A

B

router eigrp 100eigrp nsf....

router eigrp 100eigrp nsf....

router#show ip protocolsRouting Protocol is "eigrp 100“....Redistributing: eigrp 100EIGRP NSF-aware route hold timer is 240sAutomatic network summarization is in effectMaximum path: 4....


50



Routing protocol graceful restart is supported in Cisco IOS® 12.2(15)T

NonStop Forwarding is supported on the:Cisco 10000 and Cisco 12000 12.0(22)S

Cisco 7500 in 12.0(22)S, with the caveat that inserting a new standby RSP will cause some traffic loss, and switching from the primary to standby RSP will cause a microcode reload on the line cards

Cisco 7600/6500 12.2(18)SXD (Rockies1), which shipped in July 2004


Unequal Cost Load Sharing

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

Yes, using variance, as long as the paths are loop free

A

B C

D

56K 56K

500K 1000K


51



D through CDistance: 560128Reported Distance: 557568

D through BDistance: 1069568Reported 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)

56K2000ms

A

B C

D

56K2000ms

56K2000ms

1000K10ms



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

Variance is a multiplier, so it has to be some number which, when multiplied by the lower metric, is higher than or equal to the highest metric you want to include in the load sharing

A

B C

D

Distance1069568

Distance560128


52



In this case, 560128 x 2 = 1120256, which is higher than 1069568, so 2 will work as the variancerouter-a(config)#router eigrp 100router-a(config-rtr)#variance 2router-a(config-rtr)#end

A

B C

D

Distance1069568

Distance560128

Lowest metric * variance ≥

Metric of other path



Both paths are installed in the routing table

The higher metric is then divided by each lower metric to determine the load share count

1069568/560128≈2

So, the load share on the path through C will be set to 2, and the load share on the path through B will be set to 1

A

B C

D

Distance1069568

Distance560128


53



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 two packets forwarded through C

A

B C

D

Distance1069568

Distance560128

Load Share 1

Load Share 2


EIGRP Fast Convergence

Already a standard part of EIGRP

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

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

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

Cisco is currently in the process of quantifying scalability numbers


54


EIGRP Feasible Successor

EIGRP No Feasible Successor+ IS-IS Default Timers

IS-IS Tuned TimersOSPF Tuned TimersOSPF Default Timers

Tested on 12.4(3a)

EIGRP Fast ConvergenceCombined Results


Configuring Bandwidth

EIGRP paces packets based on the configured bandwidth

By default, EIGRP uses 50% of the configured or default bandwidth

Default bandwidth on serial links is 1544 (T1)

Just using the default isn’t always right


55



For point-to-point links (PPP, HDLC, ATM), configure the actual bandwidth available on the link

For burstable links, configure the normal bandwidth, not the burst

For point-to-point subinterfaces off a multipoint link, configure the committed access rate, rather than the line speed



For 0 CIR links, guess

You need to set it high enough to get EIGRP to work, so 56k is probably a reasonable number


56



If you need to change the amount of actual bandwidth EIGRP is using, use the percentage bandwidth interface command to adjust this, rather than setting the bandwidth

IP Percentage-Bandwidth EIGRP <AS> <Percentage>

By default, EIGRP uses 50% of the configured or default bandwidth



Dial and point-to-multipoint links present some difficulties

Each peer which connects over a multipoint reduces the available bandwidth by division

Remote Sites

A

512k


57



One peer: 512k available

Two peers: 256k available

Three peers: 170k available

Four peers: 128k available

Five peers: 102k available

Remote Sites

A

512k



At some point, EIGRP won’t have enough bandwidth to operate correctly

Use dialer profiles for dial links, which makes EIGRP treat them as point-to-point links

Use subinterfaces for multipoint interfaces

Remote Sites

A

512k


58


Problems with Using Bandwidth

Assume you would like to influence the path that packets switched by router A will take to router D

Using bandwidth, you will need to lower the bandwidth on the A-C link or the A-B link to something lower than 56K

Bandwidth is not granular enough to effectively control traffic flow

A

B C

D

56K 56K

1000K 1000K

Control over These Two Links Only!

( ) 256*delaysbandwidthmin

107

⎥⎦

⎤⎢⎣

⎡+∑



Reducing the bandwidth on either the A-B or the A-C link will also impact EIGRP’s operation

EIGRP uses the configured bandwidth to control the rate at which packets are transmitted across a link via the packet pacing timer

A

B C

D

56K 56K

1000K 1000K

Must Be Reduced Dramatically to Impact Path Selection!


59



Don’t use bandwidth to influence path selection!

Set the bandwidth to the actual available bandwidth, and use the delay to influence traffic flow

Delay is added inbound; set the delay on A’s interface which connects to B or C

A

B C

D

56K 56K

1000K 1000K

Configure Delay Here


Multiple Autonomous Systems

Okay, maybe it’s not that bad…

But we still wouldn’t recommend it

Do You Really Want to Do This?


60



A route is redistributed from RIP into AS 200

At A, it is redistributed into AS 100

B receives this route as well; which of the two externals will it prefer?

There are two routes learned through separate routing processes with the same administrative distance, so the route installed first wins

AS 100

AS 200

RIP

A B

C



If router B prefers the route through AS 100, it will redistribute the route back into AS200

If the redistribution metric at B is lower than the redistribution metric at C, A will prefer the path through B

We have a permanent loop!

AS 100

AS 200

RIP

A B

Met

ric 1

000

C

Met

ric 5

00


61



If router B prefers the route through AS 100, it will redistribute the route back into AS200

If the redistribution metric at B is lower than the redistribution metric at C, A will prefer the path through B

We have a permanent loop!

AS 100

AS 200

RIP

A B

Met

ric 1

000

C

Met

ric 5

00



CSCdm47037 resolves the routing loop and the suboptimal routing (12.2(06.01)T)

If two routes with the same administrative distances are compared, and the process type is the same (both EIGRP), then compare the metrics of the routes as well

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdm47037


62


AS 100

AS 200

RIP

A B


External routes can also carry administrative tags; as the external route is redistributed into AS 100 at A, it can be tagged

This tag can then be used to block the redistribution of the route back into AS 200 at B

Tag 100

route-map filtertag deny 10match tag 100

route-map filtertag permit 20!router eigrp 200redistribute eigrp 100 route-map filtertag

route-map settag permit 10set tag 100

!router eigrp 100redistribute eigrp 200 route-map settag....


AS 100

AS 200

RIP

A B


This blocks the formation of the loop, since A will no longer receive the redistributed routes from B through AS 200

B still receives both routes, however, and could still choose the path through AS 100, resulting in suboptimal routing




route-map filtertag permit 20!router eigrp 200redistribute eigrp 100 route-map filtertag

tag 100


63



If the redistribution metric is not manually set at A, it will be carried from AS 200 into 100

The cost of the path between A and B is then added at B

At B, the route through AS 200 wins; it has the lower metric

AS 100

AS 200

RIP

A BMetric 1000

Metric 1500

IP-EIGRP Topology Table for AS(100)/ID(10.0.17.10)....P 10.1.1.0/24, 1 successors, FD is 1500

via 10.0.6.4 (1500/1000), FastEthernet0/0....IP-EIGRP Topology Table for AS(200)/ID(10.2.17.10)....P 10.1.1.0/24, 1 successors, FD is 1000

via 10.2.8.20 (1000/256256), FastEthernet0/1



CSCdt43016, Support for Incoming Route Filtering Based on Route Maps, makes it possible to filter routes based on any route map condition before it is accepted into the local routing protocol database (12.2T 12.0S)

This is listed as an OSPF feature, but it works for all routing protocols

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122relnt/xprn122t/122tnewf.htm#33626


64


AS 100

AS 200

RIP

A B


This blocks the formation of the loop, since B will no longer have the path redistributed from A into AS 100 in its topology table

This also prevents the suboptimal routing




route-map filtertag permit 20!router eigrp 100distribute-list route-map filtertag in



But, before you rush off and configure your network with multiple autonomous systems…

What are you gaining by designing a network this way?


65



A query originates at router C, and propagates to router A

The query stops at A, and a reply is sent back

The query range has been limited at A; the query stopped there, and was replied to; or has it? ...

AS 100

AS 200

A B

C

Query

Reply



What happens at A in AS 100? A now needs to query all of its neighbors, including the neighbors in AS 100

A builds a query in AS 100, and sends it to B; if the timing is right, B will have already received and replied to the query from C, so it would answer that it has no alternate path

The query wasn’t stopped, it was just delayed along the way!

AS 100

AS 200

A B

C

Query

Reply


66



Don’t use multiple autonomous systems for scaling, they don’t limit query range

General scaling methods (summarization, distribute lists, stubs, etc.) actually limit query scope

Multiple autonomous systems are fine for merging two networks over time, but they are not a permanent solution

AS 100

AS 200

A B

C

Query

Reply


Managing EIGRP


67


Managing EIGRP

Reading the EIGRP Topology Table

Reading Show IP EIGRP Neighbors

Neighbor Logging

Event Log



Summary of the Topology Table provides a quick snapshot of the routers status and topology

Shows the following:Number of routes in the local topology table

Number of queries that this router is waiting to receive a reply

Number of interfaces enabled for EIGRP

Number of Neighbors/Number of Interfaces

Quiescent interfaces—those interfaces with nothing to send or have acknowledged

Router#sh ip eigrp topology summary

IP-EIGRP Topology Table for AS(1)/ID(120.0.0.1)Head serial 341880, next serial 6401413027 routes, 0 pending replies, 0 dummiesIP-EIGRP(0) enabled on 1002 interfaces, 1007 neighbors present on 1002 interfacesQuiescent interfaces: Gi0/0.100 Tu10000 Tu871 Tu162 Tu466 Tu268 Tu841 Tu221 Tu528 …


68



router#show ip eigrp topology IP-EIGRP Topology Table for AS(1)/ID(70.1.1.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R -Reply,

r - reply Status, s - sia Status

P 41.1.28.52/30, 1 successors, FD is 21026560via 60.1.1.2 (21026560/20514560), FastEthernet1/0via 60.1.2.1 (46740736/20514560), FastEthernet1/1

StateComputedDistance Reported

Distance

Feasible Successor

Successor

FeasibleDistance


Reading Show IP EIGRP Neighbors

Handle: Internal use to keep track of the NeighborsAddress: Neighbor IP addressInterface: Local Interface which connects to that NeighborHold Time: Seconds remaining before declaring that neighbor downUptime: The period of time since the neighbor was most recently discoveredSRTT: The number of milliseconds it takes for this neighbor to respond to reliable packetsRTO: How long we’ll wait before retransmitting if we get no acknowledgementQ Cnt: Number of outstanding packets waiting to be acknowledged by the neighborSeq Num: Counter to track the number of packets sent to the neighbor

router#show ip eigrp neighborIP-EIGRP neighbors for process 1H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num4 1.1.1.5 Gi0/0.100 14 01:09:54 326 1956 0 4177501480 1.1.1.6 Gi0/0.100 14 1d19h 63 378 0 91717867412 120.0.14.126 Tu928 14 1d22h 1155 5000 0 105404 120.0.11.210 Tu757 14 1d22h 988 5000 0 831003 120.0.5.106 Tu347 12 1d22h 51 5000 0 101


69



Show ip eigrp topology activeInformation about links that are currently in active state

Show ip eigrp topology all-linksDisplays all information about everything that EIGRP has in the topology table

Show ip eigrp topology <net> <mask>Displays everything that the eigrp process has for a specific route

Show ip eigrp topology zeroShows the “zero successor” links, or routes that don’t make it into the routing table as another route with a better Admin Distance has won


Neighbor Logging

Provides the frequency and reason that a neighbor changes state

Strong recommendation to always have this functionality enabled

Enabled under router eigrp processeigrp log-neighbor-changes

Default behavior since 12.2(12)

Use the logging buffer to minimize potential impactEnabled globally: logging buffered 10000


70


Neighbor Logging—Demystified!

New Adjacency—Why look dear, we have a new neighborEither initial startup or recovery after a neighbor has gone down

Holding Time Expired—No EIGRP packets were seen from this neighbor for the duration of the hold time

Typically 15 seconds, though some are 180

Peer Restarted—Not my fault! The other router reset the peer and that’s where you need to look to find the reason

Retry Limit Exceeded—A reliable packet was not acknowledged after at least 16 retransmissions

(Actual number is based on the hold time, but there were at least 16)

Route Filter Change—EIGRP doesn’t refresh routes; when a filter changes that affects what is sent to the peers the neighbor is dropped to remove the old information and then it is retold with the new filter in place (Graceful Restart could minimize the impact of this!)

Apr 21 11:02:22.285: … Neighbor 40.1.24.134 (ATM1/0.2934) is up: new adjacencyApr 21 11:02:22.941: … Neighbor 40.1.16.98 (ATM1/0.1955) is down: holding time expiredApr 21 11:02:22.953: … Neighbor 40.1.7.86 (ATM1/0.872) is down: peer restartedApr 21 10:52:24.787: … Neighbor 60.1.1.2 (FastEthernet1/1) is down: retry limit exceedApr 21 11:12:42.945: … Neighbor 40.1.16.110 (ATM1/0.1963) is down: route filter changed


Event Log

The most important tool for getting a view of what’s going on in the network

Always running, separate log kept per AS

Default 500 lines (very little actually…)eigrp event-log-size <number of lines>

0 lines disables logging

If you can spare the memory (very little) increasing the size is recommended!

Read from the bottom up as new events are written on top

The log may be cleared by entering:clear ip eigrp event


71


MIB Support

Introduction of EIGRP MIB12.3(14T)

Included in images with SNMP feature base

Currently IPv4 only, but IPv6 in the works (Along with EIGRP for IPv6, 12.4(T))

Implemented Per AS, Per VPN basisAllows for granular reporting and management of EIGRP in multi AS, VPN and non-VPN networks

Sample configuration: Router(config)# snmp-server host 10.0.0.1 traps version 2c NETMANAGER eigrp

Router(config) snmp-server community EIGRP1NET1A

Router(config)# snmp-server enable traps eigrp


MIB Support

Includes two TrapseigrpRouteSIA

eigrpAuthFailure

Five Object Groups on a per VPN, per AS basisEIGRP VPN Table

EIGRP Traffic Statistics

EIGRP Topology Data

EIGRP Neighbor Data

EIGRP Interface Data

For more specifics on the objects and MIB please see the following: http://www.cisco.com/en/US/products/sw/iosswrel/ ps5207/products_feature_guide09186a00803d2d3d.html


72


MIB Support

EIGRP Traffic StatisticsAS Number

Hellos Sent/Received

Updates Sent/Received

Queries Sent/Received

Replies Sent/Received

EIGRP Topology DataDestination Net/Mask

Active State

Feasible Successors

Origin Type

Distance

Reported Distance

EIGRP Interface DataPeer Count

Reliable/Unreliable Queues

Pacing

Pending Routes

Hello Interval

EIGRP Neighbor DataPeer Address

Peer Interface

Hold Time

Up Time

SRTT/RTO

Version

And Many More...


Q and A


73


Recommended Reading

Continue your Cisco Live learning experience with further reading from Cisco Press®

Check the Recommended Reading flyer for suggested books

Available Onsite at the Cisco Company Store


Recommended Reading

ASIN: 1578701651 ISBN: 0201657732 ISBN 1587051877


74


Complete Your Online Session Evaluation

Give us your feedback and you could win fabulous prizes; winners announced daily

Receive 20 Passport points for each session evaluation you complete

Complete your session evaluation online now (open a browser through our wireless network to access our portal) or visit one of the Internet stations throughout the Convention Center

Don’t forget to activate your Cisco Live virtual account for access to all session material on-demand and return for our live virtual event in October 2008

Go to the Collaboration Zone in World of Solutions or visit www.cisco-live.com


Documents

EIGRP Deployment - Cursuri Automatica si Calculatoareandrei.clubcisco.ro/cursuri/4prc/deploying/BRKRST-2330.pdf · in the bandwidth or delay causes EIGRP to reread them or when a