Don Slice [Mon, 26 Mar 2018 19:16:09 +0000 (19:16 +0000)]
pbrd: adjust/remove the rule correctly when dst and/or src removed
When the last match criteria was removed (dst-ip or src-ip), we were
not deleting the rule correctly for ipv6. This fix retains the
needed src-ip/dst-ip during the pbr_send_pbr_map process so the
appropriate information is available for the rule delete.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Donald Sharp [Mon, 26 Mar 2018 17:32:41 +0000 (13:32 -0400)]
pbrd: Remove table and rule range commands
Since PBR is meant to be for small deployments, allowing
end users to arbitrarily change rule and table ranges
without some more careful thought on what is going on
and how to do it, sets us up for issues.
At this time remove these knobs.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Mon, 26 Mar 2018 15:05:52 +0000 (11:05 -0400)]
zebra: Add code to notice nexthop changes for pbr tables
When we have a PBR installed as a table, we need to notice
when a nexthop changes and rethink the routes for the pbr
tables.
Add code to nexthop tracking to notice the pbr watched
nexthop has changed in some manner. If it is a pbr route
that depends on the nexthop then just enqueue it for
rethinking.
This is a bit of a hammer, we know that only pbr routes
are going to be installing routes in weird non-standard
tables as such we need to only handle nexthop changes
for nexthops that are actually changing that we care
about and to only requeue for route nodes we have
route entries for from PBR
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Mon, 26 Mar 2018 01:18:56 +0000 (21:18 -0400)]
pbrd: Do not use vrf_frame for pbrms display
When displaying a pbr map sequence for a show run do not use the
vty_frame construct. We should display the config even if we
do not have much to display.
Ticket: CM-20196 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Don Slice [Thu, 22 Mar 2018 13:56:56 +0000 (13:56 +0000)]
pbrd: fix deletion of match or src of valid pbr-map
When removing either the match dst or match src of a previously
valid pbr map, we would just try to re-install the rule which
was rejected. This fix deletes the old rule before we re-apply
the new rule.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Donald Sharp [Mon, 19 Mar 2018 13:04:17 +0000 (09:04 -0400)]
pbrd: Remove pbr_events
The pbr_events.c file was a mistake in that it overly complicated
the code and made it hard to think about what was happening.
Remove all the events and just do the work where needed.
Additionally rethink the sending of the pbr map to
zebra and only send one notification at a time instead
of having the sending function attempt to figure out
what to do.
Clean up some of the no form of commands to make them
work properly.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Quentin Young [Mon, 19 Mar 2018 13:01:52 +0000 (09:01 -0400)]
lib: Add hash and use const a bit more intelligently
This commit adds code to notify the compiler that we
will not be changing the arguments to nexthop2str
and we expect thre return to be treated the same.
Additionally we add some code to allow nexthops to
be hashed to be used in a hash.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Donald Sharp [Tue, 23 Jan 2018 18:11:36 +0000 (13:11 -0500)]
pbrd: Add PBR to FRR
This is an implementation of PBR for FRR.
This implemenation uses a combination of rules and
tables to determine how packets will flow.
PBR introduces a new concept of 'nexthop-groups' to
specify a group of nexthops that will be used for
ecmp. Nexthop-groups are specified on the cli via:
nexthop-group DONNA
nexthop 192.168.208.1
nexthop 192.168.209.1
nexthop 192.168.210.1
!
PBR sees the nexthop-group and installs these as a default
route with these nexthops starting at table 10000
robot# show pbr nexthop-groups
Nexthop-Group: DONNA Table: 10001 Valid: 1 Installed: 1
Valid: 1 nexthop 192.168.209.1
Valid: 1 nexthop 192.168.210.1
Valid: 1 nexthop 192.168.208.1
I have also introduced the ability to specify a table
in a 'show ip route table XXX' to see the specified tables.
robot# show ip route table 10001
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR,
> - selected route, * - FIB route
F>* 0.0.0.0/0 [0/0] via 192.168.208.1, enp0s8, 00:14:25
* via 192.168.209.1, enp0s9, 00:14:25
* via 192.168.210.1, enp0s10, 00:14:25
PBR tracks PBR-MAPS via the pbr-map command:
!
pbr-map EVA seq 10
match src-ip 4.3.4.0/24
set nexthop-group DONNA
!
pbr-map EVA seq 20
match dst-ip 4.3.5.0/24
set nexthop-group DONNA
!
pbr-maps can have 'match src-ip <prefix>' and 'match dst-ip <prefix>'
to affect decisions about incoming packets. Additionally if you
only have one nexthop to use for a pbr-map you do not need
to setup a nexthop-group and can specify 'set nexthop XXXX'.
To apply the pbr-map to an incoming interface you do this:
interface enp0s10
pbr-policy EVA
!
When a pbr-map is applied to interfaces it can be installed
into the kernel as a rule:
[sharpd@robot frr1]$ ip rule show
0: from all lookup local
309: from 4.3.4.0/24 iif enp0s10 lookup 10001
319: from all to 4.3.5.0/24 iif enp0s10 lookup 10001
1000: from all lookup [l3mdev-table]
32766: from all lookup main
32767: from all lookup default
[sharpd@robot frr1]$ ip route show table 10001
default proto pbr metric 20
nexthop via 192.168.208.1 dev enp0s8 weight 1
nexthop via 192.168.209.1 dev enp0s9 weight 1
nexthop via 192.168.210.1 dev enp0s10 weight 1
The linux kernel now will use the rules and tables to properly
apply these policies.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Signed-off-by: Don Slice <dslice@cumulusnetworks.com> Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Arthur Jones [Wed, 4 Apr 2018 02:15:11 +0000 (19:15 -0700)]
alpine packaging: build packages and base image directly from git
Currently, we tar up the git repo before building alpine packages.
This ensures that the packages we're building are exactly what is
checked in. But, in practice, this restriction causes us to not
be able to build off of git contexts, which is a convenient feature
especially when using docker-compose.
So, here, we build the alpine packages directly from the contents
of the current directory and we install the packages into a base
image to ease downstream consumption. There is still work to be
done in that area, as we need to package up the daemons, frr user
and all the rest, but that's for later...
Testing-done:
Built directly from the git repo, built from a reference to the
git repo and built using docker-compose, all seemed to work. Also,
tested by @leleobhz and seems to build fine.
Thanks to Leonardo Amaral (@leleobhz) for reporting the issue and for
the original idea for a fix.
Issue: https://github.com/FRRouting/frr/issues/2024 Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
G. Paul Ziemba [Fri, 23 Mar 2018 23:57:03 +0000 (16:57 -0700)]
bgpd: nexthop tracking with labels for vrf-vpn leaking
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.
Quentin Young [Mon, 2 Apr 2018 18:41:38 +0000 (14:41 -0400)]
doc: add more CLI documentation
* Document modes & nodes
* Document walkup behavior
* Document struct cmd_node
* Add graph of node relationships
* Reorder sections to make more logical sense
* Rewrap sections to 80 lines
* Fix code block indent
* Specify language for code blocks in order to get syntax highlighting
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Fri, 30 Mar 2018 02:13:57 +0000 (22:13 -0400)]
lib, vtysh: vrf walkup bugfix
Static route commands are now installed inside the VRF nodes. This has
quietly broken top-level static routes in certain scenarios due to
walkup logic resolving a static route configuration command inside
VRF_NODE first if the command is issued while in a CLI node lower than
VRF_NODE. To fix this VRF_NODE needs a special exit command, as has been
done for many other nodes with the same issue, to explicitly change the
vrf context to the default VRF so that when walkup resolves against the
VRF node it will configure against the default VRF as desired.
Of course this is a hack on top of a hack and the CLI walkup
implementation needs to be rewritten.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
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>
vivek [Fri, 30 Mar 2018 00:24:00 +0000 (00:24 +0000)]
bgpd: Fix use of ROUTE_IMPORTED for EVPN
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>
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>
projects / mirror / frr.git / log