Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-25 Thread Miguel Angel Ajo Pelayo 
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 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 me that router IP is an special case that will be handled
> by the specific chassis.
>
> Sorry for misleading again. I think we can focus on the implementatioin of
> multipath now. :)
>
> Thanks
> Zhenyu Gao
>
> 2017-09-22 20:22 GMT+08:00 Russell Bryant :
>
>> 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 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 route cannot dispatch traffic to some nodes or logical
>> port
>> >> then the multipath cannot make it as well.
>> >>
>> >> I am not sure if my understanding is right: I think if you deploy a
>> router
>> >> only on a specific ovn-node, then traffic between
>> A(src)---routerB(dst)
>> >> should go through this router.
>> >>
>> >
>> > That is the point where I'm not sure either. On the tests I made, if you
>> > configured an specific chassis for a router, only the N/S traffic went
>> > through that router (so multipath would make sense there), but in E/W
>> the
>> > traffic going through a router was directly going from origin port
>> chassis,
>> > to destination port chassis, without going through the specific router
>> > chassis.
>> >
>> > May be it is a bug, or may be it was missconfiguration at my side. I
>> will
>> > double check it.
>>
>> I haven't followed all of this discussion in detail, but the behavior
>> you describe is correct and intentional.
>>
>> E/W is distributed.  N/S is centralized.
>>
>> It's actually a little more complicated because you can also define
>> N/S NAT rules that are on other chassis if you have a 1-1 NAT mapping
>> to a logical port on that chassis.
>>
>> >
>> >
>> >>
>> >> Any suggestions and comments are welcome :)
>> >>
>> >>
>> >> Thanks
>> >> Zhenyu Gao
>> >>
>> >> 2017-09-21 19:07 GMT+08:00 Miguel Angel Ajo Pelayo <
>> majop...@redhat.com>:
>> >>
>> >>> 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 wrong.
>> >>>
>> >>>
>> >>> On Wed, Sep 20, 2017 at 4:48 PM, Gao Zhenyu 
>> >>> 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 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 tunnel packet between chassisA and chassis B ]
>> 
>>  The benifit is if you have two ovn-routers and those router are ONLY
>>  deployed in chassis C and chassis D, the traffics can be sperated in
>> two
>>  paths automatically. Otherwise you need to config static rule one by
>> one to
>>  seperate traffics.
>>  To make a long story short, you also can do same thing by config
>>  numerous static rules to seperate traffic but the multipath can do it
>>  automatically.
>> 
>>  2017-09-20 22:08 GMT+08:00 Miguel Angel Ajo Pelayo <
>> majop...@redhat.com>
>>  :
>> 
>> > 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 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 connection between chassis A and chassis B ?
>> >>
>> >> I suspect there's something I'm missing on the picture.
>> >>
>> >> On Wed, Sep 20, 2017 at 3:49 PM, Gao Zhenyu <
>> sysugaozhe...@gmail.com>
>> >> wrote:
>> >>

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-22 Thread Gao Zhenyu 
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 me that router IP is an special case that will be handled
by the specific chassis.

Sorry for misleading again. I think we can focus on the implementatioin of
multipath now. :)

Thanks
Zhenyu Gao

2017-09-22 20:22 GMT+08:00 Russell Bryant :

> 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 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 route cannot dispatch traffic to some nodes or logical
> port
> >> then the multipath cannot make it as well.
> >>
> >> I am not sure if my understanding is right: I think if you deploy a
> router
> >> only on a specific ovn-node, then traffic between
> A(src)---routerB(dst)
> >> should go through this router.
> >>
> >
> > That is the point where I'm not sure either. On the tests I made, if you
> > configured an specific chassis for a router, only the N/S traffic went
> > through that router (so multipath would make sense there), but in E/W the
> > traffic going through a router was directly going from origin port
> chassis,
> > to destination port chassis, without going through the specific router
> > chassis.
> >
> > May be it is a bug, or may be it was missconfiguration at my side. I will
> > double check it.
>
> I haven't followed all of this discussion in detail, but the behavior
> you describe is correct and intentional.
>
> E/W is distributed.  N/S is centralized.
>
> It's actually a little more complicated because you can also define
> N/S NAT rules that are on other chassis if you have a 1-1 NAT mapping
> to a logical port on that chassis.
>
> >
> >
> >>
> >> Any suggestions and comments are welcome :)
> >>
> >>
> >> Thanks
> >> Zhenyu Gao
> >>
> >> 2017-09-21 19:07 GMT+08:00 Miguel Angel Ajo Pelayo  >:
> >>
> >>> 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 wrong.
> >>>
> >>>
> >>> On Wed, Sep 20, 2017 at 4:48 PM, Gao Zhenyu 
> >>> 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 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 tunnel packet between chassisA and chassis B ]
> 
>  The benifit is if you have two ovn-routers and those router are ONLY
>  deployed in chassis C and chassis D, the traffics can be sperated in
> two
>  paths automatically. Otherwise you need to config static rule one by
> one to
>  seperate traffics.
>  To make a long story short, you also can do same thing by config
>  numerous static rules to seperate traffic but the multipath can do it
>  automatically.
> 
>  2017-09-20 22:08 GMT+08:00 Miguel Angel Ajo Pelayo <
> majop...@redhat.com>
>  :
> 
> > 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 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 connection between chassis A and chassis B ?
> >>
> >> I suspect there's something I'm missing on the picture.
> >>
> >> On Wed, Sep 20, 2017 at 3:49 PM, Gao Zhenyu <
> sysugaozhe...@gmail.com>
> >> wrote:
> >>
> >>> 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
> >>> 20.0.0.0/24

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-22 Thread Russell Bryant 
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 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 route cannot dispatch traffic to some nodes or logical port
>> then the multipath cannot make it as well.
>>
>> I am not sure if my understanding is right: I think if you deploy a router
>> only on a specific ovn-node, then traffic between A(src)---routerB(dst)
>> should go through this router.
>>
>
> That is the point where I'm not sure either. On the tests I made, if you
> configured an specific chassis for a router, only the N/S traffic went
> through that router (so multipath would make sense there), but in E/W the
> traffic going through a router was directly going from origin port chassis,
> to destination port chassis, without going through the specific router
> chassis.
>
> May be it is a bug, or may be it was missconfiguration at my side. I will
> double check it.

