Cisco Catalyst 2960-X – Adding ACL Rule for L2TP Packet Filtering

ciscocisco-catalystcisco-commandsipipv4

I am using a Cayalyst 2960-X series Cisco Switch, Whose 2 SFPs are connecting between 2 hosts (A,B).

A,B are connected to the switch's 1,2 ports respectively.
The host communicates using an l2tp based protocol. As you know l2tp is a link layer protocol.

As part of the l2tp traffic sourced at host A whose destination is B, there are few packets I want to deny from getting to port 2 / Host B.

The packets that I want to drop have a source MAC address of 88:77:66:55:44:33 in their Ethernet 2 metadata, which is part of the whole l2tp packet (see the byte layout bellow).

I would like to set a rule or an access list that drops the l2tp packet by inspecting its Ethernet 2 attribute and in case the specific 88:77:66:55:44:33 MAC address appears in the SA.

I am familiar with the mac access-list command but every manual I had seen explicitly says that ACLs filter only non-IP protocols. In spite of that I tried to use mac access-list and indeed it didn't help.

Moreover, I found the Catalyst 2960-X Switch Security Configuration Guide, Cisco IOS
Release 15.0(2)EX, and under the Restrictions for Configuring Network Security with ACLs section it says:

You cannot apply named MAC extended ACLs to Layer 3 interfaces.

Isn't it feasible to filter ip protocols by drill down and inspecting their Ethernet 2 Mac addresses data?

By sniffing the traffic between the 2 hosts, I can tell the packets has the following byte layout (As I see on Wireshark):

 0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Ethernet 2 (14 Bytes)     |       IP(20 Bytes)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IP  |L2TP 4B|HDLC 4B| Data                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Best Answer

There seems to be some confusion about this topic for you. Let's begin by clearing up a few details.

I am familiar with the mac access-list command but every manual I had seen explicitly says that ACLs filter only non-IP protocols.

If you think about this a bit, it makes sense. An IP packet doesn't contain a MAC addresses, so this would be difficult. However, IP traffic is encapsulated in a L2 protocol, typically Ethernet which does utilize MAC addresses.

You cannot apply named MAC extended ACLs to Layer 3 interfaces.

Again, this is natural. Since MAC ACLs function on L2, they wouldn't really need/want them on a L3 interface anyway.

However, by default interfaces on a 2960-X are layer 2 interfaces, so you can apply a MAC access-list to them.

So, this series of commands should provide the result you want (using the first SFP port on a WS-C2960X-48FPS-L so adjust as necessary):

! Create the ACL
mac access-list extended TestACL
deny host 8877.6655.4433 any
permit any any

! Now apply to the interface
interface Gi1/0/49
mac access-group TestACL in

Edit based on comments: if you want to rule out the source port being incorrect, you can use the following with the above ACL to block all traffic from that MAC going out the second SFP port:

! Now apply to the interface
interface Gi1/0/50
mac access-group TestACL out

If that doesn't work, then the MAC address has to be incorrect and you need to provide more information.

The ACL will work no matter if the MAC address table is updated dynamically or if you add a static entry. However, if the dynamic entry for this MAC is flapping between different ports, that could explain why the ACL didn't work as intended. Additionally, without additional features configured, the static entry will not have an effect on traffic arriving on a port, only on the destination port used for the traffic.

And finally, the packet being highlighted in red by Wireshark doesn't tell me much. Different versions of Wireshark have used different coloring rules, the default rules typically include a number of matches that get colored red, and many of us use our own custom rules. You would need to provide more detail or the actual capture for us to know what exactly that means.

Related Topic