On Wed, Sep 16, 2020 at 10:07 AM Alexander Constantinescu < acons...@redhat.com> wrote:
> In this example it is equivalent to just "ip4.src == 10.244.2.5/32"'. >> > > Yes, I was just using it as an example (though, granted, noop example) > > Some background to help steer the discussion: > > Essentially the functionality here is to have south -> north traffic from > certain logical switch ports exit the cluster through a dedicated node (an > egress node if you will). To do this we currently have a set of default > logical router policies, intended to leave east <-> west traffic untouched, > and then logical router policies with a lower priority, which specify > reroute actions for this functionality to happen. However, on large > clusters, there's this concern that the default logical router policies > will become too many. Hence why the idea here would be to drop them > completely and have this "special IP" that we can use to filter on the > destination, south -> north, traffic . > > If you have a default route, anything "unknown" would just hit the default >> route, right? Why would you need another IP for this purpose? >> > > As to remove the default logical router policies, which can become a > lot, on big clusters - as described above. With only reroute policies of > type: "ip4.src == 10.244.2.5/32 && ip4.dst == SOUTH_TO_NORTH_IP" things > would become lighter. > Thanks for the background. So you have: <east-west route1> <east-west route2> ... default route (lowest priority): ip4.src == <logical switch X subnet>, nexthop = <gateway router for X> default route (lowest priority): ip4.src == <logical switch Y subnet>, nexthop = <gateway router for Y> Is this the current situation? When you say there are too many default routes, what do you mean in the above example? How would the SOUTH_TO_NORTH_IP solve the problem? In addition, if SOUTH_TO_NORTH_IP is a user defined IP, I am not sure how would it work, because ip4.dst is the dst IP from packet header. Comparing it with SOUTH_TO_NORTH_IP would just result in mismatch, unless all south-to-north traffic really has this IP as destination (I guess that's not the case). > In policies/ACL you will need to make sure the priorities are set >> properly to achieve the default-route behavior. >> > > Yes, so this is currently done, as described above. > > On Wed, Sep 16, 2020 at 6:35 PM Han Zhou <hz...@ovn.org> wrote: > >> >> >> On Wed, Sep 16, 2020 at 5:42 AM Alexander Constantinescu < >> acons...@redhat.com> wrote: >> > >> > Hi >> > >> > I was wondering if anybody is aware of an IP address signifying >> "external IP destinations"? >> > >> > Currently in OVN we can use the IP address 0.0.0.0/0 for match >> expressions in logical routing policies / ACLs when we want to specify a >> source or destination IP equating to the pseudo term: "all IP >> addresses",ex: 'match="ip4.src == 10.244.2.5/32 && ip4.dst ==0.0.0.0/0"' >> > >> In this example it is equivalent to just "ip4.src == 10.244.2.5/32"'. >> >> > Essentially what I would need to do for an OVN-Kubernetes feature is >> specify such a match condition for south -> north traffic, i.e when the >> destination IP address is external to the cluster, and most likely >> "unknown" to OVN. Thus, when OVN does not know how to route it within the >> OVN network topology and has no choice except sending it out the default >> route. >> > >> > Do we have such an IP address in OVN/OVS? Would it be feasible to >> introduce, in case there is none? >> > >> We don't have such a special IP except 0.0.0.0/0. If you have a default >> route, anything "unknown" would just hit the default route, right? Why >> would you need another IP for this purpose? In logical_router_static_route >> the priority is based on prefix length. In policies/ACL you will need to >> make sure the priorities are set properly to achieve the default-route >> behavior. >> >> Thanks, >> Han >> >> > Thanks in advance! >> > >> > -- >> > >> > Best regards, >> > >> > >> > Alexander Constantinescu >> > >> > Software Engineer, Openshift SDN >> > >> > Red Hat >> > >> > acons...@redhat.com >> > >> > _______________________________________________ >> > discuss mailing list >> > disc...@openvswitch.org >> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> > > > -- > > Best regards, > > > Alexander Constantinescu > > Software Engineer, Openshift SDN > > Red Hat <https://www.redhat.com/> > > acons...@redhat.com > <https://www.redhat.com/> >
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss