Re: [ovs-discuss] OVN - VLAN packet duplicate processing on egress pipeline

[Anil Venkata]

On Mon, Jul 23, 2018 at 6:30 PM, Mark Michelson  wrote:

> On 07/23/2018 08:03 AM, Anil Venkata wrote:
>
>> Packets destined for VLAN remote logical ports are sent out through
>> physical table 65 rather than physical table 32 (Geneve remote logical
>> ports are sent through table 32). I found below description in ovn
>> architecture documentation.
>>
>> http://www.openvswitch.org//support/dist-docs/ovn-architecture.7.html
>>
>> A  special  case  is  that  when a localnet port exists on the
>> datapath, remote port is connected by switching to the  local‐
>> net  port.  In this case, instead of adding a flow in table 32
>> to reach the remote port, a flow  is  added  in  table  33  to
>> switch  the logical outport to the localnet port, and resubmit
>> to table 33 as if it were unicasted to a logical port  on  the
>> local hypervisor.
>>
>>
>> Any reason for this decision. Because of this, packet is redundantly
>> processed in logical switch's egress pipeline on both local and remote
>> hypervisors.
>>
>
> Keep in mind that from OVN's perspective, a localnet port represents a
> local exit from the logical switch. It doesn't know if the packet will end
> up back in br-int again on another hypervisor. It would be equally valid
> for the packet to be modified by a separate OVS switch and sent out of the
> underlay network entirely once it has gone out the localnet port.


Thanks Mark. Agree, tunnelled packet can only be decapsulated by  br-int on
remote hypervisor. But in case of VLAN packet any one can process it.
But I don't see stages (and tables) in egress pipeline checking against
this localnet port (but I can see checks for other localports). If the
remote port is not a ovs br-int port on other chassis, then why do we need
to apply ACL?

Thus if it does not go through the egress pipeline of the local hypervisor,
> there is the chance that it will not go through the egress pipeline of the
> logical switch at all.
>
> There are potential ways that we could get around this redundant
> processing. However, before suggesting anything concrete or actually
> proposing that anything actually should be done, I'll echo Russell's
> question about whether this is actually causing a noticeable problem.
>
>
Miguel found the issue 1) described in [1] while reviewing the patch [2].
As a solution we wanted to have gateway MAC address as reply packet source
MAC address when the packet is travelling from gateway node to compute node
so that external physical switches can update their FDB.
To implement this solution
1)  Router pipeline in gateway node will set packet  MAC address to gateway
MAC address and then submit to VLAN switch pipeline.
2)  VLAN switch pipeline should replace this with router internal port MAC
address before delivering to VM.
 I want to add below flow in physical table 33 local VM ports for
replacing MAC address
 table=33, priority= metadata=,dl_dst= actions=mod_dl_dst:,resubmit(,33)

But VLAN switch pipeline can process the above generic flow for remote
port, thus packet while leaving the gateway node will have router internal
port MAC address.
As a work around I can add a new flow which checks MAC address for each
port i.e (but I prefer the above generic flow in table 33)
table=33, priority= metadata=,dl_dst=,*outport=* actions=mod_dl_dst:,resubmit(,33)

Before that I wanted to understand why we are differentiating VLAN
networks( i.e processing differently in table 32 and 33) ?

[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/349803.html
[2] https://patchwork.ozlabs.org/patch/934524/


>
>> Thanks
>> Anil
>>
>>
>>
>>
>> ___
>> discuss mailing list
>> disc...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>
>>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVN - VLAN packet duplicate processing on egress pipeline

[Anil Venkata]

Packets destined for VLAN remote logical ports are sent out through
physical table 65 rather than physical table 32 (Geneve remote logical
ports are sent through table 32). I found below description in ovn
architecture documentation.

http://www.openvswitch.org//support/dist-docs/ovn-architecture.7.html

A  special  case  is  that  when a localnet port exists on the
datapath, remote port is connected by switching to the  local‐
net  port.  In this case, instead of adding a flow in table 32
to reach the remote port, a flow  is  added  in  table  33  to
switch  the logical outport to the localnet port, and resubmit
to table 33 as if it were unicasted to a logical port  on  the
local hypervisor.


Any reason for this decision. Because of this, packet is redundantly
processed in logical switch's egress pipeline on both local and remote
hypervisors.

Thanks
Anil
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN vm on vlan network using geneve tunnel for external traffic

[Anil Venkata]

I played adding some flows for forwarding as vlan packets and it worked(i.e
compute and gateway communicated through vlan packets on both sides)
I created a vm on vlan network 172.16.1.1/24 with vlan id 20 and an
external network 10.0.0.0/24 to reach internet.

In the current code, when I tired to reach external network(8.8.8.8) from
this vm, below physical flows will be run for routing and redirecting the
packet through geneve tunnel.

table=15 ip,metadata=0x2
actions=dec_ttl(),load:0xa01->NXM_NX_XXREG0[96..127],load:0xa65->NXM_NX_XXREG0[64..95],set_field:fa:16:3e:49:bb:60->eth_src,set_field:0x3->reg15,load:0x1->NXM_NX_REG10[0],resubmit(,16)
//routing
table=17 reg15=0x3,metadata=0x2
actions=set_field:0x4->reg15,resubmit(,18)  //redirect
table=32, priority=100,reg15=0x4,metadata=0x2
actions=load:0x2->NXM_NX_TUN_ID[0..23],set_field:0x4->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],bundle(eth_src,0,active_backup,ofport,slaves:3,4)

When I manually added below flows (in same tables) with higher priority for
vlans, packet is forwarded with vlan tag instead of tunneling.

sudo ovs-ofctl add-flow br-int
"table=15,ip,priority=49,metadata=0x2,dl_dst=fa:16:3e:8c:02:5d,actions=dec_ttl(),load:0xac100201->NXM_NX_REG0[],load:0x3->NXM_NX_REG15[],load:0x1->NXM_NX_REG10[0],resubmit(,16)"
sudo ovs-ofctl add-flow br-int
"table=16,priority=100,reg0=0xac100201,reg15=0x3,metadata=0x2,action=mod_dl_dst:fa:16:3e:8c:02:5d,resubmit(,17)"
sudo ovs-ofctl add-flow br-int
"table=32,priority=200,reg0=0xac100201,reg15=0x4,metadata=0x2,action=mod_vlan_vid:20,output:9,strip_vlan"

Note: Above table 15 flow is added by ovn-controller for each vlan
network(fa:16:3e:8c:02:5d is 172.16.1.1 MAC)

I will work on ovn-controller changes to have these flows.

Thanks
Anil


On Tue, Apr 17, 2018 at 2:20 AM, Ben Pfaff <b...@ovn.org> wrote:

> On Fri, Apr 13, 2018 at 09:22:44PM -0400, Russell Bryant wrote:
> > On Fri, Apr 13, 2018 at 9:01 PM, Russell Bryant <russ...@ovn.org> wrote:
> > > On Fri, Apr 13, 2018 at 5:27 PM, Ben Pfaff <b...@ovn.org> wrote:
> > >> On Wed, Apr 11, 2018 at 07:44:25PM +0530, Anil Venkata wrote:
> > >>> vm created on a vlan tenant network is using geneve tunnel(between
> compute
> > >>> and gateway nodes) to reach external network. Because of this, we
> need to
> > >>> consider tunnelling overhead while assigning MTU for vlan network.
> Can we
> > >>> improve OVN to avoid tunnelling in this case.
> > >>
> > >> When OVN tunnels packets, the tunnel metadata includes information on
> > >> the logical network, logical input port, and logical output port.  The
> > >> logical input port is only used for egress ACLs, so it could be
> omitted
> > >> if egress ACLs are constrained not to match on the logical input port.
> > >> The logical network and logical output port are still needed, though,
> so
> > >> to encode that in a VLAN they would have to add up to 12 bits or less.
> > >> That's pretty constraining.  Do you have some idea for how to do it?
> > >
> > > I don't think ACLs are a factor here because it's actually the logical
> > > router pipeline forwarded the packet over a tunnel.  The only logical
> > > switches involved are VLAN networks (a switch with a localnet port).
> > >
> > > The unexpected behavior here is that despite using all VLAN networks,
> > > a Geneve tunnel is used when the packet is sent to the L3 gateway node
> > > that's doing SNAT.  Note that the type of router configured here is
> > > the hybrid-type, where routing is fully distributed in all cases
> > > except when NAT is required, then it gets redirected to a central
> > > point.  That redirect is what we're seeing here.
> > >
> > > I've thought of two ways out of this:
> > >
> > > 1) In this scenario, if you really don't want any tunneling in use,
> > > configure a fully centralized router instead.  The downside is that
> > > East-West routing will be centralized, as well.
> > >
> > > 2) Use two routers.  ls1 (VLAN) with all ports for VMs <-> distributed
> > > east-west router <-> ls2 (VLAN) used just to interconnect the routers
> > > <-> centralized router for SNAT.  The downside here is that you still
> > > lose the ability to bind floating IPs directly to compute nodes like
> > > today.
> > >
> > > 3) Figure out a way for OVN to do this redirect to the gateway host
> > > over a VLAN network.  I suspect this isn't trivial and honestly
> > > haven

[ovs-discuss] ovn-controller periodically reporting status

[Anil Venkata]

In Openstack neutron reference implementation, all agents will be
periodically reporting their status to neutron server. Similarly in
Openstack OVN based deployment, we want ovn-controller to periodically
report its status to neutron server.

We can follow two approaches for this:

1) ovn-controller periodically writing timestamp(along with its name and
type) in SBDB chassis table

  smap_add(_ids, "OVN_CONTROLER_TYPE:ovn-controller1", timestamp);

  sbrec_chassis_set_external_ids(chassis_rec, _ids);

Then networking-ovn watching and processing the timestamp and updating
neutron DB.

2) Alternatively, use OVSDB server monitoring

  As ovn-controller is a client to OVSDB server(for SBDB), OVSDB server
periodically monitors this connection and updates the status in
"Connection" table.  But when the connection method is inbound (eg: ptcp or
punix), it updates only "n_connections" in status field and doesn't write
connection details in the OVSDB. Pros and Cons with this approach

Pros:

Using existing ovsdb-server monitoring(and no need to spawn a thread in
ovn-controller for reporting timestamp)

Cons:

a) ovsdb-server will only have remote ip address and port as part of
connection. How this information will be used to identify remote ovsdb
client(i.e ovn-controller)?

One approach is, OVSDB client(ovn-controller), after creating connection,
can add ip address and port in a new table in SBDB. Then ovsdb-server can
search this table with connection's ip address and port and update the
connection status(only if there is a change in status) in the resulting
row. Networking-ovn can watch this table and update neutron DB accordingly.
This require changes in all OVSDB clients and OVSDB server, though we have
requirement for only ovn-controller.

b) If a deployment wants to disable monitoring, can set "inactivity_probe"
to 0. Then we can't have status reporting. Here we are tightly coupling
status reporting with inactivity_probe.

Please suggest which approach will be better?

Note: I have proposed a spec [1] in networking-ovn for this. Reviews can be
helpful :)


Thanks

Anil

[1]
https://review.openstack.org/#/c/552447/1/doc/source/contributor/design/status_reporting.rst
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Including bfd status for tunnel endpoints on ovs-vsctl show

[Anil Venkata]

This is nice option to have.

On 07-Mar-2018 6:27 PM, "Miguel Angel Ajo Pelayo" 
wrote:

>
> As OVN started implementing L3HA with the use of BFD monitoring, after
> discussing with the people who is doing QA and thinking about future
> troubleshooting of the feature, they proposed something the thing on
> $subject.
>
> What do you think?
>
> For example, in this case:
>
> [heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl list Interface |
> grep -E "bfd |name |bfd_status"
> bfd : {}
> bfd_status  : {}
> name: "tapc6eed125-08"
> bfd : {enable="true"}
> bfd_status  : {diagnostic="No Diagnostic", flap_count="1",
> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
> state=up}
> name: "ovn-e4dd7a-0"
> bfd : {enable="true"}
> bfd_status  : {diagnostic="No Diagnostic", flap_count="1",
> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
> state=up}
> name: "ovn-14d60a-0"
> bfd : {}
> bfd_status  : {}
> name: br-ex
> bfd : {}
> bfd_status  : {}
> name: "vlan30"
> bfd : {}
> bfd_status  : {}
> name: br-int
> bfd : {}
> bfd_status  : {}
> name: "vlan20"
> bfd : {}
> bfd_status  : {}
> name: "tapd09b3382-50"
> bfd : {}
> bfd_status  : {}
> name: "vlan50"
> bfd : {}
> bfd_status  : {}
> name: "eth0"
> bfd : {enable="true"}
> bfd_status  : {diagnostic="No Diagnostic", flap_count="1",
> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
> state=up}
> name: "ovn-c8b85a-0"
>
>
> It could look like:
>
> [heat-admin@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: {remote_state="up", state="up", flap_count="1"}*
> Port "ovn-e4dd7a-0"
> Interface "ovn-e4dd7a-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.16.0.22"}
>* bfd: {remote_state="up", state="up", flap_count="1"}*
> Port br-int
> Interface br-int
> type: internal
> Port "tapd09b3382-50"
> Interface "tapd09b3382-50"
> Port "tapc6eed125-08"
> Interface "tapc6eed125-08"
> Port "ovn-c8b85a-0"
> Interface "ovn-c8b85a-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.16.0.17"}
> *bfd: {remote_state="up", state="up", flap_count="1"}*
> Bridge br-ex
> fail_mode: standalone
> Port "vlan30"
> tag: 30
> Interface "vlan30"
> type: internal
> Port br-ex
> Interface br-ex
> type: internal
> Port "eth0"
> Interface "eth0"
> Port "vlan50"
> tag: 50
> Interface "vlan50"
> type: internal
> Port "vlan20"
> tag: 20
> Interface "vlan20"
> type: internal
> ovs_version: "2.8.1"
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN load balancing on same subnet failing

