No problem Gao.
Btw, give it a try if you want, and double check that's as we said. I
dint't have time to recheck, and my memory doesn't use to be great ;-)
On Sat, Sep 23, 2017 at 1:54 AM, Gao Zhenyu wrote:
> Sorry for misleading, in my other testing, I ping the
Sorry for misleading, in my other testing, I ping the IP(is a router port's
IP) and saw packets go into a chassis(router are pined on this ovn-chassis
by using option:chassis=x). So in that time I though the router
should be only on a specific ovn-node if route was pinned.
Miguel had told
On Thu, Sep 21, 2017 at 10:56 AM, Miguel Angel Ajo Pelayo
wrote:
> On Thu, Sep 21, 2017 at 2:21 PM, Gao Zhenyu wrote:
>
>> I think the S/N or E/W are not the matter we should considering now.
>>
>> The multipath implementation is based on the
On Thu, Sep 21, 2017 at 2:21 PM, Gao Zhenyu wrote:
> I think the S/N or E/W are not the matter we should considering now.
>
> The multipath implementation is based on the existing ovn workflows. If
> you can use route to dispatch traffics to different node/logical port,
I think the S/N or E/W are not the matter we should considering now.
The multipath implementation is based on the existing ovn workflows. If you
can use route to dispatch traffics to different node/logical port, then the
multipath can make it. Otherwise it must get bug in multipath.
If the static
May be I missed something, but when I tried setting logical routers into
specific chassis, still the E/W traffic was handled in a distributed way
(from original chassis to destination chassis without going through the
router chassis), such chassis was only used for N/S, but may be I got
something
"
But, if an ovn port in foo (chassis A) wants to talk to alice1 (chassis B),
wouldn't all that E/W routing will happen virtually and the end result is
just a tunneled packet between chassis A and chassis B ? "
[ Now the hash function base on dst IP, if foo1 only talks to alice1, and
it is the
I forgot to say thank you very much for the explanation and diagrams.
On Wed, Sep 20, 2017 at 4:07 PM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:
> But, if an ovn port in foo (chassis A) wants to talk to alice1 (chassis
> B),
> wouldn't all that E/W routing will happen virtually and
But, if an ovn port in foo (chassis A) wants to talk to alice1 (chassis B),
wouldn't all that E/W routing will happen virtually and the end result is
just a tunneled packet between chassis A and chassis B ?
What's the benefit of multipath there if the possible failing link is
always the
You can take a look at this patch that implement a testcase :
https://patchwork.ozlabs.org/patch/815475/
In the testcase, we have R1, R2, R3.
R1 and R2 that are connected to each other via LS "join" in 20.0.0.0/24
network.
R1 and R3 that are connected to each other via LS "join2" in
Can you share an example of how this would benefit E/W routing. I'm just
not seeing the specific use case myself out of ignorance.
It'd be great if you could explain how would it work between several ports
in the networks and routers (may be a diagram?) otherwise I can't be really
helpful
Thanks for the suggestions!
Not all Logical port has a real ofp_port connect with it. And
bundle_load/bundle actions need real ovs port.
Especially in ovn router port, all router port are virtual port which just
a number/reg in our ovs-flows.
This implement of multipath can seperate ovn
I'm not very familiar with multipath implementations,
but would it be possible to use bundle( ouput action with hrw algorithm
instead of multipath calculation to a register?.
I say this, because if you look at lib/multipath.c lib/bundle.c you will
find that bundle.c is going to consider the
Thansk for the questions.
the multipath_port can be set via ovn-nbctl.
Like : ovn-nbctl -- --id=@lrt create Logical_Router_Static_Route
ip_prefix=0.0.0.0/0 nexthop=10.88.77.1 multipath_port=[mp1,mp2] -- add
Logical_Router edge1 static_routes @lrt
This patch haven't implement a ovn-nbctl command
14 matches
Mail list logo