Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Group 40 Test 40: Max Priority Overflow #103

Open
michaelatremblay opened this issue Jan 26, 2015 · 1 comment
Open

Group 40 Test 40: Max Priority Overflow #103

michaelatremblay opened this issue Jan 26, 2015 · 1 comment

Comments

@michaelatremblay
Copy link

The priority of the OFPT_FLOW_MODs generated in this test increments every time a new Flow Mod is sent. This is a problem, however, because the maximum priority value is 65535, and there does not appear to be a limit on the max_entries field. Since this test is trying to max out the table, it is possible for more than 65535 Flow Mods to be sent. The way this test is set up, it crashes when it tries to send the 65536th Flow Mod.

The error that occurs in this scenario is below.


runTest (testgroup40.Grp40No40) ... ERROR

ERROR: runTest (testgroup40.Grp40No40)

Traceback (most recent call last):
File "/root/oftest-1.0.0/tests/testgroup40.py", line 226, in runTest
rv = self.controller.message_send(flowmod)
File "/root/oftest-1.0.0/src/python/oftest/controller.py", line 601, in message_send
outpkt = msg.pack()
File "/root/oftest-1.0.0/src/python/oftest/message.py", line 879, in pack
packed += ofp_flow_mod.pack(self)
File "/root/oftest-1.0.0/src/python/oftest/cstruct.py", line 3408, in pack
packed += struct.pack("!QHHHHLHH", self.cookie, self.command, self.idle_timeout, self.hard_timeout, self.priority, self.buffer_id, self.out_port, self.flags)
error: 'H' format requires 0 <= number <= 65535

Ran 1 test in 4193.282s

FAILED (errors=1)

@jonstout
Copy link
Member

We ran into this problem when testing v1.3 devices. The fix we used increments mac addresses, and ignores priority.

In the past vendors have been able to artificially limit their flow table capacity to facilitate testing this case. Until this issue is resolved, that's the only way around this limitation.

@jonstout jonstout self-assigned this Jan 28, 2015
@jonstout jonstout removed their assignment Jan 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants