Thanks Krzysztof, all
Let me see if I understand the 'native' proposal. Please amend as necessary
:)
On Tue, Mar 16, 2021 at 9:28 PM Krzysztof Klimonda <
kklimo...@syntaxhighlighted.com> wrote:
>
>
> On Tue, Mar 16, 2021, at 19:15, Mark Gray wrote:
> > On 16/03/2021 15:41, Krzysztof Klimonda
On 16/03/2021 20:28, Krzysztof Klimonda wrote:
> Do you have something more in mind, like programming routes received from BGP
> router into OVN?
Yes, this is what I was thinking of. We are looking at how to do this
for ovn-kubernetes. For shared gateway mode, we may not be able to use
the
On Tue, Mar 16, 2021, at 19:15, Mark Gray wrote:
> On 16/03/2021 15:41, Krzysztof Klimonda wrote:
> > Yes, that seems to be prerequisite (or one of prerequisites) for keeping
> > current DPDK / offload capabilities, as far as I understand. By Proxy
> > ARP/NDP I think you mean responding to
On 16/03/2021 15:41, Krzysztof Klimonda wrote:
> Yes, that seems to be prerequisite (or one of prerequisites) for keeping
> current DPDK / offload capabilities, as far as I understand. By Proxy ARP/NDP
> I think you mean responding to ARP and NDP on behalf of the system where FRR
> is running?
Hi Daniel,
On Tue, Mar 16, 2021, at 15:19, Daniel Alvarez Sanchez wrote:
>
>
> On Tue, Mar 16, 2021 at 2:45 PM Luis Tomas Bolivar
> wrote:
> > Of course we are fully open to redesign it if there is a better approach!
> > And that was indeed the intention when linking to the current efforts,
On Tue, Mar 16, 2021 at 3:20 PM Krzysztof Klimonda <
kklimo...@syntaxhighlighted.com> wrote:
>
> On Tue, Mar 16, 2021, at 14:45, Luis Tomas Bolivar wrote:
>
> Of course we are fully open to redesign it if there is a better approach!
> And that was indeed the intention when linking to the current
On Tue, Mar 16, 2021 at 2:45 PM Luis Tomas Bolivar
wrote:
> Of course we are fully open to redesign it if there is a better approach!
> And that was indeed the intention when linking to the current efforts,
> figure out if that was a "valid" way of doing it, and how it can be
>
On Tue, Mar 16, 2021, at 14:45, Luis Tomas Bolivar wrote:
> Of course we are fully open to redesign it if there is a better approach! And
> that was indeed the intention when linking to the current efforts, figure out
> if that was a "valid" way of doing it, and how it can be
Of course we are fully open to redesign it if there is a better approach!
And that was indeed the intention when linking to the current efforts,
figure out if that was a "valid" way of doing it, and how it can be
improved/redesigned. The main idea behind the current design was not to
need
Would it make more sense to reverse this part of the design? I was thinking of
having each chassis its own IPv4/IPv6 address used for next-hop in
announcements and OF flows installed to direct BGP control packets over to the
host system, in a similar way how localport is used today for
Hi Krzysztof,
On Tue, Mar 16, 2021 at 12:54 PM Krzysztof Klimonda <
kklimo...@syntaxhighlighted.com> wrote:
> Hi Luis,
>
> I haven't yet had time to give it a try in our lab, but from reading your
> blog posts I have a quick question. How does it work when either DPDK or
> NIC offload is used
Hi Luis,
I haven't yet had time to give it a try in our lab, but from reading your blog
posts I have a quick question. How does it work when either DPDK or NIC offload
is used for OVN traffic? It seems you are (de-)encapsulating traffic on chassis
nodes by routing them through kernel - is this
Hi Sergey, all,
In fact we are working on a solution based on FRR where a (python) agent
reads from OVN SB DB (port binding events) and triggers FRR so that the
needed routes gets advertised. It leverages kernel networking to redirect
the traffic to the OVN overlay, and therefore does not require
On 3/10/21 2:09 PM, Sergey Chekanov wrote:
I am looking to Gobgp (BGP implementation in Go) + go-openvswitch for
communicate with OVN Northbound Database right now, but not sure yet.
FRR I think will be too heavy for it...
On 10.03.2021 05:05, Raymond Burkholder wrote:
You could look at it
I am looking to Gobgp (BGP implementation in Go) + go-openvswitch for
communicate with OVN Northbound Database right now, but not sure yet.
FRR I think will be too heavy for it...
On 10.03.2021 05:05, Raymond Burkholder wrote:
You could look at it from a Free Range Routing perspective. I've
We are also looking towards some kind of BGP functionality in
Neutron/OVN, because a provider/external networks does not scale well,
especially without network segmentation support.
Currently we are working on POC implementation of a BGP speaker plugged
into Neutron which will announce /32
Looks like what I want to do.
But seems they do not want to use current VTEP Gateway functionality as
a base for it, will be interesting why...
On 10.03.2021 00:47, Daniel Alvarez wrote:
+Ankur
On 9 Mar 2021, at 22:34, Ben Pfaff wrote:
I'm not arguing against it, I just don't know of
+Ankur
> On 9 Mar 2021, at 22:34, Ben Pfaff wrote:
>
> I'm not arguing against it, I just don't know of anyone working on it.
Nutanix folks presented this in the OVS/OVN conf last fall:
http://www.openvswitch.org/support/ovscon2020/slides/OVS-CONF-2020-OVN-WITH-DYNAMIC-ROUTING.pdf
I am not
I'm not arguing against it, I just don't know of anyone working on it.
On Wed, Mar 10, 2021 at 12:23:31AM +0300, Sergey Chekanov wrote:
> I mean why not use EVPN to extend OVN logical switch (with current VTEP
> Gateway functionality)?
> Is it a good Idea to implement it as a BGP daemon which
I mean why not use EVPN to extend OVN logical switch (with current VTEP
Gateway functionality)?
Is it a good Idea to implement it as a BGP daemon which will takes
records from vtep database?
The reason is: not all switches support vtep schema, but almost all
support EVPN.
Maybe it is bad
On Mon, Mar 08, 2021 at 01:40:58PM +0300, Sergey Chekanov wrote:
> Is there are any plans for support BGP EVPN for extending virtual networks
> to ToR hardware switches?
> Or why it is bad idea?
I haven't heard anyone mention such plans.
___
discuss
21 matches
Mail list logo
