[ovs-discuss] Including bfd status for tunnel endpoints on ovs-vsctl show
Miguel Angel Ajo Pelayo
majopela at redhat.com
Fri Mar 9 17:43:00 UTC 2018
Ok, I have modified it to just show bfd_status, for rexample, in a 3
controller + 1 compute
environment, with a router and a vm on the compute:
[heat-admin at overcloud-controller-2 ovs]$ sudo utilities/ovs-vsctl show
a4cf68a7-07e9-4ed4-a317-016cb610c821
Bridge br-int
fail_mode: secure
Port "ovn-7e8b8a-0"
Interface "ovn-7e8b8a-0"
type: geneve
options: {csum="true", key=flow, remote_ip="172.16.0.5"}
bfd_status: {diagnostic="No Diagnostic", flap_count="1",
forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
state=up}
Port "ovn-0c37dd-0"
Interface "ovn-0c37dd-0"
type: geneve
options: {csum="true", key=flow, remote_ip="172.16.0.7"}
bfd_status: {diagnostic="No Diagnostic", flap_count="1",
forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
state=up}
Port br-int
Interface br-int
type: internal
Port "patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4"
Interface
"patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4"
type: patch
options:
{peer="patch-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4-to-br-int"}
Port "ovn-9f2335-0"
Interface "ovn-9f2335-0"
type: geneve
options: {csum="true", key=flow, remote_ip="172.16.0.11"}
bfd_status: {diagnostic="No Diagnostic", flap_count="1",
forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
state=up}
Bridge br-ex
fail_mode: standalone
Port br-ex
Interface br-ex
...
if I admin disable that single router with " neutron router-update router1
--admin-state-up false"
(the bfd should be disabled all around because it's not necessary, and
ovs-vswitchd takes care
of clearing up bfd_status):
[heat-admin at overcloud-controller-2 ovs]$ sudo utilities/ovs-vsctl show
a4cf68a7-07e9-4ed4-a317-016cb610c821
Bridge br-int
fail_mode: secure
Port "ovn-7e8b8a-0"
Interface "ovn-7e8b8a-0"
type: geneve
options: {csum="true", key=flow, remote_ip="172.16.0.5"}
Port "ovn-0c37dd-0"
Interface "ovn-0c37dd-0"
type: geneve
options: {csum="true", key=flow, remote_ip="172.16.0.7"}
Port br-int
Interface br-int
type: internal
Port "patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4"
Interface
"patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4"
type: patch
options:
{peer="patch-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4-to-br-int"}
Port "ovn-9f2335-0"
Interface "ovn-9f2335-0"
type: geneve
options: {csum="true", key=flow, remote_ip="172.16.0.11"}
Bridge br-ex
fail_mode: standalone
...
On Fri, Mar 9, 2018 at 9:32 AM Miguel Angel Ajo Pelayo <majopela at redhat.com>
wrote:
> Thank you Ben, I'll finish it, test it properly and submit the patch.
>
> I don't know if it makes any sense to add a filter where the dictionary
> has only a key "enabled" and it's "false",
> or it's really not worth it. I'll check out how it looks with a real
> deployment and get back here with the results.
>
> On Thu, Mar 8, 2018 at 7:12 PM Ben Pfaff <blp at ovn.org> wrote:
>
>> On Thu, Mar 08, 2018 at 04:43:50PM +0000, Miguel Angel Ajo Pelayo wrote:
>> > Ok, looking at the code, it seems like we may only need to do this?
>> >
>> > diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c
>> > index 21fa18d..2ac60bf 100644
>> > --- a/utilities/ovs-vsctl.c
>> > +++ b/utilities/ovs-vsctl.c
>> > @@ -1018,7 +1018,9 @@ static struct cmd_show_table cmd_show_tables[] = {
>> > &ovsrec_interface_col_name,
>> > {&ovsrec_interface_col_type,
>> > &ovsrec_interface_col_options,
>> > - &ovsrec_interface_col_error},
>> > + &ovsrec_interface_col_error,
>> > + &ovsrec_interface_col_bfd,
>> > + &ovsrec_interface_col_bfd_status},
>> > {NULL, NULL, NULL}
>> > },
>>
>> Yes, you also need to increase the size of columns[] in cmd_show_table:
>>
>> diff --git a/lib/db-ctl-base.h b/lib/db-ctl-base.h
>> index eb444270535b..5d8532a7bde2 100644
>> --- a/lib/db-ctl-base.h
>> +++ b/lib/db-ctl-base.h
>> @@ -197,7 +197,7 @@ struct weak_ref_table {
>> struct cmd_show_table {
>> const struct ovsdb_idl_table_class *table;
>> const struct ovsdb_idl_column *name_column;
>> - const struct ovsdb_idl_column *columns[3]; /* Seems like a good
>> number. */
>> + const struct ovsdb_idl_column *columns[5]; /* Seems like a good
>> number. */
>> const struct weak_ref_table wref_table;
>> };
>>
>> > But that would render something like:
>> >
>> >
>> > [heat-admin at overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
>> > 5f35518a-ab34-49a4-a227-e487e251b7e3
>> > Manager "ptcp:6640:127.0.0.1"
>> > is_connected: true
>> > Bridge br-int
>> > fail_mode: secure
>> > Port "ovn-14d60a-0"
>> > Interface "ovn-14d60a-0"
>> > type: geneve
>> > options: {csum="true", key=flow,
>> remote_ip="172.16.0.12"}
>> > bfd: {enable="true"}
>> > bfd_status: {diagnostic="No Diagnostic", flap_count="1",
>> > forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
>> > state=up}
>> >
>> >
>> > I'm partly guessing here based on what I see around lib/db-ctl-base.c
>> and
>> > doing a little bit of debugging.
>> >
>> > @Ben is there any way of filtering out those columns when
>> > bfd:enabled="false" or not set ?
>>
>> It appears that that's already what happens, at least for the "not set"
>> case. I doubt there are many controllers that explicitly set enable to
>> false.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20180309/7c793039/attachment-0001.html>
More information about the discuss
mailing list