ip(8) in base

[Mike Karels]

> From: "Rodney W. Grimes" <freebsd-rwg at gndrsh.dnsmgr.net>
> Subject: Re: ip(8) in base
> Date: Sun, 16 Aug 2020 09:38:47 -0700 (PDT)

> > > From: "Alexander V. Chernikov" <melifaro at ipfw.ru>
> > > To: net <net at freebsd.org>, freebsd-hackers <freebsd-hackers at freebsd.org>
> > > Subject: ip(8) in base
> > > Date: Sun, 16 Aug 2020 10:11:11 +0100
> > 
> > > I want to introduce ip(8) or something similar in base.
> > > Basically, I need some userland tool to explicitly operates on nexthops, nexthop groups and fib lookup algorithms.
> > 
> > > The existing tools are not well suited for the job: route(8) may be a candidate, but (a) it would either add another bunch of  options or drastically change the tool by introducing [route nhop add], [route nhgroup add] and (b) listing is traditionally done by netstat(8).
> > 
> > I agree with the others who said not to use ip(8) if the tool is not
> > compatible with the Linux ip.  Also, routing is (at least in theory)
> > independent of address family, and that makes the name "ip" too specific.

> I strongly agree with this.

> > However, I think that route and netstat are sufficiently extensible to
> > add additional facilities, as they have been so far.  One suggestion,
> > though, would be to preserve the general strategy of using "route verb ...",
> > e.g. "route add nhop ..." rather than "route nhop add ...".  These seem
> > sufficiently similar to existing functionality to share a tool.

> Again, I agree with the above statement by Mike.

> The proposed commands are all in support of "route" features,
> and in BSD it is the route command that is used to maniplate
> these, please do not deviate from that.  I have seen no strong
> reason given that route(8) and netstat(1) can not be extended
> to add the desired functionality.

> > Similarly, if possible I would prefer to see --libxo json rather than -j.

> I have no skin in this one, other than to state that iirc the
> route(8) command is currently without any long options so
> adding this --libxo would require adding long option support,
> which is probably not justifiable for 1 option.

I think the reporting ("list") should be in netstat rather than route,
with the possible exception of enhancements to "route get".  Of course,
netstat already uses libxo.

> > > I feel like there is a need of some cli tool that provides the ability to easily extend it by having separate namespaces for each sub-command (hello, ifconfig).
> > 
> > > Naming is hard. I can, for example, use "rt" as a name to address my use cases.
> > > However, given the kernel interfaces for managing nexthops/nexhop groups are the same as with routes/arp/ndp, why not spending some additional time and support operating on routes and neighbors and name it ip?
> > 
> > > Though, that arises multiple questions.
> > > Are we comfortable with ip(8) as a name in general?
> > > If we are, what's our take on having the compatible interface with Linux ip(8)? 
> > 
> > > Any comments/feedback is welcome :-)
> > 
> > 
> > > Appendix 
> > > List of commands I need implemented
> > 
> > > cmd [-46m] nhop create [gw XX] [iface YYY] [mtu YYY] [reject] [proxyfib Y] [fib X][ipv4] [ipv6]
> > > cmd [-46m] nhop delete nhop_id
> > > cmd -46m nhop list 
> > > cmd -j nhop list # json 

> What is special about these nhop routes that this is not just a route add?
> Could that not be handled as either a route flag ala -iface/-static/-reject/-blackhole
> or via a route modifier ala -osi/-xns/-inet/-inet6?

> I am actually a bit confused in that all routes are really just an expression
> of the "next hop" as far as the kernel goes, or are we now doing lsdb type
> routing in the kernel?

> > 
> > > cmd -46m nhgroup create nhops 1,2,3,4,5,6 [fib X]
> > > cmd -46 nhgroup create nhops 1=100,2=100,3=200,4=100 [proxyfib Y][fib X]
> > > cmd -46 nhroup list
>             ^ nhgroup?

> > > cmd -46 nhgroup delete nhgroup_id
> > 
> > > cmd -46 fib algo list
> > > cmd -46 fib algo set algo dpdk_lpm6 fib 0
> > > cmd -46 fib algo set algo auto fib 0
> > 
> > 
> > > /Alexander

> -- 
> Rod Grimes                                                 rgrimes at freebsd.org
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"