[ovs-discuss] [OVN]: IP address representing external destinations
hzhou at ovn.org
Wed Sep 16 21:08:56 UTC 2020
On Wed, Sep 16, 2020 at 10:07 AM Alexander Constantinescu <
aconstan at 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:
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 <hzhou at ovn.org> wrote:
>> On Wed, Sep 16, 2020 at 5:42 AM Alexander Constantinescu <
>> aconstan at 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
>> > 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
>> > Thanks in advance!
>> > --
>> > Best regards,
>> > Alexander Constantinescu
>> > Software Engineer, Openshift SDN
>> > Red Hat
>> > aconstan at redhat.com
>> > _______________________________________________
>> > discuss mailing list
>> > discuss at openvswitch.org
>> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> Best regards,
> Alexander Constantinescu
> Software Engineer, Openshift SDN
> Red Hat <https://www.redhat.com/>
> aconstan at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss