dot1p-based qos-config does not work

Bug #1603340 reported by Vedamurthy Joshi
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Fix Committed
High
Anand H. Krishnan
R3.1
Fix Committed
High
Anand H. Krishnan

Bug Description

R3.1.0.0 Build 2738

Created a qos-config with only dot1p mapping of 0 -> FC id 10 and applied it to a tagged VMI.

root@nodek2:~# ./qosmap --dump-fc
Forwarding Class Map 0
 FC DSCP EXP .1p Queue
  0 0 0 0 0
 10 10 2 2 0
root@nodek2:~#

Using scapy, sent Ethernet 802.1q raw packets(non-IP) with .1p bit set to 0
Expectation was that the fabric outer 802.1q header should have 2 as .1p bit set, which is not happening.

Tags: qos vrouter
Jeba Paulaiyan (jebap)
tags: added: qos
Revision history for this message
Anand H. Krishnan (anandhk) wrote :
Changed in juniperopenstack:
status: New → In Progress
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/22136
Committed: http://github.org/Juniper/contrail-vrouter/commit/53a87a75edb8af60370e02ba23149c0695d69392
Submitter: Zuul
Branch: master

commit 53a87a75edb8af60370e02ba23149c0695d69392
Author: Anand H. Krishnan <email address hidden>
Date: Tue Jul 19 13:56:54 2016 +0530

.1p based QOS marking for L2 packets

For packets that are not IPv4 or IPv6, qos remarking will be based on
802.1p information present in the packet. For supporting this feature,
we do the following:

. save the priority information in the packet before untagging the
packet, if it comes in the vRouter vlan interface
. use this saved information to lookup in the qos configuration table
to determine the forwarding class, as is the case with DSCP based
lookups
. save and restore 802.1p information in the forwarding metadata, if
and when the packet is queued somewhere

Also, fix the incremental checksum code that comes into play when tos
bits in the IPv4 header is changed. There is a problem with the current
code where the diff is shifted by 8 bits to reflect the position of TOS
bits in the IPv4 header. We should do this shift to original values
rather than the diff.

Change-Id: Iade0adae4163a3dd5e4ad9ae41cb91c6bcbb8c0d
Closes-BUG: #1603340
Closes-BUG: #1603864

Changed in juniperopenstack:
status: In Progress → Fix Committed
milestone: none → r3.2.0.0-fcs
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.1

Review in progress for https://review.opencontrail.org/22317
Submitter: Anand H. Krishnan (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/22317
Committed: http://github.org/Juniper/contrail-vrouter/commit/2a218fed0ec3c8821d293098b8fceaa6921ec1da
Submitter: Zuul
Branch: R3.1

commit 2a218fed0ec3c8821d293098b8fceaa6921ec1da
Author: Anand H. Krishnan <email address hidden>
Date: Tue Jul 19 13:56:54 2016 +0530

.1p based QOS marking for L2 packets

For packets that are not IPv4 or IPv6, qos remarking will be based on
802.1p information present in the packet. For supporting this feature,
we do the following:

. save the priority information in the packet before untagging the
packet, if it comes in the vRouter vlan interface
. use this saved information to lookup in the qos configuration table
to determine the forwarding class, as is the case with DSCP based
lookups
. save and restore 802.1p information in the forwarding metadata, if
and when the packet is queued somewhere

Also, fix the incremental checksum code that comes into play when tos
bits in the IPv4 header is changed. There is a problem with the current
code where the diff is shifted by 8 bits to reflect the position of TOS
bits in the IPv4 header. We should do this shift to original values
rather than the diff.

Change-Id: Iade0adae4163a3dd5e4ad9ae41cb91c6bcbb8c0d
Closes-Bug: #1603340
Closes-Bug: #1603864

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.