Philippe Guibert [Wed, 14 Mar 2018 09:33:40 +0000 (10:33 +0100)]
bgpd: mp_unreach_nlri fs sent with no nexthop
FS UNREACH message with 0 NLRI inside is sent after each peer
establishment. FS can send NLRI messages with no nexthop.
The commit fixes a message that is triggered by mistake
if FS was about to be sent, then that message is not output.
Also it fixes a typo.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Thu, 15 Mar 2018 12:32:04 +0000 (13:32 +0100)]
bgpd: enhance show bgp ipv4 flowspec <IP>
This command gives detail about a FS entry which contains an IP that
matches one of the rules of the FS entry. The output is the same output
as when one does show bgp ipv4 flowspec detail
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Tue, 20 Feb 2018 09:58:42 +0000 (10:58 +0100)]
bgpd: introduce [no] debug bgp flowspec
It is possible to enhance debug bgp flowspec feature by using vty
command. This command, if enabled, will dump the match/set couple of
information received on NLRI.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Mon, 19 Feb 2018 16:17:41 +0000 (17:17 +0100)]
bgpd: support for show bgp ipv4 flowspec
The show bgp ipv4 flowspec routine is made available, displays the
flowspec rules contained in the BGP FIB database, as well as the actions
to be done on those rules. Two routines are available:
show bgp ipv4 flowspec
show bgp ipv4 flowspec detail
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgpd: use bgp flowspec API to validate and receive NLRI
The changes introduce validation of NLRI FS entries at incoming, before
being pushed in FIB. Note that the so called validation only checks for
validity of the incoming flowspec nlri format, and not the validation as
per RFC5575.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Wed, 14 Feb 2018 10:13:50 +0000 (11:13 +0100)]
bgpd: add flowspec utilities to decode, convert fs nlri
The FS nlri is depicted so as to be able to be in readable format,
either by human, or by some other ( remote daemon ?).
This work is a derived work from [0]. Initially done for validation
only, this work is extended.
The FS NLRI is able to decode addresses, numbers ( protocols, ports,
tcp values) combined ( or not) with operators. This makes possible
to have a NLRI entry for a set of ports, and/or for an other set of
value of port.
This implementation mainly brings the API visible. The API should be
consistent across the various usages.
Flowspec entries do not need aggregation feature.
Actually, all flowspec entries are unique.
So, some check is done against aggregate functionalities in the code.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
jaydom [Mon, 23 Jan 2017 02:45:30 +0000 (10:45 +0800)]
bgpd: add flowspec feature
This work is derived from a work done by China-Telecom.
That initial work can be found in [0].
As the gap between frr and quagga is important, a reworks has been
done in the meantime.
The initial work consists of bringing the following:
- Bringing the client side of flowspec.
- the enhancement of address-family ipv4/ipv6 flowspec
- partial data path handling at reception has been prepared
- the support for ipv4 flowspec or ipv6 flowspec in BGP open messages,
and the internals of BGP has been done.
- the memory contexts necessary for flowspec has been provisioned
In addition to this work, the following has been done:
- the complement of adaptation for FS safi in bgp code
- the code checkstyle has been reworked so as to match frr checkstyle
- the processing of IPv6 FS NLRI is prevented
- the processing of FS NLRI is stopped ( temporary)
Philippe Guibert [Wed, 10 Jan 2018 18:13:27 +0000 (19:13 +0100)]
lib: prefix support for flowspec
prefix structure is used to handle flowspec prefixes. A new AFI is
introduced: AF_FLOWSPEC. A sub structure named flowspec_prefix is
used in prefix to host the flowspec entry.
Reason to introduce that new kind is that prefixlen from prefix
structure is too short to all the flowspec needs, since NLRI can go over
0xff bytes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Chirag Shah [Tue, 27 Mar 2018 22:28:14 +0000 (15:28 -0700)]
ospf6d: fix loop in ABRs
When two routers from same area connected to backbone,
intra route advertised from area x should take precedence
within area x. The same route would be injected as summary
lsa to area 0/y. The same LSA via second abr injected back to
area x and since area 0 is lower than area x its route take
precedence.
Move the area check below path type and cost as both are crucial
to determine best route.
Ticket:CM-19627
Testing Done:
Initial route generated via area 1 as Intra-Prefix LSA (2009).
R1 and R2 both re advertised Inter Area Prefix LSA
(Summary LSA 2003) to area 1.
With the change area 1 Intra route precedence is preserved.
The address of H1 from Right is reachable via ping.
area 1 | area 0
R1
/ \
/ \
/ \
H1 --Left Right
\ /
\ /
\ /
R2
area 1 | area 0
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Donald Sharp [Thu, 29 Mar 2018 15:43:49 +0000 (11:43 -0400)]
bgpd: Only supply ifindex for a v6 nexthop if LL
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>
Donald Sharp [Thu, 29 Mar 2018 12:52:39 +0000 (08:52 -0400)]
zebra: Subtract header length in the right spot
The header length needs to be subtracted from the handling
side of the zapi in zebra. This is because we refigure the
header data structure. The receive side doesn't care
about the total header length so no need to subtract there.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: add API to allocate a range of table identifiers
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>
zebra: add the handling of table ids from remote daemons
This commit is connecting the table manager with remote daemons by
handling the queries.
As the function is similar in many points with label allocator, a
function has been renamed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The range is given from table manager from zebra daemon.
There are 2 ranges available for table identifier:
- [1;252] and [256;0xffffffff]
If the wished size enters in the first range, then the start and end
range of table identifier is given within the first range.
Otherwise, the second range is given, and an appropriate range is given.
Note that for now, the case of the VRF table identifier used is not
taken into account. Meaning that there may be overlapping. There are two
cases to handle:
- case a vrf lite is allocated after the zebra and various other daemons
started.
- case a vrf lite is initialised and the daemons then start
The second case is easy to handle. For the former case, I am not so
sure.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
lib: add framework for allocating routing table identifier IDs
The library changes add 3 new messages to exchange between daemons and
ZEBRA.
- ZEBRA_TABLE_MANAGER_CONNECT,
- ZEBRA_GET_TABLE_CHUNK,
- ZEBRA_RELEASE_TABLE_CHUNK,
the need is that routing tables identifier are shared by various
services. For the current case, policy routing enhancements are planned
to be used in FRR. Poliy routing relies on routing tables identifiers
from kernels. It will be mainly used by the future policy based routing
daemon, but not only. In the flowspec case, the BGP will need also to
inject policy routing information into specific routing tables.
For that, the proposal is made to let zebra give the appropriate range
that is needed for all daemons.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donald Sharp [Wed, 28 Mar 2018 18:52:55 +0000 (14:52 -0400)]
tools: Cleanup shutdown
The shutdown code was sometimes taking 1 minute to run because
the ssd program was misbehaving after a make install.
This commit just removes the usage of ssd for shutdown
since we already have a pid file and we know that the
frr script cleans up the pid file as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Quentin Young [Mon, 19 Mar 2018 16:35:48 +0000 (12:35 -0400)]
tools, doc: update checkpatch for u_int_*
* Checkpatch.pl now checks for nonstandard integral types
* Add shell script to replace all nonstandard types with their standard
counterparts in C source files
* Document usage of types, mention conversion script
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Philippe Guibert [Tue, 23 Jan 2018 17:09:12 +0000 (18:09 +0100)]
bgpd: add an API to get incoming VRF from a RT
This commit is relying on bgp vpn-policy. It is needed to configure
several bgp vrf instances, and in each of the bgp instance, configure
the following command under address-family ipv4 unicast node:
[no] rt redirect import RTLIST
Then, a function is provided, that will parse the BGP instances.
The incoming ecommunity will be compared with the configured rt redirect
import ecommunity list, and return the VRF first instance of the matching
route target.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Quentin Young [Mon, 26 Mar 2018 05:24:41 +0000 (01:24 -0400)]
bgpd: actually suppress coalesce-time
Previous patches to suppress display of automatically calculated
coalesce-time did not fully work because the flag indicating whether the
value was automatically calculated was not set properly upon creation.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Donald Sharp [Sun, 25 Mar 2018 23:35:27 +0000 (19:35 -0400)]
zebra: Set table id *before* we enable the vrf
The table id of the vrf is being given to us as part
of the vrf creation netlink callback. Unfortunately it
was being set in the zvrf *after* the vrf_enable callback.
This didn't used to matter until we started having config data
stored on the side that we needed to act on when the vrf
came up enough to start working.
So when we were storing static routes and installing them
they were being pushed into the default table for non-default
vrf's.
Ticket: CM-19141 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Quentin Young [Fri, 23 Mar 2018 17:20:43 +0000 (13:20 -0400)]
doc: tweak html body width
The default theme has a css rule that limits the body element width to
800px, which results in sizeable chunk of empty space to the right of
the docs. Add a small css override to remove this limit (like the Python
docs do).
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Chirag Shah [Mon, 12 Mar 2018 23:37:06 +0000 (16:37 -0700)]
ospf6d: retain inter area border router type-4
During Intra area border router calculation, all
border routers are marked for remove from brouter table.
Once SPF calculation is done, retain inter area
border router if the adv. intra border router (abr)
is present in SPF table.
Ticket:CM-20171
Testing Done:
Validated inter area ASBR (L1) is retained at
R1 and R2 post intra border router calculation.
L1 -- (area 1)-- L2 -- (area 0) -- R1 --- R2
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
vivek [Wed, 1 Nov 2017 20:36:46 +0000 (13:36 -0700)]
bgpd: Use BGP instance to derive the VRF for route uninstall
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.