trace through ISP via BGP

[brooklynheight]

I am trying to traceroute from one remote site to another remote site--A to Z

z router (destination of trace)

gig 0/0 with an IP address of 192.168.255.25----connected to our ISP (using bgp)

(bgp neighbor shows 192.168.255.26) AS XXXX

gig 0/1 with an ip address of 192.168.255.251--to our local lan

however when i trace route from router A to the .251 address (local lan port) I get this output

5 192.168.255.25 [AS XXXX] 44 msec * 40 msec <------last hop than trace stops (different IP of trace)

router A1#

but when i trace .25 address....(which is connected to our ISP).i get this output

5 192.168.255.25 [AS XXXX] 44 msec 52 msec 40 msec---again destinatioin of trace but trace continues

6 * * *

7 * * *

8 * * *

9 * * *

10 * * *

11 * * *

why is this?

1-why is the first trace not resolving at the .251 address

2. why is the 2nd trace not stoping at the destination?

[brooklynheight]

.

[marikakis]

Hello,

The traceroute reports at each hop the IP address of the interface through which the probe packet actually entered the machine. So if you trace from "outside" towards your lan and packet enters the Z router via the ISP attached gig 0/0, the trace is considered complete (the IP address .251 is directly connected to the same machine) and the ISP connection IP address is reported (because is the entry point from the initiating machine's point of view to the Z router that also "owns" the ultimate destination).

This means that if you want to check if your lan is ok from ouside, you would have to choose a destination IP address on the lan that is not the Z router's IP address on the lan, so that the packet leaves the Z router via the lan interface and attempts to reach a host also attached there. Try to traceroute from "outside" towards a host on the lan and see what happens.

I am not sure why the second trace does not stop at the .25 IP address. For the traceroute to be considered complete (which means the initiating machine stops sending probes with increasing TTL towards the destination), the destination must send an ICMP Port Unreachable message back to the probing machine (instead of the ICMP Time Exceeded messages from the hops before the destination). My guess would be that for some reason (e.g. interface configuration)interface connected to the ISP is not sending unreachable messages back when probed as the ultimate destination (or rate-limits those messages), while has no problem sending back time exceeded messages (or unreachables on behalf of the lan interface). That is just a guess about the second trace, haven't really thought about it well, can't be sure, depends on your general setup and the configuration of the interfaces of the Z router.

Kind Regards,

M.

[marikakis]

It would be helpful if you supplied complete trace output, just to eliminate wild guesses. I was also wondering if there is anything in your setup that is protective against icmp unreachable messages. You could also try to initiate priviledged traces with different source addresses and check if you get different behavior.

Kind Regards,

M.