I haven't followed all of this discussion in detail, but the behavior
you describe is correct and intentional.

E/W is distributed.  N/S is centralized.

It's actually a little more complicated because you can also define
N/S NAT rules that are on other chassis if you have a 1-1 NAT mapping
to a logical port on that chassis.

>
>
>>
>> Any suggestions and comments are welcome :)
>>
>>
>> Thanks
>> Zhenyu Gao
>>
>> 2017-09-21 19:07 GMT+08:00 Miguel Angel Ajo Pelayo :
>>
>>> 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 wrong.
>>>
>>>
>>> On Wed, Sep 20, 2017 at 4:48 PM, Gao Zhenyu 
>>> 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 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 tunnel packet between chassisA and chassis B ]

 The benifit is if you have two ovn-routers and those router are ONLY
 deployed in chassis C and chassis D, the traffics can be sperated in two
 paths automatically. Otherwise you need to config static rule one by one to
 seperate traffics.
 To make a long story short, you also can do same thing by config
 numerous static rules to seperate traffic but the multipath can do it
 automatically.

 2017-09-20 22:08 GMT+08:00 Miguel Angel Ajo Pelayo 
 :

> 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 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 connection between chassis A and chassis B ?
>>
>> I suspect there's something I'm missing on the picture.
>>
>> On Wed, Sep 20, 2017 at 3:49 PM, Gao Zhenyu 
>> wrote:
>>
>>> 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
>>> 20.0.0.0/24 network.
>>>  R1 has switchess foo (192.168.1.0/24) connected to it. R2 and R3
>>> has alice (172.16.1.0/24) connected to it.
>>>  R2 and R3 are gateway routers.
>>>
>>> A packet send  to alice1/aclie2 from foo have mulitpath to
>>> destination:
>>>1. foo-->R1-->join-->R2-->alice.
>>>2. foo-->R1-->join2-->R3-->alice.
>>>
>>> In this testcase, it simulates two packet, one's destination is
>>> 172.16.1.2, another is 172.16.1.4.  The mulitpath that was configured 
>>> in R1
>>> can seperate those traffics to R2/R3. Finally,  172.16.1.2 packet 
>>> travels
>>> path2, 172.16.1.4  packet travels path1
>>>
>>>   +--+
>>>   |  foo |
>>>   +--+
>>>   |
>>>   |

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-21 Thread Miguel Angel Ajo Pelayo 
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, then
> the multipath can make it. Otherwise it must get bug in multipath.
> If the static route cannot dispatch traffic to some nodes or logical port
> then the multipath cannot make it as well.
>
> I am not sure if my understanding is right: I think if you deploy a router
> only on a specific ovn-node, then traffic between A(src)---routerB(dst)
> should go through this router.
>

That is the point where I'm not sure either. On the tests I made, if you
configured an specific chassis for a router, only the N/S traffic went
through that router (so multipath would make sense there), but in E/W the
traffic going through a router was directly going from origin port chassis,
to destination port chassis, without going through the specific router
chassis.

May be it is a bug, or may be it was missconfiguration at my side. I will
double check it.


>
> Any suggestions and comments are welcome :)
>
>
> Thanks
> Zhenyu Gao
>
> 2017-09-21 19:07 GMT+08:00 Miguel Angel Ajo Pelayo :
>
>> 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 wrong.
>>
>>
>> On Wed, Sep 20, 2017 at 4:48 PM, Gao Zhenyu 
>> 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 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 tunnel packet between chassisA and chassis B ]
>>>
>>> The benifit is if you have two ovn-routers and those router are ONLY
>>> deployed in chassis C and chassis D, the traffics can be sperated in two
>>> paths automatically. Otherwise you need to config static rule one by one to
>>> seperate traffics.
>>> To make a long story short, you also can do same thing by config
>>> numerous static rules to seperate traffic but the multipath can do it
>>> automatically.
>>>
>>> 2017-09-20 22:08 GMT+08:00 Miguel Angel Ajo Pelayo 
>>> :
>>>
 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 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 connection between chassis A and chassis B ?
>
> I suspect there's something I'm missing on the picture.
>
> On Wed, Sep 20, 2017 at 3:49 PM, Gao Zhenyu 
> wrote:
>
>> 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
>> 20.0.0.0/24 network.
>>  R1 has switchess foo (192.168.1.0/24) connected to it. R2 and R3
>> has alice (172.16.1.0/24) connected to it.
>>  R2 and R3 are gateway routers.
>>
>> A packet send  to alice1/aclie2 from foo have mulitpath to
>> destination:
>>1. foo-->R1-->join-->R2-->alice.
>>2. foo-->R1-->join2-->R3-->alice.
>>
>> In this testcase, it simulates two packet, one's destination is
>> 172.16.1.2, another is 172.16.1.4.  The mulitpath that was configured in 
>> R1
>> can seperate those traffics to R2/R3. Finally,  172.16.1.2 packet travels
>> path2, 172.16.1.4  packet travels path1
>>
>>   +--+
>>   |  foo |
>>   +--+
>>   |
>>   |
>>+--+
>>|  R1 |-+
>>+--+   |
>>||
>>||
>> +--+   +---+
>> | join |   | join2 |
>> +--+   +---+
>> |  |
>> |  |
>> +--+   +---+
>> |  R2 |   |  R3  |
>> +--+   +---+
>>|   |
>>|   |
>> +-+
>> |  alice  |
>>

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-21 Thread Gao Zhenyu 
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 route cannot dispatch traffic to some nodes or logical port
then the multipath cannot make it as well.