[Anil Venkata]

On Fri, Mar 2, 2018 at 7:23 AM, Guru Shetty <g...@ovn.org> wrote:

>
>
> On 27 February 2018 at 03:13, Anil Venkata <anilvenk...@redhat.com> wrote:
>
>> For example, I have a 10.1.0.0/24 network and a load balancer is added
>> to it with 10.1.0.10 as VIP and 10.1.0.2(MAC 50:54:00:00:00:01),
>> 10.1.0.3(MAC 50:54:00:00:00:02) as members.
>> ovn-nbctl  create load_balancer vips:10.1.0.10="10.1.0.2,10.1.0.3"
>>
>
> We currently need the VIP to be in a different subnet. You should connect
> switch it to a dummy logical router (or connect it to a external router).
> Since a VIP is in a different subnet, it sends an ARP for logical router IP
> and then things will work.
>
>

Thanks Guru. Any reason for introducing this constraint(i.e VIP to be in a
different subnet)? Can we address this limitation?


>>  When I try to send a request from client within the subnet(i.e
>> 10.1.0.33) its not reaching any load balancer members.
>> I noticed ARP not resolved for VIP 10.1.0.10.
>>
>> I tried to resolve this in two ways
>> 1) Adding a new ARP reply ovs flow for VIP 10.1.0.10 with router port's
>> MAC. When client tries to connect VIP, it will use router's MAC. Now router
>> gets the packet after load balancing, and will forward the packet to
>> appropriate member.
>>
>> 2) Second approach,
>>a) Using a new MAC(example, 50:54:00:00:00:ab) for VIP 10.1.0.10, and
>> adding a new ARP reply flow with this MAC.
>>b) As we are not using router, when load balancing changes destination
>> ip, VIP MAC has to be replaced with corresponding member's MAC i.e
>>   sudo ovs-ofctl add-flow br-int "table=24,ip,priority=150,dl_d
>> st=50:54:00:00:00:ab,nw_dst=10.1.0.2,action=mod_dl_dst:50:54
>> :00:00:00:01,load:0x1->NXM_NX_REG15[],resubmit(,32)"
>> sudo ovs-ofctl add-flow br-int "table=24,ip,priority=150,dl_d
>> st=50:54:00:00:00:ab,nw_dst=10.1.0.3,action=mod_dl_dst:50:54
>> :00:00:00:02,load:0x2->NXM_NX_REG15[],resubmit(,32)"
>>
>> Which approach will be better or is there any alternate solution?
>>
>> Thanks
>> Anil
>>
>>
>> ___
>> discuss mailing list
>> disc...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>
>>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVN load balancing on same subnet failing

[Anil Venkata]

For example, I have a 10.1.0.0/24 network and a load balancer is added to
it with 10.1.0.10 as VIP and 10.1.0.2(MAC 50:54:00:00:00:01), 10.1.0.3(MAC
50:54:00:00:00:02) as members.
ovn-nbctl  create load_balancer vips:10.1.0.10="10.1.0.2,10.1.0.3"

 When I try to send a request from client within the subnet(i.e 10.1.0.33)
its not reaching any load balancer members.
I noticed ARP not resolved for VIP 10.1.0.10.

I tried to resolve this in two ways
1) Adding a new ARP reply ovs flow for VIP 10.1.0.10 with router port's
MAC. When client tries to connect VIP, it will use router's MAC. Now router
gets the packet after load balancing, and will forward the packet to
appropriate member.

2) Second approach,
   a) Using a new MAC(example, 50:54:00:00:00:ab) for VIP 10.1.0.10, and
adding a new ARP reply flow with this MAC.
   b) As we are not using router, when load balancing changes destination
ip, VIP MAC has to be replaced with corresponding member's MAC i.e
  sudo ovs-ofctl add-flow br-int
"table=24,ip,priority=150,dl_dst=50:54:00:00:00:ab,nw_dst=10.1.0.2,action=mod_dl_dst:50:54:00:00:00:01,load:0x1->NXM_NX_REG15[],resubmit(,32)"
sudo ovs-ofctl add-flow br-int
"table=24,ip,priority=150,dl_dst=50:54:00:00:00:ab,nw_dst=10.1.0.3,action=mod_dl_dst:50:54:00:00:00:02,load:0x2->NXM_NX_REG15[],resubmit(,32)"

Which approach will be better or is there any alternate solution?

Thanks
Anil
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss