| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
|
|
|
|
|
|
|
| |
now that we know what thread we're currently executing, let's add that
information to SEGV / assert backtraces.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the library's thread scheduling functions keep track of the thread
function's name, so far so good. However, copying the compiler-provided
constant into a buffer inside the thread structure is plain useless.
Also, strip_funcname() was trying to support something that never
happens.
Instead, let's use some bytes here to track where threads are scheduled
from. Another commit will print that information on crashes.
Ripping out useless stuff: -64 bytes in the thread structure
Re-add as const ptr: +8 bytes
Extra debug info: +12 bytes
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In _netlink_route_build_multipath():
- Each time when appending a IPv4 gateway in the message, rtnh_len
is increased by sizeof (struct rtattr) + 4, where we should use
"bytelen" instead of the hard coding "4".
- As what done for IPv4, we should increase rtnh_len accordingly
along with adding a IPv6 gateway, or else the IPv6 gateways will
be lost.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a new command "[no] allow-ecmp" to enable/disable the
ECMP feature in RIP. By default, ECMP is not allowed.
Once ECMP is disabled, only one route entry can exist in the list.
* rip_zebra.c: adjust a debugging information, which shows the number
of nexthops according to whether ECMP is enabled.
* ripd.c: rip_ecmp_add() will reject the new route if ECMP is not
allowed and some entry already exists.
A new configurable command "allow-ecmp" is added to control
whether ECMP is allowed.
When ECMP is disabled, rip_ecmp_disable() is called to
remove the multiple nexthops.
* ripd.h: Add a new member "ecmp" to "struct rip", indicating whether
ECMP is allowed or not.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Each node in the routing table is changed into a list, holding
the multiple equal-cost paths.
* If one of the multiple entries gets less-preferred (greater
metric or greater distance), it will be directly deleted instead
of starting a garbage-collection timer for it.
The garbage-collection timer is started only when the last entry
in the list gets INFINITY.
* Some new functions are used to maintain the ECMP list. And hence
rip_rte_process(), rip_redistribute_add() and rip_timeout() are
significantly simplified.
* rip_zebra_ipv4_add() and rip_zebra_ipv4_delete() now can share
the common code. The common part is moved to rip_zebra_ipv4_send().
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|\
| |
| |
| | |
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On OpenBSD, carp interfaces claim to be PtP interfaces with a 0.0.0.0/0
peer address. We process those in zebra and try to send them to
clients, at which point they get encoded as all-0. The client code,
however, decodes that to a NULL pointer instead of 0.0.0.0. This later
turns into a SEGV when CONNECTED_PREFIX sees that ZEBRA_IFA_PEER is set
and tries to access the peer prefix.
This is a band-aid fix for stable/0.99.23, a long-term solution needs
some conceptual improvements on the entire thing.
(The usefulness of a PtP-to-0.0.0.0/0 is a separate question; at this
point dropping the peer prefix seems the least intrusive solution.)
Reported-by: Laurent Lavaud <laurent.lavaud@ladtech.fr>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Whoops, these are in6_addrs, not prefix_ipv6... funnily enough, it does the
right thing either way, if it compiles, which it only does on Linux because
IN6_IS_ADDR_LINKLOCAL contains a cast to the right type. On BSD there is no
such cast, hence it explodes on trying to compile, trying to access struct
members of in6_addrs while operating on prefix_ipv6...
Fixes: 28a8cfc ("isisd: don't require IPv4 for adjacency")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In bgpd/bgp_community_del_val memcpy is used for potentially overlapping
regions which is *not* safe. It may "work" in some cases but is not
guaranteed to work in all cases. The case that I saw fail was on an
x86_64 architecture with the number of bytes being moved/copied equal to
8.
The way the code is written the uint32_t pointers will always differ by
1, which is equivalent to a memcpy/memmove of regions that are 4 bytes
away from one another. So the code failed while copying an 8 byte region
to an address that is 4 bytes lower i.e. overlapping regions.
Interestingly, the same architecture had no problems with a 12 byte
copy.
When the code failed the communities were [200,300,400] and a call was
made to delete the 200 community. The result of this was an array that
looked like [400,400] which was uniquified to [400]. Of course the
expected result should have been [300, 400].
One additional point - in our production environment memmove would not
*link* without including <string.h> but in an isolated quagga git repo
this #include does not seem to be required and I see memmove is used in
vtysh.c without this #include either.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The whole IPv6 stack detection could need refactoring. But this
fixes the linux check to not assume glibc. Fixes build against
musl c-library.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
struct msghdr field orders are not strictly specified in POSIX.
Improve portability by using designated initializer. This fixes
build against musl c-library where struct msghdr is POSIX
compliant (Linux kernel and glibc definitions are non-conforming).
As the result is also more readable, struct iovec initilizers
were also converted.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This header is non-standard (though present on many systems) and
there is no standard for what it should or should not define.
Remove it where it is not really needed. But add also a configure
check, so it can be used if available but otherwise fallback to
defining the needed macroes.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This was precluding isisd from IPv6-only operation; no adjacency would
come up unless there was IPv4 in parallel.
Reported-by: Martin Winter <mwinter@netdef.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
f57000c ("bgpd: don't send NOTIFY twice for malformed attrs") introduces
BGP_ATTR_PARSE_ERROR_NOTIFYPLS as additional error code that implies the
caller should sent a NOTIFY and convert it to BGP_ATTR_PARSE_ERROR.
Sadly, the latter was hardcoded in bgp_mp_attr_test.c, which now didn't
consider the new value to be an error.
Make the testcase treat all nonzero values as error without discern.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
RIP_MAX_RTE is defined in ripd.h as 25 but is in fact the
result of a formula. More over it is not used in the code:
the code itself includes the fomula. This makes it un-clear
for maintenance.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|\|
| |
| |
| |
| |
| | |
bgp extcommunity fixes from stable branch
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| | |
Most of the attribute parsing functions were already sending a notify,
let's clean up the code to make it happen only once.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| | |
inet_ntop expects network byte order.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| |
| | |
When bgp_attr_parse returns BGP_ATTR_PARSE_ERROR, it may already have
parsed and allocated some attributes before hitting that error. Free
the attr's data before returning.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The route-map extcommunity set code was incorrectly assuming that it
owns the intern'd struct ecommunity reference. In reality, the intern'd
reference belongs to bgp_update_receive() and we're not supposed to
touch it in the route-map code.
Instead, like all the other set commands, we use a on-heap but
non-intern'd ecommunity to set the new value. This is then either
intern'd in bgp_update_main/_rsclient() through bgp_attr_intern(), or
free'd through bgp_attr_flush().
This fixes Bugzilla #799, which is that bgpd otherwise crashes with a
double free. The ecommunity got unintern'd first in the route-map set
command, then in bgp_update_receive().
Debugged-by: Milan Kocian <milon@wq.cz>
Reported-by: Florian S <florian@herrenlohe.de>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| | |
route_set_ecommunity_rt and _soo share almost all of their code.
Let's remove one of the redundant copies.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
bgp_update_main() wasn't doing anything to release attribute values
set from route maps for two of its error paths. To fix, pull up the
appropriate cleanup from further down and apply it here.
bgp_update_rsclient() doesn't have the issue since it immediately
does bgp_attr_intern() on the results from bgp_{export,import}_modifier.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|\ \
| |/
|/|
| |
| |
| | |
route-map tidying + next-hop-self all
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
| |
| |
| | |
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As specified in:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html#wp4972925610
This allows overriding next-hop for ibgp learned routes on an
RR for reflected routes.
Especially useful for using iBGP in DMVPN setups. See:
http://blog.ipspace.net/2014/04/changes-in-ibgp-next-hop-processing.html
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
|
|/
|
|
| |
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quagga sources have inherited a slew of Page Feed (^L, \xC) characters
from ancient history. Among other things, these break patchwork's
XML-RPC API because \xC is not a valid character in XML documents.
Nuke them from high orbit.
Patches can be adapted simply by:
sed -e 's%^L%%' -i filename.patch
(you can type page feeds in some environments with Ctrl-V Ctrl-L)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
| |
this is not a full release version, so neither release notes nor
documentation are updated yet. Also, signing the tag with my private
GPG key instead of the Quagga one.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When processing LSPDUs, the unrecognized TLVs/sub-TLVs should be
silently ignored.
In parse_tlvs(), ISIS_WARNING is returned once an unrecognized TLV
exists. It breaks the processing in lsp_authentication_check() and
lsp_update_data(). So remove it.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
| |
The command was mis-named in the documentation as "show ip protocols".
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The interface metric is initialized to 0 in the commit db19c85:
zebra: set metric for directly connected routes via netlink to 0
Ripd and ripngd must be aware of it and avoid increase the
route metric by 0.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
| |
POSIX defines <fcntl.h>, <sys/fcntl.h> is the same thing. However,
it should not be used as it's existence can depend on C-library
implementation. E.g. musl gives warning if <sys/fcntl.h> is used.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
| |
When allowas-in is changed on a peer that is not up, BGP would crash
trying to do route_refresh. If peer is not up, there is no need
to do notification or send.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Feng Lu <lu.feng@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ISSUE:
Currently, for non-ipv4-unicast address families where prefixes are
encoded in MP_REACH/MP_UNREACH attributes, BGP ends up sending one
prefix per UPDATE message. This is quite inefficient. The patch
addresses the issue.
PATCH:
We introduce a scratch buffer in the peer structure that stores the
MP_REACH/MP_UNREACH attributes for non-ipv4-unicast families. This
enables us to encode multiple prefixes. In the end, the two buffers
are merged to create the UPDATE packet.
Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
[DL: removed no longer existing bgp_packet_withdraw prototype]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While announcing a path to a peer, the code currently compares the path's
next-hop with the peer's router-id. This can lead to problems as the router
IDs are unique only within an AS. Suppose AS 1 sends route with next-hop
10.1.1.1. It is possible that the speaker has an established BGP peering
with a router in AS 2 with router ID 10.1.1.1. The route will not be
advertised to that peer in AS 2.
The patch removes this check.
Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Shrijeet Mukherjee <shm@cumulusnetworks.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
| |
readline 6.3 removes some old deprecated funnily-named types. This
updates vtysh to use the new types so it builds again.
Reported-by: Joel Teichroeb <klusark@archlinux.invalid>
References: https://bugs.archlinux.org/task/39495
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because of recent changes when creating AF_NETLINK socket, kernel will
cache capabilities of the caller and if file descriptor is used or
otherwise handed to another process it will check that current user has
necessary capabilities to use the socket. Hence we need to ensure we
have necessary capabilities when creating the socket and at the time we
use the socket.
See: http://www.spinics.net/lists/netdev/msg280198.html
Signed-off-by: Michal Sekletar <msekleta@redhat.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Currently when you set neighbour's 'allowas-in' option on route server side
you get redistribution of the prefixes from this neighbour's table into all
neighbour's tables which have the same AS number. I think that wanted behaviour
is to allow import prefixes from neighbour's tables with the same AS num
into neighbour which has 'allowas-in' option set.
Signed-off-by: Milan Kocian <milon@wq.cz>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Traditionally, ttl-security feature has been associated with EBGP
sessions as those identify directly connected external peers. The
GTSM RFC (rfc 5082) does not make any restrictions on type of
peering. In fact, it is beneficial to support ttl-security for both
EBGP and IBGP sessions. Specifically, in data centers, there are
directly connected IBGP peerings that will benefit from the protection
ttl-security provides.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
[DL: function refactoring split out into previous 2 patches. changes:
- bgp_set_socket_ttl(): ret type int -> void
- is_ebgp_multihop_configured(): stripped peer == NULL check
- comments/whitespace]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
| |
The check for an eBGP multihop configuration is unwieldy; factor it out
into a separate function.
[DL: originally by Dinesh G Dutt <ddutt@cumulusnetworks.com>,
split off from the next commit]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
| |
TTL/min TTL are set from both bgp_accept() and bgp_connect(). Factor
them out so the following change to enable iBGP GTSM becomes more
readable.
[DL: originally by Dinesh G Dutt <ddutt@cumulusnetworks.com>,
split off from the next commit]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ISSUES
1. When an interface goes down, the zclient callbacks are invoked
in the following order: (a) address_delete() that removes the
connected address list: ifp->connected, (b) interface_down()
that performs "fast external fallover" operation. The operation
relies on ifp->connected to look for peers that should be brought
down. That's a cyclic dependency.
2. 'ttl-security' configuration handler sets peer->ttl to
MAXTTL (so that BGP packets are sent with TTL=255, as per the
requirement of ttl-security). This, however, is incompatible
with 'fast external fallover' as the fallover operation checks
for (ttl == 1) to determine directly connected peers.
3. The current fallover operation does not work for IPv6 address family.
PATCH
1. The patch removes the dependency on 'ifp->connected' list for fast
fallover. The peer already contains a nexthop structure that reflects
the peering address. The nexthop structure has a pointer to the
interface (ifp) that peering address resolves to. Everytime the TCP
connection succeeds, the ifp is updated. The patch uses this ifp in
the interface_down() callback for a match for the peers that should be
brought down.
2. The evaluation for directly connected peering is enhanced as
'peer->ttl == 1' OR 'peer->gtsm_hops == 1'. Thus a ttl-security
configuration on the peer with one hop is directly connected and
should be brought down under 'fast external fallover'.
3. Because of fix (1), IPv6 address family works automatically.
Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BGP does not respond fairly in high scale. As the number of BGP peers
and prefixes increase, triggers like interface flaps which lead to BGP
peer flaps, cause blockage in bgp_write.
BGP does handle the cases of TCP socket buffer full by queuing a write
event back, there is no functional issue there as such. Still,
increasing the peer socket buffer size should help reduce event queueing
in BGP.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Reviewed-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
[DL: patch split, this is item 3.]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BGP was setting sockets to be non-blocking only for the accepted passive
peers. As a fix, setting the BGP sockets to be non-blocking even for
the active peers.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Reviewed-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
[DL: patch split, this is item 1.]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue it fixes is that the notification message is not sent to a
second peer when bgp is stopped manually.
According to BGP RFC4271, section 8.2.2, regarding the FSM transitions,
in OpenSent state:
If a ManualStop event (Event 2) is issued in the OpenSent state, the
local system:
* sends the NOTIFICATION with a Cease,
* sets the ConnectRetryTimer to zero,
* releases all BGP resources,
* drops the TCP connection,
* sets the ConnectRetryCounter to zero, and
* changes its state to Idle.
I've added a check for OpenSent state when the notification is sent from
the functions which are called from the CLI commands which
directly/indirectly stop/restart BGP.
Acked-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The output of "show ip bg" does not show whether and which routes are
installed as multipath routes along the best route:
BGP table version is 0, local router ID is 10.10.100.209
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i1.0.0.0/24 10.10.100.1 1 111 0 15169 i
* i 10.10.100.2 1 111 0 15169 i
* i 10.10.100.3 1 111 0 65100 15169 i
This patch adds a new status code that is showing exactly which routes
are used as multipath:
BGP table version is 0, local router ID is 10.10.100.209
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i1.0.0.0/24 10.10.100.1 1 111 0 15169 i
*=i 10.10.100.2 1 111 0 15169 i
* i 10.10.100.3 1 111 0 65100 15169 i
The inconsistency in the status code legend ("i - internal" vs. "i internal")
inherent from old IOS was fixed. It had to be touched anyways.
Signed-off-by: Boian Bonev <bbonev at ipacct.com>
[DL: rewrap long line, clean whitespace in same chunk]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|