I have configured some ACL's on a Cisco router. When I send pings between the endpoints I noticed that sometimes it states Destination Net Unreachable and sometimes Request timed Out.
Why is it not consistent?
1. From where to where w/description so we can have some sort of diagram
2. sh run of the router in which you built the acls
3. sh run of others possibly involved
ip access-list extended IP-Options-and-Powerball
deny ip any any winning-powerball-ticket
permit ip any any option any-options
!
class-map ACL-Options-and-Powerball
match access-group name IP-Options-and-Powerball
!
policy-map CoPP-POLICY
class ACL-Options-and-Powerball
drop
!
control-plane
service-policy input CoPP-POLICY
Router Config:
interface FastEthernet0/0.1
encapsulation dot1Q 1 native
ip address 10.0.31.250 255.255.255.0
ip address 192.168.31.1 255.255.255.0 secondary
ip access-group 151 in
interface FastEthernet0/1.2
encapsulation dot1Q 2
ip address 172.16.31.1 255.255.255.0
ip access-group 152 in
access-list 151 permit ip 10.0.31.0 0.0.0.255 10.0.0.0 0.0.0.255
access-list 151 permit ip 192.168.31.0 0.0.0.255 host 10.0.0.205
access-list 151 permit ip 192.168.31.0 0.0.0.255 host 10.0.0.136
access-list 151 permit ip 192.168.31.0 0.0.0.255 host 10.0.0.240
access-list 151 permit ip 192.168.31.0 0.0.0.255 host 192.168.31.1
access-list 151 permit ip 10.0.31.0 0.0.0.255 host 10.0.31.1
access-list 151 deny ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
access-list 151 deny ip 10.0.0.0 0.255.255.255 172.16.0.0 0.15.255.255
access-list 151 deny ip 10.0.0.0 0.255.255.255 192.168.0.0 0.0.255.255
access-list 151 deny ip 192.168.0.0 0.0.255.255 10.0.0.0 0.255.255.255
access-list 151 deny ip 192.168.0.0 0.0.255.255 172.16.0.0 0.15.255.255
access-list 151 deny ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
access-list 151 permit ip any any
access-list 152 permit ip 172.16.31.0 0.0.0.255 172.16.0.0 0.0.0.255
access-list 152 permit ip 172.16.31.0 0.0.0.255 host 172.16.31.1
access-list 152 deny ip 172.16.0.0 0.15.255.255 10.0.0.0 0.255.255.255
access-list 152 deny ip 172.16.0.0 0.15.255.255 172.16.0.0 0.15.255.255
access-list 152 deny ip 172.16.0.0 0.15.255.255 192.168.0.0 0.0.255.255
access-list 152 permit ip any any
When I do my tests I have 2 laptops connected to a layer 2 managed switch. Each laptop is in a separate vlan based on the router config.
So one laptop in the 172.16.31.0 subnet and one in the 10.0.31.0 subnet. When I ping between the 2 subnets the 4 pings packets can be Request timed out or Destination Net Unreachable. It varies with the 4 packets. Sometimes it's 4 packets of Dest Net Unreachable.
Here's a sample:
C:\Windows\system32>ping 10.0.31.50
Pinging 10.0.31.50 with 32 bytes of data:
Request timed out.
Reply from 172.16.31.1: Destination net unreachable.
Request timed out.
Reply from 172.16.31.1: Destination net unreachable.
Ping statistics for 10.0.31.50:
Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
access-list 152 deny ip 172.16.0.0 0.15.255.255 10.0.0.0 0.255.255.255
is blocking that particular ping. If you want the subnets to access eachother...
access-list 151 (ACE number to edit a single line) permit ip 10.0.31.0 0.0.0.255 172.16.31.0 0.0.0.255
and a line for acl 152...permit ip 172.16.31.0 0.0.0.255 10.0.31.0 0.0.0.255
post a sh access-l and I will show you exactly how to edit/add/delete single ACEs from a given ACL
ip access-list extended IP-Options-and-Powerball
deny ip any any winning-powerball-ticket
permit ip any any option any-options
!
class-map ACL-Options-and-Powerball
match access-group name IP-Options-and-Powerball
!
policy-map CoPP-POLICY
class ACL-Options-and-Powerball
drop
!
control-plane
service-policy input CoPP-POLICY
I do not want the subnets to access each other that is the purpose of the ACL's.
What I don't understand is why when I send a ping the response is not always Request Timed Out or Destination NET unreachable.
Not sure without more info...could be that because of some static or something, it could be trying to go out to your secondary IP on vlan1...why the secondary IP anyway, and not another subint? Just curious...
Is it consistent, like every other message is either dest net unreachable and timed out?
ip access-list extended IP-Options-and-Powerball
deny ip any any winning-powerball-ticket
permit ip any any option any-options
!
class-map ACL-Options-and-Powerball
match access-group name IP-Options-and-Powerball
!
policy-map CoPP-POLICY
class ACL-Options-and-Powerball
drop
!
control-plane
service-policy input CoPP-POLICY
I mean to see if ICMP is behaving correctly and you don't have some weird little routing problem, you could open those up for successful pings all the way through and see if you get 50% or 100% then. That experiment will tell you definitively
ip access-list extended IP-Options-and-Powerball
deny ip any any winning-powerball-ticket
permit ip any any option any-options
!
class-map ACL-Options-and-Powerball
match access-group name IP-Options-and-Powerball
!
policy-map CoPP-POLICY
class ACL-Options-and-Powerball
drop
!
control-plane
service-policy input CoPP-POLICY
If I create a another subint instead of secondary IP then I will have to create the vlan in the switch.
I don't think that is the problem (if any) though.
ip access-list extended IP-Options-and-Powerball
deny ip any any winning-powerball-ticket
permit ip any any option any-options
!
class-map ACL-Options-and-Powerball
match access-group name IP-Options-and-Powerball
!
policy-map CoPP-POLICY
class ACL-Options-and-Powerball
drop
!
control-plane
service-policy input CoPP-POLICY
!
line con 0
logging synchronous
line vty 0 4
session-timeout 30
access-class 11 in
logging synchronous
transport input telnet ssh
line vty 5 15
session-timeout 30
access-class 11 in
logging synchronous
transport input telnet ssh
!
end
Okay, you have port security enabled on some interfaces, lets eliminate that first.
Could you move the endpoint devices to ports that have no port security on them and see what happens.
Also, could you post a running config of the router, let have look at the routing table.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.