Date: Sun, 16 Aug 2020 13:21:19 -0500 From: Mike Karels <mike@karels.net> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: "Alexander V. Chernikov" <melifaro@ipfw.ru>, net <net@freebsd.org> Subject: Re: ip(8) in base Message-ID: <202008161821.07GILJH3055045@mail.karels.net> In-Reply-To: Your message of Sun, 16 Aug 2020 09:38:47 -0700. <202008161638.07GGclX4056884@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>
> Subject: Re: ip(8) in base
> Date: Sun, 16 Aug 2020 09:38:47 -0700 (PDT)
> > > From: "Alexander V. Chernikov" <melifaro@ipfw.ru>
> > > To: net <net@freebsd.org>, freebsd-hackers <freebsd-hackers@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 nexth=
ops, 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 dras=
tically change the tool by introducing [route nhop add], [route nhgroup ad=
d] 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 specif=
ic.
> 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 see=
m
> > 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 abili=
ty 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 gr=
oups 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 L=
inux 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] [proxy=
fib 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 ad=
d?
> Could that not be handled as either a route flag ala -iface/-static/-rej=
ect/-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 expre=
ssion
> of the "next hop" as far as the kernel goes, or are we now doing lsdb ty=
pe
> routing in the kernel?
> > =
> > > cmd -46m nhgroup create nhops 1,2,3,4,5,6 [fib X]
> > > cmd -46 nhgroup create nhops 1=3D100,2=3D100,3=3D200,4=3D100 [proxyf=
ib 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@freeb=
sd.org
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202008161821.07GILJH3055045>