[ovs-discuss] [OVN]: IP address representing external destinations

[Han Zhou]

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:
<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 <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
>> 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
>> >
>> > 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
> <https://www.redhat.com/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20200916/f202c7a0/attachment.html>