I am not sure if my understanding is right: I think if you deploy a router
only on a specific ovn-node, then traffic between A(src)---routerB(dst)
should go through this router.

Any suggestions and comments are welcome :)


Thanks
Zhenyu Gao

2017-09-21 19:07 GMT+08:00 Miguel Angel Ajo Pelayo :

> 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 wrong.
>
>
> On Wed, Sep 20, 2017 at 4:48 PM, Gao Zhenyu 
> 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 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 tunnel packet between chassisA and chassis B ]
>>
>> The benifit is if you have two ovn-routers and those router are ONLY
>> deployed in chassis C and chassis D, the traffics can be sperated in two
>> paths automatically. Otherwise you need to config static rule one by one to
>> seperate traffics.
>> To make a long story short, you also can do same thing by config numerous
>> static rules to seperate traffic but the multipath can do it
>> automatically.
>>
>> 2017-09-20 22:08 GMT+08:00 Miguel Angel Ajo Pelayo :
>>
>>> 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 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 connection between chassis A and chassis B ?

 I suspect there's something I'm missing on the picture.

 On Wed, Sep 20, 2017 at 3:49 PM, Gao Zhenyu 
 wrote:

> 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
> 20.0.0.0/24 network.
>  R1 has switchess foo (192.168.1.0/24) connected to it. R2 and R3 has
> alice (172.16.1.0/24) connected to it.
>  R2 and R3 are gateway routers.
>
> A packet send  to alice1/aclie2 from foo have mulitpath to
> destination:
>1. foo-->R1-->join-->R2-->alice.
>2. foo-->R1-->join2-->R3-->alice.
>
> In this testcase, it simulates two packet, one's destination is
> 172.16.1.2, another is 172.16.1.4.  The mulitpath that was configured in 
> R1
> can seperate those traffics to R2/R3. Finally,  172.16.1.2 packet travels
> path2, 172.16.1.4  packet travels path1
>
>   +--+
>   |  foo |
>   +--+
>   |
>   |
>+--+
>|  R1 |-+
>+--+   |
>||
>||
> +--+   +---+
> | join |   | join2 |
> +--+   +---+
> |  |
> |  |
> +--+   +---+
> |  R2 |   |  R3  |
> +--+   +---+
>|   |
>|   |
> +-+
> |  alice  |
> +-+
>| |
>   alice1 alice2
>
> Please let me know if you have any question on it. :)
>
> Thanks
> Zhenyu Gao
>
> 2017-09-20 20:58 GMT+08:00 Miguel Angel Ajo Pelayo <
> majop...@redhat.com>:
>
>> 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 reviewing :)
>>
>> Cheers, and thanks for the

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-21 Thread Miguel Angel Ajo Pelayo 
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 wrong.


On Wed, Sep 20, 2017 at 4:48 PM, Gao Zhenyu  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 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 tunnel packet between chassisA and chassis B ]
>
> The benifit is if you have two ovn-routers and those router are ONLY
> deployed in chassis C and chassis D, the traffics can be sperated in two
> paths automatically. Otherwise you need to config static rule one by one to
> seperate traffics.
> To make a long story short, you also can do same thing by config numerous
> static rules to seperate traffic but the multipath can do it
> automatically.
>
> 2017-09-20 22:08 GMT+08:00 Miguel Angel Ajo Pelayo :
>
>> 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 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 connection between chassis A and chassis B ?
>>>
>>> I suspect there's something I'm missing on the picture.
>>>
>>> On Wed, Sep 20, 2017 at 3:49 PM, Gao Zhenyu 
>>> wrote:
>>>
 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
 20.0.0.0/24 network.
  R1 has switchess foo (192.168.1.0/24) connected to it. R2 and R3 has
 alice (172.16.1.0/24) connected to it.
  R2 and R3 are gateway routers.

 A packet send  to alice1/aclie2 from foo have mulitpath to destination:
1. foo-->R1-->join-->R2-->alice.
2. foo-->R1-->join2-->R3-->alice.

 In this testcase, it simulates two packet, one's destination is
 172.16.1.2, another is 172.16.1.4.  The mulitpath that was configured in R1
 can seperate those traffics to R2/R3. Finally,  172.16.1.2 packet travels
 path2, 172.16.1.4  packet travels path1

   +--+
   |  foo |
   +--+
   |
   |
+--+
|  R1 |-+
+--+   |
||
||
 +--+   +---+
 | join |   | join2 |
 +--+   +---+
 |  |
 |  |
 +--+   +---+
 |  R2 |   |  R3  |
 +--+   +---+
|   |
|   |
 +-+
 |  alice  |
 +-+
| |
   alice1 alice2

 Please let me know if you have any question on it. :)

 Thanks
 Zhenyu Gao

 2017-09-20 20:58 GMT+08:00 Miguel Angel Ajo Pelayo :

> 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 reviewing :)
>
> Cheers, and thanks for the patience.
>
> On Wed, Sep 20, 2017 at 12:25 PM, Gao Zhenyu 
> wrote:
>
>> 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 east-west traffic, it
>> helps dispatch traffic to gateways and routers easily.
>>
>> For south-north traffic, we can have bundle/bundle_load action to
>> consider the remote tunnel up/down status. I would like to make it step 
>> by
>> step and implement it in my next series patches.
>>
>> Thanks
>> Zhenyu Gao
>>
>> 2017-09-20 17:53 GMT+08:00 Miguel Angel Ajo

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-20 Thread Gao Zhenyu 
"
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 tunnel packet between chassisA and chassis B ]

The benifit is if you have two ovn-routers and those router are ONLY
deployed in chassis C and chassis D, the traffics can be sperated in two
paths automatically. Otherwise you need to config static rule one by one to
seperate traffics.
To make a long story short, you also can do same thing by config numerous
static rules to seperate traffic but the multipath can do it automatically.

2017-09-20 22:08 GMT+08:00 Miguel Angel Ajo Pelayo :

