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

Guru Shetty guru at ovn.org
Sat Jul 2 22:45:23 UTC 2016


On 1 July 2016 at 14:36, Ben Pfaff <blp at ovn.org> wrote:

> On Fri, Jul 01, 2016 at 03:23:39AM -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.
> >
> > Signed-off-by: Gurucharan Shetty <guru at ovn.org>
>
> Maybe it is my own naivete, because I have not used policy-based routing
> before, but it is not obvious to me how dst and src routes should
> interact.  Is it normal for a single routing table to contain both dst
> and src routes?  It appears from the implementation that if both are
> present then they are applied using a longest-prefix-match approach
> regardless of the field that matches.  In the OpenFlow implementation, I
> see that the meaning of the routing table is ambiguous when there are
> src and dst routes with the same prefix length.
>

I agree that the above is a problem. We can now have router's connected
(in-built) routes having the same priority as policy based routes causing
problem for east-west traffic. This was not a general problem for
destination ip based routes as you would add routes that are not directly
reachable. I need to re-think this and I will try and come up with
something better.


>
> The two forks here are so similar:
>     char *match;
>     if (policy && !strcmp(policy, "src-ip")) {
>         match = xasprintf("ip4.src == "IP_FMT"/"IP_FMT,
>                           IP_ARGS(network), IP_ARGS(mask));
>     } else {
>         match = xasprintf("ip4.dst == "IP_FMT"/"IP_FMT,
>                           IP_ARGS(network), IP_ARGS(mask));
>     }
> that I'd be inclined to factor it out, e.g.:
>     const char *dir = policy && !strcmp(policy, "src-ip") ? "src" : "dst";
>     char *match = xasprintf("ip4.%s == "IP_FMT"/"IP_FMT,
>                             dir, IP_ARGS(network), IP_ARGS(mask));
>
> I would have expected the new argument to the ovn-nbctl command to be
> optional.
>
> The ovn-nbctl manpage needs an update.
>
> Acked-by: Ben Pfaff <blp at ovn.org>
>



More information about the dev mailing list