Solved: Interface won't ping itself - Page 2

Carlton Patterson · ‎12-18-2012

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

Carlton Patterson · ‎12-18-2012

I'm not sure, but I think John is going to lab it up .... lets see

John Blakley · ‎12-18-2012

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 ***

Carlton Patterson · ‎12-18-2012

John,

I've been reading this post over-and-over and the penny has dropped - I totally get it now. I put the static route on the host as suggested.

Brilliant mate.

Can't thank you enough for following through with the lab. Of course this wouldn't be deployed in a production environment - this was a personally issue.

Thanks again mate.

Cheers

Carlton

Carlton Patterson · ‎12-18-2012

John, did I rate this question to you or to myself?

John Blakley · ‎12-18-2012

You rated it Thank you for the rating! This one was fun....

HTH,
John

*** Please rate all useful posts ***

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

Carlton Patterson · ‎12-18-2012

John,

I took the above from a book by 'O'Reilly - Cisco IOS Access-List. The actual scenario goes as follows:

The router shown has two interfaces, Ethernet and Ethernet 1. Network 192.168.33.0/24,

where the payroll hosts live, is on the Ethernet 1 interface while the rest of the network is

reachable through the Ethernet interface. We wish to limit access to the payroll systems on

network 192.168.33.0/24 to the following hosts: 192.168.30.1, 172.28.38.1 (and no other host on network 172.28.38.0/24), and any remaining host in network 172.28.0.0/16. The hosts thatcan send traffic to the payroll hosts on network 192.168.33.0/24 should still be able to send any kind of IP traffic to that network. No other hosts have any business with the payroll systems and should have no access whatsoever.

To implement this policy, let's first define a policy set containing the hosts that can access the payroll machines:

Policy Set #6: host with IP address 192.168.30.1

Policy Set #6: host with IP address 172.28.38.1

Policy Set #6: no other host on subnet 172.28.38.0/24 of network

172.28.0.0/16

Policy Set #6: any remaining hosts in network 172.28.0.0/16 not previously

excluded This policy set needs to be applied to any packet going out to interface Ethernet 1 where network 192.168.33.0/24 is attached:

Ethernet interface 1: Apply Policy Set #6 to outgoing packets

Policy Set #6 translates into the following standard access list:

access-list 6 permit 192.168.30.1

access-list 6 permit 172.28.38.1

access-list 6 deny 172.28.38.0 0.0.0.255

access-list 6 permit 172.28.0.0 0.0.255.255

The first line puts the host at IP address 192.168.30.1 into the policy set, and the second line

includes the host at 172.28.38.1. After this, we exclude all other hosts in the subnet

172.28.38.0/24. The fourth and last line includes the remaining hosts in network

Cisco IOS Access lists

Page 30

172.28.0.0/16. Note that the sequence of entries is critical. If the second and third lines switch positions, host 172.28.38.1 is never included in the policy set. If the third and fourth lines are switched, the hosts in subnet 172.28.38.0/24 are never excluded from the policy set.

The Cisco configuration commands to set our policy are:

interface Ethernet1

ip access-group 6 out

The first line specifies that we will modify the properties of interface Ethernet 1. The second

line says that we apply the policy set defined by standard access list 6 to all IP traffic going

out through router interface Ethernet 1 from the router.

access-list 6 deny 172.28.38.0 0.0.0.255

The router shown has two interfaces, Ethernet and Ethernet 1. Network 192.168.33.0/24,

where the payroll hosts live, is on the Ethernet 1 interface while the rest of the network is

reachable through the Ethernet interface. We wish to limit access to the payroll systems on

network 192.168.33.0/24 to the following hosts: 192.168.30.1, 172.28.38.1 (and no other host on network 172.28.38.0/24), and any remaining host in network 172.28.0.0/16. The hosts thatcan send traffic to the payroll hosts on network 192.168.33.0/24 should still be able to send any kind of IP traffic to that network. No other hosts have any business with the payroll systems and should have no access whatsoever.

To implement this policy, let's first define a policy set containing the hosts that can access the payroll machines:

Policy Set #6: host with IP address 192.168.30.1

Policy Set #6: host with IP address 172.28.38.1

Policy Set #6: no other host on subnet 172.28.38.0/24 of network

172.28.0.0/16

Policy Set #6: any remaining hosts in network 172.28.0.0/16 not previously

excluded This policy set needs to be applied to any packet going out to interface Ethernet 1 where network 192.168.33.0/24 is attached:

Ethernet interface 1: Apply Policy Set #6 to outgoing packets

Policy Set #6 translates into the following standard access list:

access-list 6 permit 192.168.30.1

access-list 6 permit 172.28.38.1

access-list 6 deny 172.28.38.0 0.0.0.255