> 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 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 connection between chassis A and chassis B ?
>>
>> I suspect there's something I'm missing on the picture.
>>
>> On Wed, Sep 20, 2017 at 3:49 PM, Gao Zhenyu 
>> wrote:
>>
>>> 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
>>> 20.0.0.0/24 network.
>>>  R1 has switchess foo (192.168.1.0/24) connected to it. R2 and R3 has
>>> alice (172.16.1.0/24) connected to it.
>>>  R2 and R3 are gateway routers.
>>>
>>> A packet send  to alice1/aclie2 from foo have mulitpath to destination:
>>>1. foo-->R1-->join-->R2-->alice.
>>>2. foo-->R1-->join2-->R3-->alice.
>>>
>>> In this testcase, it simulates two packet, one's destination is
>>> 172.16.1.2, another is 172.16.1.4.  The mulitpath that was configured in R1
>>> can seperate those traffics to R2/R3. Finally,  172.16.1.2 packet travels
>>> path2, 172.16.1.4  packet travels path1
>>>
>>>   +--+
>>>   |  foo |
>>>   +--+
>>>   |
>>>   |
>>>+--+
>>>|  R1 |-+
>>>+--+   |
>>>||
>>>||
>>> +--+   +---+
>>> | join |   | join2 |
>>> +--+   +---+
>>> |  |
>>> |  |
>>> +--+   +---+
>>> |  R2 |   |  R3  |
>>> +--+   +---+
>>>|   |
>>>|   |
>>> +-+
>>> |  alice  |
>>> +-+
>>>| |
>>>   alice1 alice2
>>>
>>> Please let me know if you have any question on it. :)
>>>
>>> Thanks
>>> Zhenyu Gao
>>>
>>> 2017-09-20 20:58 GMT+08:00 Miguel Angel Ajo Pelayo 
>>> :
>>>
 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 reviewing :)

 Cheers, and thanks for the patience.

 On Wed, Sep 20, 2017 at 12:25 PM, Gao Zhenyu 
 wrote:

> 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 east-west traffic, it
> helps dispatch traffic to gateways and routers easily.
>
> For south-north traffic, we can have bundle/bundle_load action to
> consider the remote tunnel up/down status. I would like to make it step by
> step and implement it in my next series patches.
>
> Thanks
> Zhenyu Gao
>
> 2017-09-20 17:53 GMT+08:00 Miguel Angel Ajo Pelayo <
> majop...@redhat.com>:
>
>> 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 up/down status
>> (slave_enabled check) of the links.
>>
>> That way the controller doesn't need to modify any flow based on link
>>

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-20 Thread Miguel Angel Ajo Pelayo 
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 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 connection between chassis A and chassis B ?
>
> I suspect there's something I'm missing on the picture.
>
> On Wed, Sep 20, 2017 at 3:49 PM, Gao Zhenyu 
> wrote:
>
>> 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
>> 20.0.0.0/24 network.
>>  R1 has switchess foo (192.168.1.0/24) connected to it. R2 and R3 has
>> alice (172.16.1.0/24) connected to it.
>>  R2 and R3 are gateway routers.
>>
>> A packet send  to alice1/aclie2 from foo have mulitpath to destination:
>>1. foo-->R1-->join-->R2-->alice.
>>2. foo-->R1-->join2-->R3-->alice.
>>
>> In this testcase, it simulates two packet, one's destination is
>> 172.16.1.2, another is 172.16.1.4.  The mulitpath that was configured in R1
>> can seperate those traffics to R2/R3. Finally,  172.16.1.2 packet travels
>> path2, 172.16.1.4  packet travels path1
>>
>>   +--+
>>   |  foo |
>>   +--+
>>   |
>>   |
>>+--+
>>|  R1 |-+
>>+--+   |
>>||
>>||
>> +--+   +---+
>> | join |   | join2 |
>> +--+   +---+
>> |  |
>> |  |
>> +--+   +---+
>> |  R2 |   |  R3  |
>> +--+   +---+
>>|   |
>>|   |
>> +-+
>> |  alice  |
>> +-+
>>| |
>>   alice1 alice2
>>
>> Please let me know if you have any question on it. :)
>>
>> Thanks
>> Zhenyu Gao
>>
>> 2017-09-20 20:58 GMT+08:00 Miguel Angel Ajo Pelayo :
>>
>>> 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 reviewing :)
>>>
>>> Cheers, and thanks for the patience.
>>>
>>> On Wed, Sep 20, 2017 at 12:25 PM, Gao Zhenyu 
>>> wrote:
>>>
 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 east-west traffic, it
 helps dispatch traffic to gateways and routers easily.

 For south-north traffic, we can have bundle/bundle_load action to
 consider the remote tunnel up/down status. I would like to make it step by
 step and implement it in my next series patches.

 Thanks
 Zhenyu Gao

 2017-09-20 17:53 GMT+08:00 Miguel Angel Ajo Pelayo :

> 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 up/down status
> (slave_enabled check) of the links.
>
> That way the controller doesn't need to modify any flow based on link
> status.
>
> On Wed, Sep 20, 2017 at 5:45 AM, Gao Zhenyu 
> wrote:
>
>> 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 to configure
>> multipath routing. Because I am still considering reusing nexthop or
>> output_port(make them become array entries), and want to collect
>> suggestions on it.
>>
>> About the status of next -hop, I would like to introduce bundle_load
>> and bfd to make it later.
>>
>> Thanks
>> Zhenyu Gao
>>
>> 2017-09-20 11:13 GMT+08:00 :
>>
>>> How to configure multipath_port in static_route?

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-20 Thread Miguel Angel Ajo Pelayo 
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 connection between chassis A and chassis B ?

I suspect there's something I'm missing on the picture.

On Wed, Sep 20, 2017 at 3:49 PM, Gao Zhenyu  wrote:

