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

Alexander Constantinescu aconstan at redhat.com
Fri Sep 18 07:57:54 UTC 2020


Hi Han

Sorry for the late reply.

Is this the current situation?
>

Yes, it is.

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?
>

Each <east-west routeX> corresponds to a node in our cluster, like this:

 <east-west route1> ip4.src == <logical switch Y subnet> && ip4.dst ==
<node 1  IPv4>, allow
 <east-west route1> ip6.src == <logical switch Y subnet> && ip6.dst ==
<node 1  IPv6>, allow
 <east-west route1> ip4.src == <logical switch Y subnet> && ip4.dst ==
<node 2  IPv4>, allow
...
 <east-west route1> ip6.src == <logical switch Y subnet> && ip6.dst ==
<node X  IPv6>, allow

so on large clusters (say 1000 nodes) with IPv6 and IPv4 enabled we can
reach ~2000 logical router policies. By having the SOUTH_TO_NORTH_IP we can
completely remove all of them and have the "default route" logical router
policy specify:

default route (lowest priority): ip4.src == <logical switch Y subnet>
ip4.dst == SOUTH_TO_NORTH_IP, nexthop = <gateway router for Y>

In addition, if SOUTH_TO_NORTH_IP is a user defined IP,
>

I didn't think it should be user defined, more so "system defined", like
0.0.0.0/0

 I am not sure how would it work,  because ip4.dst is the dst IP from
> packet header
>

I didn't intend for such an IP to be used solely as a destination IP, but
as source too, if the user requires it.

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).
>

Sure, I just wanted to assess the feasibility of such an IP from OVN's
point of view. Obviously the real destination IP would be different, but I
(without knowing the underlying works of OVN) thought there might be a
programmable way of saying: "this IP is unknown to my network topology, so
I could use identifier/alias grouping all such IPs under an umbrella
identifier such as X.X.X.X/X"


On Wed, Sep 16, 2020 at 11:09 PM Han Zhou <hzhou at ovn.org> wrote:

>
>
> 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/>
>>
>

-- 

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/20200918/c62056c7/attachment-0001.html>


More information about the discuss mailing list