extended trace

[shiva_ial]

hi ,

when i issue an extended trace for destination i am getting output like

this

Tracing the route to 10.128.10.10

1 10.132.252.13 0 msec

10.132.253.30 4 msec

10.132.252.13 0 msec

2 10.132.253.33 4 msec

10.132.253.22 0 msec

10.132.253.33 4 msec

3 10.143.252.130 0 msec 4 msec 4 msec

4 10.143.252.66 8 msec 12 msec 8 msec

5 10.128.10.10 12 msec 12 msec 8 msec

is the traceroute mean there is loop in between 10.132.252.13 & 10.132.253.30

my understanding is there is no loop,since ospf cost to destination is same with my

2 links to destination router is trying to load balance

is it right?

ospf cost to destination is same for both the path

[asanlu1977]

understand, everything is ok since hop nº 2 is totally different from hop nº 1. This means the path the packet goes through, but nothing like a loop.

rgds

[royalblues]

This generally happens when you have multiple links to a destination and is not a problem

If you do a trace/ping from the router, the packet is always process-switched and hence is loadbalanced on a per packet basis as apposed to Per destination

You might not see the same results when you do a trace from any inside hosts

HTH

Narayan

[shiva_ial]

narayanan,

by the last line you mean to say pc connected

to local lan on the router will not have as above

if so how pls explain

[royalblues]

Shiva,

As i said, packets that are localy generated are always process switched and by default load balancing is done on a per packet basis.

On the other hand traffic passing through the router is CEF switched and the default load balancing method is per destination.

This is the reason i asked him to do a trace to simulate a traffic flow through the router rather than from the router

HTH

Narayan

[bvsnarayana03 · Accepted solution]

Trace sends 3 packets eachtime with TTL value starting from 0, & increments the TTL value till the time the pkt has actually reached the destination.

Its been observed that when there are multiple paths to the destination, then each trace pkt takes a separate alternate path to the destination.

In your case, seems like there are 2 alternate paths at each hop & thats why 1st pkt goes to primary 1st hop (10.132.252.13 ), 2nd pkt goes to redundant 1st hop (10.132.253.30) & 3rd pkt again goes to pri 1st hop(252.13-since there are no more alt paths). This repeats for 2nd hop as well.

hope that clarifies.

pls rate all helpful posts.

[cindylee27]

Hi Narayan,

I always have this question in minda about multiple links.

Can i say that if there are 2 links A and B a traffic can go through , the traffics can actually travel through A and then handshake traffic(coming back) can be to B?

Not necessary must be same link A where the traffic travels?

[shiva_ial]

thanks narayanan,

your answer is ok looking the probelm at very high level

still confusion at second hop taken by first packet will u pls explain the second hop instance in trace also

[bvsnarayana03]

Thanks shiva.

What i mentioned is, after having a loadbalancing at the 1st hop there is another redundant path at hop 2 (10.132.253.33 & 22) to reach the 3rd hop i.e. 10.143.252.130. So at hop 2 again the three trace pkts will be loadbalance among the redundant path towards hop 3.

hope that clarifies.

pls rate all helpful posts.