Archive

Archive for the ‘QoS’ Category

CiscoLive 2012 – Day 2

Note to self – don’t forget your badge.  I was walking out the door of the hotel to catch the shuttle to the convention center when I realized that my badge was back in my room.  That would have been bad – no session access (bad) and no breakfast (worse.)  Thankfully, I remembered before leaving.

As I said in my last post, one of the awesome pieces of CiscoLive is meeting new people.  This morning at breakfast was no exception.  I had a great discussion with an engineer from Montreal and another from West Point.  Though it was mostly on wireless, they made an interesting point about being the “expert” for a technology since they had installed that technology once.  It is interesting that in the world of networking, if you’ve done it, you’re the expert (at least in the eyes of some.)

My first session was BRKSEC-2022, “Demystifying TrustSec, Identity, NAC, and ISE” by Aaron Woland.  I highly recommend any sessions that he does, as he is a very engaging and knowledgeable speaker.  And, he busts on Cisco from time to time, which is good to see.  Though most of the sessions was review, having taken the ISE class, it was good to have some concepts reaffirmed.  A couple of key points from this session were:

1. For TrustSec (which is the former name of “Secure Group Access” or SGA – thanks Cisco for reusing a term that now includes the former use plus more!),identity means the Who, What, Where, When and How of access.  With that, most of the work of ISE is in the Authorization piece.  While Authentication is good, it is not nearly enough.

2. At least for Wired 802.1X, deploy in Monitor Mode to begin with.  That way you don’t cause yourself a DoS when you bring it up.  There are too many variables involved that can cause clients to not connect properly to begin with.  With this, make sure that the network device and the backend server (ISE in this case) are set up properly for logging what is going on.  That way you can see what is going on.  Also, make sure URL Redirect is not part of the Authorization policy being tested, unless you really want them to be redirected to begin with.

3. Most supplicants don’t have sufficient logging for troubleshooting issues.  Cisco provides the AnyConnect Network Access Manager as a no-cost licensed product for as many clients as needed for those that have ASA5500s, ACS, ISE, Cisco switches, or anything with which AnyConnect could interconnect as long as that component is under Cisco SmartNet.  What that “no-cost” license does is allows for TAC access.  AnyConnect also provides DART.

My second session, vearing from the mobility/security side was “Nexus 7000 Hardware Architecture.”  I’ve worked with these a little bit, so I wanted to better understand what was going on under the hood.  I found that you almost need a PhD in Nexusology to understand how things can be grouped or not-grouped or whatever.  Also, the way that queueing is performed has forced me to rethink the N7K QoS configs I’ve done.  This is due to mostly ingress queueing, before traffic is placed on the fabric.  There is some egress queueing, but the arbiter has already done most of that work prior to placing it on the output interface.

The third session brought me back to ISE.  Another terrific session delivered by Aaron Woland.  Note to self: book sessions with him whenever possible!  He brought a lot of terrific tips and hints that you wouldn’t automatically think of when implementing ISE.  A few key ones for me were:

1. When running ISE install wizard, use lower-case for the hostname.  That will alleviate issues later.

2. All ISE nodes must be resolvable by their FQDN.  Also, a DNS A Record should also have accompanying Pointer Record.  Otherwise, you will not get the redirects that you are wanting.

3. Related to #2, there is a way of creating the certificate such that it allows for the use of multiple host names (such as one for administering ISE, another for sponsors, another for guests, etc.) by the use of Subject Alternate Names.  That requires some OpenSSL magic.  They should have something about this in an upcoming guide.

4. Time Zone = UTC is best practice for a distributed deployment.  Also, remember that if you change the time zone on an ISE, the database is deleted!  So, set this during initial setup.  BTW, for the Eastern Time Zone in the United States, use EST5EDT in order to allow for Daylight Saving Time.

5. Always use the RADIUS probe, and usually the DHCP probe.  Use as few as required to get the information you need.

While all these were great, the highlight of the day was going to dinner at Jakes’s Del Mar in Del Mar, CA with Pat Goessling, Annese Account Manager, and several customers.  We were right on the ocean and had a terrific time talking and laughing.

Advertisements

Nexus 7K QoS – Part 1

2011/12/02 2 comments

I’m working on a project for a customer where QoS for the Nexus 7K is a requirement.  Anyone who has attempted to configure QoS on these boxes has probably questioned how different are these devices from, say, the Catalyst 6500s.  Well, they are quite different.  If you are familiar with Modular QoS CLI (MQC,) that is a huge advantage, as all QoS configuration on the N7K is based on MQC.

IMPORTANT NOTE:  DISCUSSIONS AND CONFIGURATIONS FOR THIS SERIES ARE BASED ON NX-OS 5.1(1).  PREVIOUS FIRMWARE VERSIONS DO NOT SUPPORT ALL OF THESE FEATURES!

Let me start by pointing out some key differences between the 6500 and the N7k.

6500 N7K
ENABLE QOS       mls qos Enabled by default
TRUST mls qos trust [cos|dscp|ip-precedence] DSCP (on M1 modules) and CoS (on F1 modules) trusted by default
INTERNAL QOS QoS Label is used internally CoS and/or DSCP passed through, though QoS-Groups can be used
COS TO DSCP MAPPING Default of CoS to 3 most significant bits of DSCP (CoS 1 to DSCP 8 ) Same
DSCP to COS MAPPING Default 3 most significant bits of DSCP to CoS (DSCP 10 to CoS 1) Same
CHANGE COS/DSCP MAPPING Modify cos-dscp or dscp-cos maps Create and apply qos policy-map(s) ingress and/or egress

So, it’s a different way of thinking about QoS when it comes to the Nexus 7Ks.  Why should things stay the same (rhetorical question…)  And, I haven’t even discussed ingress or egress queueing.

In addition to thinking in terms of class-maps and policy-maps, there are some other key pieces that need to be understood.  First, there are three class-map and policy-map object-types that can be created:

  1. Network qos: This is defined in the default VDC.  It defines CoS properties for the entire switch, including all VDCs.  These can be overriden per interface.
  2. QoS: They can be applied ingress and egress to interfaces.  They can be used to mark and police traffic.
  3. Queuing: They can be  ingress and egress to interfaces.  They can be used to mark, shape and (not surprisingly) queue traffic.
    • NOTE: “queuing” class-maps are pre-defined and CANNOT be changed.  These are defined per the input and output queuing options of the specific module.

Another aspect that makes N7K interesting is that different modules (the M1(-XL) and the F1) have different options for QoS.  In particular, the F1 queueing policies should match the network-qos policies.  Also, F1 modules don’t support mapping to QoS Groups.  The “Cisco Nexus 7000 Series NX-OS Quality of Service Configuration Guide, Release 5.X” has further information on the F1 and specific items for its configuration.

In working through an N7K QoS configuration, I came to the conclusion that it generally makes sense to do the following:

  1. Develop a QoS policy for inbound traffic.  Trusting is fine, but is module dependent (see above on the M1 and F1 differences.)  Matching and either trusting or changing DSCP values, in particular, was key to the proper development of the config.
  2. Develop a queuing policy for outbound traffic.  What CoS values should be used for which output queues (module dependent)?  Is priority queuing needed? What DWRR weights should be used for each CoS value?

So, again – inbound QoS and outbound queueing seems to make the most sense for building QoS configurations for most situations.  And, having that decided helps in better determining the actual configurations.

In part 2, I’ll go through a network-qos policy configuration, an ingress qos policy, and an ingress queueing policy to provide some more concrete examples.