Filtering on IP protocol 0 causes all rules to be silently rejected
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
networking-calico |
New
|
Undecided
|
Unassigned |
Bug Description
Moved here from https:/
Brook-Roberts commented on 21 Aug 2015
Adding a security group rule in Openstack, through Horizon, that filters on IP protocol 0, causes all other rules in that security group to stop taking affect.
I believe it's expected that we can't implement this rule, however:
a) The user isn't informed that their rule wasn't allowed, so if they intended to put in a different rule (e.g. allowing a different protocol) it won't be obvious that they put in the wrong thing
b) Since the user isn't informed, they won't realise straight away that the rest of their rules also aren't working.
Likely to be a particular pain for people using scripts, which could well mistakenly enter such rules.
fasaxc commented on 3 Sep 2015
Two approaches we can take here:
Find a way to police this in the neutron plugin. Does it just work if we raise an exception when we stop a bad rule?
Wait for status reporting in felix which will let us report the failure to program back up to neutron. This may not be very visible in the UI, though.
fasaxc commented on 3 Sep 2015
We could also improve limit the "blast" radius to only the single rule by making a safe approximation.
neiljerram commented on 9 Mar
What should filtering on IP protocol 0 do?
fasaxc commented on 9 Mar
@neiljerram Not sure, is there a Neutron blueprint or something that defines the valid values?
Note: since fasaxc's comment on 3 Sep 2015, agent and port status reporting have been added to Felix. I'm not yet clear how we can use those for this problem, but they are there to be used.