N1K cos marking CBWFQ

[NaelShahid]

I have been reading the nk1v QoS guide and the fair queuing white paper which show quite clearly how to use the in build nk1 and vmw protocol matches to apply bandwidth guarantees to the uplink (egress) – However, I would like to assign cos markings for the upstream N5Ks.

Can I create a policy which would be assigned to each port profile to set cos, then use these markings on the CWFQ policy on the uplink profile? This way I assign bandwidth policy based on cos on the uplink as well as looking for the markings to do the same on the n5k... If so do you have an example of this config?

[lwatta]

Check out this link. It shows you how to set the marking on the N1KV side.

http://www.vnephos.com/index.php/2011/11/another-nexus-1000v-wfq-qos-example/

louis

[NaelShahid]

Hi - I have seen this link, however, it is not clear where the policy should be applied. I have added (above) where I think policy should be applied.

[NaelShahid]

Below is an example I have put together from the various documents - Does it look correct?? (it only includes NFS for now)

n1kv# show policy-map

Type qos policy-maps

  ====================

  policy-map type qos class-cos4

    class  class-default

      set cos 4

  Type queuing policy-maps

========================

  policy-map type queuing nfs-policy

    class type queuing nfs-class

      bandwidth percent 30

nav-n1kv# show class-map

  Type queuing class-maps

========================

    class-map type queuing match-all nfs-class

      match cos 4

port-profile nfs

type: Vethernet

description:

status: enabled

max-ports: 32

min-ports: 1

inherit:

config attributes:

  switchport mode access

  switchport access vlan 892

  service-policy input class-cos4

  no shutdown

evaluated config attributes:

  switchport mode access

  switchport access vlan 892

  service-policy input class-cos4

  no shutdown

assigned interfaces:

  Vethernet10

port-group: nfs

system vlans: 892

capability l3control: no

capability iscsi-multipath: no

port-profile role: none

port-binding: static

port-profile uplink

type: Ethernet

description:

status: enabled

max-ports: 32

min-ports: 1

inherit:

config attributes:

  switchport mode trunk

  switchport trunk allowed vlan 892,900,998

  service-policy type queuing output nfs-policy

  channel-group auto mode on mac-pinning

  no shutdown

evaluated config attributes:

  switchport mode trunk

  switchport trunk allowed vlan 892,900,998

  service-policy type queuing output nfs-policy

  channel-group auto mode on mac-pinning

  no shutdown

assigned interfaces:

  port-channel1

  Ethernet3/7

  Ethernet3/8

port-group: uplink

system vlans: 892,900,998

capability l3control: no

capability iscsi-multipath: no

port-profile role: none

port-binding: static

[cutran]

Hi Nael. So I'm a little confused on what you are asking.  Are you asking to mark a CoS value for virtual machines that can match up to an upstream switch (i.e. Nexus 5000/5500 or 7000)?  May I ask what you are trying to achieve?

[NaelShahid]

Hi

I am looking to mark the different traffic classes attached to the different port profiles (nfs, vmotion, vm data, mgmt etc). This is so I can apply bandwidth guarantees on the upstream N5K as well as on the N1K. Once marked I can apply CBWFQ on the uplink port profile (N1K) using the COS markings I applied on ingress from the vethernet ports. 

If I mark at the N1K the qos configuration on the N5K becomes much simpler as opposed to having to create ACLs to classify the traffic.

[NaelShahid]

The above configuration does not seem to work. If I run "module vem 3 execute vemcmd pinst 305" I can see the correct number of queues, however there are no matches whatsoever. This makes me think that the cos value is not being applied. 

I have seen a few blogs / documents stating a similar config, however, has anyone actually checked to see if the queuing policy on the uplink profile is matching?

This may have something to do with cos only being applied on dot1q trunk (which the uplink actually is) or, does the cos value need to be trusted on egress?

Does anyone have any insight into this? Or can someone with a similar config check to see if the classes are being matched on the uplink?

[NaelShahid · Accepted solution]

Troubleshooting this issue I used the command "show system internal ipqos event-history errors" which stated that I was not providing bandwidth for n1k_control, mgmt, packet.

I removed the policy-map which was marking cos 6 from the veth port-profile (all N1k data is marked with cos 6 by default so I did not need this anyway) - I also removed the class-map relating to this then created the class-map based on the n1k_control, mgmt, packet protocol, lastly, I referenced this within the uplink queuing policy which seems to have done the trick.