Problem Tracing to Router

Unanswered Question
Oct 17th, 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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jon Marshall Fri, 10/17/2008 - 07:44

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 Fri, 10/17/2008 - 07:56

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 Fri, 10/17/2008 - 08:00

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 Fri, 10/17/2008 - 10:08

"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 Fri, 10/17/2008 - 18:58

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

Jon Marshall Sat, 10/18/2008 - 08:23

"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 Sun, 10/19/2008 - 10:33

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


Thanks for the rating... :-)

Actions

This Discussion