Hey!

For the last couple of days, i’ve been busy with a couple of stuff.  I do coding for a living , so the company i work for wanted me to do some “extra” work this week ( because of some deadline) . That’s why i havent been able to dedicate as much time as i would like to finish these tasks. But now i’m done with almost 90% of them and i’m posting my notes here.

This is going to be a long blog post. Again, all these points are totally unedited, so please forgive any typos , grammatical errors, etc. If i find anything interesting, i will add to this post

• DHCP Spoofing
  • Inspects DHCP packets transiting a L2 device.
  • DHCP client sends-> DHCP Discover( to discover a DHCP server and request for an IP) , DHCP request ( to select an IP  addres ), DHCP release (to give back the IP )
  • DHCP relay -> middleman between DHCP clients and the servers.
  • When the relay receives the broadcast messages fromt he clients, it converts it into a unicast frame and sends it over to the DHCP server
  • But when it sends , the giaddr ( or the source address ) of the frame will be changed from 0 ( default for broadcast DHCP discover messages ) to the id of the interface of the swx connected to the DHCP server.
  • The DHCP server will reply to this interface.
  • The relay can be configured using : #ip helper-address X.X.X.X
  • DHCP server sends -> DHCP offer ( contains the IP address to be sent to the client ), DHCP ACK/NACK (accept/reject) messages.
  • DHCP Snooping
    • unless a swx port is configured as trusted, the swx applies DHCP message filtering on the ports . only accepting messages accepted from DHCP clients ( DHCP request, DHCP discover, DHCP release) .
    • on trusted ports, any type of message is allowed.
      • #ip dhcp snooping trust
    • Untrusted ports do not accept messages with a non-zero Giaddr( i.e the frames which have been relayed ), so the interfaces shold be configured as trusted
    • DHCP snooping also populates a table which contains details like
      • IP adderss allocated to the client
      • client MAC address
      • client swx port
      • VLAN number
      • lease duration
    • The swx checks this table everytime it receives DHCP messages like DHCPRELEASE to make sure no one would spoof a DHCP message for another host.
    • to Start the DHCP snooping,
      • we need to activate it globally (and)
      • start it per vlan
    • when DHCP snooping is enabled , the swx  adds Option 82 field to all received packets. The purpose of this option is to identify the device and port that the client connects to.
    • THe thing is when DHCP snooping is enabled, even though some DHCP packets may be relayed, the giaddr field is kept to 0. But, the DHCP server receiving them will implicity reject these packets ‘coz he’s confused as to why the packets have Option 82 set, but they don’t have the giaddr field set to 0
    • To enable IOS to accept such messages. we have 3 options
      • Instruct the IOS DHCP server to accept DHCP messages with 0 “giaddr” using ip dhcp relay information trust-all , or interface level command ip dhcp relay information trusted
      • Configure the DHCP snooping feature in the switch not to insert Option 82, #no ip dhcp snooping information option
      • Trust the port where you receive the original DHCP message. The DHCP snooping doesnt’ insert information options for packets received on trusted ports.

• Dynamic Arp inspection
  • it prevents MITM attacks where the ARP messages are spoofed.
  • creates a IP to MAC address binding table in the swx.
  • this is dynamically populated based on the DHCP snooping database contents. Static entries can also be added.
  • This also prevents ARP poinsoning attacks.
  • On un-trusted ports, if the switch receives an ARP packet, it inspects the packet contents. If the IP, MAC address mapping corresponds with the ARP inspection table, the packet is permitted.Else dropped.
  • implementing this may break some services like Proxy ARP, etc.
  • to prevent this, the switch does not inspect any ARP message on trusted ports.
  • #ip arp inspection trust -> makes the port trusted. i.e the arp messages that are received aren’t checked against the ARP inspection database.
  • It can also check if the destination MAC address inside the ARP packet bodies match the destination address in Ethernet frames for ARP responses.Similarly for Source MAC’s.
  • This checking can be enabled using
    • #ip arp inspection validate src-mac
    • #ip arp inspection validate dst-mac
  • #ip arp inspection validate ip -> is used to perfom IP checks similar to the MAC checks ( stated in the previous point ) , it also ensures that no  host tries to bind it’s MAC address to IP such as 255.255.255.255. or 0.0.0.0
  • by default, ARP-inspection builds the mapping info based on the DHCP bindings table. If there are hosts not using DHCP, then we ned to configure ARP access-lists.
    • #arp access-list <ACL_NAME>
      • #permit [request|response] ip <address> <mask> mac <address> <mac> [log]
    • #ip arp inspection filter <ACL_NAME> vlan <VLAN_ID> [static].
  • The ARP acl’s take precendence over the DHCP bindings. As in, first the ARP acl’s are checked to see if the IP and MAC binding matches the incoming ARP packet, then the DHCP binding. ( unless there is an explicit DENY ALL) at the end of the ACL
  • To enable arp inspection we use the command,
    • #ip arp inspection vlan < VLAN-ID>
  • arp-probe packets are sent with a srouce IP of 0.0.0.0.
  • #ip arp inspection limit rate {<pps> [burst interval <seconds>] | none }
  • So, if the task asks us to enable ARP security without trusting any port, then statically configure ACL’s.
  • When it says additional “sanity” checks, do the “ip arp inspection validate src-mac dst-mac ip command.

• IP SOURCE GUARD
  • prevents IP packet spoofing at layer 2
  • when applied on a part , the switch only accepts the packets with source IP addresses matching DHCP snooping bindings created for the port.
  • Enabling DHCP snooping is a pre-requisite, but you may bind an IP address to a port manually.
  • It also allows ingress DHCP packets from the hosts.
  • #ip verify-source [port-security]
  • port-security option requires port-security to enabled on the switch port (#switchport port-security )as well.with this option, the swx flters packets based on the source IP and MAC address ( out of the DHCP binding table )

• NETFLOW
  • statistics gathering tool.
  • ingress flow : captures data on
    • Packets flowing into the router , to be either switched out or destined to the router
  • egress flow
    • packets which are switched through the router and which exit the router through an egress interface. Packets originated from the router are not included.
  • ingress netflow is applied before ACLs and rate-limiting and egress netflow is applied after rate-limiting and encryption features.
  • ver 5 of netflow is default on IOS routers.
  • For configuration, refer the workboook.
  • To enable it on an interface
    • ip flow ingress/egress
  • ip flow-top-talkers
    • this feature allows collecting information about most packet or traffic-intense flows.
    • we can filter the view, so that we can see only what we want , based on protocol types, address filtering and so onl.
    • ex : R2 should collect information about 10 most intense ICMP flows and it should count the packets. Match only the TCP and ICMP flows coming from the subnet 136.1.0.0/16
      • #ip flow-top-talkers
        • #top 10
        • #sort-by packets
        • #match source address 136.1.0.0 255.255.0.0
        • #match protocol 1 -> This means ICMP

• STP
  • BPDU guard
    • #int fa0/10
    • #spanning-tree bpduguard enable
    • if we receive a BPDU on thsi interfcec, the interface goes into err-disable mode
  • BPDU Filter
    • #int fa0/0
    • #spanning-tree bpdufilter enable
    • Here if receive a BPDU, it is ignored, but the interface still remains up
    • BPDU’s are also not sent out of this interface.
  • ROOT guard
    • #int fa0/0
    • #spanning-tree guard root
    • The difference between this and BPDU guard is that, here it MUST receive a “superior” BPDU before it goes into err-disable state. BPDU guard will go into err-disable irrespective of if its’ an inferior or superior BPDU
  • Port fast
    • #int fa0/0
    • #spanning-tree port-fast enable
  • The STP PortFast BPDU guard enhancement allows network designers to enforce the STP domain borders and keep the active topology predictable. The devices behind the ports that have STP PortFast enabled are not able to influence the STP topology. At the reception of BPDUs, the BPDU guard operation disables the port that has PortFast configured.

• RFC 1918/3330
  • We use infrastructure ACL’s to do the job
  • the iACL’s are deployed at the network ingress points.
  • these ipv4 and ipv6 ACL’s deny access from external sources to all infrastructre addresses ( ex : Router interfaces ) , but at the same time permit transit traffic to flow interrepted and provide basic RFC 1918, RFC 3330 and anti-spoof filtering
  • http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml
  • The singular purpose of the infrastructure protection ACL is to restrict on a granular level what protocols and sources can access critical infrastructure equipment
  • by network infrastructure equipment , we mean
    • all router anbd switch management addresses, including loopback addresses
    • all internal link addresses : Router-to-router links ( point-to-point and multiple access )
    • Internal servers or services that should not be accessed from external sources
    • Infrastructre protection can be achieved through the use of
      • Receive ACLs ( rACLs)
      • Hop-by-hop router ACLs
      • Edge filtering via Infrastructre ACL
       
    • Example :
      !— Anti-spoofing entries are shown here.
      
      
      !— Deny special-use address sources.
      !— Refer to RFC 3330 for additional special use addresses.
      
      access-list 110 deny ip host 0.0.0.0 any
      access-list 110 deny ip 127.0.0.0 0.255.255.255 any
      access-list 110 deny ip 192.0.2.0 0.0.0.255 any
      access-list 110 deny ip 224.0.0.0 31.255.255.255 any
      
      !— Filter RFC 1918 space.
      
      access-list 110 deny ip 10.0.0.0 0.255.255.255 any
      access-list 110 deny ip 172.16.0.0 0.15.255.255 any
      access-list 110 deny ip 192.168.0.0 0.0.255.255 any
      
      !— Deny your space as source from entering your AS.
      !— Deploy only at the AS edge.
      
      
      access-list 110 deny ip YOUR_CIDR_BLOCK any
      
      !— Permit BGP.
      
      access-list 110 permit tcp host bgp_peer host router_ip eq bgp
      access-list 110 permit tcp host bgp_peer eq bgp host router_ip
      
      !— Deny access to internal infrastructure addresses.
      
      access-list 110 deny ip any INTERNAL_INFRASTRUCTURE_ADDRESSES
      
      !— Permit transit traffic.
      
      access-list 110 permit ip any any –IMPORTANT!
    • In general an iACL consists of 4 sections
      • special-use addresses and anti-spoofing entries that deny illegitimate sources and packets with source addresses that belong withi the AS from entring the AS from an external source
      • Explicitly permitted externally sourced traffic destined to infrastructure addresses
      • deny statements for all other externally sourced traffic to infrastructure addresses
      • permit statements for all other traffic for normal backbone traffic en route to noninfrastructure destinations
    • use of the “fragments” keyword in ACE’s
      • ACLs have a fragments keyword that enables specialized fragmented packet-handling behavior. Without this fragments keyword, noninitial fragments that match the Layer 3 statements (irrespective of the Layer 4 information) in an ACL are affected by the permit or deny statement of the matched entry. However, by adding the fragments keyword, you can force ACLs to either deny or permit noninitial fragments with more granularity. This behavior is the same for both IPv4 and IPv6 access-lists, with the exception that, while IPv4 ACLs allow the use of the fragments keyword within Layer 3 and Layer 4 statements, IPv6 ACLs only allow the use of the fragments keyword within Layer 3 statements.Filtering fragments adds an additional layer of protection against a Denial of Service (DoS) attack that uses noninitial fragments (that is, FO > 0). Using a deny statement for noninitial fragments at the beginning of the ACL denies all noninitial fragments from accessing the router. Under rare circumstances, a valid session might require fragmentation, and therefore be filtered if a deny fragment statement exists in the ACL.For example, consider this partial IPv4ACL:
        

        access-list 110 deny tcp any infrastructure_IP fragments
        access-list 110 deny udp any infrastructure_IP fragments
        access-list 110 deny icmp any infrastructure_IP fragments
        <rest of ACL>

        The addition of these entries to the beginning of an ACL denies any noninitial fragment access to the core routers, while nonfragmented packets or initial fragments pass to the next lines of the ACL unaffected by the deny fragment statements. The preceding ACL command also facilitates classification of the attack since each protocol—Universal Datagram Protocol (UDP), TCP, and ICMP—increments separate counters in the ACL.

        This is a comparable example for IPv6:

            ipv6 access-list iacl
               deny ipv6 any infrastructure_IP fragments
        

        The addition of this entry to the beginning of an IPv6 ACL denies any noninitial fragment access to the core routers. As previously noted, IPv6 access-lists only allow the use of the fragments keyword within Layer 3 statements.

        Since many attacks rely on flooding core routers with fragmented packets, filtering incoming fragments to the core infrastructure provides an added measure of protection and helps ensure that an attack cannot inject fragments by simply matching Layer 3 rules in the infrastructure ACL.

• RFC 2827/3704
  •  RFC 2827 -> Anti spoofing guidelines. The source IP of the packet coming from outside,shouldn’t be the IP address of the AS ( your company’s private IP )
  • Transit ACL’s are used to explicity permitting only required traffic into your network or networks.

  • TRANSIT ACLs

    In general, a transit ACL is composed of four sections.

    • Special-use address and anti-spoofing entries that deny illegitimate sources and packets with source addresses that belong within your network from entering the network from an external sourceNote:  RFC 1918 defines reserved address space that is not a valid source address on the Internet. RFC 3330 defines special-use addresses that might require filtering. RFC 2827 provides anti-spoofing guidelines.
    • Explicitly permitted return traffic for internal connections to the Internet
    • Explicitly permitted externally sourced traffic destined to protected internal addresses
    • Explicit deny statement -> This is a difference between this and iACLs
  • In addition to direct protection, the transit ACL should also provide a first line of defense against certain types of invalid traffic on the Internet.
    • Deny RFC 1918 space.
    • Deny packets with a source address that falls under special-use address space, as defined in RFC 3330.
    • Apply anti-spoof filters, in accordance with RFC 2827; your address space should never be the source of packets from outside your autonomous system (AS).

    Other types of traffic to consider include:

    • External protocols and IP Addresses that need to communicate with the edge router
      • ICMP from service provider IP Addresses
      • Routing protocols
      • IPSec VPN, if an edge router is used as the termination
    • Explicitly permitted return traffic for internal connections to the Internet
      • Specific Internet Control Message Protocol (ICMP) types
      • Outbound Domain Name System (DNS) query replies
      • TCP established
      • User Datagram Protocol (UDP) return traffic
      • FTP data connections
      • TFTP data connections
      • Multimedia connections
    • Explicitly permitted externally sourced traffic destined to protected internal addresses
      • VPN Traffic
        • Internet Security Association and Key Management Protocol (ISAKMP)
        • Network Address Translation (NAT) Traversal
        • Proprietary encapsulation
        • Encapsulating Security Payload (ESP)
        • Authentication Header (AH)
      • HTTP to web servers
      • Secure Socket Layer (SSL) to web servers
      • FTP to FTP servers
      • Inbound FTP data connections
      • Inbound FTP passive (pasv) data connections
      • Simple Mail Transfer Protocol (SMTP)
      • Other applications and servers
      • Inbound DNS queries
      • Inbound DNS zone transfers
  •  EXAMPLE :
  • !— Add anti-spoofing entries.
    !— Deny special-use address sources.
    !— Refer to RFC 3330 for additional special use addresses.
    
    access-list 110 deny ip 127.0.0.0 0.255.255.255 any
    access-list 110 deny ip 192.0.2.0 0.0.0.255 any
    access-list 110 deny ip 224.0.0.0 31.255.255.255 any
    access-list 110 deny ip host 255.255.255.255 any
    
    !— The deny statement should not be configured
    !— on Dynamic Host Configuration Protocol (DHCP) relays.
    
    access-list 110 deny ip host 0.0.0.0 any
    
    !— Filter RFC 1918 space.
    
    access-list 110 deny ip 10.0.0.0 0.255.255.255 any
    access-list 110 deny ip 172.16.0.0 0.15.255.255 any
    access-list 110 deny ip 192.168.0.0 0.0.255.255 any
    
    !— Permit Border Gateway Protocol (BGP) to the edge router.
    
    access-list 110 permit tcp host bgp_peer gt 1023 host router_ip eq bgp
    access-list 110 permit tcp host bgp_peer eq bgp host router_ip gt 1023
    
    !— Deny your space as source (as noted in RFC 2827).
    
    access-list 110 deny ip your Internet-routable subnet any
    
    !— Explicitly permit return traffic.
    !— Allow specific ICMP types.
    
    access-list 110 permit icmp any any echo-reply
    access-list 110 permit icmp any any unreachable
    access-list 110 permit icmp any any time-exceeded
    access-list 110 deny   icmp any any
    
    !— These are outgoing DNS queries.
    
    access-list 110 permit udp any eq 53  host primary DNS server gt 1023
    
    !— Permit older DNS queries and replies to primary DNS server.
    
    access-list 110 permit udp any eq 53  host primary DNS server eq 53
    
    !— Permit legitimate business traffic.
    
    access-list 110 permit tcp any Internet-routable subnet established
    access-list 110 permit udp any range 1 1023 Internet-routable subnet gt 1023
    
    !— Allow ftp data connections.
    
    access-list 110 permit tcp any eq 20 Internet-routable subnet gt 1023
    
    !— Allow tftp data and multimedia connections.
    
    access-list 110 permit udp any gt 1023 Internet-routable subnet gt 1023
    
    !— Explicitly permit externally sourced traffic.
    !— These are incoming DNS queries.
    
    access-list 110 permit udp any gt 1023 host <primary DNS server> eq 53
    
    !– These are zone transfer DNS queries to primary DNS server.
    
    access-list 110 permit tcp host secondary DNS server gt 1023 host primary DNS server eq 53
    
    !— Permit older DNS zone transfers.
    
    access-list 110 permit tcp host secondary DNS server eq 53  host primary DNS server eq 53
    
    !— Deny all other DNS traffic.
    
    access-list 110 deny udp any any eq 53
    access-list 110 deny tcp any any eq 53
    
    !— Allow IPSec VPN traffic.
    
    access-list 110 permit udp any host IPSec headend device eq 500
    access-list 110 permit udp any host IPSec headend device eq 4500
    access-list 110 permit 50 any host IPSec headend device
    access-list 110 permit 51 any host IPSec headend device
    access-list 110 deny   ip any host IPSec headend device
    
    !— These are Internet-sourced connections to
    !— publicly accessible servers.
    
    access-list 110 permit tcp any host public web server eq 80
    access-list 110 permit tcp any host public web server eq 443
    access-list 110 permit tcp any host public FTP server eq 21
    
    !— Data connections to the FTP server are allowed
    !— by the permit established ACE.
    !— Allow PASV data connections to the FTP server.
    
    access-list 110 permit tcp any gt 1023 host public FTP server gt 1023
    access-list 110 permit tcp any host public SMTP server eq 25
    
    !— Explicitly deny all other traffic.
    
    
    access-list 101 deny ip any any

• SINK HOLES
  •  http://www.cisco.com/web/about/security/intelligence/worm-mitigation-whitepaper.html
  •  is used to engulf network attacks and draw the attacks away from the targetTHE ATTACK
  • 
  • THE DIVERSION
  • 

• BLACK HOLES
  • used to drop undesirable traffic before it enters a protected network.
  • used for the mitigattion of dDos attacks , worm attack mitigation , blacklist filtering
  •  http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd80313fac.pdf
  •  Destination based IP black holes with remote triggerring allows a network-wide destination-based black hole to be propagted by adding a simple static route to the triggerring device ( trigger )
  • Source based IP black hole triggering uses uRPF(loose)
    • if the router doesn’t have a route for the source of the packet
    • (or) if theroute points to a null route ( null 0 ) , then the packet is dropped
  • so all we need to do is to create a static route for the source IP , pointing it to Null0 and advertise it.
  • also make sure we disable ICMP unreachables on the null 0 interfaces

• DOS prevention and Smurf attacks
            http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080149ad6.shtml
  •  SMURF attack victim protection
    • IDENTIFICATION OF THE VICTIM : if we do a packet analysis, we will see a large amount of echo-replies
    • One stopgap measure is to ask the upstream network provider to filter out all ICMP echo replies, or all ICMP echo replies from specific reflectors. It is not recommended that you leave this sort of filter in place permanently. Even for a temporary filter, only echo replies should be filtered, not all ICMP packets. Another possibility is to have the upstream provider use Quality of Service and rate limiting features to restrict the bandwidth available to echo replies. A reasonable bandwidth limitation can be left in place indefinitely. Both of these approaches depend on the equipment of the upstream provider having the necessary capacity, and sometimes that capacity is not available.
  •  SMURF REFLECTOR PROTECTION
    • There are several ways to distinguish the smurf attack from the simple ping flood:
      • Smurf stimulus packets are sent to a directed broadcast address, rather than to a unicast address, whereas ordinary ping floods almost always use unicasts. You can see the addresses that use the log-input keyword on the appropriate access list entry.
      • If you are used as a smurf reflector, there is a disproportionate number of output broadcasts in the show interface display on the Ethernet side of the system, and usually a disproportionate number of broadcasts sent in the show ip traffic display. A standard ping flood does not increase the background broadcast traffic.
      • If you are used as a smurf reflector, there is more traffic outgoing towards the Internet than traffic incoming from the Internet. In general, there is more output packets than input packets on the serial interface. Even if the stimulus stream completely fills the input interface, the response stream is larger than the stimulus stream, and packet drops are counted.
    • A smurf reflector has more options than the ultimate target of a smurf attack. If a reflector chooses to shut down the attack, appropriate use of no ip directed-broadcast (or equivalent non-IOS commands) usually suffices
  • FRAGGLE ATTACK
    • Similar to smurf attack , but here UDP echo requests are used for the stimulus stream instead of ICMP echo requests.
    • The best way to mitigate this, is to “COMPLETELY DISABLE ” udp echo-requests
  • SYN Floods
    • in a usual network, the number of non-SYN TCP packets outnumber the SYN packets by a fcator of 4-5 atleast.
    • But here, we will see that the number of ACK packets are high.
    •  usually, the Source IP of the SYN packets contain invalid source addreesses.
    • PROCESS ATTACK  : In the process table attack, the TCP connections are completed, then allowed to time out with no further protocol traffic, whereas in the SYN flood, only the initial connection requests are sent.
    •  Response options for the victims of SYN floods are very limited. The system under attack is usually an important service, and blocking access to the system usually accomplishes what the attacker wants

• DDOS prevention
  •  http://www.cisco.com/en/US/tech/tk59/technologies_white_paper09186a0080174a5b.shtml
  •  
  •  Behind a Client is a person that orchestrate an attack. A Handler is a compromised host with a special program running on it. Each handler is capable of controlling multiple agents. An Agent is a compromised host that is running a special program. Each agent is responsible for generating a stream of packets that is directed toward the intended victim
  • Prevention methods
    • urpf
      • use the #ip verify unicast reverse-path ( old ) interface command on the input interface on the router at the upstream end of the connection.
      • so the packets without a known route in the CEF table, will be dropped.
      • it stops SMURF attacks.
    • filter all rfc 1918  addresses using ACLs
    • Apply ingress and egress filtering ( RFC 2267 ) using ACLs
      •  similar to rfc 2827
      • The ISP should not accept packets who’s IP  is’nt the customer’s IP
      • the customer should not accept packets with its own IP as the source of the packet( RFC 2827 )
    • CAR for ICMP packets
      • use CAR to limit ICMP packets
      • #access-list 2020 permit icmp any any echo-reply
      • #int fa 0/0
      • #rate-limit output accesss-group 2020 300000 512000 786000 conform-action transmit exceed-action drop
    • CAR for SYN packets / ACK packets

• VLAN SECURITY
  •  http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml

• RANDOM NOTES
  • RIP uses udp port 520
  • The differnce between intercept and watch mode is that, in the intercept mode, suppose the client stops responding, it uses a random backoff approach to contact the client, after which the entry is removed.
  • whereas in watch mode, as soon as the watch-timeout expires, it sends RST to both the client and the server if they are not responding
  • In urpf there are 2 modes
    • Strict mode : ip verify unicast source reachable-via rx
      
      •  here when a packet is received, it is checked for 2 things
        • 1 ) Is there a route to the source in the routing table ( CEF table )
        • 2 ) is the interface on which it’s coming, the next hop interface used for that remote source IP
    • Loose mode : ip verify unicast source reachable-via any
      • here when a packet is received, it is only checked if there is a route to it. The interface on which it comes does not matter
  • to test uRPF, create a loopback interface on one of the routers, and ping using that as the source. If you want to see the logs of the packets that are not matching, create an ACL ” access-list 101 deny ip any any log” and link it to the command using ” ip verify unicast source reachable-via rx 101 “
  • to enable unreachables to be sent during testing of route-map, disable cef on the interface where you are testng, using ” #int fa0/0  , #no ip route-cache”
  • we cannnot apply mac or ip acces-list on the outbound direction on L2 ports on a swx. You can only do that on the SVI.
  • in 3550, mac-acls match only non-ip traffc such as ARP, STP and IPv6.

          ACL caveats

The counter on an access list entry counts all matches against that entry. If you apply an access list to two interfaces, the counts you see are aggregate counts.

Access list logging does not show every packet that matches an entry. Logging is rate-limited to avoid CPU overload. What logging shows you is a reasonably representative sample, but not a complete packet trace. Remember that there are packets that you do not see.

In some software versions, access list logging works only in certain switching modes. If an access list entry counts a lot of matches, but logs nothing, try to clear the route cache to force packets to be process switched. Be careful if you do this on heavily loaded routers with many interfaces. A lot of traffic can get dropped while the cache is rebuilt. Use Cisco Express Forwarding whenever possible.

Access lists and logging have a performance impact, but not a large one. Be careful on routers that run at more than about 80 percent CPU load, or when you apply access lists to very high-speed interfaces