Answers: IPv6 Extended ACLs 1

By Wendell October 7, 2016 09:10

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.


Figure 1: Two Router ROAS Topology for IPv6 ACL Lab


Example 5: R1 Config



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.

IPv6 Extended ACLs 1
Multilink PPP 2
By Wendell October 7, 2016 09:10
Write a comment


  1. Erjol October 8, 12:38

    Should be “traffic-filter” instead, right?

    Reply to this comment
  2. Pshko February 8, 03:36

    We are not allowed to take the exam from Iran
    SSH has no keyword in ACL replace it with 22

    Reply to this comment
  3. Gabriel Moran November 30, 03:24

    I didn’t see where you asked us to explicitly permit the ICMP NA/ND messages. Please advise.

    Reply to this comment
    • certskills January 19, 13:19

      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.

      Reply to this comment
  4. Konstantin A April 30, 13:46

    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 ?

    Reply to this comment
    • certskills May 16, 09:07

      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.

      PS ditto for protocol type “ospf”

      Reply to this comment
  5. Mr. David P. Hummel Jr. June 7, 04:07

    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.

    Reply to this comment
    • certskills June 22, 10:23

      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.


      Reply to this comment
      • Mr. David P. Hummel Jr. June 22, 16:21

        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.

        Reply to this comment
View comments

Write a comment

Comment; Identify w/ Social Media or Email


Subscribe to our mailing list and get interesting stuff and updates to your email inbox.

Thank you for subscribing.

Something went wrong.