cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

16239
Views
4
Helpful
26
Replies
Highlighted

Interface won't ping itself

Hello Community,

I have a problem that I simply can't understand - although I'm sure there is simple explanation.

R3 can't ping itself on 172.28.38.11/16 and I can't understand why. I appreciate R2 has an interface on Eth 1/2 with ip address 172.28.38.1/24, but its on a separate router and different mask.

Can someone please explain what I'm missing here.

Please see logs

Cheers

Everyone's tags (3)
1 ACCEPTED SOLUTION

Accepted Solutions
Advisor

Re: Interface won't ping itself

I did lab this up for you and came up with the same result.

R1 cannot ping its locally connected interface due to the longest match rule:

R1(config-router)#do sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.13.0.0/24 is subnetted, 1 subnets

C       172.13.0.0 is directly connected, FastEthernet0/1

     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

O       10.12.0.0/24 [110/30] via 172.13.0.3, 01:42:38, FastEthernet0/1

C       10.12.0.0/16 is directly connected, FastEthernet0/0

O       10.23.0.0/24 [110/20] via 172.13.0.3, 01:42:48, FastEthernet0/1

R1(config-router)#do ping 10.12.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.12.0.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Italicized is the locally 10.12.0.0/16 subnet with R1 at 10.12.0.1/16. R2 has 10.12.0.2/24. When you ping 10.12.0.1, the router looks at the routing table and notices that 10.12.0.0/24 is the more specific match and tries to send it out Fa0/1 to R2.

Also, being that you're using OSPF, the neighbor's masks have to match. You'll probably notice that the interface that you're trying to ping doesn't have an adjacency with the neighbor on the other side. So, the route that should be connected is actually being learned from another interface due to the mismatched mask and no adjacency on this interface.

On R1 debug ip packet:

*Mar  1 02:53:33.951: IP: tableid=0, s=172.13.0.1 (FastEthernet0/0), d=10.12.0.1 (FastEthernet0/1), routed via RIB

*Mar  1 02:53:33.951: IP: s=172.13.0.1 (FastEthernet0/0), d=10.12.0.1 (FastEthernet0/1), g=172.13.0.3, len 100, forward

*Mar  1 02:53:33.955:     ICMP type=8, code=0

I've attached my topology for you to see. Here are my adjacencies:

R1:

Neighbor ID     Pri   State           Dead Time   Address         Interface

172.13.0.3        1   FULL/DR         00:00:34    172.13.0.3      FastEthernet0/1

R2:

Neighbor ID     Pri   State           Dead Time   Address         Interface

172.13.0.3        1   FULL/DR         00:00:32    10.23.0.3       FastEthernet0/1

R3:

Neighbor ID     Pri   State           Dead Time   Address         Interface

10.23.0.2         1   FULL/BDR        00:00:33    10.23.0.2       FastEthernet0/1

172.13.0.1        1   FULL/BDR        00:00:39    172.13.0.1      FastEthernet0/0

So what I did was create a static route for 10.12.0.1/32 pointing to fa0/1 (172.13.0.1) on R3. I then created a static route on R2 pointing 10.12.0.1/32 to R3. I was able to ping at that point:

R2#trace 10.12.0.1

Type escape sequence to abort.

Tracing the route to 10.12.0.1

  1 10.23.0.3 48 msec 36 msec 24 msec

  2 172.13.0.1 84 msec *  52 msec

R2#

Before doing this, I wasn't able to ping from R2 to 10.12.0.1/32. The reason was once it hit R3, R3 had a route for 10.12.0.0/24 from R2 and was sending it back to R2 creating a loop.

Now I can ping R1, but why? R1 still sends the packet to R3, but R3 now tells R1 to go back to itself on 172.13.0.1:

R1#ping 10.12.0.1 rep 2

Type escape sequence to abort.

Sending 2, 100-byte ICMP Echos to 10.12.0.1, timeout is 2 seconds:

!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 28/48/68 ms

R1#

R3#

*Mar  1 03:08:14.523: ICMP: redirect sent to 172.13.0.1 for dest 10.12.0.1, use gw 172.13.0.1

R3#

