A routing question

[TimOnCisco]

Hi I’m studying towards the CCNA exam and an currently working through Ch 4 of the ICND 2 book.

I’ve created a simulated network, the significant portion of which is shown in the above diagram.  There are other switches and hosts, but no other routers.  The routers are using EIGRP.  No configuration has been done to modify route metrics/bandwidths, so each link should be considered equal.  I would therefore expect two primary routes between H1 and H2:

H1 to H2: R1-R6-R3-R4 or R1-R2-R5-R4.

H2 to H1: R4-R3-R6-R1 or R4-R5-R2-R1.

These are shown by the red and green lines in the diagram below:

I used the show ip route <ip address> command on R1 for H2's ip and on R4 for H1's ip.  In both cases each router listed two possible routes/connections (as I would expect).  In each case the first connection listed has an asterisk next to it; which I presume means it is the preferred route to that IP for that router?  R1 lists R6 as the preferred route, whilst R4 lists R3 (the first of the two possible paths for each route I speculate above).

To confirm my expectations, I used the tracert command from each of the hosts.  Unfortunately this is where things seemed to fall apart.

H1 reports R1-R6-R5-R4-H2 whilst H2 reports R4-R5-R6-R1-H1.

I’m guessing here, but I think that one possible cause for this is because when R4 receives the ICMP echo request from H1’s tracert command, (R1-R6-R3) it returns the ICMP echo reply via R5-R2 to R1. This does not, however, explain why R3 is missing from the tracert output.

So, why R3 didn’t respond to the tracert command?  After R6, the best route to R4 is R3, with an alternative route via R2 and R5.  Given, it is possible to reach R3 via R2-R5, but it is not possible to reach R5 from R6 without going via R1, R2 or R3 (all of which add to the route), why the jump from R6 directly to R5?

The output of the H2 tracert command is even more perplexing, it hasn’t even started off following the expected route!  I suspect, however, that an explanation for the behaviour of the H1 tracert command will also cover the behaviour of the H2 tracert command.

I’m hoping that someone can provide some enlightenment.

Tim

[smitesh kharecha · Accepted solution]

Hi Tim,

By default EIGRP can load balace across mutiple equal paths...

In your case you have 2 equal cost paths, which are R1-R2-R5-R4 and another as R1-R6-R3-R4...

Now first thing, when you check on R1, you see two equal cost path in your routing table of H2 ( as you expected) and little asterix sign in front of one route. That asterix is nothing but only indicating that at that moment it is forwarding traffic via that path.

Secondly, if you try to trace H2 from R1, you will see multiple host entries on first and second hop.

Just try tracing the H2 from R1 and then you can see EIGRP load-balancing in action.

Also, just to confirm the same, you can enable "debug ip icmp" on both R1 and R4...

HTH,

Smitesh

PS: Please rate helpful posts...

[smitesh kharecha]

Also, your CEF ( by default enable ) will come into the picture.

By default CEF will load-balace the packet based on Source and Destination IP.

Since, in your case Source IP and Destination IP are not changing, it will always transverse one path ( best as selected by CEF table).

HTH,

Smitesh

[TimOnCisco]

Smitesh,

Thank you for taking the time to respond.

Ahhh, think I know what you mean about the load-balancing.  Although since restarting the simulation the apparent anomalies have changed, the effect is essentially the same.

I set up H1 to run a continuous ping to H2, then ran the the traceroute command from R1 to H2 a few times.  Here are a few of the outputs, which I have annoted to help me analyse them:

Tracing the route to 192.168.1.67 (H2)

  1   192.168.1.193   6 msec    7 msec    5 msec    R2

  2   192.168.1.222   5 msec    11 msec   8 msec    R3

  3   192.168.1.209   7 msec    12 msec   19 msec   R4 to R3

  4   192.168.1.67    10 msec   24 msec   23 msec   H2

Tracing the route to 192.168.1.67

  1   192.168.1.198   11 msec   4 msec    6 msec    R6

  2   192.168.1.222   6 msec    8 msec    10 msec   R3

  3   192.168.1.209   14 msec   10 msec   20 msec   R4 to R3

  4   192.168.1.67    18 msec   13 msec   21 msec   H2

Tracing the route to 192.168.1.67

  1   192.168.1.193   38 msec   4 msec    3 msec    R2

  2   192.168.1.222   7 msec    15 msec   12 msec   R3

  3   192.168.1.214   27 msec   8 msec    12 msec   R4 to R5

  4   192.168.1.67    21 msec   13 msec   29 msec   H2

For some reason echo replies from R3 are consistent, although I suppose that it would only be a matter of time before R5 popped up in its place?

Is this what you meant when you said that I would see "multiple host entries on the first and second hops".

I can see now that the load-balancing is taking place between each of the ICMP echo requests, which is causing the appearance of anomalies.  I had been under the illusion that load-balancing wouldn't come into the equation for such small data quantities.

I've converted the simulation to run in RIP v2 as well, and received the same results (RIP will automatically load balance too, or is that just a Cisco feature?).  I also added some more PCs to the ends of the LANs, set them up using continuous pings and then carried out repeated tracert commands from another PC.  After a running the command a few times I started to see variation in the reports; until then they had always reported the same sequence.

Thank you again for replying.  The exercise and your response have been most helpful.

Regards,

Tim