Jorge

I agree with you that what we are seeing is not a routing problem. I disagree with your statement that :"EIGRP uses round-robin for load balancing". EIGRP does not do the load balancing. EIGRP discovers routes and places them into the routing table. It is another process that does the load balancing (round-robin or otherwise).

What we are really seeing here is the effect of process switched traffic. Any traffic that is generated by the router is inherently process switched. And process switched traffic will always round robin between available paths to the destination.

HTH

Rick

I am sorry to up this old post. I have same problem as dimzaaaa. Now I understand the the way traceroute works in the case which has more than one paths to the destination. But the problem is that I cannot see the change when doing traceroute command serveral times. What's wrong with me?

Message was edited by: Cong Tran Minh

I do not understand what you are asking. You say that you do not see changes when you do traceroute several times. But you do not show us anything, so how can we help you?

Perhaps if you would post the output of your several tiems of doing traceroute then we might be able to be more helpful.

HTH

Rick

I am sorry, because of the first time I posted in this forum.

I mean that the output of traceroute command like this:

1.192.168.13.3

   192.168.12.2

   192.168.13.3

2.192.168.34.4

   192.168.23.4 *

Completed!

1.192.168.13.3

   192.168.12.2

   192.168.13.3

2.192.168.34.4

   192.168.23.4 *

Completed!

No changes like Mr Jorge.Calvo said. I think there is a problem with loadbalancing model. I put everythings in default

The "show ip route" command also have two paths to reach the destination. Do I need more commnads for round-robin mode to work?

Thanks

Hi All

The Routing protocol supports load-balancing but the actual load-balancing mechanism is controlled by the routers's switching process as precisely mentioned by Richards earlier.

Default is the Fast-Switching in current IOS with CEF enabled and that leads to per-flow also popularly known as per-destination load-balaning which means between a Source-Destination Pair always the same Link will be used. So if we do multiple traces between same source-destination we would always see same path to be followed and no round-robin.

Other option for load-balancing is per-packet load-balancing which is CPU intensive and is done via process-switching and disabling CEF and ip route-cache under interface config. The effect of this is that router resorts back to legacy process switching whereby the whole frame is parsed for each packet being switches and thus packets are sent in round-robin over the available equal cost links...

Hope this helps to answer the queries.

Regards

Varma

Varma

You have presented a good explanation of the switching process for transit traffic (traffic which is generated outside of the router and is received on one router interface and is forwarded out another router interface). But this question is about traffic which is generated by the router itself (the traceroute from the router to some external address). And as I explained in a previous post in this thread, traffic generated by the router is always processed switched.

In this new part of the discussion we can clearly see the effects of process switching (and that there are 2 equal cost routes to the destination) in this output:

1.192.168.13.3

   192.168.12.2

   192.168.13.3

The poster did not include the traceroute command so we do not know what was the destination address, and we do not know whether there were any parameters in the traceroute command which might affect how traffic was forwarded. But clearly 192.168.13.3 and 192.168.12.2 are both next hop addresses on the path to the destination.

I do not have a good explanation about why both traceroute outputs have the same pattern of next hop addresses. If 192.168.13.3 was the first next hop in the first traceroute then I would expect 192.168.12.2 to be the first next hop in the next traceroute. I wonder if there was some other traffic to that destination address in between the 2 traceroute outputs. If the new poster wants to investigate this issue further I would suggest this as an experiment:

- terminal monitor

- debug ip packet

- traceroute

- traceroute

- undeb all

- terminal no monitor

then post all of the output generated.

If there is lots of traffic flowing through the router there might be a lot of debug output which complicates understanding what is going on. If that is the case then I would suggest modifying the debug to use an access list to select traffic to be reported. It might look something like this:

access-list <1nn> permit ip any host 

debug ip packet <1nn>

where <1nn> is an available number for an extended IP access list (the range is 100 to 199) and where is the destination ip address.

HTH

Rick

Thank you Richard!

I learn alot from your post.

I has been use the command "no ip cef" and see how round-robin work by using show ip route 4.4.4.4. The wilcard (*) is up and down each time issue the command "ping 4.4.4.4 source loopback 0 repeat 1"

This is output of some command after Issued "no ip cef"

ping 4.4.4.4 source loopback 0 repeat 10

*Mar  1 03:44:53.631: IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), routed via RIB

*Mar  1 03:44:53.635: IP: s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), len 100, sending

*Mar  1 03:44:53.655: IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/1), routed via RIB

*Mar  1 03:44:53.655: IP: s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/1), len 100, sending

*Mar  1 03:44:53.723: IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), routed via RIB

*Mar  1 03:44:53.723: IP: s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), len 100, sending

traceroute 4.4.4.4 source loopback 0 (first time)

1 192.168.12.2 12 msec

    192.168.13.3 68 msec

    192.168.12.2 28 msec

  2 192.168.34.4 12 msec

    192.168.24.4 32 msec

Complete!

*Mar  1 03:53:48.595: IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), routed via RIB

*Mar  1 03:53:48.595: IP: s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), len 28, sending

*Mar  1 03:53:48.631: IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/1), routed via RIB

*Mar  1 03:53:48.635: IP: s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/1), len 28, sending

*Mar  1 03:53:48.715: IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), routed via RIB

*Mar  1 03:53:48.719: IP: s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), len 28, sending

*Mar  1 03:53:48.731: IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/1), routed via RIB

traceroute 4.4.4.4 source loopback 0 (second time)

1 192.168.12.2 12 msec

    192.168.13.3 68 msec

    192.168.12.2 28 msec

  2 192.168.34.4 12 msec

    192.168.24.4 32 msec

Complete!

*Mar  1 03:53:56.291: IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), routed via RIB

*Mar  1 03:53:56.291: IP: s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), len 28, sending

