Add support for CLI "auto" keyword in vrf->vpn export label:
router bgp NNN vrf FOO
address-family ipv4 unicast
label vpn export auto
exit-address-family
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
MPLS label pool backed by allocations from the zebra label manager.
A caller requests a label (e.g., in support of an "auto" label
specification in the CLI) via lp_get(), supplying a unique ID and
a callback function. The callback function is invoked at a later
time with the unique ID and a label value to inform the requestor
of the assigned label.
Requestors may release their labels back to the pool via lp_release().
The label pool is stocked with labels allocated by the zebra label
manager. The interaction with zebra is asynchronous so that bgpd
is not blocked while awaiting a label allocation from zebra.
The label pool implementation allows for bgpd operation before (or
without) zebra, and gracefully handles loss and reconnection of
zebra. Of course, before initial connection with zebra, no labels
are assigned to requestors. If the zebra connection is lost and
regained, callbacks to requestors will invalidate old assignments
and then assign new labels.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Routes that have labels must be sent via a nexthop that also has labels.
This change notes whether any path in a nexthop update from zebra contains
labels. If so, then the nexthop is valid for routes that have labels.
If a nexthop update has no labeled paths, then any labeled routes
referencing the nexthop are marked not valid.
Add a route flag BGP_INFO_ANNC_NH_SELF that means "advertise myself
as nexthop when announcing" so that we can track our notion of the
nexthop without revealing it to peers.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Ensure that only EVPN routes are flagged as such when installing into or
withdrawing from zebra, the earlier check broke L3VPN or VRF route-leaked
routes. Also, fix an incorrect check related to imported routes in path
selection.
Updates: bgpd: Use BGP_ROUTE_IMPORTED for EVPN [vivek]
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
BGP is calculating a v6 routes nexthop as the nexthop address
+ an ifindex. The ifindex calculated comes from where we received
the route from as that we have to do this for LL addresses.
But a v6 address that is not a LL we do not need to provide
to zebra for nexthop resolution because a global address
by default can be looked up and resolved appropriately.
Modify the code so that we must have an ifindex for a v6 nexthop
if the address is LL, else don't pass the ifindex down to zebra.
Fixes: #1986
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In BGP, doing policy-routing requires to use table identifiers.
Flowspec protocol will need to have that. 1 API from bgp zebra has been
done to get the table chunk.
Internally, onec flowspec is enabled, the BGP engine will try to
connect smoothly to the table manager. If zebra is not connected, it
will try to connect 10 seconds later. If zebra is connected, and it is
success, then a polling mechanism each 60 seconds is put in place. All
the internal mechanism has no impact on the BGP process.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The following types are nonstandard:
- u_char
- u_short
- u_int
- u_long
- u_int8_t
- u_int16_t
- u_int32_t
Replace them with the C99 standard types:
- uint8_t
- unsigned short
- unsigned int
- unsigned long
- uint8_t
- uint16_t
- uint32_t
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
When uninstalling routes from zebra, ensure that the BGP instance for
which processing is being done is used to derive the VRF. It is incorrect
to derive the VRF from the peer when dealing with scenarios like VRF route
leaking, EVPN symmetric/external routing etc., where the peer which sourced
the route could belong to a different VRF.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Ticket: CM-18413
Reviewed By: CCR-6778
Testing Done: Manual testing of BGP route withdraw/delete, bgp-min
PR #1739 added code to leak routes between (default VRF) VPN safi and unicast RIBs in any VRF. That set of changes included temporary CLI including vpn-policy blocks to specify RD/RT/label/&c. After considerable discussion, we arrived at a consensus CLI shown below.
The code of this PR implements the vpn-specific parts of this syntax:
router bgp <as> [vrf <FOO>]
address-family <afi> unicast
rd (vpn|evpn) export (AS:NN | IP:nn)
label (vpn|evpn) export (0..1048575)
rt (vpn|evpn) (import|export|both) RTLIST...
nexthop vpn (import|export) (A.B.C.D | X:X::X:X)
route-map (vpn|evpn|vrf NAME) (import|export) MAP
[no] import|export [vpn|evpn|evpn8]
[no] import|export vrf NAME
User documentation of the vpn-specific parts of the above syntax is in PR #1937
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Set EVPN routes imported into a VRF to (sub)type BGP_ROUTE_IMPORTED and
use this for passing appropriate information to zebra. This is needed
because relying on the Router MAC for this purpose was incorrect and
impacted routing to/from external destinations, particularly for IPv6.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Place the nexthop vrf id setting outside the afi if split
so that each side does not need to keep track of this.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
- add "debug bgp vpn label" CLI
- improved debug messages for "debug bgp bestpath"
- send vrf label to zebra after zebra informs bgpd of vrf_id
- withdraw vrf_label from zebra if zebra informs bgpd that vrf_id is disabled
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
The ZEBRA_FLAG_INTERNAL flag is used to signal to zebra that
the route being added, the nexthops for it can be recursively
resolved. This name keeps throwing me off when I read it
so let's rename to something that allows the developer to
understand what is going on.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Asymmetric routing is an ideal choice when all VLANs are cfged on all leafs.
It simplifies the routing configuration and
eliminates potential need for advertising subnet routes.
However, we need to reach the Internet or global destinations
or to do subnet-based routing between PODs or DCs.
This requires EVPN type-5 routes but those routes require L3 VNI configuration.
This task is to support EVPN type-5 routes for prefix-based routing in
conjunction with asymmetric routing within the POD/DC.
It is done by providing an option to use the L3 VNI only for prefix routes,
so that type-2 routes (host routes) will only use the L2 VNI.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
None of these variables can actually be used before being initialized,
but unfortunately some old compilers are not smart enough to detect that.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When an IPv4 or IPv6 unicast route is injected into EVPN as a type-5 route
(upon user configuration), ensure that the source route (best path)'s path
attributes are used to build the EVPN type-5 route. This will result in
correct AS_PATH and ORIGIN attributes for the type-5 route so that it doesn't
appear that all type-5 routes are locally sourced. This is necessary to
ensure that external paths (IPv4 or IPv6 from EBGP peer) are preferred over
internal EVPN paths, if both exist.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-19051
Reviewed By: CCR-7009
Testing Done: Verify failed scenario
In EVPN symmetric routing, not all subnets are presents everywhere.
We have multiple scenarios where a host might not get learned locally.
1. GARP miss
2. SVI down/up
3. Silent host
We need a mechanism to resolve such hosts. In order to achieve this,
we will be advertising a subnet route from a box and that box will help
in resolving the ARP to such hosts.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
When doing symmetric routing,
EVPN type-2 (MACIP) routes need to be advertised with two labels (VNIs)
the first being the L2 VNI (identifying the VLAN) and
the second being the L3 VNI (identifying the VRF).
The receive processing needs to handle one or two labels too.
Ticket: CM-18489
Review: CCR-6949
Testing: manual and bgp/evpn/mpls smoke
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Problem reported that when "systemctl restart networking" was
performed, prefixes previously redistributed into bgp from connected
were deleted from the bgp table. Determined that we were not correctly
changing the redistribution bitmask when the vrf_id of the vrf was
changed. This patch corrects that behavior.
Manual tests look good. bgp-min and vrf-min completed with no new failures.
Ticket: CM-19369
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
For EVPN type-5 route the NH in the NLRI is set to the local tunnel ip.
This information has to be obtained from kernel notification.
We need to pass this info from zebra to bgp in l3vni call flow.
This patch doesn't handle the tunnel-ip change.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Allow the higher level protocol to specify if it would
like to receive notifications about it's routes that
it has installed.
I've purposely made it part of zclient_new_notify because
we need to track the routes on a per daemon basis only.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When BGP is being redistributed prefixes, allow it to
understand the nexthop type.
This fixes the issue where a blackhole route was being interpreted
to having a nexthop of 1.0.0.0( ruh-roh!!! ). This broke
downstream neighbors as that they would receive a 1.0.0.0 nexthop,
which is bad, very very bad.
This commit sets us up for the future where we can match
a route-map against a nexthop type. In that bgp is
now at least nominally paying attention to the type.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When bgp is coming up and is reading a non-integrated config.
The bgp connection to zebra has not fully had a chance to start.
As such when a redistribute line is parsed the attempt is
made to install it but it was erroring out with a warning.
This caused the `redistribute XXX` line to create a error
message to the end user.
Since bgp calls zclient_send_reg_requests which re-registers
the redistribute call once the actual zebra connection is up
and once bgp comes alive this is ok.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In some situations we already know the ifp and by extension
the ifindex there is no need to look it up for every
route we send to zebra.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This improves code readability and also future-proofs our codebase
against new changes in the data structure used to store interfaces.
The FOR_ALL_INTERFACES_ADDRESSES macro was also moved to lib/ but
for now only babeld is using it.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Performance tests showed that, when running on a system with a large
number of interfaces, some daemons would spend a considerable amount
of time in the if_lookup_by_index() function. Introduce a new rb-tree
to solve this problem.
With this change, we need to use the if_set_index() function whenever
we want to change the ifindex of an interface. This is necessary to
ensure that the 'ifaces_by_index' rb-tree is updated accordingly. The
return value of all insert/remove operations in the interface rb-trees
is checked to ensure that an error is logged if a corruption is
detected.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
IFINDEX_DELETED is not necessary anymore as we moved from a global
list of interfaces to a list of interfaces per VRF.
This reverts commit 84361d615.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is an important optimization for users running FRR on systems with
a large number of interfaces (e.g. thousands of tunnels). Red-black
trees scale much better than sorted linked-lists and also store the
elements in an ordered way (contrary to hash tables).
This is a big patch but the interesting bits are all in lib/if.[ch].
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Problem reported with the log displaying error messages if bgpd was
enabled in /etc/frr/daemons but bgp wasn't actually configured. The
problem was due to operating on interfaces before if_create had been
called (which happens at "router bgp" not at frr starting. Moved the
checks for the bgp instance before operating on interfaces. Manual
testing successful and bgp-smoke completed with no new issues.
Ticket: CM-13504
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-6738
list_free is occassionally being used to delete the
list and accidently not deleting all the nodes.
We keep running across this usage pattern. Let's
remove the temptation and only allow list_delete
to handle list deletion.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This is a fallout from PR #1022 (zapi consolidation). In the early days,
the client daemons would allocate enough memory to send all nexthops
to zebra. Then zebra would add all nexthops to the RIB and respect
MULTIPATH_NUM only when installing the routes in the kernel. Now things
are different and the client daemons can send at most MULTIPATH_NUM
nexthops to zebra, and failure to respect that will result in a buffer
overflow. The MULTIPATH_NUM limit in the new zebra API is a small price
we pay to avoid allocating memory for each route sent to zebra.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The previous code assumed that all nexthops of an ECMP route were of
the same address-family. This is not always the case.
Reported-by: Don Slice <dslice@cumulusnetworks.com>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
bgp_attr_deep_dup is based on a misunderstanding of how route-maps work.
They never change actual data, just pointers & fields in "struct attr".
The correct thing to do is copy struct attr and call bgp_attr_flush()
afterwards.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
FLAG_BLACKHOLE is used for different things in different places. remove
it from the zclient API, instead indicate blackholes as proper nexthops
inside the message.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Some differences compared to the old API:
* Now the redistributed routes are sent using address-family
independent messages (ZEBRA_REDISTRIBUTE_ROUTE_ADD and
ZEBRA_REDISTRIBUTE_ROUTE_DEL). This allows us to unify the ipv4/ipv6
zclient callbacks in the client daemons and thus remove a lot of
duplicate code;
* Now zebra sends all nexthops of the redistributed routes to the client
daemons, not only the first one. This shouldn't have any noticeable
performance implications and will allow us to remove an ugly exception
we had for ldpd (which needs to know all nexthops of the redistributed
routes). The other client daemons can simply ignore the nexthops if
they want or consult just the first one (e.g. ospfd/ospf6d/ripd/ripngd).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The code path for a deleted interface was calling
zebra with a IFINDEX_DELETED, which caused zebra
to bitch and moan about the issue. Since the
only thing this function does is call zebra
to deregister the RA stuff, don't set the
ifindex to DELETED till afterwords.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This reverts commit c14777c6bf.
clang 5 is not widely available enough for people to indent with. This
is particularly problematic when rebasing/adjusting branches.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
This allows frr-reload.py (or anything else that scripts via vtysh)
to know if the vtysh command worked or hit an error.
Most of the attributes in 'struct attr_extra' allow for
the more interesting cases of using bgp. The extra
overhead of managing it will induce errors as we add
more attributes and the extra memory overhead is
negligible on anything but full bgp feeds.
Additionally this greatly simplifies the code for
the handling of data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Fix missing label set
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Implement support for sticky (static) MACs. This includes the following:
- Recognize MAC is static (using NUD_NOARP flag) and inform BGP
- Construct MAC mobility extended community for sticky MACs as per
RFC 7432 section 15.2
- Inform to zebra that remote MAC is sticky, where appropriate
- Install sticky MACs into the kernel with the right flag
- Appropriate handling in route selection
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Core EVPN route handling functionality. This includes support for the
following:
- interface with zebra to learn about local VNIs and MACIPs as well as
to install remote VTEPs (per VNI) and remote MACIPs
- create/update/delete EVPN type-2 and type-3 routes
- attribute creation, route selection and install
- route handling per VNI and for the global routing table
- parsing of received EVPN routes and handling by route type
- encoding attributes for EVPN routes and EVPN prefix creation (for
Updates)
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Implement the command 'advertise-all-vni' under the EVPN address-family
in order to allow the local system to learn about local VNIs (and MACs
and Neighbors corresponding to those VNIs) and exchange with other EVPN
speakers.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
The if_update function was taking the interface name as
input and reapplying it, using strncpy to reapply the name.
This has several issues. strncpy should not be used
to copy memory in place. The second issue is that
the interface name is not actually changing when we
update interface to be in the new vrf.
Since every usage of if_update was just reapplying the same
name the interface actually had, just remove that part of
the function and rename it to if_update_to_new_vrf
to represent what it is actually doing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The data for each nexthop is stored off of the info
pointer, instead of handling the first one and then looping
over the remaining, just loop over them all and handle the
first one as a special case.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In the bgp code to send routes to zebra we were spending
a non trivial amount of time managing buffer sizes.
We know a priori the multipath supported by our system
so let's just use that value to appropriately size
the buffers.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
- All ipv4 labeled-unicast routes are now installed in the ipv4 unicast
table. This allows us to do things like take routes from an ipv4
unicast peer, allocate a label for them and TX them to a ipv4
labeled-unicast peer. We can do the opposite where we take routes from
a labeled-unicast peer, remove the label and advertise them to an ipv4
unicast peer.
- Multipath over a labeled route and non-labeled route is not allowed.
- You cannot activate a peer for both 'ipv4 unicast' and 'ipv4
labeled-unicast'
- The 'tag' variable was overloaded for zebra's route tag feature as
well as the mpls label. I added a 'mpls_label_t mpls' variable to
avoid this. This is much cleaner but resulted in touching a lot of
code.
This reverts commit fa14eb2c0b.
This was for stable/2.0 and wasn't intended to go on stable/3.0
-- my bad, missed this in the merge.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Problem reported that ecmp wasn't working correctly in a vrf with
ipv6. Issue was that originator of the routes were sending the updates
with a link-local nexthop and nhlen of 16. In this particular case,
bgp_zebra_announce was using the wrong call to get the ifindex and
was not supplying the vrf. This caused ecmp to work only in the case
of the default vrf.
Ticket: CM-15545
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-6017
The FSF's address changed, and we had a mixture of comment styles for
the GPL file header. (The style with * at the beginning won out with
580 to 141 in existing files.)
Note: I've intentionally left intact other "variations" of the copyright
header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Labeled-unicast updates were being sent with an ipv6 nexthop due to
not setting the mp_nexthop_len or nh_afi. On the receive side, the
prefix length was being incorrectly determined and has been fixed.
Also the stream for bgp_label_buf was not created. All resolved.
Ticket: CM-15260
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by:
Implement support for negotiating IPv4 or IPv6 labeled-unicast address
family, exchanging prefixes and installing them in the routing table, as
well as interactions with Zebra for FEC registration. This is the
implementation of RFC 3107.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
When starting up bgp and zebra now, you can specify
-e <number> or --ecmp <number>
and that number will be used as the maximum ecmp
that can be used.
The <number specified must be >= 1 and <= MULTIPATH_NUM
that Quagga is compiled with.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Since zebra might be sending srcdest routes down to the various daemons,
they need to understand the presence of the field at the very least.
Sadly, that's also the best we can do at this point since none of the
protocols has support for handling srcdest routes. The only consistent
thing to do is to ignore them throughout.
If an administrator wants to have the srcdest route as non-srcdest in a
protocol, setting a non-srcdest static route (possibly blackhole) is
probably the best way to go.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This introduces ZAPI_MESSAGE_SRCPFX, and if set adds a source prefix
field to ZAPI IPv6 route messages sent from daemons to zebra. The
function calls all have a new prefix_ipv6 * argument specifying the
source, or NULL. All daemons currently supply NULL.
Zebra support for processing the field was added in the previous patch,
however, zebra does not do anything useful with the value yet.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Until today the admin distance cannot be configured for any IPv6
routing protocol. This patch implements it for bgp.
Signed-off-by: Maitane Zotes <maz@open.ch>
Signed-off-by: Roman Hoog Antink <rha@open.ch>
This patch improves zebra,ripd,ripngd,ospfd and bgpd so that they can
make use of 32-bit route tags in the case of zebra,ospf,bgp or 16-bit
route-tags in the case of ripd,ripngd.
It is based on the following patch:
commit d25764028829a3a30cdbabe85f32408a63cccadf
Author: Paul Jakma <paul.jakma@hpe.com>
Date: Fri Jul 1 14:23:45 2016 +0100
*: Widen width of Zserv routing tag field.
But also contains the changes which make this actually useful for all
the daemons.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
* zclient.c: prefix length on router-id and interface address add
messages not sanity checked. fix.
* */*_zebra.c: Prefix length on zebra route read was not checked, and
clients use it to write to storage. An evil zebra could overflow
client structures by sending overly long prefixlen.
Prompted by discussions with:
Donald Sharp <sharpd@cumulusnetworks.com>
Since recently zebra uses only the ZEBRA_REDISTRIBUTE_* messages
to advertise redistributed routes to its clientes. Now the old
ZEBRA_IPV*_ROUTE_* messages are only used for client->zebra communication.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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
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)
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
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.
Logic for determining the router-id was spread out over bgp_zebra.c and
bgp_vty.c. Move to bgpd/bgpd.c and have these two call more properly
encapsulated functions.
Significant work by Christian Franke <chris@opensourcerouting.org>.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When the metric for a redistributed route is changed through configuration,
the path attribute for the route/routes need to be "re-created" as the hash
entry would change. In the absence of this, the entry would have the correct
values but when a hash lookup is done at a later time (e.g., when trying to
free the entry), it would fail. This patch addresses the "re-creation"
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-11168
Reviewed By: CCR-4990
Testing Done: Manual, bgp-smoke
Ticket: CM-11256
Signed-off-by: Radhika Mahankali <radhika@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Kanna Rajagopal <kanna@cumulusnetworks.com>
Testing: Unit, PTM smoke, OSPF smoke, BGP Smoke
Issue:
BFD client registrations are not being sent to PTM from BGP/OSPF clients when the quagga clients have no BFD configuration. This can create stale BFD sessions in PTM when BFD is removed from quagga configuration before quagga is restarted.
BFD client de-registrations from BGP/OSPF also go missing sometimes when quagga is restarted. This also will cause stale BFD sessions in PTM.
Root Cause:
BFD client registrations were being sent at the time of BGP/OSPF daemon initialization. But, they were being sent to zebra before the socket connection between zebra and BGP/OSPF was established. This causes the missing BFD client registrations.
BFD client de-registrations are sent from zebra when zebra detects socket close for BGP/OSPF daemons. Based on the timing, the de-registrations may happen after socket between PTM and zebra is closed. This will result in missing de-registrations.
Fix:
Moved sending of BFD client registration messages to zebra connected callback to make sure that they are sent after the BGP/OSPF daemons connect with zebra.
Added BFD client de-registrations for BGP/OSPF to be also sent when zebra daemon gets restart signal. They are sent from the signal handler only if it was not already handled in zebra client socket close callback.
As the comments in if.h, it is better to call ifname2ifindex()
instead of if_nametoindex().
And ifname2ifindex() can work for VRF by appending a parameter
while if_nametoindex() can not.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Vincent JARDIN <vincent.jardin@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 395828eea809e8b2b8c5824d3639cefedd7aa9f0)
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
This change extends the earlier change which added the ability in BGP to
trigger IPv6 Router Advertisements when an unnumbered neighbor is configured.
In addition to triggering the RAs, the advertisement interval is also set to
10 seconds. This is needed to handle the scenario where the peer may start
later.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-10896
Reviewed By: CCR-4693
Testing Done: Manual, bgp-min, bgp-smoke
The call into bgp_zebra_terminate_radv was
setting the peer->ifp to NULL before
calling into bgp_zebra_terminate_radv.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Instead of turning on IPv6 RA on every interface as soon as it has an IPv6
address, only enable it upon configuration of BGP neighbor. When the BGP
neighbor is deleted, signal that RAs can be turned off.
To support this, introduce new message interaction between BGP and Zebra.
Also, take appropriate actions in BGP upon interface add/del since the
unnumbered neighbor could exist prior to interface creation etc.
Only unnumbered IPv6 neighbors require RA, the /30 or /31 based neighbors
don't. However, to keep the interaction simple and not have to deal with
too many dynamic conditions (e.g., address deletes or neighbor change to/from
'v6only'), RAs on the interface are triggered upon any unnumbered neighbor
configuration.
BGP-triggered RAs will cause RAs to be initiated on the interface; however,
if BGP asks that RAs be stopped (upon delete of unnumbered neighbor), RAs
will continue to be exchanged if the operator has explicitly enabled.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-10640
Reviewed By: CCR-4589
Testing Done: Various manual and automated (refer to defect)
Ticket:
Reviewed By:
Testing Done:
For interface-based peering, we don't update the reset reason to be
interface down. Similarly, we don't update the reason to be loss of
neighbor address (maybe due to RA loss). This patch addresses these
limitations.
Protocols receive zclient vrf creation events from zebra.
This data was being handed to the protocol to decode and
then to hand back to zclient to create the vrf to then
handle appropriately. This is a bad idea.
Modify the code such that when zclient.c receives a vrf
event from zebra that it decodes the data and just creates
the vrf. Individual protocols just need to handle the
appropriate vrf events.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
When doing a redistribution re-registration upon route-map
updates, the correct VRF id was not being used. Fixed.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-10311
Reviewed By: Trivial
Testing Done: Manual - verified failed scenario
All daemons changed to flag an interface that has been moved to a vrf as DELETED instead of INTERNAL.
When they were flagged as IFINDEX_INTERNAL, ospf, rip, and isis would re-install them in the default
assuming that they were being "pre-defined" before the kernel definitions.
Ticket: CM-9265
Signed-off-by: Don Slice
Reviewed-by: Donald Sharp
With the vrf startup code put in place we've modified
bgp startup. If we are running inside of the 'make check'
infrastructure zclient is going to be NULL since it is
not initialized yet nor do we really want to connect
to zebra.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When BGP deals with interfaces at a VRF-level, it may get an interface delete
for a VRF which it has just de-registered, so it may not be able to locate
the interface. This is no longer an error, so handle this in the message
processing.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-9462
Reviewed By: None (trivial)
Testing Done: None
Handle VRF change for an interface in BGP (the only VRF client
right now).
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-9527
Reviewed By: CCR-4174
Testing Done: Manual tests of various scenarios
Link BGP instance (Default or VRF) to the corresponding VRF structure and
modify lookup to use this. The logic is very similar to what is implemented
in zebra - the 'struct zebra_vrf' there is essentially 'struct bgp' in BGP.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-9122
Reviewed By: CCR-4102
Testing Done: Manual
Various changes and fixes related to VRF registration, deletion,
BGP exit etc.
- Define instance type
- Ensure proper handling upon instance create, delete and
VRF add/delete from zebra
- Cleanup upon bgp_exit()
- Ensure messages are not sent to zebra for unknown VRFs
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-9128, CM-7203
Reviewed By: CCR-4098
Testing Done: Manual
Clients (BGP, OSPF etc.) register with Zebra for information about
a VRF such as Router ID, interfaces and redistribution. Add API to
support unregister also which is required for the non-default VRF.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-9128
Reviewed By: CCR-4098
Testing Done: Manual testing
During CR for nexthop upstream it was noticed that usage
of prefix2str was not consistent. This fixes this problem
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This patch addresses three main issues:
a. Passing along the global IPv6 nexthop received from the EBGP peer to
IBGP peers but setting the link-local IPv6 nexthop to ourselves when
advertising EBGP-learnt routes to IBGP peers (in the absence of outbound
route-map or other overrides). The fix is to not send a link-local IPv6
nexthop in this case.
b. Passing along the link-local IPv6 nexthop received from one peer to
another peer which is (or may be) on a different subnet. This violates the
semantics of link-local IPv6 address. The fix is to set the nexthop to
ourselves in the situation where the nexthop normally has to be passed
but is a link-local IPv6 address.
c. Different behavior wrt nexthop advertisement for BGP unnumbered peering
if it is setup using link-local IPv6 address versus IPv4 /30 or /31. The
fix is to make the behavior consistent as long as the interface config is
the same in both cases.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Ticket: CM-7846, CM-8043
Reviewed By: CCR-3749
Testing Done: Manual testing, bgpsmoke (on 2.5-br)
Note: Imported from 2.5-br patch bgpd-fix-link-local-nexthop-setting.patch
The API messages are used by zebra to exchange the interfaces, addresses,
routes and router-id information with its clients. To distinguish which
VRF the information belongs to, a new field "VRF ID" is added in the
message header. And hence the message version is increased to 3.
* The new field "VRF ID" in the message header:
Length (2 bytes)
Marker (1 byte)
Version (1 byte)
VRF ID (2 bytes, newly added)
Command (2 bytes)
- Client side:
- zclient_create_header() adds the VRF ID in the message header.
- zclient_read() extracts and validates the VRF ID from the header,
and passes the VRF ID to the callback functions registered to
the API messages.
- All relative functions are appended with a new parameter "vrf_id",
including all the callback functions.
- "vrf_id" is also added to "struct zapi_ipv4" and "struct zapi_ipv6".
Clients need to correctly set the VRF ID when using the API
functions zapi_ipv4_route() and zapi_ipv6_route().
- Till now all messages sent from a client have the default VRF ID
"0" in the header.
- The HELLO message is special, which is used as the heart-beat of
a client, and has no relation with VRF. The VRF ID in the HELLO
message header will always be 0 and ignored by zebra.
- Zebra side:
- zserv_create_header() adds the VRF ID in the message header.
- zebra_client_read() extracts and validates the VRF ID from the
header, and passes the VRF ID to the functions which process
the received messages.
- All relative functions are appended with a new parameter "vrf_id".
* Suppress the messages in a VRF which a client does not care:
Some clients may not care about the information in the VRF X, and
zebra should not send the messages in the VRF X to those clients.
Extra flags are used to indicate which VRF is registered by a client,
and a new message ZEBRA_VRF_UNREGISTER is introduced to let a client
can unregister a VRF when it does not need any information in that
VRF.
A client sends any message other than ZEBRA_VRF_UNREGISTER in a VRF
will automatically register to that VRF.
- lib/vrf:
A new utility "VRF bit-map" is provided to manage the flags for
VRFs, one bit per VRF ID.
- Use vrf_bitmap_init()/vrf_bitmap_free() to initialize/free a
bit-map;
- Use vrf_bitmap_set()/vrf_bitmap_unset() to set/unset a flag
in the given bit-map, corresponding to the given VRF ID;
- Use vrf_bitmap_check() to test whether the flag, in the given
bit-map and for the given VRF ID, is set.
- Client side:
- In "struct zclient", the following flags are changed from
"u_char" to "vrf_bitmap_t":
redist[ZEBRA_ROUTE_MAX]
default_information
These flags are extended for each VRF, and controlled by the
clients themselves (or with the help of zclient_redistribute()
and zclient_redistribute_default()).
- Zebra side:
- In "struct zserv", the following flags are changed from
"u_char" to "vrf_bitmap_t":
redist[ZEBRA_ROUTE_MAX]
redist_default
ifinfo
ridinfo
These flags are extended for each VRF, as the VRF registration
flags. They are maintained on receiving a ZEBRA_XXX_ADD or
ZEBRA_XXX_DELETE message.
When sending an interface/address/route/router-id message in
a VRF to a client, if the corresponding VRF registration flag
is not set, this message will not be dropped by zebra.
- A new function zread_vrf_unregister() is introduced to process
the new command ZEBRA_VRF_UNREGISTER. All the VRF registration
flags are cleared for the requested VRF.
Those clients, who support only the default VRF, will never receive
a message in a non-default VRF, thanks to the filter in zebra.
* New callback for the event of successful connection to zebra:
- zclient_start() is splitted, keeping only the code of connecting
to zebra.
- Now zclient_init()=>zclient_connect()=>zclient_start() operations
are purely dealing with the connection to zbera.
- Once zebra is successfully connected, at the end of zclient_start(),
a new callback is used to inform the client about connection.
- Till now, in the callback of connect-to-zebra event, all clients
send messages to zebra to request the router-id/interface/routes
information in the default VRF.
Of corse in future the client can do anything it wants in this
callback. For example, it may send requests for both default VRF
and some non-default VRFs.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
Conflicts:
lib/zclient.h
lib/zebra.h
zebra/zserv.c
zebra/zserv.h
Conflicts:
bgpd/bgp_nexthop.c
bgpd/bgp_nht.c
bgpd/bgp_zebra.c
isisd/isis_zebra.c
lib/zclient.c
lib/zclient.h
lib/zebra.h
nhrpd/nhrp_interface.c
nhrpd/nhrp_route.c
nhrpd/nhrpd.h
ospf6d/ospf6_zebra.c
ospf6d/ospf6_zebra.h
ospfd/ospf_vty.c
ospfd/ospf_zebra.c
pimd/pim_zebra.c
pimd/pim_zlookup.c
ripd/rip_zebra.c
ripngd/ripng_zebra.c
zebra/redistribute.c
zebra/rt_netlink.c
zebra/zebra_rnh.c
zebra/zebra_rnh.h
zebra/zserv.c
zebra/zserv.h
Later, an interface will belong to a specific VRF, and the interface
initialization will be a part of the VRF initialization. So now call
if_init() from vrf_init(), and if_terminate() from vrf_terminate().
Daemons have the according changes:
- if if_init() was called or "iflist" was initialized, now call
vrf_init() instead;
- if if_terminate() was called or "iflist" was destroyed, now call
vrf_terminate() instead.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Vincent JARDIN <vincent.jardin@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Conflicts:
bgpd/bgp_main.c
pimd/pim_iface.c
pimd/pim_iface.h
pimd/pim_main.c
pimd/pimd.c
When there is a change to a redistributed route, either an attribute
such as the metric or the route type itself has changed, protocol clients
receive an update of the route instead of a delete and add as a result
of an earlier optimization. The update needs to be handled as an implicit
delete for any existing redistributed route, especially to handle change
in route type.
Signed-off-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Ticket: CM-7578
Reviewed By: CCR-3718
Testing Done: Manual verification
Related-to: CM-6768
Ticket: CM-6768
Reviewed By: CCR-3207
Testing Done: bgpsmoke, smoke, topo to create failure
Redistributing routes goes through a del/add cycle whenever a redistributed
is updated. This del/add cycle causes disruption by causing traffic loss
for brief/long periods of time(6-8 s in case of OSPF). The modifications in
this patch remove the del/add cycle to ensure that this disruption doesn't
happen.
Also fixed sending no forwarding address when announcing IPv4 routes with IPv6
nexthops, and sending nexthop only when there is a single path.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
zclient.c depended upon link time inclusion of a
extern struct thread_master *master. This is a violation of the
namespace of the calling daemon. If a library needs the pointer
pass it in and save it for future use.
This code change also makes the zclient code consistent with
the other lib functions that need to schedule work on your behalf
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-7339
Reviewed-by: CCR-3446
Testing: Test Suite passes now
The bgp_redistribute_metric_set function was not
taking into account the table # for deciding
what metric to set.
Ticket: CM-6883
Reviewed By: CCR-3272
Testing Done: Tested on 2.5.3-SE-1
This commit is a port of the patch bgpd-handle-peer-local-address-failure.patch
from 2.5-br.
When a peering is being established, the IPv4 and IPv6 addresses of the
local end of the connection, as applicable, are obtained and stored in
the peer's 'nexthop' structure to facilitate filling of the NEXT_HOP
field in Update messages among other things. The process of obtaining the
local address involves examination of the list of interfaces to identify
a match corresponding to the socket address of the connection.
There are timing conditions, especially when BGPD starts with a config,
where the interface may not have reached BGP from Zebra at the time a
peering reaches the state to determine the local addresses. The code does
not handle this well and the result could be Updates generated with bad
(Martian) NEXT_HOP values. Resolve the issue by bringing down the connection
in this case as not identifying the local addresses is really an error.
Ticket: CM-7177
Reviewed-by: CCR-3396
Testing: See bug
This code change does several small things:
(A) Fix a couple detected memory leaks
(B) Fix all malloc operations to use the correct XMALLOC operation in bgpd and parts of lib
(C) Adds a few new memory types to make it easier to detect issues
Ticket: CM-6789
Reviewed By: CCR-3263
Testing Done: Manual Testing and smoke tests
Whenever some sort of output is encountered, added a json version with
proper logic as well.
