EIGRP, strange Costs GNS3

These GNS3 Emulated EIGRP route costs do not make sense to me as they seam inefficient.
Are these costs correct and how would I optimize this routing setup?
Why would the R3 to R4 network not be accessed through the faster left network?

Update: R1-R6 is 100M and R1-R2-R3 also has faster 8M links, but eigrp still only lists R4's route through the R5 path with 10M ethernet and then T1 serial from R4 to R5.

(just a linear loop, screenshot in reply below)
R1 - R2 - R3 - R4 - R5
\........................ /
.\...................... /
..\.................... /
...

All routers are the same model C3725 with dual FE and one WIC-2t.

R1 to R5 are connected together with serial links. R1-R3 have clock rate to 8000000 and bandwidth to 8000. R4 to R5, default T1 clock rate/bandwidth

R1 to R6, 100 FastEthernet
R6 to R5, 10 Ethernet

R6#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 6 subnets
C 172.16.50.0 is directly connected, FastEthernet0/1
D 172.16.40.0 [90/2195456] via 172.16.50.1, 00:24:51, FastEthernet0/1
D 172.16.30.0 [90/2707456] via 172.16.50.1, 00:24:51, FastEthernet0/1
D 172.16.20.0 [90/1369600] via 172.16.0.1, 00:24:51, FastEthernet0/0
D 172.16.10.0 [90/857600] via 172.16.0.1, 00:24:51, FastEthernet0/0
C 172.16.0.0 is directly connected, FastEthernet0/0
R6#

resetting all serial links to default and all FA to FA speed yields the symmetrical routing table that would be expected.
R6#show ip route eigrp
172.16.0.0/24 is subnetted, 6 subnets
D 172.16.40.0 [90/2195456] via 172.16.50.1, 00:00:18, FastEthernet0/1
D 172.16.30.0 [90/2707456] via 172.16.50.1, 00:00:18, FastEthernet0/1
D 172.16.20.0 [90/2707456] via 172.16.0.1, 00:00:18, FastEthernet0/0
D 172.16.10.0 [90/2195456] via 172.16.0.1, 00:00:18, FastEthernet0/0

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

pham0329

Can you post a picture of the topology, including the networks? It's a little confusing to try and figure out the topology from your post. From my experience, GNS3 does a perfect job calculating the metric in any routing protocol.

On whatever router you're having issues with, you can do a show ip eigrp topology subnet_number to get detailed information about the route. Or you can do show ip eigrp topology all links

smcyclist

Sure Here is a diagram:
(paste)
Py8nJzc3NxcZHkGGdnZ1dXVw8Pj2PHjp08eTIoKCg8PDwuLi49Pf3OnTv5+fmvXr1i+wUBAMvQjgIAAABSChkFAAAApA7aUQAAAEBKIaMAAACA1EE7CgAAAEgpZBQAAACQOmhHAQAAACmFjAIAAABSJzM94f+M1tsVIrmLewAAAABJRU5ErkJggg==

Py8nJzc3NxcZHkGGdnZ1dXVw8Pj2PHjp08eTIoKCg8PDwuLi49Pf3OnTv5+fmvXr1i+wUBAMvQjgIAAABSChkFAAAApA7aUQAAAEBKIaMAAACA1EE7CgAAAEgpZBQAAACQOmhHAQAAACmFjAIAAABSJzM94f+M1tsVIrmLewAAAABJRU5ErkJggg==

rakem

I have had some issues with EIGRP and costs in GNS3... Seems to be a bit buggy.

Trying clearing the EIGRP processes, that should fix it, but you'll need to do it every time you make a metric change.

Forsaken_GA

The thing to keep in mind with EIGRP metrics is that the lowest bandwidth on the path is used in the metric calculation. So if you've got one router with 100m link to another router, and that second router has an 8 meg link to a third router, the 100m link is essentially useless, the bandwidth will be calculated with the 8meg value. So at that point, delay becomes the deciding factor. Going from R6 to R4 has less links involved, therefore less delay (given all of your top routers are connected together through 8 meg links, the bandwidth calc is static), so that's why it's going right.

Looking at your routing table, it looks like you have an additional link between R1 and R6 (I'm assuming that 172.16.10.0 is R1). R1 isn't showing as directly connected, as it would appear to be in your diagram, so that tells me there's another link between the two of them. So your route to R3 through R1 has one more hop, therefore more delay, than if it goes through R5.

If R1 and R6 were directly connected, you'd likely see it doing load balancing for the route to R3.

if you want all traffic to go via R1 instead, increase the delay on the link between R6 and R5, that should force everything to take the right network.