CCNA And CCENT Lab: Testing Access Lists With Extended Ping
Here’s our network!
In our extended ACL lab, we applied an ACL to R1 that should block traffic sourced from 3.3.3.0 /24 if the destination is 11.11.11.0 /24. Here’s that ACL:
R1#show ip access-list Extended IP access list 111 10 deny ip 3.3.3.0 0.0.0.255 11.11.11.0 0.0.0.255 20 permit ip any any
Here’s the verification of that ACL being successfully applied to R1’s Serial 0/1/0 interface.
R1#show ip interface serial 0/1/0 Serial0/1/0 is up, line protocol is up Internet address is 172.12.123.1/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is 101 (output truncated for clarity)
It’s not enough to verify that the ACL is applied. We have to make sure it’s doing what we want it to do — in this case, stop traffic sourced from 3.3.3.0 /24 and destined for 11.11.11.0 /24 while allowing all other traffic.
I want to go the extra mile for you and show you the traffic flow before the ACL was applied. With that in mind, I’m going to remove the ACL from R1’s Serial interface. I’ve also added a default static route to R3 pointing to R1, and a default static route to R1 pointing to R3 to allow us to ping the loopbacks without adding a dynamic routing protocol. A quick reminder of the network:
R1(config)#int serial 0/1/0 R1(config-if)#no ip access-group 111 in R1(config)#ip route 0.0.0.0 0.0.0.0 172.12.123.3 R3(config)#ip route 0.0.0.0 0.0.0.0 172.12.123.1
The ACL requirements revolve around packets from 3.3.3.0 /24, but if we send packets from R3 via a regular ping, the source of those packets will be 172.12.123.3, the interface closest to the destination being pinged. Pings have the source IP address of their exit interface by default, as I’ll verify with debug ip packet and ping 11.11.11.11.
R3#debug ip packet IP packet debugging is on
R3#ping 11.11.11.11 Sending 5, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds: IP: s=172.12.123.3 (local), d=11.11.11.11 (Serial0/1/0), len 100, sending
Now we’ll put the ACL back on R1 and test it from R3 with that same ping command.
R1(config)#int serial 0/1/0 R1(config-if)#ip access-group 111 in
R3#ping 11.11.11.11 source 3.3.3.3 Sending 5, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds: Packet sent with a source address of 3.3.3.3 U.U.U Success rate is 0 percent (0/5)
The packets are now denied, which indicates the ACL on R1 is working correctly. Let’s ping another loopback on R1 with that same source to be sure.
R3#ping 1.1.1.1 source 3.3.3.3 Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: Packet sent with a source address of 3.3.3.3 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 64/64/68 ms
Success indeed! These packets go through because they don’t match both the source and destination IP of the first ACL line. The second line permits everything, so the packets zoom right through.
The requirements mentioned allowing packets to “all other subnets, including those added in the future,” so let’s go the extra mile add a subnet to R1 and ping it from 3.3.3.3.
R1(config)#int loopback111 R1(config-if)#ip address 111.111.111.111 255.255.255.0
R3#ping 111.111.111.111 source 3.3.3.3 Sending 5, 100-byte ICMP Echos to 111.111.111.111, timeout is 2 seconds: Packet sent with a source address of 3.3.3.3 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 64/65/68 ms
Our tests prove pings from 3.3.3.3 to 11.11.11.11 are blocked, but pings from 3.3.3.3 to other subnets are allowed. Just what we wanted!
Two ACL terms you’ll see all over your Cisco certification exams and in your real-world networking career are host and any. We’ll have a look at those two ACL options in the next CCNA tutorial, coming up on July 26, 2018. In the meantime, have a look or three at these, and thanks for making my work a part of your success. — Chris B.
CCNA Practice Exam: Access Lists