*Mar  1 03:53:56.355: IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/1), routed via RIB

*Mar  1 03:53:56.359: IP: s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/1), len 28, sending

*Mar  1 03:53:56.395: IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), routed via RIB

*Mar  1 03:53:56.399: IP: s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), len 28, sending

I may see how round-robin mode work through debug info of ping and traceroute. But the output of traceroute is not what I expected:

1 192.168.12.2 12 msec

    192.168.13.3 68 msec

    192.168.12.2 28 msec

  2 192.168.34.4 12 msec

    192.168.24.4 32 msec

and

1 192.168.13.3 40 msec

    192.168.12.2 60 msec

    192.168.13.3 16 msec

  2 192.168.24.4 68 msec

    192.168.34.4 48 msec

One more thing, I use ping and traceroute with source parameter, do this like as traffic generated by router itself or transit traffic?

I am glad that using debug has helped to show what is going on.

It does not really matter whether you specify source address or just let the router use its default. When you execute traceroute on the router then the packets are generated by the router and are not transit traffic.

The only way to get transit traffic is to have some other device generate the packets and send them to the router to forward toward the destination.

HTH

Rick

Sorry I have more questions. In this lab I add more 2 routers. The lab now already looks like transit traffic.

First: On R2  "debug ip packet 101" (access-list to permit ip any host 6.6.6.6)

                    "no ip cef"

        On R1, "traceroute 6.6.6.6 source loopback 0"    two times              

                    1 192.168.12.2 36 msec 48 msec 16 msec

                    2 192.168.23.3 12 msec 40 msec 12 msec

                    3 192.168.35.5 44 msec 44 msec 12 msec

                    4 192.168.56.6 108 msec *  116 msec

               Complete!

                    1 192.168.12.2 36 msec 48 msec 16 msec

                    2 192.168.23.3 12 msec 40 msec 12 msec

                    3 192.168.35.5 44 msec 44 msec 12 msec

                    4 192.168.56.6 108 msec *  116 msec

               Complete!

         Jump to R2: no debug output

               But on R2 when I put "debug ip packet". After traceroute again, debug output:  

*Mar  1 02:07:13.439: IP: tableid=0, s=192.168.12.2 (local), d=1.1.1.1 (FastEthernet1/0), routed via RIB

*Mar  1 02:07:13.439: IP: s=192.168.12.2 (local), d=1.1.1.1 (FastEthernet1/0), len 56, sending

*Mar  1 02:07:13.503: IP: tableid=0, s=192.168.12.2 (local), d=1.1.1.1 (FastEthernet1/0), routed via RIB

*Mar  1 02:07:13.503: IP: s=192.168.12.2 (local), d=1.1.1.1 (FastEthernet1/0), len 56, sending

*Mar  1 02:07:13.519: IP: tableid=0, s=192.168.12.2 (local), d=1.1.1.1 (FastEthernet1/0), routed via RIB

*Mar  1 02:07:13.519: IP: s=192.168.12.2 (local), d=1.1.1.1 (FastEthernet1/0), len 56, sending

I don't understand these debug info

          Additional, when I "ping 6.6.6.6 source loopback 0" no debug info output at all.

Plz tell me why there is no debug output when debug ip packet with access-list?

Second: when  I put more command in R2 "no ip route-cache " in subcommand of  interface fa0/0 and fa0/1 not interface fa1/0, the result go as I  expected.   

          On R1, "ping 6.6.6.6 source loopback 0"

          The output on R2:                 

*Mar  1 02:38:37.883: IP: tableid=0, s=1.1.1.1 (FastEthernet1/0), d=6.6.6.6 (FastEthernet0/0), routed via RIB

*Mar  1 02:38:37.883: IP: s=1.1.1.1 (FastEthernet1/0), d=6.6.6.6 (FastEthernet0/0), g=192.168.23.3, len 100, forward

*Mar  1 02:38:37.983: IP: tableid=0, s=1.1.1.1 (FastEthernet1/0), d=6.6.6.6 (FastEthernet0/1), routed via RIB

*Mar  1 02:38:37.983: IP: s=1.1.1.1 (FastEthernet1/0), d=6.6.6.6 (FastEthernet0/1), g=192.168.24.4, len 100, forward

*Mar  1 02:38:38.035: IP: tableid=0, s=1.1.1.1 (FastEthernet1/0), d=6.6.6.6 (FastEthernet0/0), routed via RIB

*Mar  1 02:38:38.035: IP: s=1.1.1.1 (FastEthernet1/0), d=6.6.6.6 (FastEthernet0/0), g=192.168.23.3, len 100, forward

          On R1 "traceroute 6.6.6.6 source loopback 0" two times

  1 192.168.12.2 20 msec 68 msec 8 msec

  2 192.168.24.4 72 msec

    192.168.23.3 28 msec

    192.168.24.4 32 msec

  3 192.168.35.5 116 msec

    192.168.45.5 12 msec

    192.168.35.5 72 msec

  4 192.168.56.6 80 msec *  136 msec

  1 192.168.12.2 32 msec 48 msec 32 msec

  2 192.168.23.3 24 msec

    192.168.24.4 28 msec

    192.168.23.3 44 msec

  3 192.168.45.5 52 msec

    192.168.35.5 16 msec

    192.168.45.5 12 msec

  4 192.168.56.6 88 msec *  96 msec

           Round-robin works well

Why I need more "no ip route-cache" command in specified interface subcommand?

You may need to use no ip route-cache to get debug output. The reason for this is that debug is a process that runs in the router CPU and it can only report of traffic that is routed by the router CPU. If route cache/fast switching/CEF/hardware switching is forwarding packets without using the CPU then debug will not see or report those packets.

HTH

Rick