> 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 20.0.0.0/24
> network.
>  R1 has switchess foo (192.168.1.0/24) connected to it. R2 and R3 has
> alice (172.16.1.0/24) connected to it.
>  R2 and R3 are gateway routers.
>
> A packet send  to alice1/aclie2 from foo have mulitpath to destination:
>1. foo-->R1-->join-->R2-->alice.
>2. foo-->R1-->join2-->R3-->alice.
>
> In this testcase, it simulates two packet, one's destination is
> 172.16.1.2, another is 172.16.1.4.  The mulitpath that was configured in R1
> can seperate those traffics to R2/R3. Finally,  172.16.1.2 packet travels
> path2, 172.16.1.4  packet travels path1
>
>   +--+
>   |  foo |
>   +--+
>   |
>   |
>+--+
>|  R1 |-+
>+--+   |
>||
>||
> +--+   +---+
> | join |   | join2 |
> +--+   +---+
> |  |
> |  |
> +--+   +---+
> |  R2 |   |  R3  |
> +--+   +---+
>|   |
>|   |
> +-+
> |  alice  |
> +-+
>| |
>   alice1 alice2
>
> Please let me know if you have any question on it. :)
>
> Thanks
> Zhenyu Gao
>
> 2017-09-20 20:58 GMT+08:00 Miguel Angel Ajo Pelayo :
>
>> 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 reviewing :)
>>
>> Cheers, and thanks for the patience.
>>
>> On Wed, Sep 20, 2017 at 12:25 PM, Gao Zhenyu 
>> wrote:
>>
>>> 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 east-west traffic, it helps
>>> dispatch traffic to gateways and routers easily.
>>>
>>> For south-north traffic, we can have bundle/bundle_load action to
>>> consider the remote tunnel up/down status. I would like to make it step by
>>> step and implement it in my next series patches.
>>>
>>> Thanks
>>> Zhenyu Gao
>>>
>>> 2017-09-20 17:53 GMT+08:00 Miguel Angel Ajo Pelayo 
>>> :
>>>
 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 up/down status
 (slave_enabled check) of the links.

 That way the controller doesn't need to modify any flow based on link
 status.

 On Wed, Sep 20, 2017 at 5:45 AM, Gao Zhenyu 
 wrote:

> 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 to configure
> multipath routing. Because I am still considering reusing nexthop or
> output_port(make them become array entries), and want to collect
> suggestions on it.
>
> About the status of next -hop, I would like to introduce bundle_load
> and bfd to make it later.
>
> Thanks
> Zhenyu Gao
>
> 2017-09-20 11:13 GMT+08:00 :
>
>> How to configure multipath_port in static_route? I think the the
>> multipath
>> can be figured out from exist data of static_route, may not need to
>> add
>> this multipath_port column.
>>
>> And I think we should add a status column to indicate the nexthop
>> state.
>> When some of nexthop in multipath is down, ovn

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-20 Thread Gao Zhenyu 
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 20.0.0.0/24
network.
 R1 has switchess foo (192.168.1.0/24) connected to it. R2 and R3 has alice
(172.16.1.0/24) connected to it.
 R2 and R3 are gateway routers.

A packet send  to alice1/aclie2 from foo have mulitpath to destination:
   1. foo-->R1-->join-->R2-->alice.
   2. foo-->R1-->join2-->R3-->alice.

In this testcase, it simulates two packet, one's destination is 172.16.1.2,
another is 172.16.1.4.  The mulitpath that was configured in R1 can
seperate those traffics to R2/R3. Finally,  172.16.1.2 packet travels
path2, 172.16.1.4  packet travels path1

  +--+
  |  foo |
  +--+
  |
  |
   +--+
   |  R1 |-+
   +--+   |
   ||
   ||
+--+   +---+
| join |   | join2 |
+--+   +---+
|  |
|  |
+--+   +---+
|  R2 |   |  R3  |
+--+   +---+
   |   |
   |   |
+-+
|  alice  |
+-+
   | |
  alice1 alice2

Please let me know if you have any question on it. :)

Thanks
Zhenyu Gao

2017-09-20 20:58 GMT+08:00 Miguel Angel Ajo Pelayo :

> 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 reviewing :)
>
> Cheers, and thanks for the patience.
>
> On Wed, Sep 20, 2017 at 12:25 PM, Gao Zhenyu 
> wrote:
>
>> 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 east-west traffic, it helps
>> dispatch traffic to gateways and routers easily.
>>
>> For south-north traffic, we can have bundle/bundle_load action to
>> consider the remote tunnel up/down status. I would like to make it step by
>> step and implement it in my next series patches.
>>
>> Thanks
>> Zhenyu Gao
>>
>> 2017-09-20 17:53 GMT+08:00 Miguel Angel Ajo Pelayo :
>>
>>> 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 up/down status (slave_enabled
>>> check) of the links.
>>>
>>> That way the controller doesn't need to modify any flow based on link
>>> status.
>>>
>>> On Wed, Sep 20, 2017 at 5:45 AM, Gao Zhenyu 
>>> wrote:
>>>
 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 to configure multipath
 routing. Because I am still considering reusing nexthop or output_port(make
 them become array entries), and want to collect suggestions on it.

 About the status of next -hop, I would like to introduce bundle_load
 and bfd to make it later.

 Thanks
 Zhenyu Gao

 2017-09-20 11:13 GMT+08:00 :

> How to configure multipath_port in static_route? I think the the
> multipath
> can be figured out from exist data of static_route, may not need to add
> this multipath_port column.
>
> And I think we should add a status column to indicate the nexthop
> state.
> When some of nexthop in multipath is down, ovn should change the
> correspond flows.
>
> Thanks.
>
>
>
>
>
> Zhenyu Gao 
> 发件人： ovs-dev-boun...@openvswitch.org
> 2017/09/19 19:37
>
> 收件人：b...@ovn.org, majop...@redhat.com,
> anilvenk...@redhat.com, russ...@ovn.org, d...@openvswitch.org,
> 抄送：
> 主题：  [ovs-dev] [PATCH v1 1/3] Add multipath static router in
> OVN northd  and north-db
>
>
> 1. ovn-nb.ovsschema was updated to add new field multipath_port.
> 2. Add multipath feature in ovn-northd part. northd generates multipath
> flows to dispatch traffic by

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-20 Thread Miguel Angel Ajo Pelayo 
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 reviewing :)

