10-17-2008 07:23 AM - edited 03-06-2019 02:00 AM
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
10-17-2008 07:44 AM
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
10-17-2008 07:56 AM
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
10-17-2008 08:00 AM
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.
10-17-2008 10:08 AM
"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
10-17-2008 06:58 PM
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
10-17-2008 09:19 PM
Good job Victor !
10-18-2008 08:23 AM
"Stupid, stupid, stupid me! :-(" - well we've known for some time...... :)
Seriously not stupid at all Victor, great bit of logical thinking - rated.
Jon
10-19-2008 10:33 AM
As Ralph Kramden would have said, "you're a regular riot, Alice..."
Thanks for the rating... :-)
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: