[ovs-dev] [PATCH V5 1/1] ovn-northd: Add support forstatic_routes.
Darrell Ball
dlu998 at gmail.com
Tue May 3 20:02:16 UTC 2016
Hi Steve
Your e-mail content was filtered by the mailing list and hence
my response was also filtered.
I added the context below.
Thanks Darrell
On Tue, May 3, 2016 at 3:36 AM, Shi Xin Ruan <Steve.ruan at cn.ibm.com> wrote:
> Hi Darrell,
>
>
> Thanks for the comments.
> Sorry for the latest reply because I had a long vacaction.
>
> All the comments will be fixed as your suggested except
> "I don't think the longest prefix match decision is being tested by the
> below test
> since there is only a single logical router port to choose in each
> direction
>
> lrp1_uuid=`ovn-nbctl -- --id=@lrp create Logical_Router_port name=R1_R2 \
> network="20.0.0.1/24" mac=\"00:00:00:02:03:04\" \
> -- add Logical_Router R1 ports @lrp`"
>
> For a logical router, the subnets of its interfaces will not be overlapped
> with each other.
> Or it should be a configure error.
> This code will be change to find the interface which subnet match nexthop.
>
>
> For normal usage, you would not have overlapping subnets and since it
seems you had no special usage in mind when the original code was written,
it is much better and simpler to just consider it a configuration error. I
saw you fixed the main loop from the original code by adding a break below
and getting rid of code keeping track and updating the longest match.
+ for (i = 0; i < od->nbr->n_ports; i++) {
+
+ struct nbrec_logical_router_port *lrp = od->nbr->ports[i];
+ out_port = ovn_port_find(ports, lrp->name);
+ if (!out_port) {
+ /* This should not happen */
+ continue;
+ }
+
+ if (out_port->network
+ && !((out_port->network ^ next_hop) & out_port->mask)) {
+ /* There should have ONLY 1 interface match the next hop,
+ * or it's a configuration error, because subnets of
router's
+ * interfaces should NOT be overlapped */
+ break;
+ }
The only normal usage I could think of for the original code in the
previous patches is
maybe for reconfiguration transitional cases, but thats beyond the scope of
this kind
of support and will waste CPU cycles ongoing for little to no gain. So
better to avoid it.
More information about the dev
mailing list