Blog‎ > ‎


posted Apr 23, 2014, 7:45 PM by Rick McGee
ACL Type and Applications in NX-OS

    Nexus suport he following type of ACL's for security traffic filtering
        IPv4 ACL's    
            Object groups can be used for IPv4 and Port (PBACL Policy Based)
                Doesn't limit ACE's (ACL control entries) to SoC (switch on chip)
        IPv5 ACL's 
            Object groups can be used for IPv6 and PBACL
        MAC ACL's 
            The device applies MAC ACL's only to non-IP traffic by default, but you can also 
            configure L2 interfaces to apply MAC ACL's to all traffic
        Security-Group ACL's (SGACL's)
             A device applies SGACL's to traffic tagged by Cisco TrustSec

IP and MAC ACL's 
    IP and MAC ACL's have the following types of applications
         Port ACL= L2 interface that can support IPv4/v6, MAC ACL's 
            Filters L2 traffic ( can peer into L3 and L4 traffic)
        Route ACL= Any L3 interface Physical, Sub, SVI, Port-Channel, Tunnel, and mgmt
            Support IPv4/v6
            Supports MAC ACL's only if the "mac packet classify" is enabled 
            Filters Layer 3 traffic

        VLAN ACL= VLAN itself doesn't have to be an SVI IPv4/v6, MAC
            Filters VLAN traffic

        VTY ACL= VTY IPv4/v6
            Can filter VTY Telnet and SSH traffic to the device

        Policy Based ACL's (PBACL) 
            Using Object Groups in conjunction with ACL's 
            PBACL's don't reduce the resources required by an ACL when you apply it to an 
            When you apply a BPACL, the device expands each rule that refers to an object
            group into one ACL entry per object within the group
            If a rule specifies the source and destination both with an object group, the 
            number of ACE's created on the I/O module when  you apply the PBACL is 
            equal to the number of objects in the source group X the number of objects in 
            the destination group. You have to take care not to exhaust the TCAM

    Security group ACL's
    The device applies Fibre Channel over Ethernet ACL's only to Fibre Channel traffic

!! Nexus Switches don't match traffic generated by itself by default!!
    You have to specify with "ip access-list match-local-traffic" command

ACL Logging 
    NX-OS doesn't log ACL's like Catalyst IOS does
    A log message is not generated every time ACE has a hit
    Instead, hit notifications are send at specific intervals
    Optimized Access-list logging (OAL) is a feature that was introduced in the 6500 
    series switches age's ago
    Nexus 7K's uses the same architecture to keep the CPU from being overrun with ACL's
    that end users may have miss configured and want to log.
    OAL provides hardware support for ACL logging and permits or drops packets in 
    hardware and uses an optimized routine to send information to the Supervisor 
    to generate the logging messages
    On the 6500/7600 OAL was optional and off by default

    For the Nexus 7K's, OAL is  your only option for ACL logging
        "sh logging ip access-list cache" (show the hits per ACE (Access Control Entries) 
        Can modify the command output by 
        "loggin ip access-list cache"
            Entries - Sets the max flow numbers of cached entries 
            interval- Sets interval between logging
            threshold- sets the hit counter value at which we start logging an ACL entry

Atomic ACL updates
    By default, when a SUP module in a Cisco Nexus 7K switch updates an I/O module with 
    changes to an ACL, it performs an atomic ACL update
    Atomic updates don't disrupt traffic that the updated ACL applies to. The Atomic
    update requires that that an I/O module that receives an ACL updated has enough
    resources (TCAM memory space) to store each updated ACL entry in addition to all
    pre-existing ACL's. After the update occurs, the additional resources are freed up
    by the removal of the older ACL entries. If the I/O module doesn't have enough 
    resources the Nexus 7K will generate an error message and the ACL update to the 
    I/O module will fail

    If an I/O module lacks the resources required for an atomic update, you can disable
    them. If you do this applying new ACl's to an I/O module will be disruptive.

    For instance if you would like to permit all traffic that an ACL applies to while it 
    receives a non-atomic update
        "hardware access-list update default-result permit"

    You can use ACL with the capture purpose to SPAN (monitor) only certain types of 
    traffic coming from a port

ACL Oder of operation


    conf t
    ip access-list L3Port
    10 permit tcp 

Config t
    object-group ip address SERVERS
    10 host
    object-group ip port WEB
    10 eq 80
    20 eq 443
    30 range 8000 8999
    ip access-list L3Port
    10 permit tcp addrgroup SERVERS portgroup WEB any

 sh run | sec access|object

    config t
    vlan access-map VACL-MAP 10
    match ip address L3Port
    action forward
to apply 
    vlan filter VACL-MAP 10 vlan-list (to one or more vlan's)

    statistics per-entry (more detailed logging)

    conf t
    hardware access-list updated default-result permit 
        this will allow you to updated the ACL iff you don't have 
        enough memory for the older ACL and newer ACL the updated will fail.
    no hardware access-list update atomic
        This will disable atomic access list updates all together 

ACL capture 
    hardware access-list capture 
    ip access-list CAP
    capture session 1 (have to apply to an interface)
    permit tcp any any eq 80
    permit tcp any any eq 443
    deny ip any any
    monitor session 1

show log ip access-list cache 
    logging level acllog 3 (severity level 3)
    acllog match-log level 3

    logging logfile ACLLOGFILE 3