Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

EIGRP traffic engineering?

I have been struggling with EIGRP metrics this week when it comes to traffic engineering.

 

Just a simple topology here, All the destination networks are held on SW1 SVI's. I am currently working with R2 and with the commands I have used it appears the the best path to network 192.168.100.0/24 is through R1, makes sense. But according to the show ip eigrp topology table thats the only path! So now I want to start making changes to links so that if the link from R2 to R1 fails, R2 can use the path of R5 > R3 > R1 to get to the networks. I have configured all eigrp AS's with "metric weights 0 0 0 1 0 0" this way the calculation is based on delay only.

Now if I change the delay of R2's fa0/0 to something crazy like 999999 then R2 will show its path through R5. But I want to know how to figure out the calculation so that the path for R2 > R5 > R3 > R1 can be a FS.

 

How can I start this process? Do I work backwards in the topology?

8 REPLIES
Hall of Fame Super Blue

StevenOn R2 can you do a "sh

-

New Member

One path: R2#show ip eigrp

One path:

 

R2#show ip eigrp topology all-links
IP-EIGRP Topology Table for AS(100)/ID(10.10.10.21)

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

P 10.10.10.8/30, 1 successors, FD is 2560, serno 1
        via Connected, FastEthernet0/1
P 10.10.10.12/30, 1 successors, FD is 5120, serno 6
        via 10.10.10.22 (5120/2560), FastEthernet0/0
        via 10.10.10.9 (7680/5120), FastEthernet0/1
P 10.10.10.0/30, 1 successors, FD is 5120, serno 3
        via 10.10.10.9 (5120/2560), FastEthernet0/1
        via 10.10.10.22 (7680/5120), FastEthernet0/0
P 192.168.100.0/24, 1 successors, FD is 130560, serno 11
        via 10.10.10.22 (130560/128000), FastEthernet0/0

P 10.10.10.4/30, 1 successors, FD is 5120, serno 4
        via 10.10.10.9 (5120/2560), FastEthernet0/1
        via 10.10.10.22 (7680/5120), FastEthernet0/0
P 10.10.10.24/30, 1 successors, FD is 5120, serno 8
        via 10.10.10.22 (5120/2560), FastEthernet0/0
P 10.10.10.16/30, 1 successors, FD is 5120, serno 7
        via 10.10.10.22 (5120/2560), FastEthernet0/0
        via 10.10.10.9 (7680/5120), FastEthernet0/1

P 10.10.10.20/30, 1 successors, FD is 2560, serno 2
        via Connected, FastEthernet0/0
P 192.168.10.0/24, 1 successors, FD is 130560, serno 9
        via 10.10.10.22 (130560/128000), FastEthernet0/0
P 192.168.11.0/24, 1 successors, FD is 130560, serno 10
        via 10.10.10.22 (130560/128000), FastEthernet0/0
P 192.168.254.0/30, 1 successors, FD is 5376, serno 13
        via 10.10.10.22 (5376/2816), FastEthernet0/0
R2#

Hall of Fame Super Blue

I think this will be

I think this will be complicated by your topology because you are seeing split horizon in effect.

The all-links conmand shows all routes received whether they are FS or not.

The issue is from R5's perspective it has three equal cost paths to 192.168.100.0/24 assuming youi have left the default delays on the interfaces and all interfaces are fast ethernet.

So R5 receives a route from R2 to 192.168.100.0/24 and it uses R2 as one of it's paths. R5 also receives the same route advertisements from R3 and R4 but it cannot advertise them to R2 because it is using R2 as a next hop for that network.

So split horizon stops it advertsing that route.

Note this should also apply to R3 and R4.

In addition you say you want R2 to use R5 -> R3 etc. but even if we didn't face split horizon R5 would actually use R3 and R4 unless you manipulated the metrics there as well.

So it may not be the best topology to use to for influencing metrics although i would have to sit down and work it all out to make sure.

In terms of working out the delays EIGRP sums all the delays of the outgoing interfaces ie. 

R2 -> R1 -> R7 -> SW1

