1 Copper

N2000 Series Incorrect Openflow Cookie in packets_in

Hi every one!

Does anyone have issues with the cookies in the "packet_in" packets working with DELL N2000 series switches. I have seen that they are not sent correctly:


I have  a DELL N2048P with OS, and I have configured a flow with cookie 0x0F1FFF1FFFFFF (Dec:266081579040767) and OUTPUT to CONTROLLER (which by the way is a RYU Controller)

I am able to see the flow configured in the switch (show openflow switch flows), however this command doesn't show the cookie. But I am able to see the cookie if I ask for the flows through the ryu rest:

DELL_N2048P#show openflow switch flows

Flow: 4674 Type: 1DOT3
Flow table: 60 Priority: 1800
Ingress port: Gi1/0/3
Duration (secs): 342 Idle: 0 In HW yes

root@linux:~# curl -X GET --cert <deleted> --key <deleted> --cacert <deleted> https://<IP_deleted>:8443/stats/switches

{"actions": ["OUTPUT:CONTROLLER"], "idle_timeout": 0, "cookie": 266081579040767, "packet_count": 135, "hard_timeout": 0, "byte_count": 10971, "duration_sec": 498, "duration_nsec": 970000000, "priority": 1800, "length": 88, "flags": 0, "table_id": 0, "match": {"in_port": 3}}


The "packet_in" packets generated by this flow carry the COOKIE FIELD filled by 0, instead sending the correct cookie.









Labels (1)
0 Kudos
2 Replies

Re: N2000 Series Incorrect Openflow Cookie in packets_in


Can you private message me the service tag? Did you follow this guide for configuring openflow? http://downloads.dell.com/solutions/networking-solution-resources/Dell%20Networking%20N-Series%20Ope...

Josh Craig
Dell EMC Enterprise Support Services
Get support on Twitter @DellCaresPRO
0 Kudos
1 Copper

Re: N2000 Series Incorrect Openflow Cookie in packets_in

Hi Josh, I didn't follow the guide you sent because I don't want the switch to be pure-openflow. I need to use hybrid-openflow solution because I need to configure 802.1X in the access ports. So I wrote a very simple configuration using this guide: https://downloads.dell.com/manuals/all-products/esuprt_ser_stor_net/esuprt_networking/esuprt_net_fxd... Could it be a bug in the packet_in construction? Regards Luciano
0 Kudos