There have been several instances where response from kernel
has overrun the stack buffer from the caller. Avoid future problems
by passing a size argument.
Also drop the unused peer and group arguments to rtnl_talk.
If kernel complains about ip route request, exit status should be
2 not 1.
This fixes regression introduced by:
commit 42ecedd4ba
Author: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Tue Mar 17 19:26:32 2015 -0700
fix ip -force -batch to continue on errors
The kernel now has the capability to offload FDB and FIB entries to hardware.
It is important to let users know if table entries are also offloaded to
hardware. Currently offloaded FDB entries are indicated by the existence of
the flag 'external' on the entry as of the following commit:
commit 28467b7f3f
Author: Scott Feldman <sfeldma@gmail.com>
Date: Thu Dec 4 09:57:15 2014 +0100
bridge/fdb: add flag/indication for FDB entry synced from offload device
When the patch to add support for indicating that FIB entries were also
offloaded as posted to netdev by Scott Feldman it became clear that 'external'
would not be an ideal name for routes. There could definitely be confusion
about what this might mean since many routes are to external networks -- a
collision/confusion that did not happen with FDB.
Scott Feldman asked me to check with others and build concensus around a name.
After speaking with several people about this I am proposing we refer to both
FDB and FIB entries that are currently backed by hardware (based on the work
done in rocker) with the flag 'offload' appended to the end ofthe entry.
Some people liked the string 'external,' others liked 'hardware,' but the point
is to communicate that these routes are available to something that will will
offload the forwarding normally done by the kernel. Since the term 'offload'
is used so frequently it seems appropriate to use the same language in
ip/bridge output.
The term 'offload' also seems to resonate with many of the people who have
responded on Scott's original thread or to those who I reached out to directly
and did respond to my query, so it seems we have reached consensus that it
should be the term used going forward.
v2: rebased against net-next branch
Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
CC: Jamal Hadi Salim <jhs@mojatatu.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: Jiri Pirko <jiri@resnulli.us>
CC: John W. Linville <linville@tuxdriver.com>
CC: Roopa Prabhu <roopa@cumulusnetworks.com>
CC: Scott Feldman <sfeldma@gmail.com>
CC: Stephen Hemminger <stephen@networkplumber.org>
This allows querying and setting the route preference. It's usually set from
the IPv6 Neighbor Discovery Router Advertisement messages.
Introduced in "ipv6: expose RFC4191 route preference via rtnetlink", enqueued
for Linux 4.1.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
- Pull in the uapi mpls.h
- Update rtnetlink.h to include the mpls rtnetlink notification multicast group.
- Define AF_MPLS in utils.h if it is not defined from elsewhere
as is done with AF_DECnet
The address syntax for multiple mpls labels is a complete invention.
When I looked there seemed to be no wide spread convention for talking
about an mpls label stack in text for. Sometimes people did:
"{ Label1, Label2, Label3 }", sometimes people would do:
"[ label3, label2, label1 ]", and most of the time label
stacks were not explicitly shown at all.
The syntax I wound up using, so it would not have spaces and so it
would visually distinct from other kinds of addresses is.
label1/label2/label3 Where label1 is the label at the top of the label
stack and label3 is the label at the bottom on the label stack.
When there is a single label this matches what seems to be convention
with other tools. Just print out the numeric value of the mpls label.
The netlink protocol for labels uses the on the wire format for a
label stack. The ttl and traffic class are expected to be 0. Using
the on the wire format is common and what happens with other address
types. BGP when passing label stacks also uses this technique with the
exception that the ttl byte is not included making each label in a BGP
label stack 3 bytes instead of 4.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
This attribute is like RTA_DST except it specifies the destination
address to place on a packet when it leaves the host. For ip based
protocols this is destination NAT and not a common part of forwarding.
For protocols like MPLS label swapping is something that typically
happens on every hop.
There is likely to be a RTA_NEWSRC at some point so RTA_NEWDST
is printed as "as to" and can be specified either as "as to"
or just "as"
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Add support for the RTA_VIA attribute that specifies an address family
as well as an address for the next hop gateway.
To make it easy to pass this reorder inet_prefix so that it's tail
is a proper RTA_VIA attribute.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
For some address families (like AF_PACKET) it is helpful to have the
length when prenting the address.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
On ip route print dump, label externally offloaded routes with "external".
Offloaded routes are flagged with RTNH_F_EXTERNAL, a recent additon to
net-next. For example:
$ ip route
default via 192.168.0.2 dev eth0
11.0.0.0/30 dev swp1 proto kernel scope link src 11.0.0.2 external
11.0.0.4/30 via 11.0.0.1 dev swp1 proto zebra metric 20 external
11.0.0.8/30 dev swp2 proto kernel scope link src 11.0.0.10 external
11.0.0.12/30 via 11.0.0.9 dev swp2 proto zebra metric 20 external
12.0.0.2 proto zebra metric 30 external
nexthop via 11.0.0.1 dev swp1 weight 1
nexthop via 11.0.0.9 dev swp2 weight 1
12.0.0.3 via 11.0.0.1 dev swp1 proto zebra metric 20 external
12.0.0.4 via 11.0.0.9 dev swp2 proto zebra metric 20 external
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.15
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Reviewed-by: Jiri Pirko <jiri@resnulli.us>
This patch replaces exits with returns in several
iproute2 commands. This fixes `ip -batch -force`
to not exit but continue on errors.
$cat c.txt
route del 1.2.3.0/24 dev eth0
route del 1.2.4.0/24 dev eth0
route del 1.2.5.0/24 dev eth0
route add 1.2.3.0/24 dev eth0
$ip -force -batch c.txt
RTNETLINK answers: No such process
Command failed c.txt:2
RTNETLINK answers: No such process
Command failed c.txt:3
Reported-by: Sven-Haegar Koch <haegar@sdinet.de>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds configuration and dumping of congestion control metric
for ip route, for example:
ip route add <dst> dev foo congctl [lock] dctcp
Reference: http://thread.gmane.org/gmane.linux.network/344733
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
This permits to selectively enable explicit congestion notification via
the routing table.
If this ecn feature is not set, the kernel will use the tcp_ecn sysctl
to decide wheter to use ECN when establising a TCP connection.
At the time of this writing, the kernel supports ecn and allfrags, but
allfrags is of dubious value and not implemented here.
Example:
ip route change 192.168.2.0/24 dev eth0 features ecn
Signed-off-by: Florian Westphal <fw@strlen.de>
In "ip route show" output unicast type, main table, boot protocol and
universe scope are hidden as default labels.
Sometimes it is helpful to show the hidden label for people not enough
familiar with routing subsystem to map the output of "ip route show" and
kernel source code.
With this patch "ip route show" with -d option shows the default labels.
Example of difference of output with -d option:
$ ./ip/ip -4 route show table all dev virbr1
...
192.168.121.0/28 proto kernel scope link src 192.168.121.1
...
$ ./ip/ip -4 -d route show table all dev virbr1
...
unicast 192.168.121.0/28 table main proto kernel scope link src 192.168.121.1
...
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
This patch adds quickack option to enable/disable TCP quick ack
mode for per-route.
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Cong Wang <amwang@redhat.com>
Fixes Debian bug #700434
Need to table id in filter to be unsigned to avoid conversion to -1
The documentation for "ip" suggests that, when using multiple routing tables, the table ID can be an arbitrary 32 bit number. I've been writing a script that calculates a table Id based on an IP addresses and sets up tables accordingly based on it. This seems to work for everything I've tried except "ip route flush". If you specify a table to flush with an ID over 2^31, it flushes all IPv4 routing tables. For example:
Will delete all routing tables, including the default one. Needless to say, this is quite annoying. I think this is an upstream bug, but your opinions will be greatly appreciated.
This patch improves many error messages as follows:
- For incorrect parameters, show the value of the offending parameter, rather than just say that it is incorrect
- Rephrased messages for clarity
- Rephrased to more `mainstream' english
Signed-off-by: Kees van Reeuwijk <reeuwijk@few.vu.nl>
IPv6 multipath routes were not accepted by "ip route" because an IPv4
address was expected for each gateway. Use `get_addr()` instead of
`get_addr32()`.
Signed-off-by: Vincent Bernat <bernat@luffy.cx>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Some time ago the save+restore commands were added to ip route (git
id f4ff11e3, Add ip route save/restore). These two save the raw rtnl
stream into a file and restore one (reading it from stdin).
The problem is that there's no way to get the contents of the dump
file in a human readable form. The proposal is to add a command that
reads the rtnl stream from stdin and prints the data in a way the
usual "ip route list" does?
changes since v1:
* Take the magic at the beginning of the dump file into account
* Check for stdin (the dump is taken from) is not a tty
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In order to somehow verify that a blob contains route dump a
4-bytes magic is put at the head of the data and is checked
on restore.
Magic digits are taken from Portland (OR) coordinates :) Is
there any more reliable way of generating such?
Signed-of-by: Pavel Emelyanov <xemul@parallels.com>
Both rtnl_talk and rtnl_dump had a callback for handling portions
of netlink message that do not match the correct pid or seq.
But this callback was never used by any part of iproute2 so remove
it.
$ ip route help 2>&1 | grep monitor
ip route { add | del | change | append | replace | monitor } ROUTE
$ ip route monitor
Command "monitor" is unknown, try "ip route help".
(I guess what was really intended is "ip monitor route", so just remove
the argument from the help output.)
Originally reported by martin f krafft at http://bugs.debian.org/537681
While at it, also drop all non-existant (route,link,netns) monitor
arguments from the ip(8) man page.
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
The get_jiffies() function retrieves rtt-type values in units of
milliseconds. This patch updates the function name accordingly,
following the pattern given by dst_metric() <=> dst_metric_rtt().
Since July 2008 (2.6.27, c1e20f7c8b9), the kernel stores the values for
RTAX_{RTT{,VAR},RTO_MIN} in milliseconds. When using a kernel > 2.6.27 with
the current iproute2, conversion of these values is broken in either way.
This patch
* updates the code to pass and retrieve milliseconds;
* since values < 1msec would be rounded up, also drops the usec/nsec variants;
* since there is no way to query kernel HZ, also drops the jiffies variant.
Arguments such as
rtt 3.23sec
rto_min 0xff
rto_min 0.200s
rttvar 25ms
now all work as expected when reading back previously set values.
This patch adds save and restore commands to "ip route". Save dumps
the RTNL stream to stdout which can then be passed to restore later.
This may be helpful in some normal situations, and will allow C/R to
migrate the routing information in userspace. Tweaking of the stream
can be done by userspace helpers to convert between versions and adjust
things like device indexes when restoring routes in a different
environment.
By factoring out some of the common bits of print_route() into
filter_nlmsg(), the "save" command can use the same selection logic
as "list," allowing the caller to save only specific routes as
necessary.
The only change since the RFC is the addition of manpage and doc
material.
Signed-off-by: Dan Smith <danms@us.ibm.com>
Adds support for RTA_MARK rt attribute added in linux-2.6.36
$ ip route get ADDR mark 4
192.168.20.110 dev eth1 src 192.168.20.108 mark 4
cache mtu 1500 advmss 1460 hoplimit 64
$ ip route get 192.168.20.108 from ADDR iif STRING mark 256
local 192.168.20.108 from 192.168.20.110 dev lo src 192.168.20.108 mark 0x100
cache <local,src-direct> iif eth1
$ ip route list cache [ADDR] mark NUMBER
Hexadecimal output if mark >= 16
null marks are not displayed.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
iproute_get will return cloned routes for IPv4
and cloned as well non-cloned routes for IPv6.
Therefore RTM_F_CLONED flag should not be checked
for iproute_get routes. Check in print_route will
always fail because valid values are 0 and 1.
Signed-off-by: Ulrich Weber <uweber@astaro.com>
Before IPv6 routing cache entries were always displayed
if additional tables beside MAIN and LOCAL are installed.
Signed-off-by: Ulrich Weber <uweber@astaro.com>
Add initrwnd option parsing to iproute. This option uses the new
rtnetlink init_rcvwnd to set the TCP initial receive window size
advertised by passive and active TCP connections.
Signed-off-by: Laurent Chavey <chavey@google.com>
Currently you can configure "equalize" and it looks all fine and dandy.
The kernel has the interface defined, but apparently there's never actually
been any implementation for it (only a never merged patch in the 2.4 era).
I'm suggesting to drop the code to give any potential users of this feature
the benefit of receiving a proper error message. I see it unlikely that
this will be implemented in the near future, but if it ever happens
reviving the iproute2 side should be as easy as git revert this patch.
For more details see http://bugs.debian.org/149897
Stephen Hemminger
Thomas Graf
Andy Gospodarek
Lubomir Rintel
Eric W. Biederman
Scott Feldman
Roopa Prabhu
Vadim Kochan
Daniel Borkmann
Florian Westphal
Pavel Simerda
Stephen Hemminger
Masatake YAMATO
Richard Godbee
Adam Borowski
Cong Wang
Kees van Reeuwijk
Vincent Bernat
Pavel Emelyanov
Stephen Hemminger
Jorge Boncompte [DTI2]
Thomas Jarosch
Andreas Henriksson
Stephen Hemminger
Gerrit Renker
Dan Smith
Eric Dumazet
Ulrich Weber
laurent chavey