multipath option could not identified after install this iproute-extension #5
Comments
|
Hi @MagicC1, Could you check if you are using the newly installed You can compare with the binary in the source dir, something like: |
|
Closing due to inactivity. |
|
I fall into the same problem but I'm able to fix it by using latest sources from git. One more possibility is that you might have installed it in the different location than the actual binary place. And you need to look at the installation path for the newly built IP package. As you see following my actual ip package is not replaced but remaining locations are modified, to use it, I have to use full path or replace /bin/ip with /sbin/ip. root@mptcp:/usr/local/src/iproute-mptcp# /sbin/ip link help TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | macvtap | root@mptcp:/usr/local/src/iproute-mptcp# TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | can | bridge } |
cpaasch
pushed a commit
that referenced
this issue
Mar 9, 2018
As Stephen Hemminger mentioned on the last submission the new_json_obj function is always called with fp == stdout, so right now, there's no need of this extra argument. The background for the rework is the following: The ip monitor didn't call `new_json_obj` (even for in non json context), so the static FILE* _fp variable wasn't initialized, thus raising a SIGSEGV in ipaddress.c. This patch should fix this issue for good, new paths won't have to call `new_json_obj`. How to reproduce: $ ip -t mon label link (gdb) bt .#0 _IO_vfprintf_internal (s=s@entry=0x0, format=format@entry=0x45460d “%d: “, ap=ap@entry=0x7fffffff7f18) at vfprintf.c:1278 .#1 0x0000000000451310 in color_fprintf (fp=0x0, attr=<optimized out>, fmt=0x45460d “%d: “) at color.c:108 .#2 0x000000000044a856 in print_color_int (t=t@entry=PRINT_ANY, color=color@entry=4294967295, key=key@entry=0x4545fc “ifindex”, fmt=fmt@entry=0x45460d “%d: “, value=<optimized out>) at ip_print.c:132 .#3 0x000000000040ccd2 in print_int (value=<optimized out>, fmt=0x45460d “%d: “, key=0x4545fc “ifindex”, t=PRINT_ANY) at ip_common.h:189 .#4 print_linkinfo (who=<optimized out>, n=0x7fffffffa380, arg=0x7ffff77a82a0 <_IO_2_1_stdout_>) at ipaddress.c:1107 .#5 0x0000000000422e13 in accept_msg (who=0x7fffffff8320, ctrl=0x7fffffff8310, n=0x7fffffffa380, arg=0x7ffff77a82a0 <_IO_2_1_stdout_>) at ipmonitor.c:89 .#6 0x000000000044c58f in rtnl_listen (rtnl=0x672160 <rth>, handler=handler@entry=0x422c70 <accept_msg>, jarg=0x7ffff77a82a0 <_IO_2_1_stdout_>) at libnetlink.c:761 .#7 0x00000000004233db in do_ipmonitor (argc=<optimized out>, argv=0x7fffffffe5a0) at ipmonitor.c:310 .#8 0x0000000000408f74 in do_cmd (argv0=0x7fffffffe7f5 “mon”, argc=3, argv=0x7fffffffe588) at ip.c:116 .#9 0x0000000000408a94 in main (argc=4, argv=0x7fffffffe580) at ip.c:311 Fixes: 6377572 ("ip: ip_print: add new API to print JSON or regular format output") Reported-by: David Ahern <dsa@cumulusnetworks.com> Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
cpaasch
pushed a commit
that referenced
this issue
Mar 9, 2018
As Stephen Hemminger mentioned on the last submission the new_json_obj function is always called with fp == stdout, so right now, there's no need of this extra argument. The background for the rework is the following: The ip monitor didn't call `new_json_obj` (even for in non json context), so the static FILE* _fp variable wasn't initialized, thus raising a SIGSEGV in ipaddress.c. This patch should fix this issue for good, new paths won't have to call `new_json_obj`. How to reproduce: $ ip -t mon label link (gdb) bt .#0 _IO_vfprintf_internal (s=s@entry=0x0, format=format@entry=0x45460d “%d: “, ap=ap@entry=0x7fffffff7f18) at vfprintf.c:1278 .#1 0x0000000000451310 in color_fprintf (fp=0x0, attr=<optimized out>, fmt=0x45460d “%d: “) at color.c:108 .#2 0x000000000044a856 in print_color_int (t=t@entry=PRINT_ANY, color=color@entry=4294967295, key=key@entry=0x4545fc “ifindex”, fmt=fmt@entry=0x45460d “%d: “, value=<optimized out>) at ip_print.c:132 .#3 0x000000000040ccd2 in print_int (value=<optimized out>, fmt=0x45460d “%d: “, key=0x4545fc “ifindex”, t=PRINT_ANY) at ip_common.h:189 .#4 print_linkinfo (who=<optimized out>, n=0x7fffffffa380, arg=0x7ffff77a82a0 <_IO_2_1_stdout_>) at ipaddress.c:1107 .#5 0x0000000000422e13 in accept_msg (who=0x7fffffff8320, ctrl=0x7fffffff8310, n=0x7fffffffa380, arg=0x7ffff77a82a0 <_IO_2_1_stdout_>) at ipmonitor.c:89 .#6 0x000000000044c58f in rtnl_listen (rtnl=0x672160 <rth>, handler=handler@entry=0x422c70 <accept_msg>, jarg=0x7ffff77a82a0 <_IO_2_1_stdout_>) at libnetlink.c:761 .#7 0x00000000004233db in do_ipmonitor (argc=<optimized out>, argv=0x7fffffffe5a0) at ipmonitor.c:310 .#8 0x0000000000408f74 in do_cmd (argv0=0x7fffffffe7f5 “mon”, argc=3, argv=0x7fffffffe588) at ip.c:116 .#9 0x0000000000408a94 in main (argc=4, argv=0x7fffffffe580) at ip.c:311 Fixes: 6377572 ("ip: ip_print: add new API to print JSON or regular format output") Reported-by: David Ahern <dsa@cumulusnetworks.com> Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
matttbe
pushed a commit
that referenced
this issue
Nov 23, 2021
Petr Machata says: ================== The DCB tool will have commands that deal with buffer sizes and traffic rates. TC is another tool that has a number of such commands, and functions to support them: get_size(), get_rate/64(), s/print_size() and s/print_rate(). In this patchset, these functions are moved from TC to lib/ for possible reuse and modernized. s/print_rate() has a hidden parameter of a global variable use_iec, which made the conversion non-trivial. The parameter was made explicit, print_rate() converted to a mostly json_print-like function, and sprint_rate() retired in favor of the new print_rate. Patches #1 and #2 deal with this. The intention was to treat s/print_size() similarly, but unfortunately two use cases of sprint_size() cannot be converted to a json_print-like print_size(), and the function sprint_size() had to remain as a discouraged backdoor to print_size(). This is done in patch #3. Patch #4 then improves the code of sprint_size() a little bit. Patch #5 fixes a buglet in formatting small rates in IEC mode. Patches #6 and #7 handle a routine movement of, respectively, get_rate/64() and get_size() from tc to lib. This patchset does not actually add any new uses of these functions. A follow-up patchset will add subtools for management of DCB buffer and DCB maxrate objects that will make use of them. ==================== Signed-off-by: David Ahern <dsahern@gmail.com>
matttbe
pushed a commit
that referenced
this issue
Nov 23, 2021
Petr Machata says: ==================== Add support to the dcb tool for the following three DCB objects: - PFC, for "Priority-based Flow Control", allows configuration of priority lossiness, and related toggles. - DCBNL buffer interfaces are an extension to the 802.1q DCB interfaces and allow configuration of port headroom buffers. - DCBNL maxrate interfaces are an extension to the 802.1q DCB interfaces and allow configuration of rate with which traffic in a given traffic class is sent. Patches #1-#4 fix small issues in the current DCB code and man pages. Patch #5 adds new helpers to the DCB dispatcher. Patches #6 and #7 add support for command line arguments -s and -i. These enable, respectively, display of statistical counters, and ISO/IEC mode of rate units. Patches #8-#10 add the subtools themselves and their man pages. ==================== Signed-off-by: David Ahern <dsahern@gmail.com>
matttbe
pushed a commit
that referenced
this issue
Nov 23, 2021
Petr Machata says: ==================== Add support to the dcb tool for the following two DCB objects: - APP, which allows configuration of traffic prioritization rules based on several possible packet headers. - DCBX, which is a 1-byte bitfield of flags that configure whether the DCBX protocol is implemented in the device or in the host, and which version of the protocol should be used. Patch #1 adds a new helper for finding a name of a given dsfield value. This is useful for APP DSCP-to-priority rules, which can use human-readable DSCP names. Patches #2, #3 and #4 extend existing interfaces for, respectively, parsing of the X:Y mappings, for setting a DCB object, and for getting a DCB object. In patch #5, support for the command line argument -N / --Numeric is added. The APP tool later uses it to decide whether to format DSCP values as human-readable strings or as plain numbers. Patches #6 and #7 add the subtools themselves and their man pages. v2: - Two patches dropped and sent to iproute2 branch as "dcb: Fixes". This patch set now depends on that one. - Patch #5: - Make it -N / --Numeric instead of -n / --no-nice-names - Rename the flag from no_nice_names to numeric as well - Patch #6: - Adjust to s/no_nice_names/numeric/ from another patch. ==================== Signed-off-by: David Ahern <dsahern@kernel.org>
matttbe
pushed a commit
that referenced
this issue
Nov 23, 2021
Petr Machata says: ==================== Support for resilient next-hop groups was recently accepted to Linux kernel[1]. Resilient next-hop groups add a layer of indirection between the SKB hash and the next hop. Thus the hash is used to reference a hash table bucket, which is then used to reference a particular next hop. This allows the system more flexibility when assigning SKB hash space to next hops. Previously, each next hop had to be assigned a continuous range of SKB hash space. With a hash table as an intermediate layer, it is possible to reassign next hops with a hash table bucket granularity. In turn, this mends issues with traffic flow redirection resulting from next hop removal or adjustments in next-hop weights. In this patch set, introduce support for resilient next-hop groups to iproute2. - Patch #1 brings include/uapi/linux/nexthop.h and /rtnetlink.h up to date. - Patches #2 and #3 add new helpers that will be useful later. - Patch #4 extends the ip/nexthop sub-tool to accept group type as a command line argument, and to dispatch based on the specified type. - Patch #5 adds the support for resilient next-hop groups. - Patch #6 adds the support for resilient next-hop group bucket interface. To illustrate the usage, consider the following commands: # ip nexthop add id 1 via 192.0.2.2 dev dummy1 # ip nexthop add id 2 via 192.0.2.3 dev dummy1 # ip nexthop add id 10 group 1/2 type resilient \ buckets 8 idle_timer 60 unbalanced_timer 300 The last command creates a resilient next-hop group. It will have 8 buckets, each bucket will be considered idle when no traffic hits it for at least 60 seconds, and if the table remains out of balance for 300 seconds, it will be forcefully brought into balance. And this is how the next-hop group bucket interface looks: # ip nexthop bucket show id 10 id 10 index 0 idle_time 5.59 nhid 1 id 10 index 1 idle_time 5.59 nhid 1 id 10 index 2 idle_time 8.74 nhid 2 id 10 index 3 idle_time 8.74 nhid 2 id 10 index 4 idle_time 8.74 nhid 1 id 10 index 5 idle_time 8.74 nhid 1 id 10 index 6 idle_time 8.74 nhid 1 id 10 index 7 idle_time 8.74 nhid 1 [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=2a0186a37700b0d5b8cc40be202a62af44f02fa2 ==================== Signed-off-by: David Ahern <dsahern@kernel.org>
arter97
pushed a commit
to arter97/iproute-mptcp
that referenced
this issue
Jan 27, 2023
Petr Machata says:
====================
A new rtnetlink message, RTM_SETSTATS, has been added recently in kernel
commit ca0a53dcec94 ("Merge branch 'net-hw-counters-for-soft-devices'").
At the same time, RTM_GETSTATS has been around for a while. The users of
this API are spread in a couple different places: "ip link xstats" reads
stats from the IFLA_STATS_LINK_XSTATS and _XSTATS_SLAVE subgroups, "ip
link afstats" then reads IFLA_STATS_AF_SPEC.
Finally, to read IFLA_STATS_LINK_OFFLOAD_XSTATS, one would use ifstats.
This does not seem to be a good fit for IFLA_OFFLOAD_XSTATS_HW_S_INFO in
particular.
The obvious place to expose all these offload stats suites would be
under a new link subcommand "ip link offload_xstats", or similar, which
would then have syntax for both showing stats and setting them.
However, this looks like a good opportunity to introduce a new top-level
command, "ip stats", that would be the go-to place to access anything
backed by RTM_GETSTATS and RTM_SETSTATS.
This patchset therefore does the following:
- It adds the new "stats" infrastructure
- It adds specifically the ability to toggle and show the suites that
were recently added to Linux, IFLA_OFFLOAD_XSTATS_HW_S_INFO and
IFLA_OFFLOAD_XSTATS_L3_STATS.
- It adds support to dump IFLA_OFFLOAD_XSTATS_CPU_HIT, which was not
available under "ip" at all.
- Does all this in a way that is easy to extend for new stats suites.
The patchset proceeds as follows:
- Patches multipath-tcp#1 and multipath-tcp#2 lay some groundwork and tweak existing code.
- Patch multipath-tcp#3 adds the shell of the new "ip stats" command.
- Patch multipath-tcp#4 adds "ip stats set" and the ability to toggle l3_stats in
particular.
- Patch multipath-tcp#5 adds "ip stats show", but no actual stats suites.
- Patches multipath-tcp#6-multipath-tcp#9 add support for showing individual stats suites:
respectively, IFLA_STATS_LINK_64, IFLA_OFFLOAD_XSTATS_CPU_HIT,
IFLA_OFFLOAD_XSTATS_HW_S_INFO and IFLA_OFFLOAD_XSTATS_L3_STATS.
- Patch multipath-tcp#10 adds support for monitoring stats events to "ip monitor".
- Patch #11 adds man page verbiage for the above.
The plan is to contribute support for afstats and xstats in a follow-up
patch set.
====================
Signed-off-by: David Ahern <dsahern@kernel.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I was tried to specify an interface as being the backup-interface and try to install iproute-extension by compiling and installing from the git-repository, but it failed to set as the option multipath still not present.
Could anyone help to check whether any step have missed from my side,thanks!
Error information:
ip link set dev eth1 multipath backup
Error: either "dev" is duplicate, or "multipath" is a garbage.
Environment:Linux ubuntu192 4.4.83 #2 x86_64 GNU/Linux
Step:
1 Download
2 make
3 make install
ip link help
Usage: ip link add [link DEV] [ name ] NAME
[ txqueuelen PACKETS ]
[ address LLADDR ]
[ broadcast LLADDR ]
[ mtu MTU ] [index IDX ]
[ numtxqueues QUEUE_COUNT ]
[ numrxqueues QUEUE_COUNT ]
type TYPE [ ARGS ]
TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | macvtap |
bridge | bond | team | ipoib | ip6tnl | ipip | sit | vxlan |
gre | gretap | ip6gre | ip6gretap | vti | nlmon | team_slave |
bond_slave | ipvlan | geneve | bridge_slave | vrf | macsec }
The text was updated successfully, but these errors were encountered: