Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Different traceroute to same destination when using different source

I've got two 64k pvc's that parallel each other running eigrp. When I telnet to the remote router from the local router, I get a trace that shows:

Tracing the route to 208.234.171.23

1 10.203.131.110 64 msec

10.203.141.110 48 msec

10.203.131.110 57 msec

2 10.30.52.3 44 msec 60 msec 48 msec

When I telnet to the remote router from a host on my local network, I get this trace to the same host.

Tracing the route to 208.234.171.23

1 10.203.141.110 52 msec 48 msec 48 msec

2 10.30.52.3 48 msec 52 msec 68 msec

Notice the parallel routes don't show up when I telnet from a host instead of the local router. The only thing that is different is the source address.

Why do I get two different traces? Is EIGRP still load balancing between the two links?

2 REPLIES
Silver

Re: Different traceroute to same destination when using differen

Might be that one of your BW statements on one side do not match so you are only load balancing in one direction over your 64K pipes.

Might do a "show ip eigrp topology 10.30.52.3 <---- put network here not host addr and mask. ensure EIGRP sees all paths as equal.

BW is local and delay is added from end to end. So check your BW statements to ensure that your 10.203.141.110 hop is not setup with a default serial BW of 1544K.

Might also be your switching path as well... Cef does use source destination pairs to load balance by default. So this might be on your router as well. (shot in the dark on that one)

Hope this helps,

Don

New Member

Re: Different traceroute to same destination when using differen

Thanks for the help!

The eigrp topology looks right to me. BW statements were already matching @ 64k each. Here is the bizaar part. I get these wacky traceroutes only when I telnet to the router from a NAT'ed source address. If I telnet to the router and perform the trace outside of the firewall, I get the correct trace showing me multiple routes at the first hop due to the parallel circuits.

When I telnet to the router from a host inside the firewall, the source host address gets NAT'ed. The traces don't show the first hop having multiple paths due to the parallel equal cost circuits. Go figure. IOS bug?

Why would it matter where I telnet to the router from? Does it look at the source address for some reason before tracing to a specific network?

143
Views
0
Helpful
2
Replies