On 1 July 2016 at 14:36, Ben Pfaff <b...@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 <g...@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 <b...@ovn.org>
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
