This commit removes various parts of the bgpd implementation code which
are unused/useless, e.g. unused functions, unused variable
initializations, unused structs, ...
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The flowspec fragment attribute is taken into account to be pushed in
BGP policy routing entries. Valid values are enumerate list of 1, 2, 4,
or 8 values. no combined value is supported yet.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The rearrangement of where the decision point of
filling in the aggregate information, must have allowed
SA to find a path of code where we may use ifindex uninitialized.
While I don't think this is possible to happen, make this issue
go away.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The aggregate-address command is not creating the null0
route. This got lost somewhere in the last year or so.
Add this ability back for BGP route installs into
zebra.
We need this aggregate route installed into the rib
because we are drawing this traffic to us irrelevant
of the number of routes we do have for that prefix.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Sometimes at startup, BGP Flowspec may be allocated a routing table
identifier not in the range of the predefined table range.
This issue is due to the fact that BGP peering goes up, while the BGP
did not yet retrieve the Table Range allocator.
The fix is done so that BGP PBR entries are not installed while
routing table identifier range is not obtained. Once the routing table
identifier is obtained, parse the FS entries and check that all selected
entries are installed, and if not, install it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
By default, some debug traces were displayed. Those pbr traces are
hidden with 'debug bgp zebra' command.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
policy routing is configurable via address-family ipv4 flowspec
subfamily node. This is then possible to restrict flowspec operation
through the BGP instance, to a single or some interfaces, but not all.
Two commands available:
[no] local-install [IFNAME]
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Once PBR rules installed, an information is printed in the main
show bgp ipv4 flowspec detail information.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Those 3 fields are read and written between zebra and bgpd.
This permits extending the ipset_entry structure.
Combinatories will be possible:
- filtering with one of the src/dst port.
- filtering with one of the range src/ range dst port
usage of src or dst is exclusive in a FS entry.
- filtering a port or a port range based on either src or dst port.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When rule add transaction is sent from bgpd to zebra, the reference
context must not be incremented while the confirmation message of
install has not been sent back; unless if the transaction failed to be
sent.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The debugging message in charge of showing if the route is added or
witdrawn is changed accordingly to reflect this status.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Ensure that the next hop of the leaked VRF is not overwritten when the
route is being imported into the target VRF from the VPN table. Also, in
the case of multipath routes, ensure that the nexthop's ifindex is not
inadvertently reset.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ensure that when EVPN routes are installed into zebra, the router MAC
is passed per next hop and appropriately handled. This is required for
proper multipath operation.
Ticket: CM-18999
Reviewed By:
Testing Done: Verified failed scenario, other manual tests
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
All messages to/from the label manager include two additional
fields: protocol and instance. This patch fixes the parsing
of label chunks response used by BGPd, which did not consider
the two fields.
Signed-off-by: Fredi Raspall <fredi@voltanet.io>
Upon BGP destroy, the hash list related to PBR are removed.
The pbr_match entries, as well as the contained pbr_match_entries
entries.
Then the pbr_action entries. The order is important, since the former
are referencing pbr_action. So the references must be removed, prior to
remove pbr action.
Also, the zebra associated contexts are removed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Upon redirect VRF message from FS, add a default route to the VRF
interface associated to the VRF.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A table chunk of 100000 is allocated from zebra, and when needed in
flowspec, the table identifier is extracted from that chunk.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If a new rule is identified, a new table identifier is created.
In that table, add a default route when possible. If redirect IP rule is
identified, then add a default route to that IP address.
If redirect VRF is identified, nothing is done for now
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
once an iprule has been created, a notification is sent back, and the
context of bgp_action is searched.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The API for filling in an IPTABLE_ADD and IPTABLE_DELETE message.
Also, the API is handling the notification callback, so as to know if
zebra managed to add or delete the relevant iptable entry.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The APIs that handle ipset and iprule contexts from zebra are being
handled in this commit.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There were a couple of instances of code extending
beyond 80 columns, clean it up with clang-format.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Connected routes redistributed into BGP as well as IPv4 routes with IPv6
link-local next hops (RFC 5549) need information about the associated
interface in BGP if they are candidates to be leaked into another VRF. In
the absence of route leaking, this was not necessary. Introduce the
appropriate mechanism and ensure this is used during route install (in
the target VRF).
Ticket: CM-20343, CM-20382
Testing done:
1. Manually verified failed scenarios and some additional ones - logs
in the tickets.
2. Ran bgp-min and evpn-min - results are good.
3. Ran vrf smoke - has some failures, but none which look new
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
When routes are imported into a VRF from the global VPN table, the
parent instance is either the default instance in the case of L3VPN or
the source VRF in the case of VRF-to-VRF route leaking. Hence, obtain
the source peer by just looking at the parent route information.
Ticket: CM-20283
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
When sending a bgp route down to zebra for deletion, the
ZEBRA_FLAG_ALLOW_RECURSION and ZEBRA_FLAG_IBGP flags
are not needed in zebra. So remove the setting
of the api.flags. If we remove this data from being
passed down we no longer need the peer data structure.
Remove the lookup of the peer data structure and the setting
of the flags as that peer was NULL in some evpn symmetric
routing cases for shutdown of bgp.
Ticket: CM-20720
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