Cheers, and thanks for the patience.

On Wed, Sep 20, 2017 at 12:25 PM, Gao Zhenyu 
wrote:

> 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 east-west traffic, it helps
> dispatch traffic to gateways and routers easily.
>
> For south-north traffic, we can have bundle/bundle_load action to consider
> the remote tunnel up/down status. I would like to make it step by step and
> implement it in my next series patches.
>
> Thanks
> Zhenyu Gao
>
> 2017-09-20 17:53 GMT+08:00 Miguel Angel Ajo Pelayo :
>
>> 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 up/down status (slave_enabled
>> check) of the links.
>>
>> That way the controller doesn't need to modify any flow based on link
>> status.
>>
>> On Wed, Sep 20, 2017 at 5:45 AM, Gao Zhenyu 
>> wrote:
>>
>>> 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 to configure multipath
>>> routing. Because I am still considering reusing nexthop or output_port(make
>>> them become array entries), and want to collect suggestions on it.
>>>
>>> About the status of next -hop, I would like to introduce bundle_load and
>>> bfd to make it later.
>>>
>>> Thanks
>>> Zhenyu Gao
>>>
>>> 2017-09-20 11:13 GMT+08:00 :
>>>
 How to configure multipath_port in static_route? I think the the
 multipath
 can be figured out from exist data of static_route, may not need to add
 this multipath_port column.

 And I think we should add a status column to indicate the nexthop state.
 When some of nexthop in multipath is down, ovn should change the
 correspond flows.

 Thanks.





 Zhenyu Gao 
 发件人： ovs-dev-boun...@openvswitch.org
 2017/09/19 19:37

 收件人：b...@ovn.org, majop...@redhat.com,
 anilvenk...@redhat.com, russ...@ovn.org, d...@openvswitch.org,
 抄送：
 主题：  [ovs-dev] [PATCH v1 1/3] Add multipath static router in
 OVN northd  and north-db


 1. ovn-nb.ovsschema was updated to add new field multipath_port.
 2. Add multipath feature in ovn-northd part. northd generates multipath
 flows to dispatch traffic by using packet's IP dst address if user set
 Logical_Router_Static_Route's multipath_port with ports.
 3. Add new table(lr_in_multipath) in ovn-northd's router ingress stages
 to dispatch traffic to ports.
 4. Add multipath flow in Table 5(lr_in_ip_routing) and store hash result
 into reg0. reg9[2] was used to indicate packet which need dispatching.
 5. Add multipath feature description in ovn/northd/ovn-northd.8.xml
 and ovn/ovn-nb.xml

 Signed-off-by: Zhenyu Gao 
 ---
  ovn/northd/ovn-northd.8.xml |  67 +++-
  ovn/northd/ovn-northd.c | 245
 ++--
  ovn/ovn-nb.ovsschema|   6 +-
  ovn/ovn-nb.xml  |   9 ++
  4 files changed, 289 insertions(+), 38 deletions(-)

 diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
 index 0d85ec0..b1ce9a9 100644
 --- a/ovn/northd/ovn-northd.8.xml
 +++ b/ovn/northd/ovn-northd.8.xml
 @@ -1598,6 +1598,9 @@ icmp4 {
port (ingress table ARP Request will generate an ARP
request, if needed, with reg0 as the target protocol
address and reg1 as the source protocol address).
 +  A IP route can be configured that it has multipath to next-hop.
 +  If a packet has multipath to destination, OVN assign the port
 +  index into reg[0] to indicate the packet's output port in table
 6.
  

  
 @@ -1617,6 +1620,28 @@ icmp4 {


  
 +  IPv4/IPV6 multipath routing table. For each route to
 IPv4/IPv6
 +

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-20 Thread Gao Zhenyu 
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 east-west traffic, it helps
dispatch traffic to gateways and routers easily.

For south-north traffic, we can have bundle/bundle_load action to consider
the remote tunnel up/down status. I would like to make it step by step and
implement it in my next series patches.

Thanks
Zhenyu Gao

2017-09-20 17:53 GMT+08:00 Miguel Angel Ajo Pelayo :

> 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 up/down status (slave_enabled
> check) of the links.
>
> That way the controller doesn't need to modify any flow based on link
> status.
>
> On Wed, Sep 20, 2017 at 5:45 AM, Gao Zhenyu 
> wrote:
>
>> 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 to configure multipath
>> routing. Because I am still considering reusing nexthop or output_port(make
>> them become array entries), and want to collect suggestions on it.
>>
>> About the status of next -hop, I would like to introduce bundle_load and
>> bfd to make it later.
>>
>> Thanks
>> Zhenyu Gao
>>
>> 2017-09-20 11:13 GMT+08:00 :
>>
>>> How to configure multipath_port in static_route? I think the the
>>> multipath
>>> can be figured out from exist data of static_route, may not need to add
>>> this multipath_port column.
>>>
>>> And I think we should add a status column to indicate the nexthop state.
>>> When some of nexthop in multipath is down, ovn should change the
>>> correspond flows.
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>>
>>> Zhenyu Gao 
>>> 发件人： ovs-dev-boun...@openvswitch.org
>>> 2017/09/19 19:37
>>>
>>> 收件人：b...@ovn.org, majop...@redhat.com,
>>> anilvenk...@redhat.com, russ...@ovn.org, d...@openvswitch.org,
>>> 抄送：
>>> 主题：  [ovs-dev] [PATCH v1 1/3] Add multipath static router in
>>> OVN northd  and north-db
>>>
>>>
>>> 1. ovn-nb.ovsschema was updated to add new field multipath_port.
>>> 2. Add multipath feature in ovn-northd part. northd generates multipath
>>> flows to dispatch traffic by using packet's IP dst address if user set
>>> Logical_Router_Static_Route's multipath_port with ports.
>>> 3. Add new table(lr_in_multipath) in ovn-northd's router ingress stages
>>> to dispatch traffic to ports.
>>> 4. Add multipath flow in Table 5(lr_in_ip_routing) and store hash result
>>> into reg0. reg9[2] was used to indicate packet which need dispatching.
>>> 5. Add multipath feature description in ovn/northd/ovn-northd.8.xml
>>> and ovn/ovn-nb.xml
>>>
>>> Signed-off-by: Zhenyu Gao 
>>> ---
>>>  ovn/northd/ovn-northd.8.xml |  67 +++-
>>>  ovn/northd/ovn-northd.c | 245
>>> ++--
>>>  ovn/ovn-nb.ovsschema|   6 +-
>>>  ovn/ovn-nb.xml  |   9 ++
>>>  4 files changed, 289 insertions(+), 38 deletions(-)
>>>
>>> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
>>> index 0d85ec0..b1ce9a9 100644
>>> --- a/ovn/northd/ovn-northd.8.xml
>>> +++ b/ovn/northd/ovn-northd.8.xml
>>> @@ -1598,6 +1598,9 @@ icmp4 {
>>>port (ingress table ARP Request will generate an ARP
>>>request, if needed, with reg0 as the target protocol
>>>address and reg1 as the source protocol address).
>>> +  A IP route can be configured that it has multipath to next-hop.
>>> +  If a packet has multipath to destination, OVN assign the port
>>> +  index into reg[0] to indicate the packet's output port in table 6.
>>>  
>>>
>>>  
>>> @@ -1617,6 +1620,28 @@ icmp4 {
>>>
>>>
>>>  
>>> +  IPv4/IPV6 multipath routing table. For each route to IPv4/IPv6
>>> +  network N with netmask M, on multipath
>>> port
>>> +  P with IP address A and Ethernet
>>> +  address E, a logical flow with match
>>> +  ip4.dst ==N/M,whose
>>> priority
>>> +  is the number of 1-bits plus 10 in M,
>>> +  has the following actions:
>>> +
>>> +
>>> +
>>> +ip.ttl--;
>>> +multipath (nw_dst, 0, modulo_n, n_links, 0, reg0);
>>> +reg9[2] = 1
>>> +next;
>>> +
>>> +
>>> +  n_links is the number of multipath port.
>>> +
>>> +  
>>> +
>>> +  
>>> +

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-20 Thread Miguel Angel Ajo Pelayo 
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 up/down status (slave_enabled
check) of the links.

That way the controller doesn't need to modify any flow based on link
status.

On Wed, Sep 20, 2017 at 5:45 AM, Gao Zhenyu  wrote:

> 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 to configure multipath
> routing. Because I am still considering reusing nexthop or output_port(make
> them become array entries), and want to collect suggestions on it.
>
> About the status of next -hop, I would like to introduce bundle_load and
> bfd to make it later.
>
> Thanks
> Zhenyu Gao
>
> 2017-09-20 11:13 GMT+08:00 :
>
>> How to configure multipath_port in static_route? I think the the multipath
>> can be figured out from exist data of static_route, may not need to add
>> this multipath_port column.
>>
>> And I think we should add a status column to indicate the nexthop state.
>> When some of nexthop in multipath is down, ovn should change the
>> correspond flows.
>>
>> Thanks.
>>
>>
>>
>>
>>
>> Zhenyu Gao 
>> 发件人： ovs-dev-boun...@openvswitch.org
>> 2017/09/19 19:37
>>
>> 收件人：b...@ovn.org, majop...@redhat.com,
>> anilvenk...@redhat.com, russ...@ovn.org, d...@openvswitch.org,
>> 抄送：
>> 主题：  [ovs-dev] [PATCH v1 1/3] Add multipath static router in
>> OVN northd  and north-db
>>
>>
>> 1. ovn-nb.ovsschema was updated to add new field multipath_port.
>> 2. Add multipath feature in ovn-northd part. northd generates multipath
>> flows to dispatch traffic by using packet's IP dst address if user set
>> Logical_Router_Static_Route's multipath_port with ports.
>> 3. Add new table(lr_in_multipath) in ovn-northd's router ingress stages
>> to dispatch traffic to ports.
>> 4. Add multipath flow in Table 5(lr_in_ip_routing) and store hash result
>> into reg0. reg9[2] was used to indicate packet which need dispatching.
>> 5. Add multipath feature description in ovn/northd/ovn-northd.8.xml
>> and ovn/ovn-nb.xml
>>
>> Signed-off-by: Zhenyu Gao 
>> ---
>>  ovn/northd/ovn-northd.8.xml |  67 +++-
>>  ovn/northd/ovn-northd.c | 245
>> ++--
>>  ovn/ovn-nb.ovsschema|   6 +-
>>  ovn/ovn-nb.xml  |   9 ++
>>  4 files changed, 289 insertions(+), 38 deletions(-)
>>
>> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
>> index 0d85ec0..b1ce9a9 100644
>> --- a/ovn/northd/ovn-northd.8.xml
>> +++ b/ovn/northd/ovn-northd.8.xml
>> @@ -1598,6 +1598,9 @@ icmp4 {
>>port (ingress table ARP Request will generate an ARP
>>request, if needed, with reg0 as the target protocol
>>address and reg1 as the source protocol address).
>> +  A IP route can be configured that it has multipath to next-hop.
>> +  If a packet has multipath to destination, OVN assign the port
>> +  index into reg[0] to indicate the packet's output port in table 6.
>>  
>>
>>  
>> @@ -1617,6 +1620,28 @@ icmp4 {
>>
>>
>>  
>> +  IPv4/IPV6 multipath routing table. For each route to IPv4/IPv6
>> +  network N with netmask M, on multipath
>> port
>> +  P with IP address A and Ethernet
>> +  address E, a logical flow with match
>> +  ip4.dst ==N/M,whose
>> priority
>> +  is the number of 1-bits plus 10 in M,
>> +  has the following actions:
>> +
>> +
>> +
>> +ip.ttl--;
>> +multipath (nw_dst, 0, modulo_n, n_links, 0, reg0);
>> +reg9[2] = 1
>> +next;
>> +
>> +
>> +  n_links is the number of multipath port.
>> +
>> +  
>> +
>> +  
>> +
>>IPv4 routing table.  For each route to IPv4 network
>> N with
>>netmask M, on router port P with IP
>> address
>>A and Ethernet
>> @@ -1686,7 +1711,43 @@ next;
>>
>>  
>>
>> -Ingress Table 6: ARP/ND Resolution
>> +Ingress Table 6: Multipath
>> +
>> +  Any packet taht reaches this table is an IP packet and reg9[2]=1
>> +  using the following flows to route to corresponding port. This
>> table
>> +  implement dispatching by consuming reg0.
>> +
>> +
>> +
>> +  
>> +
>> +  A packet with netmask M, IP address A and
>> +  reg9[2] = 1, whose priority above 1 has following
>> +  actions:
>> +
>> +
>> +
>> +reg0 = G;
>> +reg1 = A;
>> +eth.src = E;
>>

Re: [ovs-dev] 答复: [PATCH v1 1/3] Add multipath static router in OVN northd and north-db

2017-09-19 Thread Gao Zhenyu 
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 to configure multipath
routing. Because I am still considering reusing nexthop or output_port(make
them become array entries), and want to collect suggestions on it.

About the status of next -hop, I would like to introduce bundle_load and
bfd to make it later.

Thanks
Zhenyu Gao

2017-09-20 11:13 GMT+08:00 :

> How to configure multipath_port in static_route? I think the the multipath
> can be figured out from exist data of static_route, may not need to add
> this multipath_port column.
>
> And I think we should add a status column to indicate the nexthop state.
> When some of nexthop in multipath is down, ovn should change the
> correspond flows.
>
> Thanks.
>
>
>
>
>
> Zhenyu Gao 
> 发件人： ovs-dev-boun...@openvswitch.org
> 2017/09/19 19:37
>
> 收件人：b...@ovn.org, majop...@redhat.com,
> anilvenk...@redhat.com, russ...@ovn.org, d...@openvswitch.org,
> 抄送：
> 主题：  [ovs-dev] [PATCH v1 1/3] Add multipath static router in
> OVN northd  and north-db
>
>
> 1. ovn-nb.ovsschema was updated to add new field multipath_port.
> 2. Add multipath feature in ovn-northd part. northd generates multipath
> flows to dispatch traffic by using packet's IP dst address if user set
> Logical_Router_Static_Route's multipath_port with ports.
> 3. Add new table(lr_in_multipath) in ovn-northd's router ingress stages
> to dispatch traffic to ports.
> 4. Add multipath flow in Table 5(lr_in_ip_routing) and store hash result
> into reg0. reg9[2] was used to indicate packet which need dispatching.
> 5. Add multipath feature description in ovn/northd/ovn-northd.8.xml
> and ovn/ovn-nb.xml
>
> Signed-off-by: Zhenyu Gao 
> ---
>  ovn/northd/ovn-northd.8.xml |  67 +++-
>  ovn/northd/ovn-northd.c | 245
> ++--
>  ovn/ovn-nb.ovsschema|   6 +-
>  ovn/ovn-nb.xml  |   9 ++
>  4 files changed, 289 insertions(+), 38 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index 0d85ec0..b1ce9a9 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -1598,6 +1598,9 @@ icmp4 {
>port (ingress table ARP Request will generate an ARP
>request, if needed, with reg0 as the target protocol
>address and reg1 as the source protocol address).
> +  A IP route can be configured that it has multipath to next-hop.
> +  If a packet has multipath to destination, OVN assign the port
> +  index into reg[0] to indicate the packet's output port in table 6.
>  
>
>  
> @@ -1617,6 +1620,28 @@ icmp4 {
>
>
>  
> +  IPv4/IPV6 multipath routing table. For each route to IPv4/IPv6
> +  network N with netmask M, on multipath
> port
> +  P with IP address A and Ethernet
> +  address E, a logical flow with match
> +  ip4.dst ==N/M,whose priority
> +  is the number of 1-bits plus 10 in M,
> +  has the following actions:
> +
> +
> +
> +ip.ttl--;
> +multipath (nw_dst, 0, modulo_n, n_links, 0, reg0);
> +reg9[2] = 1
> +next;
> +
> +
> +  n_links is the number of multipath port.
> +
> +  
> +
> +  
> +
>IPv4 routing table.  For each route to IPv4 network
> N with
>netmask M, on router port P with IP
> address
>A and Ethernet
> @@ -1686,7 +1711,43 @@ next;
>
>  
>
> -Ingress Table 6: ARP/ND Resolution
> +Ingress Table 6: Multipath
> +
> +  Any packet taht reaches this table is an IP packet and reg9[2]=1
> +  using the following flows to route to corresponding port. This
> table
> +  implement dispatching by consuming reg0.
> +
> +
> +
> +  
> +
> +  A packet with netmask M, IP address A and
> +  reg9[2] = 1, whose priority above 1 has following
> +  actions:
> +
> +
> +
> +reg0 = G;
> +reg1 = A;
> +eth.src = E;
> +outport = P;
> +flags.loopback = 1;
> +next;
> +
> +
> +
> +  G is the gateway IP address. A,
> E
> +  and P are the values that were described in
> multipath
> +  routeing in table 5
> +
> +
> +
> +  A priority-0 logical flow with match has actions
> next;.
> +
> +  
> +
> +
> +Ingress Table 7: ARP/ND Resolution
>
>  
>Any packet that reaches this table is an IP packet whose next-hop
> @@ -1779,7 +1840,7 @@ next;
>
>  
>
> -Ingress Table 7: Gateway Redirect
> +Ingress Table 8: Gateway Redirect
>
>  
>For distributed