1) SW1 advertise the route with the delay included in the EIGRP route advertisement (the delay here is the delay to the SVI)

2) R7 receives the route advertisement and adds the delay of the interface used to connect to SW1 to the delay in the EIGRP route advertisement to work out the locally calculated distance.

3) R7 then advertises the route to R1 with the sum of the delays ie. the delay of it's interface that connects to SW1 + the delay advertised by SW1

3) R1 then adds the delay of it's interface to the delay value received in the EIGRP route advertisement to work out it's locally calculated distance. It then sends a route advertisement to R2 which again contains a delay value with is the sum of delays from R1 -> R7 -> SW1

4) R2 adds it's own interface delay to that delay value to calculate the distance.

So you need to work out the delays like that.

For a route to be a FS it's advertised distance must be less than the FD so you need R5 to advertise a distance that is less than the FD on R2.

Note here we are assuming the FD on R2 is via the direct path to R1 -> R7 -> SW1

But you also need to make sure that once R2 has calculated the distance via R5 it is greater than it's current FD via R1 or it will choose R5 as the path ie

R2's FD must be less than R5s advertised distance but greater than  R2's locally calculated distance via R5.

Like i say though with your toplogy things may not work out correctly due to other things but you can always experiment and you will probably learn a fair bit.

Hopefully that makes some sense.

I'll check back tomorrow if you need any futher clarification and nobody else responds.

Finally EIGRP terminology is much misused in terms of FD, FS and how these things are worked out etc so if Peter Paluch sees this he may well need to correct some of what i have said if i have made any glaring errors.

Peter, if you do see this please feel free to join in.

Jon

 

 

New Member

SW1 is running OSPF and

SW1 is running OSPF and advertising networks to R7, R7 is then running OSPF and EIGRP and redistributing OSPF into EIGRP.

So what command do I use and what I am looking for to see what the delay is from R7 to R1?

What if I was to disable split horizon on R5?

Hall of Fame Super Blue

StevenThe delay is on the

Steven

The delay is on the interface ie "sh int <type/num>".

You are not looking at the delay from R7 to R1, you are looking at the delay from R1 to R7.

The delay used in the calculation is the delay of the interface on which the route advertisement was received.

You can try disabling split horizon althouh it may well create routing loops.

Difficult to say without something to test with.

Don't forget as well that you need to multiple everything by 256 to match the metrics EIGRP is showing.

What you should be able to do is using the delays work out the metrics displayed in the topology table as you move from one router to the other.

Obviously you should work backwards. As you are redistributing on R7 you must be assigning metrics there so you know what you are starting with.

Jon

New Member

WHOA this just made sense to

WHOA this just made sense to me:

 

R7:

router eigrp 100
 redistribute ospf 100 metric 1 1 1 1 1
 passive-interface FastEthernet0/1
 network 10.10.10.26 0.0.0.0
 metric weights 0 0 0 1 0 0
 no auto-summary
!
router ospf 100
 log-adjacency-changes
 passive-interface FastEthernet0/0
 network 192.168.254.2 0.0.0.0 area 0

 

When I add the metric values when redistributing ospf those are the K values...I define the delay in this command. so if I put 1, its actually 1*256?

 

So the delay is always the egress interface towards the destination?

New Member

So yes on R7 when I do a show

So yes on R7 when I do a show ip eigrp topology all-links I see that the FD to 192.168.x.x networks is 256. Cool. And really it doesnt matter what this says because its the only link to get to these networks anyway right?

Hall of Fame Super Blue

So the delay is always the

So the delay is always the egress interface towards the destination?

Well yes and no.

Bear in mind that from R2s perspective it has an interface connected to both R5 and R1.

On R2 the actual interface used to get to 192.168.100.0/24 is the one connecting to R1 but the delay on that interface is only used to calculate the metric of the route via R1.

For R2 to calculate the metric of the route via R5 it has to use the delay on the interface connecting R2 to R5.

On R7 there is only one link to get to those network yes so in terms of the topology table it doesn't matter if that is what you mean.

Jon

956
Views
0
Helpful
8
Replies
CreatePlease login to create content