hostname(config)#no logging snmp-authfail

Do not trust the almighty ‘?‘ command. It will not show up as a valid option. However, when actually executing the command, it has worked in every IOS case I have tried.

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.

Switch>enable
Switch#config t
Switch(config)#sdm prefer dual-ipv4-and-ipv6
Switch(config)#end
Switch#reload

Unfortunately, you will need to reload (reboot) the device in order for the changes to take place, which will obviously incur annoying downtime for your users. Once the device has reloaded you can verify by issuing a show sdm prefer command which should look something like this:

Switch#show sdm  prefer
 The current template is "desktop IPv4 and IPv6 default" template.
 The selected template optimizes the resources in
 the switch to support this level of features for
 8 routed interfaces and 1024 VLANs.

  number of unicast mac addresses:                  2K
  number of IPv4 IGMP groups + multicast routes:    1K
  number of IPv4 unicast routes:                    3K
    number of directly-connected IPv4 hosts:        2K
    number of indirect IPv4 routes:                 1K
  number of IPv6 multicast groups:                  1.125k
  number of directly-connected IPv6 addresses:      2K
  number of indirect IPv6 unicast routes:           1K
  number of IPv4 policy based routing aces:         0
  number of IPv4/MAC qos aces:                      0.5K
  number of IPv4/MAC security aces:                 1K
  number of IPv6 policy based routing aces:         0
  number of IPv6 qos aces:                          0.5K
  number of IPv6 security aces:                     0.5K

Now you should be able to configure IPv6 interfaces and ACLs.

Although their guide describes this process in enough detail to fit a lot of different situations, I felt it would be useful to revisit the configuration process in hopes of helping other people facing similar requirements and for my own documentation purposes.

Everything in this article was used specifically with a Cisco 1811 router running 12.4(24)T2 Advanced IP Services software, however the majority of this guide should work with any recent integrated service router with advanced IP services.

Scenario

This example describes a router that has one DHCP-configured interface to one ISP and one static address to another ISP, each on different WAN interfaces of this router. You should configure policy-based routing will be configured for specific or secure traffic (such as HTTPS, SSH, etc) to ensure that it always uses one ISP connection. Fail-over redundancy will also be configured in the event one of these connections become unavailable. This configuration also assumes the interfaces and NAT has already been configured for each connection.

Configuration

Specify the desired object tracking timer for interfaces in seconds. I used 5 as did the Cisco documentation:

track timer interface 5

Next create new tracked SLA objects – one for each of the ISP connections, and add desired delay change notifications in seconds:

track 100 ip sla 1 reachability
 delay down 15 up 10
track 200 ip sla 2 reachability
 delay down 15 up 10

For an interface running DHCP, route tracking can be enabled with the following interface configuration command:

ip dhcp client route track 100

*Where 100 is the desired tracking object number created above

Modify the static IP default route entry for the static IP connection to be tracked:

ip route 0.0.0.0 0.0.0.0 interface FastEthernet1 [next hop] 254 track 200

The digits in orange signify the metric for this static route. Since the DHCP learned route has a metric of 254, I set this static default route with the same metric so that equal-cost load balancing could be achieved. The red digits should match the desired object track number we created earlier.

Next configure an OER tracking entry to monitor each ISP connection. The icmp-echo line can be a difficult choice. It is important to identify an address to ping that is reachable only through that connection. With the addition of the source-interface line referencing an outside interface with a global address, I do not believe this to be an issue in the majority of topologies as the echo reply would never make it back the device, however I have not had sufficient time to experiment with this case to see how this works in reality.

ip sla 1
 icmp-echo 172.31.100.1 source-interface FastEthernet0
 timeout 1000
 threshold 40
 frequency 3
ip sla 2
 icmp-echo 172.31.200.1 source-interface FastEthernet1
 timeout 1000
 threshold 40
 frequency 3

Schedule the new SLAs for start time and duration:

ip sla schedule 1 life forever start-time now
ip sla schedule 2 life forever start-time now

Fail-over redundancy

Tacked on to the route-maps configured to allow NAT, I added an additional permit sequence that set the next hop based on availability:

route-map NET1 permit 10
  match ip address NETWORK1
  set ip next-hop verify-availability [primary route] 10 track 100
  set ip next-hop verify-availability [secondary route] 20 track 200
route-map NET2 permit 10
  match ip address NETWORK2
  set ip next-hop verify-availability [primary route] 10 track 200
  set ip next-hop verify-availability [secondary route] 20 track 100

This will set specify which router should be primary for each network. In this case I set each network’s primary route to a different connection in an effort to spread the load but still ensure both networks work in the event either ISP connection were to fail.

Conclusion

So now that load-balancing has somewhat been configured on the device, it is time to talk about the feasibility. The one point to take away from this is that it is not true load-balancing even if there are two equal default routes to choose. This is because the nature of NAT will force the session on to one of the two connections.  My suggestion is to use this but limit the subnets to use one primarily and the other for backup, alternating the networks between the two WAN connections. In the end, this is what I did and has been a wonderful solution overall.