09-01-2010 09:33 PM - edited 03-05-2019 06:43 AM
=>Routing Protocol in Question EIGRP.
=>Two equal metric routes for destination A(through R1 and R2-SVIs on two upstream 6500s)
e.g. Destination A=10.100.100.1
R1(SVI 1)=172.16.1.1
R2(SVI 2)=172.16.10.1
<Show IP Route> excerpt example for the destination IP 10.100.100.1:
D EX 10.100.100.0/29 [170/3400448] via 172.16.1.1 Vlan11
[170/3400448] via 172.16.10.1 Vlan111
=>Traceroute Output example:
tracing to 10.100.100.1
1. 172.16.1.1
172.16.10.1
172.16.1.1
2.(entries on #2 and #3 are Irrelevant or just in place to show destination is beyond directly connected 6500 MLSs)
192.168.50.1
3. 192.168.75.1
4.10.100.100.1(Destination)
Complete
=>5 MILLION DOLLAR OR 5 PENY QUESTION depending on subject:
Looking at #1 of Traceroute Output, is the output that alternates between 1.1=>10.1=>1.1 normal granted the two routes are "equal metric routes for the same routing procotol in use" or is that "round robin behavior" indicative of a routing problem?
09-02-2010 12:02 AM
Hello,
What can be seen in hop #1 is not a routing problem. It is the way a tracerouter shows the two equal paths. It will list you both paths first (172.16.1.1 & 172.16.10.1) and the third line shows the chosen path (172.16.1.1).
Please note that EIGRP uses round-robin for load balancing so, if you repeat the traceroute several times you will how the output wil alternate between:
1. 172.16.1.1
172.16.10.1
172.16.1.1
and
1. 172.16.10.1
172.16.1.1
172.16.10.1
Hope this helps.
09-02-2010 06:32 PM
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
10-24-2011 01:48 AM
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
10-24-2011 10:44 AM
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
10-24-2011 07:03 PM
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
10-24-2011 07:50 PM
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
10-24-2011 08:37 PM
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
HTH
Rick
10-25-2011 12:16 AM
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?
10-25-2011 09:38 AM
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
10-25-2011 09:58 PM
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?
10-26-2011 09:53 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide