cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
630
Views
5
Helpful
4
Replies

routing - ping A-B, can't ping B-A

linnea.wren
Level 1
Level 1

Hi,

First time setting up routing on real equipment, and can't seem to get it right. Equipment is:

1. 5500 (CatOS 4.3, IOS 11.3) (old equipment, not under maintenance, being thrown into the battle due to a new building that has to open, and the Cisco equipment order got hung up in contract negotiations and wont be here in time for the building opening...)

2. 3620 (IOS 12.1)

3. Two workstations.

Connections are:

ws1 (10.70.5.100) -> 5500, 3/1.

ws2 (10.70.1.100) -> 5500, 3/2.

3620, Fa0/1 (10.70.200.2) -> 5500, 3/24.

On ws2, I can ping 3620.

Also on ws2, I can telnet to 3620.

On 3620, in the telnet session from ws2, I can NOT ping ws2. (Can't ping ws2 from 3620 in a terminal session either.)

On 5500, in terminal session with switch (CatOS), can ping 10.70.1.1, 10.70.1.250, 10.70.5.1, 10.70.200.1 (those 4 are various switch interfaces), and can ping 10.70.200.2 (3620 Fa0/1). Can NOT ping ws1, ws2.

On 5500, terminal session with MSFC, can ping all switch interfaces. Can NOT ping ws1, ws2.

On 3620, terminal session, can ping all switch interfaces. Can NOT ping ws2, ws1.

Ws1 can NOT ping ws2. And ws2 can NOT ping ws1.

Configs attached. (The 3620 config, and the MSFC config also have "sh ip route" output at the bottom of the files.)

Could someone tell me what I doing wrong? (BTW - I'm pretty sure I've got the default-routes and gateway of last resort mucked up, but that wouldn't explain the above, since all subnets above are routes in ospf, right?)

TIA...

1 Accepted Solution

Accepted Solutions

Richard Burts
Hall of Fame
Hall of Fame

Linnea

I have a theory about part of your problem and some observations which might help. I suspect that the problem with pinging TO the workstations may be that they are running a private firewall which blocks ping.

Your message is explicit that ws2 can ping and telnet to the 3620 but does not say whether ws1 can access anything. If ws1 can not access other resources then I would check to see if its default gateway is set.

I note that the MSFC has configured a static default route and that it does show up in the routing table. That is good. I note that the 3620 has configured a static default route but that it does not show up in the routing table. That is not good. I believe the reason for that is that the default route specifies a next hop of 10.0.70.1 which is out interface FastEthernet0/0. But it looks like FastEthernet is protocol down state - the interface does not show up in the routing table - and so the default route does not work. If you fix the problem with the interface the default route will probably work.

I also note that the 3620 defines a default-gateway and defines a default route. This is not necessarily bad but I want to be sure that you understand what this is doing. Default route and default gateway are two very different things. Default route is used when the 3620 is acting as a router and is forwarding packets. Default gateway would be used when the 3620 is acting as an IP host (but not as a router). The default gateway here is just the same as default gateway on a PC. There are a couple of circumstances where the 3620 may use the default gateway: if you configure "no ip routing" which would make the 3620 into a bridge, or if the 3620 boots into rxboot mode.

HTH

Rick

HTH

Rick

View solution in original post

4 Replies 4

Richard Burts
Hall of Fame
Hall of Fame

Linnea

I have a theory about part of your problem and some observations which might help. I suspect that the problem with pinging TO the workstations may be that they are running a private firewall which blocks ping.

Your message is explicit that ws2 can ping and telnet to the 3620 but does not say whether ws1 can access anything. If ws1 can not access other resources then I would check to see if its default gateway is set.

I note that the MSFC has configured a static default route and that it does show up in the routing table. That is good. I note that the 3620 has configured a static default route but that it does not show up in the routing table. That is not good. I believe the reason for that is that the default route specifies a next hop of 10.0.70.1 which is out interface FastEthernet0/0. But it looks like FastEthernet is protocol down state - the interface does not show up in the routing table - and so the default route does not work. If you fix the problem with the interface the default route will probably work.

I also note that the 3620 defines a default-gateway and defines a default route. This is not necessarily bad but I want to be sure that you understand what this is doing. Default route and default gateway are two very different things. Default route is used when the 3620 is acting as a router and is forwarding packets. Default gateway would be used when the 3620 is acting as an IP host (but not as a router). The default gateway here is just the same as default gateway on a PC. There are a couple of circumstances where the 3620 may use the default gateway: if you configure "no ip routing" which would make the 3620 into a bridge, or if the 3620 boots into rxboot mode.

HTH

Rick

HTH

Rick

Thanks to you both - workstation firewall was indeed the problem.

Rick - Fa0/0 was down because it wasn't connected - That interface lead to the production network, and I didn't want to connect till I had reason to believe the equipment I was setting up wasn't completely bollixed. And the default route did pop right up once the interface was up/up.

Thanks again...

Linnea

I am glad that we were able to help solve your problem. Thanks for posting back to the forum and indicating that your problem was solved. It makes the forum more useful when people do post back confirming the solution so that we can read about a problem and then see what solution solved the problem.

I encourage you to continue your participation in the forum.

HTH

Rick

HTH

Rick

omadrid
Cisco Employee
Cisco Employee

From the switch

===============

Can ping 10.70.1.1, 10.70.1.250

...because these are Vlan999 on the RSM and local sc0 IP address.

Can ping 10.70.5.1 and 10.70.200.1

...These are RSM Vlans and local to the 5500. As long as you have your sc0 up and corresponding RSM Vlans up/up, this will work.

and can ping 10.70.200.2 (3620 Fa0/1) <--- Vlan200

...This shows you have routing correctly from sc0 to other vlans in the RSM.

From the RSM (MSFC = Cat6k / RSM = 5500)

============

can ping all switch interfaces

...Local Vlans. You should be able to ping them

Can NOT ping ws1, ws2.

...WS2: almost certain it has a personal FW as pointed out.

...WS1: Not as certain, BUT it would be interesting to see if you can ping 10.70.1.1.

If ping 10.70.1.1 = OK! but nothing else? then check ws1 subnet-mask and gateway.

If ping 10.70.1.1 = Nada? then the problem is switchport, arp resolution or GW, cam table, NIC, etc. (too bad we do not have a show port)

From the 3620

=============

Can ping all switch interfaces

...Good! It shows that it uses the routing table entries :-)

Can NOT ping ws2, ws1.

...see above.

Getting Started

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: