11-24-2012 08:53 AM - edited 03-04-2019 06:13 PM
Hi all,
Seeing following traceroute where the destination ip appears as first hop and then it goes out to internet . It should have stopped after first hop. What is happening here ? any ideas?
Tracing route to testsite[120.101.0.167]
over a maximum of 30 hops:
1 6 ms 1 ms 1 ms cncotbncfi [120.101.0.167]
2 9 ms 10 ms 8 ms 10.6.160.1
3 13 ms 8 ms 7 ms 10.7.160.0
4 10 ms 9 ms 6 ms 60.170.83.41
5 * * * Request timed out.
6 * * * Request
Why our the next hope IP is not showing ?
Thanks,
Hari
11-24-2012 09:55 AM
Maybe you have some policy based routing in the next hop.
Can you paste the config of the router.
Sent from Cisco Technical Support Android App
11-24-2012 05:13 PM
Thanks for the update. We have PBR on that interface to set next hop as another core device.
Does that mean that ?
1. The destination is always shown as first HOP?
2. Next hop wont be correctly shown ?
Thanks,
H
11-24-2012 05:28 PM
Hari
Based on what you have posted in the first post the issue is that the first hop device did not send the expected response. If it had sent the expected response then your traceroute should have ended at the first hop. But if that device did not send the expected response then the traceroute continues to the second hop and so on.
If you have PBR configured on the incoming interface of the first hop router, as indicated in your second post, then I can see that it would affect the second (and following hops) in the traceroute. I am not convinced that PBR necessarily explains the behavior at the first hop.
The behavior at the first hop seems to indicate that this device does not regard 120.101.0.167 as a locally connected interface. Can you tell us a bit more about that device (what kind of device is it, what are the addresses and subnets of its interfaces, perhaps the configuration of the interface that connects to your device)?
Does the interface of your device belong to the 120.101.0 subnet?
HTH
Rick
11-24-2012 07:48 PM
pls post a sanitised version of your config so that we can help. if you want to try yoursel insert an acl on top in the pbr rule not to match the gateway address. take care while doing in production environment. try to avoid pbr as much as possible.
rgds/dp
11-25-2012 11:34 PM
Please see the below. Does that PBR applied on the interface cause this behaviour ?
~~
inr g0/1/5.1
encapsulation dot1q 1 native
Ip address 192.168.1.1 255.255.255.0
ip policy route-map test
route-map test prmit 10
set ip next-hop 10.6.160.1
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