Answers: IPv6 Extended ACLs 1
This latest lab breaks the config lab mold just a tad, but for a good reason. It looks like a straightforward config lab, requiring just 10 minutes or so to do on paper. But it sets you up for one of the most common mistakes with IPv6 ACLs. Do the lab for yourself to see if the extra unstated bit of work is trigger in your brain, and then check here when you’re done.
Answers
Figure 1: Two Router ROAS Topology for IPv6 ACL Lab
Example 5: R1 Config
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
interface GigabitEthernet0/2.10 ipv6 traffic-filter ExtACL01-sub10 in ! interface GigabitEthernet0/2.20 ipv6 traffic-filter ExtACL01-sub20 in ! ipv6 access-list ExtACL01-sub10 permit tcp host 2001:0:0:10::100 eq telnet 2001:0:0:30::/64 permit tcp host 2001:0:0:10::100 eq 22 2001:0:0:30::/64 permit icmp any any router-solicitation permit icmp any any router-advertisement permit icmp any any nd-na permit icmp any any nd-ns deny ipv6 any any log ! ipv6 access-list ExtACL01-sub20 permit icmp 2001:0:0:20::/64 2001:0:0:40::/64 permit icmp any any router-solicitation permit icmp any any router-advertisement permit icmp any any nd-na permit icmp any any nd-ns deny ipv6 any any log |
Commentary
This lab asked you to create extended IPv6 ACLs. The difference between IPv6 standard and extended ACLs is subtle in that the configuration commands do not give any obvious clues about whether the ACL is standard or extended. If the ACL matches only the source and destination IPv6 address fields, it is a standard IPv6 ACL; otherwise, it is an extended IPv6 ACL.
Next, the lab gave two requirements for permitting traffic, but based on the topology, some of those packets enter R1’s G0/2.1 subinterface only, with the other traffic entering R1’s G0/2.2 subinterface. As a result, you could match the first permit requirement in a different ACL, enabled inbound on R1’s G0/2.1 subinterface, and match the second permit requirement in a second ACL, enabled inbound on R1’s G0/2.2 subinterface. The solution does just that. The ACLs use the following action for those permit requirements:
ACL ExtACL01-sub1: two permit statements, one for Telnet and one for SSH as the source TCP port.
ACL ExtACL01-sub2: one permit statements for all ICMPv6 messages
The requirements also ask you configure the ACL(s) so that all remaining packets are denied, and those matches are counted, and log messages are issued. Those requirements mean that you must explicitly match the remaining packets with an explicit deny command, with the log option, as shown at the end of the ACL with the deny ipv6 any any log ACL subcommand. And while correct, this command creates the one mistake that can be easily overlooked with IPv6 ACLs: the need to also then permit other types of ICMP messages, like NDP Neighbor Advertisement (NA) and Neighbor Solicitation (NS) messages.
The answers show the matching (with a permit) of four separate ICMPv6 messages that would otherwise be permitted by an inbound IPv6 ACL’s deny ipv6 any any command. In succession, each command permits ICMPv6 neighbor solicitation (NS), neighbor advertisement (NA), router solicitation (RS) and router advertisement (RA). Without these, hosts on the subnets would not discover the existence of the router nor learn the router’s MAC address.
Should be “traffic-filter” instead, right?
Yep. Fixed it. Thanks Erjol!
We are not allowed to take the exam from Iran
::
SSH has no keyword in ACL replace it with 22
I didn’t see where you asked us to explicitly permit the ICMP NA/ND messages. Please advise.
Hi Gabriel,
I looked, and I didn’t require it. It’s just good practice, because without it, NDP Neighbor Advertisement/Solicitation would fail. but I agree it’s not in the requirements.
Wendell
Won’t the implicit permit lines at the end of the list cover NDP Neighbor Advertisement/Solicitation?
Hi Dave,
Sorry for the delay.
Short version is no. There is no implicit (aka not configured) permit at the end of an IPv4 or IPv6 ACL. Do you instead refer to the explicit (aka configured) permit statements in the example answer? Those do permit NDP NS and NA. Maybe your comment is just one of disagreeing about implicit/explicit?
Wendell
No worries at all. 🙂 In your book CCNA Routing and Switching ICND2 200-105 Official Cert Guide it talks about the implicit permit rules at the end of IPv6 ACLs.
“For this very reason, Cisco IOS IPv6 ACLs have three implicit rules at the bottom of each ACL. These are invisible, but they are included at the end of each IPv6 ACL so as to implicitly permit NA and NS messages. The final implicit IPv6 ACL statement is the default deny that is commonly expected. The three implicit IPv6 ACL rules at the bottom of every ACL are shown in Example 25-13.
Example 25-13 Implicit IPv6 ACL Entries
permit icmp any any nd-na
permit icmp any any nd-ns
deny ipv6 any any
Note that these defaults do permit NDP NS and NA messages, but do not include an implicit permit of NDP RS and RA messages. If you wanted to add explicit statements to an ACL to match RS and RA messages, you could use commands like permit icmp any any router-advertisement and permit icmp any any router-solicitation.”
also curious of this because you did say in your book at these ICMP statements were invisible extras above the implicit deny
I created the network diagram from the book at chapter 25 where are the examples based.
Also i decided to activate EIGRPv6 between the routers. After the activation of the second extended ACL inbound at router R2, neighbour relation broke.
I knew the implicit deny blocked the “Hello”, so i added a permit statement about all multicast.
I was receiving an error “retry limit exceeded” which after a Google search led me to that the ACK of the “Hello” was being filtered.
I couldn’t fix it by adding a new ACE since Packet Tracer’s IOS is old (12.1) to allow ACK.
Isn’t there an easier way for routing protocols, since they don’t rely on TCP/UDP but they have their own protocol type ?
Hi Konstantin,
Interesting experiment. And yes, there’s an easier way. Just use “eigrp” as the protocol name instead of ip. “access-list 101 permit eigrp any any”. Don’t know if the PT simulator supports it, but real devices have for a long time. It’s too far back in my memory to recall if it was supported in a real 12.1 IOS.
Wendell
PS ditto for protocol type “ospf”
Wendell
I see there is a protocol type for eigrp and ospf for IPv4 access list but I do not see same options for IPv6 Access Lists. After an exhaustive search for answers I haven’t come up with a clean way to permit management packets for either routing protocol to communicate through an IPv6 Access Lists.
What I mean by clean is that I was looking for just 1 permit command that will permit either ospf or eigrp to establish and maintain relationships and topology databases. Basically I was looking for a way to command that would allow the routing protocols to work but at the same time have the flexibility to deny or permit other traffic as necessary.
Please advise.
Jonathan
Hi Jonathan,
You can match the IPv6 protocol numbers – 88 for OSPF, 89 for EIGRP. EIGRP is listed in the informational RFC here (https://tools.ietf.org/html/rfc7868#page-46), OSPF in this RFC (https://tools.ietf.org/html/rfc5340#page-14), and both protocol numbers at IANA (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). Hope this helps…
Wendell
Where can we find a list of all available ICMP message type abbreviations that can be used in an ACL? I know we can use the numbers but its much better for documentation to use things like “nd-na”, “nd-ns”, “router-solicitation”, etc.
Hi David,
Well, easiest way is to get into config mode, type the command up to that point, and type ?. That’ll reveal all the options.
There’s always IOS doc. Maybe here, and search for “ICMP message type”. That’s where I found them. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/a1/sec-a1-cr-book/sec-cr-a2.html#wp4698537840
W
Thank you for pointing me there. I guess checking the help and documentation should have been a first step; I just never saw the online command reference before.
One thing I don’t like is their suggestion to, “…Refer to the current assigned numbers RFC”. I bet that thing is update more frequently than the iOS I’m running.
In the end though, IOS changes any port number I might type in to the name ifbit has one. I suppose it’s better to be specific than to hope a name covers what you need.
Thanks again.
In access-list ExtACL01-sub10, shouldn’t the port numbers come after the destination addresses since they are destination ports? The source address would be associated with a random port automatically selected by the host opening the Telnet connection.
Hi Barbara,
The requirements state that the packets are coming from (not going to) the Telnet and SSH servers in the subnets at the top of the figure – so the ACL needs to match the source ports. But I agree, the ACL should match the well known ports, whether they be the source or destination in a particular flow.
Wendell