RFE: Security Rules should support VRRP protocol

[German Eichberger]

We are following http://blog.aaronorosen.com/implementing-high-availability-instances-with-neutron-using-vrrp/ to set up two "service vms" as an active-standby pair using VRRP for the Octavia project. While doing so we noticed that all VRRP packets were blocked and the protocol is not supported by the current security groups. Since that will gain more momentum with the NFV story we propose to add this additional protocol to security groups.

[Kyle Mestery (mestery)]

Seems reasonable to me. Following the new decoder ring process, moving the state to "Triaged" and you can move forward with implementation.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/203173

[OpenStack Infra (hudson-openstack)]

Change abandoned by Kyle Mestery (<email address hidden>) on branch: master
Review: https://review.openstack.org/203173
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Armando Migliaccio (armando-migliaccio)]

It looks like there's no actual loss of functionality without this fix. VRRP can be enabled, but it would be nice to do so by just using its well-known name.

[Li Ma (nick-ma-z)]

Hello, are you still working on this bug?

[German Eichberger (german-eichberger)]

As I said in my patch we found another way to do it and stopped working on it. Feel free to resurrect the patch and fix the problems highlighted..

[Li Ma (nick-ma-z)]

OK, I will work on this spec.

[Li Ma (nick-ma-z)]

So, is this rfe accepted? I wonder.

[Kevin Benton (kevinbenton)]

If we go forward with this, let's just map all of the protocols right now so we don't keep doing them one at a time as people want them.

[Kyle Mestery (mestery)]

Approved, though we may want to fold in adding support for protocols other than just VRRP.

[Li Ma (nick-ma-z)]

In the current implementation, all the protocol parameters are defined as individual constant in the codebase:

https://github.com/openstack/neutron/blob/master/neutron/common/constants.py#L119

and only tcp/udp/icmp/icmp6 are respected.

When we map all the necessary protocols, I don't suggest to follow the original implementation by defining lots of individual constants. Instead, a map is given to hold all these constants as follows:

PROTOCOL_MAP = {
    'tcp': 6, 'udp': 17, 'icmp': 1, 'icmpv6': 58, ...
}

Any comments on this refactor? Do I need to propose a blueprint to discuss with it?

[Armando Migliaccio (armando-migliaccio)]

How's that gonna differ? Besides, using the map will make you lose the string literals that can prevent accidental typos. I'd say stick with what we got, but no, you don't need to propose a blueprint for this.

[Li Ma (nick-ma-z)]

OK, I will stick with the constants. This rfe is proposed for VRRP protocol. As stated before, it is suggested to work on all the protocols. It is exhausting and I'm not sure which protocol is welcomed.

Here I select some popular IP protocols defined as RFC from the list [1] . I'd appreciated any suggestions.

ICMP
IGMP
TCP
EGP
UDP
IPv6
IPv6-route
IPv6-flag
RSVP
GRE
ESP
AH
IPv6-ICMP
IPv6-NoNxt
IPv6-Opts
OSPF
VRRP
PGM
L2TP
VRRP

[1] https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/252155

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/259037

[Armando Migliaccio (armando-migliaccio)]

status update: http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-01-28-22.20.log.txt

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/252155
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=592b548bb6720760efae4b10bec59e78a753f4d7
Submitter: Jenkins
Branch: master

commit 592b548bb6720760efae4b10bec59e78a753f4d7
Author: Li Ma <email address hidden>
Date: Wed Dec 2 10:30:22 2015 +0800

    Add popular IP protocols for security group

    Add these additional protocols listed below to
    security groups brings convenience to operators
    on configuring these protocols. In addition, make
    the security group rules more readable.

    The added protocols are: ah, dccp, egp, esp, gre,
    ipv6-encap, ipv6-frag, ipv6-nonxt, ipv6-opts,
    ipv6-route, ospf, pgm, rsvp, sctp, udplite, vrrp.

    A related patch is submitted to neutron-lib project:
    https://review.openstack.org/259037

    DocImpact: You can specify protocol names rather than
    protocol number in API and CLI commands. I'll update
    the documentation when it is merged.

    APIImpact

    Change-Id: Iaef9b650449b4d9d362a59305c45e0aa3831507c
    Closes-Bug: #1475717

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/259037
Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=c8be1a1be91e8f4458307e8d6bde139991d043e1
Submitter: Jenkins
Branch: master

commit c8be1a1be91e8f4458307e8d6bde139991d043e1
Author: Li Ma <email address hidden>
Date: Thu Dec 17 22:15:03 2015 +0800

    Add popular IP protocols for security group

    This patch is a follow-up of
    https://review.openstack.org/#/c/252155

    Change-Id: I9ce3dd4ef0400b134f67b9e9cbf2e09cee7ebb01
    Related-Bug: #1475717

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/neutron 8.0.0.0b3 development milestone.