Re: [ovs-dev] [PATCH v2] ovn: Add a case of policy based routing.

[Guru Shetty]

On 2 November 2016 at 09:29, Ben Pfaff  wrote:

> On Wed, Nov 02, 2016 at 09:28:44AM -0700, Ben Pfaff wrote:
> > On Thu, Oct 06, 2016 at 03:53:12AM -0700, Gurucharan Shetty wrote:
> > > OVN currently supports multiple gateway routers (residing on
> > > different chassis) connected to the same logical topology.
> > >
> > > When external traffic enters the logical topology, they can enter
> > > from any gateway routers and reach its eventual destination. This
> > > is achieved with proper static routes configured on the gateway
> > > routers.
> > >
> > > But when traffic is initiated in the logical space by a logical
> > > port, we do not have a good way to distribute that traffic across
> > > multiple gateway routers.
> > >
> > > This commit introduces one particular way to do it. Based on the
> > > source IP address or source IP network of the packet, we can now
> > > jump to a specific gateway router.
> > >
> > > This is very useful for a specific use case of Kubernetes.
> > > When traffic is initiated inside a container heading to outside world,
> > > we want to be able to send such traffic outside the gateway router
> > > residing in the same host as that of the container. Since each
> > > host gets a specific subnet, we can use source IP address based
> > > policy routing to decide on the gateway router.
> > >
> > > Rationale for using the same routing table for both source and
> > > destination IP address based routing:
> > >
> > > Some hardware network vendors support policy routing in a different
> table
> > > on arbitrary "match".  And when a packet enters, if there is a match
> > > in policy based routing table, the default routing table is not
> > > consulted at all.  In case of OVN, we mainly want policy based routing
> > > for north-south traffic. We want east-west traffic to flow as-is.
> Creating
> > > a separate table for policy based routing complicates the configuration
> > > quite a bit. For e.g., if we have a source IP network based rule added,
> > > to decide a particular gateway router as a next hop, we should add
> rules at
> > > a higher priority for all the connected routes to make sure that
> east-west
> > > traffic is not effected in the policy based routing table itself.
> > >
> > > Signed-off-by: Gurucharan Shetty 
> >
> > Thank you!
> >
> > Acked-by: Ben Pfaff 
>
> Oh, you might also add a NEWS item given that OVN is no longer
> experimental.
>
Thank you for the review. I added it to NEWS and added your suggested diff
and applied.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] ovn: Add a case of policy based routing.

[Ben Pfaff]

On Wed, Nov 02, 2016 at 09:28:44AM -0700, Ben Pfaff wrote:
> On Thu, Oct 06, 2016 at 03:53:12AM -0700, Gurucharan Shetty wrote:
> > OVN currently supports multiple gateway routers (residing on
> > different chassis) connected to the same logical topology.
> > 
> > When external traffic enters the logical topology, they can enter
> > from any gateway routers and reach its eventual destination. This
> > is achieved with proper static routes configured on the gateway
> > routers.
> > 
> > But when traffic is initiated in the logical space by a logical
> > port, we do not have a good way to distribute that traffic across
> > multiple gateway routers.
> > 
> > This commit introduces one particular way to do it. Based on the
> > source IP address or source IP network of the packet, we can now
> > jump to a specific gateway router.
> > 
> > This is very useful for a specific use case of Kubernetes.
> > When traffic is initiated inside a container heading to outside world,
> > we want to be able to send such traffic outside the gateway router
> > residing in the same host as that of the container. Since each
> > host gets a specific subnet, we can use source IP address based
> > policy routing to decide on the gateway router.
> > 
> > Rationale for using the same routing table for both source and
> > destination IP address based routing:
> > 
> > Some hardware network vendors support policy routing in a different table
> > on arbitrary "match".  And when a packet enters, if there is a match
> > in policy based routing table, the default routing table is not
> > consulted at all.  In case of OVN, we mainly want policy based routing
> > for north-south traffic. We want east-west traffic to flow as-is. Creating
> > a separate table for policy based routing complicates the configuration
> > quite a bit. For e.g., if we have a source IP network based rule added,
> > to decide a particular gateway router as a next hop, we should add rules at
> > a higher priority for all the connected routes to make sure that east-west
> > traffic is not effected in the policy based routing table itself.
> > 
> > Signed-off-by: Gurucharan Shetty 
> 
> Thank you!
> 
> Acked-by: Ben Pfaff 

Oh, you might also add a NEWS item given that OVN is no longer
experimental.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] ovn: Add a case of policy based routing.

[Ben Pfaff]

On Thu, Oct 06, 2016 at 03:53:12AM -0700, Gurucharan Shetty wrote:
> OVN currently supports multiple gateway routers (residing on
> different chassis) connected to the same logical topology.
> 
> When external traffic enters the logical topology, they can enter
> from any gateway routers and reach its eventual destination. This
> is achieved with proper static routes configured on the gateway
> routers.
> 
> But when traffic is initiated in the logical space by a logical
> port, we do not have a good way to distribute that traffic across
> multiple gateway routers.
> 
> This commit introduces one particular way to do it. Based on the
> source IP address or source IP network of the packet, we can now
> jump to a specific gateway router.
> 
> This is very useful for a specific use case of Kubernetes.
> When traffic is initiated inside a container heading to outside world,
> we want to be able to send such traffic outside the gateway router
> residing in the same host as that of the container. Since each
> host gets a specific subnet, we can use source IP address based
> policy routing to decide on the gateway router.
> 
> Rationale for using the same routing table for both source and
> destination IP address based routing:
> 
> Some hardware network vendors support policy routing in a different table
> on arbitrary "match".  And when a packet enters, if there is a match
> in policy based routing table, the default routing table is not
> consulted at all.  In case of OVN, we mainly want policy based routing
> for north-south traffic. We want east-west traffic to flow as-is. Creating
> a separate table for policy based routing complicates the configuration
> quite a bit. For e.g., if we have a source IP network based rule added,
> to decide a particular gateway router as a next hop, we should add rules at
> a higher priority for all the connected routes to make sure that east-west
> traffic is not effected in the policy based routing table itself.
> 
> Signed-off-by: Gurucharan Shetty 

Thank you!

Acked-by: Ben Pfaff 

I kind of like this better since it doesn't talk about priorities, which
seem like a lower level concept:

diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
index 3646e55..7626551 100644
--- a/ovn/ovn-nb.xml
+++ b/ovn/ovn-nb.xml
@@ -1083,6 +1083,12 @@
   Each record represents a static route.
 
 
+
+  When multiple routes match a packet, the longest-prefix match is chosen.
+  For a given prefix length, a dst-ip route is preferred over
+  a src-ip route.
+
+
 
   
 IP prefix of this route (e.g. 192.168.100.0/24).
@@ -1098,16 +1104,12 @@
 
   src-ip: This policy sends the packet to the
when the packet's source IP address matches
-  .  If the  has
-  a mask length of n, then this record gets an implicit
-  priority of 2*n.
+  .

 
   dst-ip: This policy sends the packet to the
when the packet's destination IP address
-  matches .  If the 
-  has a mask length of n, then this record gets an
-  implicit priority of 2*n + 1.
+  matches .
 
   
   
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev