| Cisco routing problem between two routers Here's my issue - any help is appreciated.
I have one router that is externally facing with only two active interfaces - one for our network and another to the internet at large.
I have another router that is a direct connect T-1 line between us and a customer.
Both of those routers are connected to a backbone managed switch (which is then connected to our internal network).
We host multiple web sites for this customer and they have no issue connecting to the sites. All of their connections internally traverse the T-1 line into the network.
The problem we're having is accessing their machines from our network. Here is the behavior:
1. I can ping from the console of the external (internet) router with no issue. A trace correctly shows that the router is sending the request to the P2P router and then traversing the T-1 into their network with no issues.
2. I cannot ping from the console of the P2P router. A trace there dies with A! A! at the P2P T-1 interface.
3. I cannot ping from inside our network. A trace from here has it going to the external router, being routed to the P2P router and dying there.
Salient points:
A. The external router has NAT Translations set so that it is always showing an external IP via the T-1 (no matter where we try and ping from) which is correct.
B. The P2P router is old enough that it does not allow ping X.X.X.X source Y.Y.Y.Y
For illustration, I've made up some IP addresses to show the traversal:
FROM EXTERNAL ROUTER CONSOLE:
Trace to 10.10.1.1
1 169.52.52.52 (IP of P2P router) 4 msec 4 msec 4 msec
2 155.40.40.40 (IP of serial interface) 8 msec 8 msec 8 msec
3 192.168.10.55 (IP of client network device) 52 msec 8 msec 8 msec
FROM P2P ROUTER CONSOLE:
Trace to 10.10.1.1
1 155.40.40.40 (IP of serial interface) !A !A *
FROM MACHINE INSIDE OUR NETWORK:
Trace to 10.10.1.1
1 169.52.52.1 (IP of External router) 1 msec 1 msec 1 msec
2 169.52.52.52 (IP of P2P router) 3 msec 2 msec 2 msec
3 Request timed out * * *
4 Request timed out * * *
Anybody have any idea how this could be? |
|
BinkVillains... knock off all that evil
join:2006-05-14
Denver, CO
kudos:4 | Not really enough information—I suggest posting a diagram and full configuration of both routers. |
|
aryobaPremium,MVM
join:2002-08-22
kudos:3 | reply to doulos2k
doulos2k  , I'm sure you are asking this question with a consideration that you are in the middle of troubleshooting process and then you faced with the ping and traceroute inability issue. I notice you did not mention what you were troubleshooting of originally. Explaining what you are troubleshooting of would provide better picture of what your objective is for people here to help.
In regards of ping or traceroute ability, I won't rely on it much since ICMP could be blocked which is still common practice. If I were you I would concentrate on the actual issue rather than creating additional troubleshooting process due to inability to ping or traceroute.
With that in mind, let's entertain a bit of the ping ability issue. When you are able to ping from one source but are unable to from different source, best bet is that ping source is locked down to only certain IP addresses so that ping ability is restricted to only "trusted" or known device as security consideration. |
|
| aryoba - great appreciate the reply and you're right, I could certainly have elaborated the initial problem.
There is a system within the client network that we have been given access to and we need to be able to direct connect to that machine. They've opened up the IPs to ensure we can ping from our network to theirs, but I'm unable to access that machine. They don't see attempts on their side, so I've come to the conclusion that there must be something preventing it on my side.
Perhaps I'm making an erroneous assumption, but what baffles me is why I can ping from one router going through a router when the router it's going through can't do the same thing even though it's IP is clearly in the trace. |
|
aryobaPremium,MVM
join:2002-08-22
kudos:3 | One common way to troubleshoot is to do packet capture, either using something like tcpdump, Wireshark, or at the very least create an ACL on your customer-facing equipment and monitor the counter. If you are able to see the packet from your terminal leaving your network towards the customer's network, then you know at least nothing blocks the packet within your network. |
|
aryobaPremium,MVM
join:2002-08-22
kudos:3 | reply to doulos2k
said by doulos2k:There is a system within the client network that we have been given access to and we need to be able to direct connect to that machine. They've opened up the IPs to ensure we can ping from our network to theirs, but I'm unable to access that machine. They don't see attempts on their side, so I've come to the conclusion that there must be something preventing it on my side.
I recalled when I was in your position managing a cloud network for customers, we had similar situation. It turned out that the customer had some NAT device that hid the customer's actual IP address. When that is your case, then the customer needs to create either some static NAT to an IP address accessible to your network, or disable NAT at least for such machine. |
|
aryobaPremium,MVM
join:2002-08-22
kudos:3 | reply to doulos2k
said by doulos2k:Perhaps I'm making an erroneous assumption, but what baffles me is why I can ping from one router going through a router when the router it's going through can't do the same thing even though it's IP is clearly in the trace.
said by aryoba:When you are able to ping from one source but are unable to from different source, best bet is that ping source is locked down to only certain IP addresses so that ping ability is restricted to only "trusted" or known device as security consideration.
I think that answers the question. Now let's fire up that Wireshark  |
|
| Yep - working that angle now. Thanks! I'll let you know how it goes. |
|
| reply to doulos2k
A diagram with IP addresses would also be helpful as well. I'd love to help out as well but find it difficult to
visualize right now.
Regards |
|
| reply to doulos2k
Is it safe to guess you've checked firewalls, misconfigured ACL's, and the all of the routes that are traversed?
Jay |
|
 TomS_Git-r-donePremium,MVM
join:2002-07-19
London, UK
kudos:4
1 edit | reply to doulos2k
Bit late, but....
!A means "administratively prohibited" which means you have an ACL blocking something somewhere, most likely on the router where you see those results, and on the interface identified in the traceroute. |
|
| said by TomS_:!A means "administratively prohibited"
Filed this little gem away for the future... thanks for pointing that out TomS_. Cisco doesn't happen to have it
documented somewhere, do they?
Regards |
|
TomS_Git-r-donePremium,MVM
join:2002-07-19
London, UK
kudos:4 | You can find references to it, and I think there is a document that describes what most of the !x codes are all about, but it never really goes in to much depth about each one so its kind of a guessing game in a way.
Found it: »www.cisco.com/en/US/products/sw/···aceroute
e.g. !H is host unreachable which you'd probably see if you had no route to the destination subnet.
But then you have * and T which are both a timeout of sorts. What T refers to exactly is another question. Im sure there is more documentation floating around somewhere, but Ive never looked. The basic 3 (*, A, H) tend to be the only ones I come across. |
|
