When running 'show bgp ipv4 uni summ' (or any variation thereof)
If you have a large # of routes, the json package starts taking
up a tremendous amount of memory and processing power.
Modify the code to output the json as we go instead of gathering
it all up and outputting at the end.
Ticket: CM-13060
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Added the capability of defining an ipv6 static route to null0,
similar to the support previously in ipv4 only.
Ticket: CM-5794
Signed-off-by: Don Slice
Reviewed By: CCR-5223
Testing Done: Manual tested added to the ticket and bgp and ospf smoke
successfully completed
Problem reported that no peers are displayed when the command "show
ip ospf neighbor detail all" is entered. Determined that the problem
was actually that the function only displayed NBMA peers, and since
we rarely (if ever) define NBMA peers, nothing is normally displayed.
Changed the code to display both NBMA and non-NBMA peers, in both the
up and down state. Manual testing attached to the jira ticket.
Ticket: CM-5878
Signed-off-by: Don Slice
Reviewed-by: Daniel Walton
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
NCLU imports quagga-reload.py and uses its Config class to parse
Quagga.conf. The Config class will call 'vtysh -m -f Quagga.conf" and
if that exited with an error Config would call sys.exit(1) which in my
cases causes the NCLU daemon to exit which is bad. The fix is to have
the Config class raise an exception instead of exiting, then NCLU can
catch the exception, log it and move on.
(cherry picked from commit 276887bb1c)
Found several leaks in bgp_show_peer and bgp_show_peer_afi where
json objects are created and then not attached to the parent, causing
them to be leaked. If not attaching them, freeing the created objects.
Manual testing performed successfully. Fix tested succesfully by the
submitter and bgp-smoke completed with same failures as base.
Ticket: CM-12846
Signed-off-by: Don Slice
Reviewed-by: CCR-5181
Entering 'show ip ospf interface json' causes ospf
to crash.
Entering 'show ip ospf interface <intf> json' causes
ospf to crash if intf has no neighbors on the otherside
Modify the code to not crash in these cases.
Ticket: CM-12776
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
A crash occurred if a prefix was defined in a prefix-list that
contained bits in the prefix but a /0 mask. Resolving that crash
and improving usability by applying the mask to the supplied prefix
and notifying the user if the prefix was modified.
Ticket: CM-12744
Signed-off-by: Don Slice
Reviewed_By:
Testing Done: Manual testing attached to the ticket, bgp-min, bgp-smoke
ospf-min, and ospf-smoke all completed before commit
Found that the logic had been changed to determine whether the next-hop
is a v4 or v6 address. This caused an unnumbered interface to be seen
as ipv4 instead of ipv6 so the swp port was not correctly displayed.
Changed it back. Manual testing attaced to the ticket and bgp-min will
be run before committing.
Ticket: CM-12759
Signed-off-by: Don Slice
Reviewed-by: CCR-5166
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-12773
- change "as-ext" to "as-external"
- drop "grp-mbr" option, it does not have a handler
- drop "type7" option, it does not have a handler
(cherry picked from commit 51f2d198c2)
When we have a single-hop BFD session for any peering, it really means
that the peering is directly connected (maybe over a L2 network), whether
it is IBGP or EBGP. In such a case, upon link down, immediately process
IBGP peers too (and bring them down), not just EBGP peers.
This change eliminates some peculiar state transitions in specific IBGP
topologies, thus getting rid of the problem of nexthops remaining inactive
in the zebra RIB.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Ticket: CM-12390
Reviewed By: CCR-5156
Testing Done: Manual, bgp-smoke
In multipath selection, there can be a scenario where the set of route
entries selected as multipath can be the same (i.e., from the same peers)
but one or more of these may have a change to the BGP next hop. In this
case, the route needs to be installed again in zebra even if the best
route entry selected has not changed, otherwise the zebra RIB may have
a different set of next hops (and first hops) than what the routing
protocol selected.
This patch handles this scenario by re-installing the route if any BGP
attribute has changed for any of the multipaths. Not all BGP attributes
are of relevance to the zebra RIB, but this approach follows existing
logic used in the code (e.g., when BGP attributes for the best route
entry has changed).
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Sid Khot <sidkhot@cumulusnetworks.com>
Ticket: CM-12390
Reviewed By: CCR-5135
Testing Done: Manual, bgp-smoke
(cherry picked from commit e10720512e)
After BGP path selection, even if the best route entry selected has not
changed, ensure that the route is installed again in zebra if any non-best
but multipath route entry has a nexthop resolution change.
In the absence of this fix, if a non-best multipath route entry had a
nexthop resolution change (such as being resolved over two first hops instead
of one), the route would get reinstalled into zebra only in some situations
(i.e., when the best route entry had its IGP change flag set). If the route
does not get reinstalled by BGP, the corresponding route in the zebra RIB
would not have all the first hops.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Sid Khot <sidkhot@cumulusnetworks.com>
Ticket: CM-12390
Reviewed By: CCR-5134
Testing Done: Manual, bgp-smoke
(cherry picked from commit 3064bf43a7)
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-12561
(cherry picked from commit 337299a936)
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-12633
(cherry picked from commit 18a4ded2a7)
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-12686
(cherry picked from commit a782e613dd)
The IPv6 RA code also receives ICMPv6 RS and RA messages.
Unfortunately, by bad coding practice, the buffer size specified on
receiving such messages mixed up 2 constants that in fact have different
values.
The code itself has:
#define RTADV_MSG_SIZE 4096
While BUFSIZ is system-dependent, in my case (x86_64 glibc):
/usr/include/_G_config.h:#define _G_BUFSIZ 8192
/usr/include/libio.h:#define _IO_BUFSIZ _G_BUFSIZ
/usr/include/stdio.h:# define BUFSIZ _IO_BUFSIZ
As the latter is passed to the kernel on recvmsg(), it's possible to
overwrite 4kB of stack -- with ICMPv6 packets that can be globally sent
to any of the system's addresses (using fragmentation to get to 8k).
(The socket has filters installed limiting this to RS and RA packets,
but does not have a filter for source address or TTL.)
Issue discovered by trying to test other stuff, which randomly caused
the stack to be smaller than 8kB in that code location, which then
causes the kernel to report EFAULT (Bad address).
Ticket: CM-12687
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
In further testing, found that if there were multiple set commands in
the route-map with one being prefer-global, the removal of the prefer-global
was not recognized and reacted to correctly. This small addition includes
that support
Ticket: CM-11480
Signed-off-by: Don Slice
Reviewed By: Donald Sharp
Testing Done: Manual testing, bgp-min and bgp-smoke completed
Instead of later tripping over an assert, add a proper warning for
interfaces whose MTU is too low.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Code's "is_type" is "circuit-type" in CLI, "circuit_type" is "network"
(type) in CLI, and the function to change is_type is
isis_event_circuit_type_change()... *headdesk*
Reported-by: Martin Winter <mwinter@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
A newly-created circuit will be in enabled state but have neither IPv4
nor IPv6 configured. The logic in isis_circuit_af_set assumed that
"enabled" is equivalent to "ip || ipv6".
This is the only place where this distinction is currently relevant, as
the CLI won't allow enabling an interface without enabling either IPv4
or IPv6; and it will also disable a circuit when both are deconfigured.
Reported-by: Martin Winter <mwinter@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Between the awkwardly managed CSM and the tacked-on IPv6 support, the
simplified logic to setup a circuit wasn't quite right.
Note that the API essentially allows creating a circuit without enabling
either IPv4 or IPv6. This wasn't possible before and probably breaks
isisd in 'interesting' ways. The CLI won't do this, so it's only an
issue when adding on other configuration mechanisms.
Reported-by: Martin Winter <mwinter@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Any interface flags/parameter change (e.g., MTU, PROMISC flag change) is
notified by zebra to clients as an "up" event. BGP literally treats this
as the interface coming up and kicks all neighbors on that interface (i.e.,
directly connected peers). When doing so for IPv4 peers on the interface
(numbered or unnumbered /30-/31) or IPv6 numbered peers, peers that may
already be Established are also flapped; when doing so for IPv6 unnumbered
peers (classic 'neighbor swpX interface' scenario with no configured IP
address on interface), only peers not in Established state are processed.
This patch fixes the code to ensure that in all cases, only non-Established
peers are kicked.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Chris Cormier <chriscormier@cumulusnetworks.com>
Ticket: CM-12526
Reviewed By: CCR-5119
Testing Done: Manual, bgp-min
NS_DEFAULT is #defined to 0, We are passing it
in to a function that is taking 'struct zebra_ns *'
which is translating into a NULL pointer. Which
in some situations will cause a crash.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Daniel Walton <dwalton@cumulusnetworks.com>
Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
(cherry picked from commit 1e9fa2763953adc603c3acc4ed2a46c9e72cbb29)
(cherry picked from commit e33efc8aa8)
Ensure we lookup interface across VRFs, not just in the default VRF.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Ticket: CM-12357
Reviewed By: CCR-5097
Testing Done: Manual, bgp-min
Ticket: CM-11777
Reviewed By: CCR-5096
Testing Done:
The recommended, and in many ways the only supported, model for
the configuration file of quagga is to use a single Quagga.conf
configuration file. However, we weren't shipping with this model,
which led to some confusion amongst users. This patch fixes this
by removing all individual daemon configuration files and replacing
it with the single Quagga.conf file.
Made fix to update the redistribute vrf bitmap when vrf goes down and comes up.
Ticket: CM-11982
Reviewed By: CCR-5032
Testing Done: bgp-min passed, manual
The VTY_GET_INTEGER_RANGE macro is failing on arm
with a warning->error issue where we are passing in
a unsigned MAXINT to this macro and it is complaining
that the comparison of (TMPL) > MAXINT is always going
to be false because of data structure size.
I've changed the tmp variable to a unsigned long long
which alleviates this issue.
Ticket: CM-12187
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
There are cases where customers desire the ability to override the
default behavior of installing ipv6 prefixes with a link-local next-hop
if both a link-local and global ipv6 next-op is present in the bgp table.
This fix provides this ability and will allow the global to be used as the
next-hop. This also retains the ability to manually set the ipv6 next-hop
global value as before, and if so, this manual entry will be used for the
next-hop.
Ticket: CM-11480
Signed-off-by: Don Slice
Reviewed By: CCR-4983
Testing Done: Manual testing results attached to the ticket. bgp-min and
bgp-smoke will be completed before committing.
Dynamically figure out the list of .c files that we need to scan
based upon whether or not the daemon is --enabled via configure.
Ticket: CM-12081
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Quentin Young <qlyoung@cumulusnetworks.com>
The 'show commandtree' command was added to the CONFIG_NODE.
We have a basic assumption that CONFIG_NODE commands actually
change state. 'show commandtree' doesn't meet this requirement.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Expense, Error and Delay metrics never quite made it into the real
world. Either way isisd does nothing useful with them, so let's drop
them from the code. If someone wants to implement them, this patch can
still be reverted.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Last isisd CLI cleanup for now. This also folds L1 & L2 configs into
common functions, reducing CLI function bloat by a bit.
(This patch contains changes authored by both Christian Franke and David
Lamparter.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
