Cisco Prime – This is what it is good for. Part 1

In the last post we looked briefly at a scripting sample on adding QoS commands to IOS-X and IOS switches using Prime Infrastructure. To recap, we were looking to push QoS policies to ~1,000 switches of various models, IOS versions and even line cards. Using APIC-EM was not an option as only about half the switches were supported either because of old platform, IOS or other issues. Prime was selected since it had just been stood up for the wireless implementation and could push to all the various switch types, from 2960 to Nexus 7K.

With the scripts we needed to take into account the platform of the switch, the IOS and linecards as previously mentioned. This process has to use a combination of automation through Prime as well as manual intervention to know what the linecard is installed in the switch so it can be selected from a drop-down of available cards.

Last time we looked at a basic IOS config for QoS, how do we handle a 6500 series with a variety of linecards? Below is a sample of how this had to be handled.

The first thing, as with the previous script is we have to query the Prime DB structure and set the variables for the slots on the switches.

<parameter-metadata>

<param-group cliName=”cli command set” isMandatory=”true” name=”Deploy_QoS_Cat6500 parameters”>

                <description>Parameters for Deploy_QoS_Cat6500</description>

                <parameter name=”slot1″>

                    <description>Line Card Slot 1 Type</description>

 <default-value label=”Select the appropriate line card type or none for slot 1″>None</default-value>

                    <default-value>6148</default-value>

                    <default-value>6524</default-value>

                    <default-value>6704</default-value>

                    <default-value>6724</default-value>

                    <default-value>6748</default-value>

                    <default-value>6824</default-value>

                    <default-value>6848</default-value>

                    <data-type>Dropdown</data-type>

                    <mandatory>true</mandatory>

                    <isGlobal>false</isGlobal>

                    <syntax>

                        <pattern/>

                    </syntax>

                    <isGlobalVariable>false</isGlobalVariable>

                </parameter>

 

This has to be done for each possible line slot depending on the model. We went all the way to 13 based on the customer having a number of 6513 chassis.

Next we get to the meat of the QoS config that will be applied to the ports.

mls qos

mls qos map cos-dscp 0 10 18 26 34 46 48 56

 

##Queuing command structure

 

#set ( $OnePSevenQEightT = “wrr-queue queue-limit 10 25 10 10 10 10 10

wrr-queue bandwidth 1 25 4 10 10 10 10

            priority-queue queue-limit 15

wrr-queue random-detect 1

            wrr-queue random-detect 2

            wrr-queue random-detect 3

            wrr-queue random-detect 4

            wrr-queue random-detect 5

            wrr-queue random-detect 6

            wrr-queue random-detect 7

wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 1 80 100 100 100 100 100 100 100

            wrr-queue random-detect max-threshold 2 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 2 80 100 100 100 100 100 100 100

            wrr-queue random-detect max-threshold 3 100 100 100 100 100 100 100 100

            wrr-queue random-detect min-threshold 3 80 100 100 100 100 100 100 100

            wrr-queue random-detect max-threshold 4 100 100 100 100 100 100 100 100

            wrr-queue random-detect min-threshold 4 80 100 100 100 100 100 100 100

            wrr-queue random-detect max-threshold 5 100 100 100 100 100 100 100 100

            wrr-queue random-detect min-threshold 5 80 100 100 100 100 100 100 100

            wrr-queue random-detect max-threshold 6 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 6 80 100 100 100 100 100 100 100

            wrr-queue random-detect max-threshold 7 100 100 100 100 100 100 100 100

            wrr-queue random-detect min-threshold 7 100 100 100 100 100 100 100 100

            wrr-queue cos-map 1 1 1

            wrr-queue cos-map 2 1 0

            wrr-queue cos-map 3 1 2

            wrr-queue cos-map 4 1 3

            wrr-queue cos-map 5 1 6

            wrr-queue cos-map 6 1 7

            wrr-queue cos-map 7 1 4

            priority-queue cos-map 1 5″ )

This is one example of the different structure that needs to be created which is also based on linecard model and what the card will support for commands and QoS. If you are new to this, as I was, the name $OnePSevenQEightT seems confusing, but being a great cryptographer, you can quicker decipher. OneP = One Priority, SevenQ =  Seven Queues and EightT = Eight Thresholds.

Now that we know what model line cards and the configs built for the actual QoS commands, we can start the interface configs for each slot.

## !—INTERFACE CONFIG for slot 1:

 

#if ( $slot1  == “6704” )

            #set ( $port_range = “Te1/1-4” )

            int range $port_range

                        $OnePSevenQEightT

 

#elseif ( $slot1  == “6708” )

            #set ( $port_range = “Te1/1-8” )

            int range $port_range

                        $OnePSevenQFourT

                       

#elseif ( $slot1  == “6724” || $slot1 == “6824” )

            #set ( $port_range = “Gi1/1-24” )

            int range $port_range

                        $OnePThreeQEightT

                       

#elseif ( $slot1 == “6748” || $slot1  == “6848” )

            #set ( $port_range = “Gi1/1-48” )

            int range $port_range

                        $OnePThreeQEightT

                       

#elseif ( $slot1 == “6524” )

            #set ( $port_range = “Gi1/1-24” )

            int range $port_range

                        $OnePThreeQOneT

                       

#elseif ( $slot1 == “6148” )

            #set ( $port_range = “Gi1/1-48” )

            int range $port_range

                         $OnePTwoQTwoT

 

#elseif ( $slot1 == “None” )

#end

In this code we are looking at each slot, #if ( $slot1, and we have to build a config for the slot with each possible linecard that could be installed because each takes a different command or queueing structure as we built in the first set of code.

The linecard model is then specified, == “6704” ). You may be asking, ‘Nick why does this even matter? That seems like a lot of extra code I just really don’t want to deal with.’ It does matter since each linecard model may have a different number of ports and even type of port. We cannot really specify commands to add configs to a Gig interface when the linecard is a TenGig card. We also have to account for the option that the linecard is not actually populated, can’t really put a config on a card that is not installed. It is painful but needed. Copy and Paste is your friend, but be careful to make sure the slot number gets updated each time.

At this point just make sure have the correct number of #end statements and don’t forget to close the clicommand.

We will now move on to Deployment of the configs we have created.

 

 

 

One thought on “Cisco Prime – This is what it is good for. Part 1”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s