So, it's definitely the longest match rule. You could try this to fix yours although I definitely wouldn't do it in production because theirs no reason really. Put a static route on the host that would be your next hop for the longest subnet (whatever host is on f0/1). You can put a static on that host for 172.28.38.1/32 pointing to it's next hop to get back to this router. Once you do that, R3 will send a packet out and it will get returned back with a response. This is only a lab thing though

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***
26 REPLIES 26
Advisor

Interface won't ping itself

I don't think you're missing anything... are you using GNS? If so, have you saved your configs and tried to restart gns/dynamips?

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

Interface won't ping itself

Hi John,

Thanks for responding. I thought just as you. But when I look at the show ip route for R3, there isn't a connected route for the interface 172.28.38.11/16. It states that to get to that subnet you need to exit fas 0/1.

What do you think?

Cheers

Re: Interface won't ping itself

Community,

Attached are the show ip routes

Advisor

Re: Interface won't ping itself

I see a route on R3:

C       172.28.0.0/16 is directly connected, Ethernet1/1

But, I believe you're running into the problem of a more specific route. You have R2 and R3 in the same major subnet (172.28.0.0/16), but R2 has a different mask. The router is seeing this route:

O       172.28.38.0/24 [110/21] via 10.0.0.5, 00:05:24, FastEthernet0/1

And it's more specific that your connected route. I'd have to lab this up, but I think this is what's happening. If you change the mask on R3 to be /24, can you ping it then?

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

Re: Interface won't ping itself

John,

Going to try your suggestion, but it doesn't make sense why I can't ping myself??? There on two separate subnets 172.28.38.X/16 and 172.28.38.X/24

I thought it was just me going crazy because I can't see what is wrong...

Re: Interface won't ping itself

John,

Yes I can ping myself if I change the subnet mask to /24. But I should be able to ping myself with /16.

Doesn't make sense.

Participant

Re: Interface won't ping itself

I agree with John.  Although an interface on itself, the router is "following the rules" to route the packet based on the most specific route available. 

However, I'm curious to see if this specific example would result differently on newer IOS versions that add the "local" route to the routing table that specifies a /32 for the interface address.  I think you'd see the behavior that you expect in that case.

ETA:

You could probably mimic the functionality that I noted by adding a static route to the interface address (/32), perhaps pointing to that interface?  I'm not able to reach my lab at the moment to verify.

My larger question (simply to satisfy my own curiosity) is why do you have overlapping address spaces to begin with?

Re: Interface won't ping itself

John,

If you have a spare moment, would you be kind enough to lab it up?

Cheers

Interface won't ping itself

Why not create that interface as a loopback interface instead?

Since it looks like it is not connected to anything.

Interface won't ping itself

Mand,

Thanks for responding. The interface is actually connected. Just like interface Ethe 1/2 on R2 is connected.

Regards

Interface won't ping itself

As per John Blakley

O    16.0.0.0/8 [110/11] via 10.0.0.14, 00:05:24, FastEthernet0/0

     172.28.0.0/16 is variably subnetted, 2 subnets, 2 masks

O       172.28.38.0/24 [110/21] via 10.0.0.5, 00:05:24, FastEthernet0/1  <<<====== Most likely destination of your traffic

C       172.28.0.0/16 is directly connected, Ethernet1/1

Better off changing subnet mask of your interface....

Re: Interface won't ping itself

Thanks for responding,

However, John did mention that it should work..... And I can't understand why. I just want to ping 172.28.38.11

I'm getting a lot of conflicted suggestions ... some say its not connected, others say its because of more specific routes .... uhmmmm

Re: Interface won't ping itself

Never mind my earlier response about it not being connected, looking at the routing table, the router will base it's decision on the more specific route to send the traffic out.  In this instance you have:

O       172.28.38.0/24 [110/21] via 10.0.0.5, 00:05:24, FastEthernet0/1

as the more specific route to the destination 172.28.38.0 network and that will be going out interface FastEthernet0/1, which for all intents and purposes is the wrong interface.

So in your routing table if you would have this interface on another subnet lets say 172.28.39.0/24, this will have a more specific route which would appear as:

c       172.28.39.0  is directly connected, Ethernet1/1

One other way of doing it would be to change the subnet mask to be lets say 172.28.38.11/32 and this will appear on your routing table as

c       172.28.38.11  is directly connected, Ethernet1/1

I hope this explains it for you.

Re: Interface won't ping itself

Thanks again for the explanation. However, it doesn't explain why I can't myself......

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards