On Tue, May 7, 2024 at 11:10 AM Felix Huettner via dev
<ovs-dev@openvswitch.org> wrote:
>
> On Tue, May 07, 2024 at 10:06:07AM -0400, Numan Siddique wrote:
> > On Tue, May 7, 2024 at 5:24 AM Felix Huettner via dev
> > <ovs-dev@openvswitch.org> wrote:
> > >
> > > On Mon, May 06, 2024 at 11:03:42PM -0400, Numan Siddique wrote:
> > > > On Mon, Apr 22, 2024 at 9:02 AM Felix Huettner via dev
> > > > <ovs-dev@openvswitch.org> wrote:
> > > > >
> > > > > In most cases IPv4 packets are routed only over other IPv4 networks
> > > > > and
> > > > > IPv6 packets are routed only over IPv6 networks. However there is no
> > > > > inherent reason for this limitation. Routing IPv4 packets over IPv6
> > > > > networks just requires the router to contain a route for an IPv4
> > > > > network
> > > > > with an IPv6 nexthop.
> > > > >
> > > > > This was previously prevented in OVN in ovn-nbctl and northd. By
> > > > > removing these filters the forwarding will work if the mac addresses
> > > > > are
> > > > > prepopulated.
> > > > >
> > > > > If the mac addresses are not prepopulated we will attempt to resolve
> > > > > them using
> > > > > the original address family of the packet and not the address family
> > > > > of the
> > > > > nexthop. This will fail and we will not forward the packet.
> > > > >
> > > >
> > > > Thanks for adding this feature.
> > > >
> > > > If I understand correctly from the above commit message about
> > > > prepopulation, is it expected that
> > > > CMS/admin needs to add a static mac binding entry in the OVN
> > > > Northbound 'Static_MAC_Binding' table
> > > > for this feature to work ? Please correct me if I'm wrong.
> > > > If this is the case, then it needs to be documented properly (perhaps
> > > > in ovn-nb.xml)
> > >
> > > no the limitation is only that the CMS must not set
> > > dynamic_neigh_routers to true on the Logical_Routers.
> > >
> > > If there are other reasons that cause OVN to send ARP request to lookup
> > > the nexthop of a route then these will have that issue as well. I am
> > > just no aware of any such reason.
> >
> > Thanks. I'm still not clear what happens if OVN doesn't know the
> > nexthop mac address.
> > What happens in that case ? Normally, OVN would generate ARP request
> > for the next hop IP and
> > learn the mac. What happens in the mix route case ?
> >
> > Numan
>
> So lets assume you run an ipv4 prefix and route that over an ipv6 network.
> If you then reach the Logical_Router you will reach the arp action in
> S_ROUTER_IN_ARP_REQUEST (build_arp_request_flows_for_lrouter).
>
> This will be handled by the node executing that action as a
> packet-in to pinctrl_handle_arp which is here actually inappropriate.
> We would need to reach pinctrl_handle_nd_na as we need to send a
> neighbor discovery packet.
>
> It could be changed in northd.c when using an additional register bit
> to store the nexthop address family and then using that bit to figure
> out what address family we need to lookup against, instead of relying on
> the packet address family.
>
> However if we end up in pinctrl_handle_nd_na we seem to reuse the
> existing ipv4 packet and patch the Neighbor Discovery packet over it.
> I thought this causes the lookup then to fail, as the address families
> missmatch.
> However i am no longer sure of that explanation after writing this :)
Let's say we add this static route - "prefix = 172.168.0.0/24,
nexthop = aef0::4"
and lets assume OVN doesn't know the next hop "aef0::4" mac address.
So with your patch, the original packet will be dropped because
pinctrl.c is not handling it properly.
I see 2 approaches here :
1. Fix it in ovn-northd/pinctrl so that for IPv6 next hop, neigh
solicit packet is generated and for IPv4 next hop, ARP request packet
is generated.
2. CMS should add a static mac binding entry in the OVN Northbound db
for the next hop for this scenario to work properly.
Eg. ovn-nbctl static-mac-binding-add lr0-public aef0::5 10:14:00:00:00:05
In this case, ovn-controller(s) will add an openflow like below
---
ovs-ofctl dump-flows br-int table=66
cookie=0xa4249f73, duration=470.024s, table=66, n_packets=0,
n_bytes=0,
priority=50,reg0=0xaef00000,reg1=0,reg2=0,reg3=0x5,reg15=0x3,metadata=0x3
actions=mod_dl_dst:10:14:00:00:00:05,load:0x1->NXM_NX_REG10[6]
----
ovn-northd adds below logical flows in the router ingress pipeline
stage - "lr_in_arp_resolve". These logical flows are hit if OVN can't
resolve the next hop mac address
table=20(lr_in_arp_resolve ), priority=1 , match=(ip4),
action=(get_arp(outport, reg0); next;)
table=20(lr_in_arp_resolve ), priority=1 , match=(ip6),
action=(get_nd(outport, xxreg0); next;)
The OVN actions get_arp and get_nd gets translated to OVS actions -
resubmit(,66).
The problem is that for IPv4 packets, reg0 is used and for IPv6
packetsm xxreg0 is used. But with your patch to support mixed static
routes, it will not work.
For both the approaches (whichever we chose to take), we need to
solve this problem. Maybe we can use a register bit to indicate if
nexhop is IPv4 addr or IPv6 addr
in the "lr_in_ip_routing" stage and depending on that we can have
below logical flows,
table=20(lr_in_arp_resolve ), priority=1 , match=(reg10[1] == 0),
action=(get_arp(outport, reg0); next;)
table=20(lr_in_arp_resolve ), priority=1 , match=(eg10[1] == 1),
action=(get_nd(outport, xxreg0); next;)
I think your next version should address this, otherwise the feature
will be incomplete.
If we go with approach (1), we can indicate pinctrl to generate ARP
or NS depending on a register bit.
Thanks
Numan
>
> Thanks
> Felix
>
> _______________________________________________
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
