Re: [Questions] Some issues about IPv4/IPv6 nexthop route

[Hangbin Liu <liuhangbin@gmail.com>]

Hi Ido,

I'm back on this question again. Hope you are not too tired on this topic.

Because in you last reply you only answered that we'd better using new nexthop
API (which I'm totally agree) to resolve the consistent of IPv4 and IPv6. New
feature should also go for the new api. But, it always takes a lot years
for the end user using new API (e.g. some users are still using ifcfg).

What I'm asking is how we should deal with the bugs for old API. See my reply
below.

On Thu, Jul 27, 2023 at 05:45:02PM +0300, Ido Schimmel wrote:
> > Since the route are not merged, the nexthop weight is not shown, which
> > make them look like the same for users. For IPv4, the scope is also
> > not shown, which look like the same for users.
> 
> The routes are the same, but separate. They do not form a multipath
> route. Weight is meaningless for a non-multipath route.
> 
> > But there are 2 issues here:
> > 1. the *type* and *protocol* field are actally ignored
> > 2. when do `ip monitor route`, the info dumpped in fib6_add_rt2node()
> >    use the config info from user space. When means `ip monitor` show the
> >    incorrect type and protocol
> > 
> > So my questions are, should we show weight/scope for IPv4?

Here is the first one. As the weight/scope are not shown, the two separate
routes would looks exactly the same for end user, which makes user confused.
So why not just show the weight/scope, or forbid user to add a non-multipath
route with weight/scope?

>> How to deal the type/proto info missing for IPv6?

What we should do for this bug? The type/proto info are ignored when
merge the IPv6 nexthop entries.

Thanks
Hangbin
>> How to deal with the difference of merging policy for IPv4/IPv6?
> 
> In my opinion, if you want consistent behavior between IPv4 and IPv6 for
> multipath routes, then I suggest using the nexthop API. It was merged in
> 5.3 (IIRC) and FRR started using it by default a few years ago. Other
> than a few bugs that were fixed, I don't remember many complaints. Also,
> any nexthop-related features will only be implemented in the nexthop
> API, not in the legacy API. Resilient nexthop groups is one example.