Description of problem: In RHOSP14, We noticed DSCP validation has failed while increasing DSCP tos value more than 100. Hence, please suggest if there is any limitation on DSCP in ODL and How we can conquer this limitation in southbound devices? Version-Release number of selected component (if applicable): puppet-opendaylight-8.2.2-4.9126c8dgit.el7ost.noarch opendaylight-8.3.0-7.el7ost.noarch How reproducible: 100% Lab environment. Steps to Reproduce: 1. Using RC puddle, I deployed Infrared environment with 3 Controller + 2 Compute including ODL & DSCP environment templates. ~~~ openstack overcloud deploy \ --timeout 100 \ --templates /usr/share/openstack-tripleo-heat-templates \ --stack overcloud \ --libvirt-type kvm \ --ntp-server clock.redhat.com \ -e /home/stack/virt/config_lvm.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /home/stack/virt/network/network-environment.yaml \ -e /home/stack/virt/inject-trust-anchor.yaml \ -e /home/stack/virt/hostnames.yml \ -e /home/stack/virt/debug.yaml \ -e /home/stack/virt/nodes_data.yaml \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-opendaylight.yaml \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/odl-dscp-marking-inheritance.yaml \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/disable-telemetry.yaml \ -e ~/containers-prepare-parameter.yaml \ --log-file overcloud_deployment_49.log ~~~ @undercloud-0 ~]$ openstack stack list +--------------------------------------+------------+----------------------------------+-----------------+----------------------+--------------+ | ID | Stack Name | Project | Stack Status | Creation Time | Updated Time | +--------------------------------------+------------+----------------------------------+-----------------+----------------------+--------------+ | 39ffb318-b576-44a8-9b98-00d85246bb34 | overcloud | ad0fc150e835411b9639f13cf50785cd | CREATE_COMPLETE | 2019-01-05T19:44:06Z | None | +--------------------------------------+------------+----------------------------------+-----------------+----------------------+--------------+ @undercloud-0 ~]$ openstack server list +--------------------------------------+--------------+--------+------------------------+----------------+------------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+--------------+--------+------------------------+----------------+------------+ | 17047870-bdb8-4dcd-a15f-d2710d4026ec | controller-2 | ACTIVE | ctlplane=192.168.24.10 | overcloud-full | controller | | 1bf90288-0969-477f-8107-5b6a86c70ed6 | controller-1 | ACTIVE | ctlplane=192.168.24.7 | overcloud-full | controller | | 27f39973-9a6f-4313-9d4b-79b913cee39f | controller-0 | ACTIVE | ctlplane=192.168.24.9 | overcloud-full | controller | | 97f315d6-3edc-4c18-a72b-604e8b63fddc | compute-0 | ACTIVE | ctlplane=192.168.24.14 | overcloud-full | compute | | f8c85b28-82aa-4b0e-8a3d-7b2928ee86b4 | compute-1 | ACTIVE | ctlplane=192.168.24.8 | overcloud-full | compute | +--------------------------------------+--------------+--------+------------------------+----------------+------------+ 2. Created two internal VXLAN network associated with tenant router which has mapped to external network (floating) access, then I provisioned two rhel7.6 instances on two compute node which each mapped individual VXLAN network. To get more details please refer attachment in comment #1. (overcloud) [stack@undercloud-0 ~]$ openstack server list +--------------------------------------+-----------+--------+--------------------------------------------------------------+-------+-----------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-----------+--------+--------------------------------------------------------------+-------+-----------+ | 74acb3b1-42fd-4d99-850a-5f54277a991e | instance2 | ACTIVE | internal2=2002::f816:3eff:fe1f:b3e8, 192.168.2.12, 10.0.0.54 | rhel | m1.medium | | 4a1d1cab-3955-43e7-a813-9614985ec082 | instance1 | ACTIVE | internal1=192.168.1.18, 2001::f816:3eff:fec9:11ff, 10.0.0.70 | rhel | m1.medium | +--------------------------------------+-----------+--------+--------------------------------------------------------------+-------+-----------+ 3. Logged in to one instance, and sending East-West traffic to validate DSCP marking with VXLAN encapsulation. i) Normal ping test working as expected. @instance2 ~]# ping -c 2 192.168.1.18 PING 192.168.1.18 (192.168.1.18) 56(84) bytes of data. 64 bytes from 192.168.1.18: icmp_seq=1 ttl=64 time=2.25 ms 64 bytes from 192.168.1.18: icmp_seq=2 ttl=64 time=1.43 ms --- 192.168.1.18 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 1.434/1.845/2.256/0.411 ms ii) Tried to ping with following DSCP tos values which threw the exception **Invalid tcclass**. Reference link http://conceptsfortheroad.com/2016/01/01/using-linux-to-verify-dscp/ DSCP 26 (011010) <==> ToS 104 (01101000) DSCP 46 (101110) <==> ToS 184 (10111000) DSCP 48 (110000) <==> ToS 192 (11000000) [root@instance2 ~]# ping 192.168.1.18 -Q 104 ping: Invalid tclass 104 [root@instance2 ~]# ping 192.168.1.18 -Q 184 ping: Invalid tclass 184 [root@instance2 ~]# ping 192.168.1.18 -Q 192 ping: Invalid tclass 192 iii) Referring to following OpenDaylight DSCP verification. It has mentioned that the valid DSCP value ranges are 0-63. which is currently working in RHOSP14 OpenDaylight environment. https://wiki.opendaylight.org/view/Network_Intent_Composition:Beryllium_Planning:QoS_Attribute_Mapping From: [root@instance2 ~]# ping -c 2 192.168.1.18 -Q 0 PING 192.168.1.18 (192.168.1.18) 56(84) bytes of data. 64 bytes from 192.168.1.18: icmp_seq=1 ttl=64 time=2.41 ms 64 bytes from 192.168.1.18: icmp_seq=2 ttl=64 time=1.60 ms --- 192.168.1.18 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 1.605/2.009/2.413/0.404 ms To: [root@instance2 ~]# ping -c 2 192.168.1.18 -Q 63 PING 192.168.1.18 (192.168.1.18) 56(84) bytes of data. 64 bytes from 192.168.1.18: icmp_seq=1 ttl=64 time=2.49 ms 64 bytes from 192.168.1.18: icmp_seq=2 ttl=64 time=1.64 ms --- 192.168.1.18 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 1.642/2.070/2.498/0.428 ms iv) Also, noticed I can test E-W traffic with DSCP tos value till 99. But when I increase tos value more than 100, it throwing Invalid tclass which indicate that it is not supported on rhel. The DSCP theory says DSCP header uses 1 byte (or 8-bits) which I assume a limitation to use the tos value 99 not more than that. ** Could you please let us know the limitation of DSCP tos values in OpenDaylight and how we can overcome the limitation OVS south bound devices? ** [root@instance2 ~]# ping -c 2 192.168.1.18 -Q 99 PING 192.168.1.18 (192.168.1.18) 56(84) bytes of data. 64 bytes from 192.168.1.18: icmp_seq=1 ttl=64 time=2.45 ms 64 bytes from 192.168.1.18: icmp_seq=2 ttl=64 time=1.66 ms --- 192.168.1.18 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 1.666/2.060/2.455/0.397 ms @instance2 ~]# ping -c 2 192.168.1.18 -Q 100 ping: Invalid tclass 100 v) Based on theory in ODL env, br-int is the default endpoint of VXLAN tunneling on each compute and we assume there should be **mod_nw_tos** action in br-int flows. But we didn't found any tos entries while dumping the integration bridge. It looks like the flow modification should be handled neutron northbound API with using **odl-qos** notification driver. Please correct if I was mistaken and kindly suggest the additional details which need to configure and validate TOS details from OVS southbound devices. @compute-0 ~]# ovs-ofctl -O OpenFlow13 dump-flows br-int|grep -i tos Expected results: How DSCP get works more than 100 TOS values? Additional info: https://docs.opendaylight.org/projects/netvirt/en/stable-oxygen/specs/qos.html
Created attachment 1518742 [details] OSP-Tenant-VM-Creation Details
(In reply to Pradipta Kumar Sahoo from comment #0) > ii) Tried to ping with following DSCP tos values which threw the exception > **Invalid tcclass**. Reference link > http://conceptsfortheroad.com/2016/01/01/using-linux-to-verify-dscp/ > DSCP 26 (011010) <==> ToS 104 (01101000) > DSCP 46 (101110) <==> ToS 184 (10111000) > DSCP 48 (110000) <==> ToS 192 (11000000) > > [root@instance2 ~]# ping 192.168.1.18 -Q 104 > ping: Invalid tclass 104 > [root@instance2 ~]# ping 192.168.1.18 -Q 184 > ping: Invalid tclass 184 > [root@instance2 ~]# ping 192.168.1.18 -Q 192 > ping: Invalid tclass 192 I think this is some bug with ping and using decimal. I also get it on F28. However if you use hex it seems to work: [trozet@localhost apex]$ ping 127.0.0.1 -4 -Q 104 ping: Invalid tclass 104 [trozet@localhost apex]$ ping 127.0.0.1 -Q 0x68 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.030 ms > iii) Referring to following OpenDaylight DSCP verification. It has mentioned > that the valid DSCP value ranges are 0-63. which is currently working in > RHOSP14 OpenDaylight environment. > > https://wiki.opendaylight.org/view/Network_Intent_Composition: > Beryllium_Planning:QoS_Attribute_Mapping > From: > [root@instance2 ~]# ping -c 2 192.168.1.18 -Q 0 > PING 192.168.1.18 (192.168.1.18) 56(84) bytes of data. > 64 bytes from 192.168.1.18: icmp_seq=1 ttl=64 time=2.41 ms > 64 bytes from 192.168.1.18: icmp_seq=2 ttl=64 time=1.60 ms > > --- 192.168.1.18 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1001ms > rtt min/avg/max/mdev = 1.605/2.009/2.413/0.404 ms > > To: > [root@instance2 ~]# ping -c 2 192.168.1.18 -Q 63 > PING 192.168.1.18 (192.168.1.18) 56(84) bytes of data. > 64 bytes from 192.168.1.18: icmp_seq=1 ttl=64 time=2.49 ms > 64 bytes from 192.168.1.18: icmp_seq=2 ttl=64 time=1.64 ms > > --- 192.168.1.18 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1001ms > rtt min/avg/max/mdev = 1.642/2.070/2.498/0.428 ms > That link is for Network Intent project and does not relate to Netvirt which we use. For the purpose of vxlan inheritance I don't think there should be any limit to which DSCP bits will be copied between the inner and outer header. > iv) Also, noticed I can test E-W traffic with DSCP tos value till 99. But > when I increase tos value more than 100, it throwing Invalid tclass which > indicate that it is not supported on rhel. > The DSCP theory says DSCP header uses 1 byte (or 8-bits) which I assume > a limitation to use the tos value 99 not more than that. > > ** Could you please let us know the limitation of DSCP tos values in > OpenDaylight and how we can overcome the limitation OVS south bound devices? > ** > > [root@instance2 ~]# ping -c 2 192.168.1.18 -Q 99 > PING 192.168.1.18 (192.168.1.18) 56(84) bytes of data. > 64 bytes from 192.168.1.18: icmp_seq=1 ttl=64 time=2.45 ms > 64 bytes from 192.168.1.18: icmp_seq=2 ttl=64 time=1.66 ms > > --- 192.168.1.18 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1001ms > rtt min/avg/max/mdev = 1.666/2.060/2.455/0.397 ms > > @instance2 ~]# ping -c 2 192.168.1.18 -Q 100 > ping: Invalid tclass 100 > > > v) Based on theory in ODL env, br-int is the default endpoint of VXLAN > tunneling on each compute and we assume there should be **mod_nw_tos** > action in br-int flows. But we didn't found any tos entries while dumping > the integration bridge. It looks like the flow modification should be > handled neutron northbound API with using **odl-qos** notification driver. > Please correct if I was mistaken and kindly suggest the additional details > which need to configure and validate TOS details from OVS southbound devices. > The ODL/Neutron QoS feature is different from the inheritance feature. The inheritance feature is inheritance of TOS for tenant instance traffic which already contains set TOS on packets, which is now supported. The ODL/Neutron QoS is about being able to set QoS on Neutron networks, meaning that when a tenant VM would send an unmarked packet into the network, the packet would be marked by the SDN and QoS would be applied throughout the network based on those DSCP markings. This latter feature is unsupported right now. > @compute-0 ~]# ovs-ofctl -O OpenFlow13 dump-flows br-int|grep -i tos > > Expected results: > How DSCP get works more than 100 TOS values? > > Additional info: > https://docs.opendaylight.org/projects/netvirt/en/stable-oxygen/specs/qos. > html
As per depreciation notice [1], closing this bug. Please reopen if relevant for RHOSP13, as this is the only version shipping ODL. [1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/14/html-single/release_notes/index#deprecated_functionality