[neutron][ovs] Different Cookie with Remote Security group

Mohan Kumar nmohankumar1011 at gmail.com
Wed Nov 3 07:52:57 UTC 2021


Hi Rodolfo,

Thanks for the reply, restart the agent fixed the issue.
The cookies are replaced with a new single cookie. It look weird to me when
I saw multiple cookies on the bridge.  Do you think it should be fixed?

Thanks .,
Mohankumar N

On Wed, Nov 3, 2021 at 1:10 PM Rodolfo Alonso Hernandez <ralonsoh at redhat.com>
wrote:

> Hello Mohan:
>
> Each OVS agent extension (QoS) or service (firewall), will have its own
> "OVSCookieBridge" instance of a specific bridge; in this case br-int. That
> means any service or extension will write OF rules using its own cookie.
>
> By default, if you are only using OVS FW (no QoS or any other extension),
> only one cookie should be present in br-int. Any new rule added to the FW
> should have the same cookie as the other present rules.
>
> Did you restart the agent? When the OVS agent is restarted, all rules are
> set again, deleting the previous ones. The OVS agent generates new cookies
> each time. No stale flows should remain after the restart.
>
> Regards.
>
> On Wed, Nov 3, 2021 at 7:33 AM Mohan Kumar <nmohankumar1011 at gmail.com>
> wrote:
>
>> Team,
>>
>>    I've created a security group with a remote security group attached
>> to it.
>>
>> openstack security group rule create --ethertype=IPv4 --protocol tcp
>>> --remote-group server-grp --ingress --dst-port=22 application-grp
>>
>>
>> when I create VM with server-grp , I can see two cookies in br-int ovs
>> bridge, one with default cookie and another new cookie with conjunction
>> flows,  is it expected behavior?
>>
>> ubuntu at req-generic-65-d012-mn:~$ sudo ovs-ofctl dump-flows br-int | awk '{print $1}' | sort -n | uniq
>> cookie=0x12b7adbe73614620,
>> cookie=0x207d02d6bbcf499e,
>> NXST_FLOW
>> ubuntu at req-generic-65-d012-mn:~$ sudo ovs-ofctl dump-flows br-int |  grep "0x207d02d6bbcf499e"
>>  cookie=0x207d02d6bbcf499e, duration=335.421s, table=82, n_packets=0, n_bytes=0, idle_age=335, priority=70,ct_state=+est-rel-rpl,ipv6,reg6=0x1,ipv6_src=fdd8:a3ce:31ae:0:f816:3eff:fe8a:f751 actions=conjunction(8,1/2)
>>  cookie=0x207d02d6bbcf499e, duration=335.420s, table=82, n_packets=0, n_bytes=0, idle_age=335, priority=70,ct_state=+new-est,ipv6,reg6=0x1,ipv6_src=fdd8:a3ce:31ae:0:f816:3eff:fe8a:f751 actions=conjunction(9,1/2)
>>  cookie=0x207d02d6bbcf499e, duration=335.420s, table=82, n_packets=0, n_bytes=0, idle_age=335, priority=70,ct_state=+est-rel-rpl,ip,reg6=0x1,nw_src=10.0.0.38 actions=conjunction(16,1/2)
>>  cookie=0x207d02d6bbcf499e, duration=335.420s, table=82, n_packets=0, n_bytes=0, idle_age=335, priority=70,ct_state=+new-est,ip,reg6=0x1,nw_src=10.0.0.38 actions=conjunction(17,1/2)
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211103/704cb888/attachment.htm>


More information about the openstack-discuss mailing list