These commands were ported forward from these
commits:
f9b6c39 bgpd: Add back old forms of 'show <afi> <safi>' for compatibility
bf1ae6c bgpd: drop machineparse / random "show" improvements
651b402 bgpd: encap show commands
35c3686 bgpd: VPNv6 show commands
135ca15 bgpd: cleanup vty bgp_node_afi/safi utils
This is the first drop of those commits. The files have
changed too much and the diffs to extensive to try to do it
in one piece. Break it up into smaller code chunks.
Original Code:
Signed-off-by: Lou Berger <lberger@labn.net>
Forward Port:
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reverts the --enable-bgp-standalone and makes it so that you
need to use --enable-cumulus to get the cumulus behavior.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The memtypes changes break gcc -O0 build (none of the other optimisation
levels are affected, *any* of -Og, -Os, -O1, etc. make this go away).
Unfortunately, the option supposed to control this doesn't actually work
(-fno-keep-static-const; that not working is the actual gcc bug).
The workaround is to avoid DECLARE_MTYPE statements when their paired
DEFINE_MTYPE isn't linked in. Thankfully, that's only a problem in a
single place in vtysh where bgp_memory.h gets chain-included.
(vtysh.c -> bgp_vty.h -> bgpd.h -> bgp_memory.h)
So, this just breaks the chain at bgp_vty.h.
No other compiler (clang & icc tested) has exhibited this problem.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This is a rather large mechanical commit that splits up the memory types
defined in lib/memtypes.c and distributes them into *_memory.[ch] files
in the individual daemons.
The zebra change is slightly annoying because there is no nice place to
put the #include "zebra_memory.h" statement.
bgpd, ospf6d, isisd and some tests were reusing MTYPEs defined in the
library for its own use. This is bad practice and would break when the
memtype are made static.
Acked-by: Vincent JARDIN <vincent.jardin@6wind.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
[CF: rebased for cmaster-next]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Move over to the new allocation counting added in the previous commit.
(This commit is mostly mechanical.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Acked-by: Vincent JARDIN <vincent.jardin@6wind.com>
The 'struct fifo' and it's accompanying #defines do not
belong in lib/zebra.h. Move them into their own header.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit b0d02889624eaafa0984873dcd78c086418bdf13)
There were several issues here. The zprivs_init is being
called *before* the cli is read in to influence the user
we are running as. This needs to be rectified. Additionally
we need to move the log creation till after cli arguments
are read.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When compiling/running in with --enable-bgp-standalone=yes allow
v4 sessions to be established with no v4 address configured.
Additionally allow v6 connections with no v6 addresses
configured.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Since the default for ipv4 unicast is to now assume
that the neighbor is activated, print out the
no neighbor 192.168.33.44 activate
line when it is explicitly turned off.
Ticket: CM-12809
Reported-by: Lou Berger <lberger@labn.net>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:
When getsockopt(...,SO_BINDTODEVICE,...); fails
assume the bgp instance we are interested is the default
one.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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)
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
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
With the addition of the AFI_ETHER we need
to initialize the appropriate tables for
nexthop's.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There is support to configure graceful restart timer. This is the
time to wait to delete stale routes before a BGP open message is
received.
bgp graceful-restart restart-time <1-3600>
no bgp graceful-restart [<1-255>]
* bgpd/bgp_vty.c
* Define command strings for above CLI
* bgpd/bgpd.c
* bgp_config_write(): Output graceful restart-time configuration
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Tested-by: NetDEF CI System <cisystem@netdef.org>
Use the 'enum nexthop_types_t' instead of
the zebra.h #defines. And remove code from
zebra.h that does not belong there.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@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
(cherry picked from commit 3aef921925)
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
bgp_address_destroy became per-bgp instance. Moved the
call to the bgp_address_destroy function to the bgp delete.
Signed-off-by: Lou Berger <lberger@labn.net>
(cherry picked from commit 637035710a2f8e1e5944ee714135b7f88ac15ac4)
* Solaris doesn't have u_int64_t, so use uint64_t instead. C99-style
fixed-width integers should always be preferred to improve portability;
* 's_addr' is a macro on Solaris, so we can't use it as a variable name.
Rename the 's_addr' variable to 'addr' in the
bgp_peer_conf_if_to_su_update_v4() function.
Signed-off-by: Renato Westphal <renato@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
lib/zebra.h has FILTER_X #define's. These do not belong there.
Put them in lib/filter.h where they belong.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 0490729cc033a3483fc6b0ed45085ee249cac779)
Only Linux has SO_BINDTODEVICE, but that's not a problem since the whole
VRF use case in that instance is currently Linux-specific. Other OS's
VRF implementations will need different code.
Reported-by: Martin Winter <mwinter@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
