- Community Home
- >
- Networking
- >
- Software Defined Networking
- >
- Unable to match on the updated DSCP mark given by ...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-13-2017 07:09 AM
03-13-2017 07:09 AM
Unable to match on the updated DSCP mark given by meter
Hi,
I am facing yet another problem in the DSCP remark meters.
consider this scenario: I have two tables and one meter.
Table 0 directs packets into meter 1, and then into table 1.
Meter 1 changes the DSCP mark of packets that are over the meter's rate from DSCP X to DSCP Y.
Table 1 has a flow entry that matches on DSCP Y.
Although packets are correctly remarked to DSCP Y as shown in the receiver's Wireshark capture, the flow entry in table 1 does not match any packets. If I originally send packets with DSCP Y with no metering, the flow entry is correctly matched.
It seems it is related somehow to the bug I have previously reported. The old DSCP mark is taken into account when performing the matching in the following tables instead of the new DSCP mark given by the meter.
At what point is the DSCP mark changed in the switch processing flow? It seems to me that the mark is changed after (or right before) the packet is queued and not inside the OpenFlow pipeline?
Note: I am only trying to match on the new meter DSCP mark as a workaround for the previous problem of incorrect queue selection, however, this also does not work :(
Thanks,
Enas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-15-2017 05:04 AM
03-15-2017 05:04 AM
Re: Unable to match on the updated DSCP mark given by meter
Hello Enas,
The behavior you see is expected. The lookup for DSCP in a packet on any OpenFlow table is not affected by the remarked value of the DSCP in the packet. Lets us just say they are read and written into 2 different locations.
The new DSCP value is only updated at the egress when all OpenFlow related processing is done on the packet.
Thanks!
Abhay
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-16-2017 12:25 AM
03-16-2017 12:25 AM
Re: Unable to match on the updated DSCP mark given by meter
Hi Abhay,
Thank you for the clarification.
I assumed that updating the DSCP is similar to the set field action. Becuase according to the Openflow standard as shown in the flow diagram below, a packet should be updated with new fields values before moving to the next table in the pipeline, thus, the update happens in the Openflow pipeline and not afterward.
Also, in section 5.3 : "The packet match fields represent the packet in its current state, if actions applied in a previous table using the Apply-Actions changed the packet headers, those changes are reflected in the packet match fields"
I have not tested the set_field action in the HP switch yet, but does it also update the fields at the egress?
Thank you very much,
Enas