Problem Tracing to Router

lamav · ‎10-17-2008

Folks:

Check out this trace:

C:\Documents and Settings\shakimi>tracert 10.34.16.205

1 <1 ms <1 ms <1 ms 10.36.244.251

2 <1 ms <1 ms <1 ms 10.36.253.249

3 <1 ms <1 ms <1 ms 10.36.29.245

4 <1 ms <1 ms <1 ms 10.36.29.226

5 <1 ms <1 ms <1 ms 10.36.125.243

6 1 ms 1 ms 1 ms 68.136.146.229

7 23 ms 23 ms 23 ms 10.34.16.205

The last hop is the server itself, but the hop just before it is the service providers PE. How come the CE on the other end of the MPLS cloud doesnt appear in the trace?

Im trying to get to the client router on the other end of the MPLS cloud -- the router that hosts this server's subnet, but with no hop info, I dont know what IP address to Telnet to.

Summary of trace path: internal routers <----> CE<---->PE (provider cloud)<----->server..

Thanks

Jon Marshall · ‎10-17-2008

Hi Victor

Is there definitely a separate device or could the PE also be acting as the CE ?

Do you know the subnet mask of the server subnet. Often there is a convention for these things ie. use the first address out of the subnet range for router interface or the last.

Just a thought.

Jon

lamav · ‎10-17-2008

Jon:

Good thoughts, buddy, but no dice.

And no, the PE is not acting as the CE.

I wonder if it has something to do with the way the static NAT translations are configured on the distant end router.

The server address (10.34.16.205) is really the outside NAT address that the clients server is NATed to and the address that the router advertises to us.

Hmmmm

Edison Ortiz · ‎10-17-2008

The server address (10.34.16.205) is really the outside NAT

Thus, that's really the CE replying in behalf of the server.

I'm afraid you need to contact the remote location and have them help you on the IP info or you can find network reachability via BGP on routes being source by that remote CE.

HTH,

__

Edison.

lamav · ‎10-17-2008

"Thus, that's really the CE replying in behalf of the server."

Exactly.

"I'm afraid you need to contact the remote location and have them help you on the IP info..."

Yup, seems like it.

"...or you can find network reachability via BGP on routes being source by that remote CE."

Nah, the CE router on the other side of the MPLS cloud will point to the PE as a next hop for that 10.34.16.0/24 network.

Thanks

lamav · ‎10-17-2008

Jon/Edison:

I dont know why I didnt think of this before, especially since the answer was right in front of my face!

If the end-router was responding on behalf of the server because of the source NATing (which Edison and I discussed in our last posts), then the key to getting the router to respond with one of its own addresses was to run a trace to a non-existent host on the same subnet that the router is advertising! In other words, a host address that is not part of a NAT.

So, instead of tracing to the host address of 10.34.16.205, I should have just traced to, say, host .210, which doesnt exist. This would have forced the router to respond, as normal, with its own address!

Stupid, stupid, stupid me! :-(

C:\Documents and Settings\Victor>tracert 10.34.16.210

Tracing route to 10.34.16.210 over a maximum of 30 hops

1 13 ms 12 ms 12 ms connect.rmtsls.com [138.69.152.252]

2 14 ms 12 ms 12 ms 10.36.202.2

3 14 ms 12 ms 11 ms 10.36.29.233

4 13 ms 12 ms 14 ms 10.36.29.214

5 12 ms 15 ms 12 ms 10.36.125.243

6 14 ms 12 ms 11 ms 68.136.146.229

7 36 ms 34 ms 34 ms 152.X.Y.146 (ROUTER's ADDRESS)

8 * * * Request timed out.

VL

Edison Ortiz · ‎10-17-2008

Good job Victor !

Jon Marshall · ‎10-18-2008

"Stupid, stupid, stupid me! :-(" - well we've known for some time...... :)

Seriously not stupid at all Victor, great bit of logical thinking - rated.

Jon

lamav · ‎10-19-2008

As Ralph Kramden would have said, "you're a regular riot, Alice..."

Thanks for the rating... :-)