For the purpose of this article, this configuration and discussion pertains to a Cisco Nexus 5020 switch running NX-OS version 4.1(3)N1(1a). Given what seems to be a variety of changes to the CLI configuration process for the Nexus, this may or may not work for you.

I felt it was important to write myself a reminder of how to create a lossless Ethernet network using Cisco Nexus devices as QoS on this platform seems to be similar, yet, take a divergent path from the methodology of configuring QoS on the Catalyst series. In this example we will assume we are working users that are requesting that any traffic marked with CoS 5 be placed in the no-drop queue. The flagship example of this is the Fiber Channel over Ethernet (FCoE) configuration present in the system configuration, although they use CoS 3, by default.

The first step is to create a qos class-map:

class-map type qos MATCH-COS-FIVE
  match cos 5

Next create a qos policy-map to set the qos-group to 2:

policy-map type qos SET-QOS-GROUP-TWO
  class MATCH-COS-FIVE
    set qos-group 2

qos-group 1 is a system default for the FCoE configuration. Setting this to our own group allows us to have different parameters for FCoE should you need to manipulate it differently in the future.

Next create a network-qos class-map to match qos-group 2:

class-map type network-qos MATCH-QOS-GROUP-TWO
  match qos-group 2

Now, create a policy-map you wish to use to manage QoS on a system wide level and ensure traffic matching qos-group 2 is in the no-drop queue.

policy-map type network-qos SYSTEM-QOS-POLICY
  class type network-qos MATCH-QOS-GROUP-TWO
    pause no-drop
  class type network-qos class-default
    mtu 9216

In this case the class-default matches other traffic and permits the MTU to be jumbo framed at 9216 bytes.

Apply the system policy we created to system qos:

system qos
  service-policy type network-qos SYSTEM-QOS-POLICY

We are now at the point where matching CoS values can be done on a system-wide level or per interface. To apply the policy system-wide:

system qos
  service-policy type qos SET-QOS-GROUP-TWO

Be aware that if you are running within a VPC domain that this may very well cause a system compatibility failure and disable links within your VPC domain. Apply this configuration domain-wide if you are interested in have this feature across multiple switches.

Otherwise you can apply the CoS matching on a per interface level:

interface Ethernet1/1
  service-policy type qos input SET-QOS-GROUP-TWO

To verify packets are matching your newly defined qos-group:

switch# show queuing interface Ethernet 1/10

If traffic is being sent that is tagged with CoS 5 you should be seeing traffic on your qos-group:

qos-group  2:
    q-size: 81920, MTU: 9216
    drop-type: no-drop, xon: 128, xoff: 230
    Statistics:
        Pkts received over the port             : 2767031
        Ucast pkts sent to the cross-bar        : 2767030
        Mcast pkts sent to the cross-bar        : 1
        Ucast pkts received from the cross-bar  : 270664
        Pkts sent to the port                   : 270664
        Pkts discarded on ingress               : 0
        Per-priority-pause status               : Rx (Inactive), Tx (Inactive)

All should be well and drop-type should be reading no-drop. If you are interested in applying bandwidth shaping, then this can be accomplished in a similar manner using the queuing type class and policy maps to map and take action with traffic in qos-group 2. That service policy can also be applied system-wide or on an interface level as shown above.

Jonathan Voss - Jan 14, 2011

Cisco IOS Firewall is capable of stateful packet filtering when it is configured to do so.

By applying inspection rules to an interface, you can configure the router to drop packets that could be potentially harmful given the state of a currently established session. For example, using a TCP inspection rule will not allow a TCP reset (RST) packet through the interface unless there is currently a TCP session established with the machine sending the reset.

To apply stateful packet filtering rules, you must apply an access control list (ACL) to the interface you wish to inspect. Packets traversing this interface will then be examined against the ACL first, then checked against the inspection rule(s) to determine whether the packet should be forwarded or dropped. Note that any packet may be rejected by the inspection rules, ACL, or both!

First, decide which interface you would like to do stateful inspection on. This is typically your WAN or untrusted network interface. Configure an IP ACL with this interface in mind. If you are configuring a firewall for an interface that uses DHCP, keep in mind that the destination IP for packets allowed in will be the IP address assigned to that interface. Therefore I generally use any and remember it is there for that purpose. This alleviates the issue of having to adjust ACLs every time your router receives a new IP address from your ISP. Also keep in mind that you must use an extended ACL when you are also using inspection rules:

Router(config)#ip access-list extended Internet-inbound-ACL
Router(config-ext-nacl)#10 permit tcp any any eq 22
Router(config-ext-nacl)#20 deny ip any any log

The above permits traffic on port 22 (SSH) to traverse the interface. The deny statement is added for clarity and logging.

Next define your inspection rules. IOS supports more than 170 protocols:
[no] ip inspect name inspection-name protocol [alert {on | off}] [timeout seconds]

Router(config)#ip inspect name FIREWALL tcp
Router(config)#ip inspect name FIREWALL udp

Finally apply the ACL and the inspection rules to the interface:

Router(config)#interface FastEthernet4
Router(config-if)#ip access-group Internet-inbound-ACL in
Router(config-if)#ip inspect FIREWALL out

It is important that the inspect statement is applied in the outbound direction. I found numerous documentation that stated it needed to be applied in the inbound direction, however I have found that this does not work and any new connection attempts are not stored in the session table or permitted through the interface!

You can verify the configuration that was just applied by issuing a show ip inspect sessioncommand. The output should look something like this:

Router#sh ip inspect sessions 
Established Sessions
 Session 83C60000 (192.168.0.3:44271)=>(76.73.X.X:22) ssh SIS_OPEN
 Session 83C65828 (192.168.0.4:54333)=>(74.X.X.X:5222) tcp SIS_OPEN
 Session 83C5AAB0 (192.168.0.4:54327)=>(208.43.X.X:80) tcp SIS_OPEN
 Session 83C685A8 (192.168.0.4:54335)=>(174.X.X.X:443) tcp SIS_OPEN
 Session 83C66EE8 (192.168.0.4:54332)=>(74.X.X.X:5222) tcp SIS_OPEN
 Session 83C63BB8 (192.168.0.4:54334)=>(208.89.X.X:80) tcp SIS_OPEN
Jonathan Voss - Apr 5, 2010