access-list 6 permit 172.28.0.0 0.0.255.255

The first line puts the host at IP address 192.168.30.1 into the policy set, and the second line

includes the host at 172.28.38.1. After this, we exclude all other hosts in the subnet

172.28.38.0/24. The fourth and last line includes the remaining hosts in network

Cisco IOS Access lists

Page 30

172.28.0.0/16. Note that the sequence of entries is critical. If the second and third lines switch positions, host 172.28.38.1 is never included in the policy set. If the third and fourth lines are switched, the hosts in subnet 172.28.38.0/24 are never excluded from the policy set.

The Cisco configuration commands to set our policy are:

interface Ethernet1

ip access-group 6 out

The first line specifies that we will modify the properties of interface Ethernet 1. The second

line says that we apply the policy set defined by standard access list 6 to all IP traffic going

out through router interface Ethernet 1 from the router.

I hae attached the diagram

My question is will that work? Because once there is a deny on access-list 6 deny 172.28.38.0 0.0.0.255, how is traffic going to pass with the permit access-list 6 permit 172.28.0.0 0.0.255.255 ?

Cheers

Carlton

John Blakley · ‎12-18-2012

The 172.28.30.0 0.0.0.255 is specific to the 172.28.30.0/24 subnet. So, if you deny it, other networks in the 172.28.0.0/16 will still get through.

So, you'd deny:

access-list 6 deny 172.28.38.0 0.0.0.255

access-list 6 permit 172.28.0.0 0.0.255.255

The second line would allow:

172.28.10.0/24

172.28.15.0/24

172.28.255.0/24

This acl would work fine. ACLs are top down, and the first line that it hits will cause the router/switch to stop processing other lines. That's why the order is very important. You could be allowing something and not want to.

Suppose you wanted to allow internet access for everyone in your branch except 1 host. You already have an existing acl:

access-list 101 permit tcp 10.10.10.0 0.0.0.255 any eq www

There is an implicit deny at the end, so www is only getting through. Now you want to deny host .50 from getting on the internet. You put the following line in:

access-list 101 deny tcp host 10.10.10.50 any eq www

The problem is that your acl entries are added in order, so your new acl entry is added to the bottom of the existing, which means that host .50 can still get on the internet. You can insert acls in the middle of other acls though by specifying the line number:

The default starts at 10:

5 access-list 101 deny tcp host 10.10.10.50 any eq www

So now your acl looks like:

5 access-list 101 deny tcp host 10.10.10.50 any eq www

10 access-list 101 permit tcp 10.10.10.0 0.0.0.255 any eq www

You just denied host .50, but allowed everyone else from .1 - .49, .51 - .254.

HTH,
John

*** Please rate all useful posts ***

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

Carlton Patterson · ‎12-18-2012

So, would/should 172.28.38.2 255.255.0.0 get through?

Carlton Patterson · ‎12-18-2012

John,

That is a wicked example I get that:

172.28.10.0/24

172.28.15.0/24

172.28.255.0/24

That seriously kicked in my brain.

I'm still toying with why an address, even with 172.28.38.0 with a subnet mask of 255.255.0.0 not 255.255.255.0 will be denied uhmmmm

John Blakley · ‎12-18-2012

Are you seeing that the 172.28.38.0/16 is being blocked with an acl of 255.255.255.0?

Does 172.28.38.0 0.0.255.255 get blocked?

Does 172.28.38.0 0.0.0.255 get blocked?

If so, here's why. The 172.28.38.0 has an inverted mask of 0.0.255.255 which means "must exist.must exist.don't care.don't care." That means that 172 (must exist), 28 (must exist), and even though you have "38" in the third octet, the inverted mask of all 1s states that it doesn't care what is in that spot.

The second line states that 172.28.38 must exist (first 3 inverted mask are "must exist (all 0s)" bits), and the last 8 bits are don't care (can be anything from 1 - 254).

So, with your last post of 172.28.38.0 with subnet mask of 255.255.0.0 translates to 172.28.38.0 0.0.255.255 which means that 172.28.0.0/16 would be blocked. Does that make sense or did I make it more confusing?

HTH,
John

*** Please rate all useful posts ***

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

Carlton Patterson · ‎12-19-2012

John,

Thanks so much for taking time out to explain the reason why 172.28.38.0 255.255.0.0 get blocked, and I really want to say I understand you explanation but I don't. 172.28.38.0 255.255.255.0 is on a completely different subnet to 172.28.38.0 255.255.0.0 ( which is the same as 172.28.0.0 255.255.0.0)

I don't understand

cadet alain · ‎12-19-2012

Hi,

Could you start a new thread as this is another problem you're talking about now.This would be beneficial to all people searching for info on this forum as well as for people answering questions.

Regards.

Alain

Don't forget to rate helpful posts.