5

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                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • 1
    To be clear, the l2tp is configured between hosts A & B, not on the 2960-X itself (I don't recall the platform having that capability, but could be wrong)? Second, the source MAC address you reference is from the frame header of the traffic going to the switch, not part of the data encapsulated in the tunnel? Finally, what do you mean by "prevent from getting to port 2"? Is this sourced from port 1 and you want to drop it when received on that interface or sourced from elsewhere on the network and you want to drop it before it leaves port 2 destined to host B? – YLearn Jun 26 '15 at 2:33
  • @YLearn, l2tp is between host A and B only. The SA is from the frame header and not encapsulated in some awkward way. It is sourced at host A (which is connected to port 1) and I want to filter such a packet from arriving to host B. – 0x90 Jun 26 '15 at 4:54
  • @YLearn basically I am using the switch in order to deny/permit specific data patterns that arrives at port 1. – 0x90 Jun 26 '15 at 5:02
  • Are you saying you want to filter by the inside mac-address inside an L2TP tunnel? There is no possible way a 2960 (or other non-L7-aware device) will be able to accomplish this. – cpt_fink Jun 26 '15 at 5:53
  • 1
    Pasting an ACL "can't hurt"? – cpt_fink Jun 30 '15 at 4:10
5

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.

  • On my 2960-X's, mac access-list is not an available command, so the difference is one is a valid command and the other isn't. – YLearn Jun 26 '15 at 18:00
  • I did try the mac access-list extended you had suggested. Unfortunately, It doesn't work for me and the packets aren't get filtered out. – 0x90 Jun 28 '15 at 8:43
  • 1
    This works fine on my 2960-X when I tested. Perhaps you could include an actual capture of the packets in question? At this point I would have to say either they aren't arriving on the port you believe they are or the MAC you provided isn't accurate. – YLearn Jun 28 '15 at 13:38
  • The byte layout isn't sufficient? I am 100% sure it is correct. – 0x90 Jun 28 '15 at 13:52
  • If the information you provided was correct, the above would work. My testing showed this dropped all traffic with the source address (TCP, UDP, ICMP, etc). If it isn't working for you, something is off. The two most likely causes for this I provided in my last comment. – YLearn Jun 28 '15 at 14:06
0

I used mac address-table static in order to drop the packets with the 8877.6655.4433 MAC address.

Apparently working with static address table entries is more robust way of doing such things.

  • 1
    So, that command statically configures a mapping of a MAC address to a particular interface / port. How does that prevent or drop frames from getting to port 2? ...are you sending them to a black hole, e.g. port 3, by statically mapping 8877... to port 3? – Ron Royston Jun 29 '15 at 17:01
  • yes .... Assuming not all the ports are in use – 0x90 Jun 29 '15 at 17:09
  • I have to agree with Ron, this sounds like a poor workaround and not an ideal solution. Also, based on this, while you keep claiming that this MAC address is the SA, this would only work if it were the DA as the MAC address table is only concerned with the DA and not the SA for forwarding decisions (obviously it uses the SA for learning). – YLearn Jun 29 '15 at 17:49
  • This is a bandaid and less than ideal. Can you run additional commands on your switch to see where these frames are flowing to? I'm inclined to believe YLearn's comment is more than likely the case you're facing. – Ryan Foley Jun 30 '15 at 17:44
-2
Switch# configure terminal
Switch(config)# mac access-list extended maclist1
Switch(config-ext-macl)# deny 8877.6655.4433 any
Switch(config-ext-macl)# deny any 8877.6655.4433
Switch(config-ext-macl)# permit any any
Switch(config-ext-macl)# end
Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# mac access-group mac1 out
Switch(config)# interface gigabitethernet1/0/2
Switch(config-if)# mac access-group mac1 out
Switch(config-if)# end

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.