Philippe Guibert [Wed, 20 Jun 2018 13:30:40 +0000 (15:30 +0200)]
bgpd: fix recursive call combination
The recursive algorithm was taking into account the fact that all the
bpof structures were filled in. Because the dscp value was not given,
the pkt_len parsing could not be achieved. Now the iteration takes into
account each type according to the previous one, thus guaranting all
parameters to be parsed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Wed, 20 Jun 2018 11:55:20 +0000 (13:55 +0200)]
bgpd: support for flowspec fragment list into policy routing
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>
Philippe Guibert [Wed, 20 Jun 2018 06:32:43 +0000 (08:32 +0200)]
bgpd: align fragment flowspec decoding with tcpflags
As fragment bitmask and tcpflags bitmask in flowspec protocol is encoded
in the same way, it is not necessary to differentiate those two fields.
Moreover, it overrides the initial fragment limit set to 1. It is now
possible to handle multiple framgent values.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Mon, 18 Jun 2018 09:18:21 +0000 (11:18 +0200)]
bgpd: extend enumerate API to handle or operations
The flowspec enumerate list can either be and values or or values.
In the latter case, a list is created that will be used later.
Also, the API supports the check for both and or or operations. This API
does not permit to handle both and and or operations at the same time.
The list will have to be either and or or. An other API retrieves the
operator unary value that is used: and or or. or 0 is the two operators
are used at the same time.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Wed, 13 Jun 2018 09:56:35 +0000 (11:56 +0200)]
bgpd: do not add default route for flowspec for each FS entry
Because the Flowspec entries are parsed first, then injected to Zebra,
there are cases where the install feedback from zebra is not received.
This leads to unnecessary add route events, whereas one should be
enough.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Tue, 12 Jun 2018 12:45:35 +0000 (14:45 +0200)]
bgpd: simplify API in BGP policy-routing to handle Flowspec
To handle FS params between FS RIB and BGP PBR entities, a structure
intermediate named bgp_pbr_filter is used, and contains all filtering
information that was before passed as a parameter.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Mon, 11 Jun 2018 13:30:11 +0000 (15:30 +0200)]
zebra: add packet length into pbr support
The packet length is added to iptable zapi message.
Then the iptable structure is taking into account the pkt_len field.
The show pbr iptable command displays the packet length used if any.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
It is possible for flowspec entries containing ICMP rule to insert PBR
entries based on ICMP type and ICMP code.
Flowspec ICMP filtering can either have icmp type or icmp code or both.
Not all combinations are permitted:
- if icmp code is provided, then it is not possible to derive the
correct icmp value. This will not be installed
- range of ICMP is authorised or list of ICMP, but not both.
- on receiving a list of ICMPtype/code, each ICMP type is attempted to
be associated to ICMP code. If not found, then ICMPtype is combined
with all known ICMP code values associated to that ICMP type.
- if a specific ICMP type/code is needed, despite the ICMP code/type
combination does not exist, then it is possible to do it by forging a
FS ICMP type/code specific for that.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This is an additional correction after 45981fda0634f7277c27c2a55e30d7f3433ffa16 / PR #2462. I hope
this fixes the Coverity warning (I've added an additional check for ensuring
the string provided by the inotify read is zero-terminated).
Unless someone intentionally changes MCAST_ALL_ROUTERS ("224.0.0.2") with a
wrong IP, this should never fail, so the fix is using "(void)" at the left
of the function call, as an explicit way of indicating we discard the
return value on purpose.
Removed all pointer arithmetic used for the checks, while keeping same
coverage. I hope this removes the Coverity warning (If this don't fix it, I'll
make Coverity work with a fork and try there as many times as necessary)
Donald Sharp [Fri, 22 Jun 2018 18:26:56 +0000 (14:26 -0400)]
zebra: Log how we got to this failure.
When a filter function fails to work correctly, we get an
error message that something has gone wrong. Unfortunately
we may not have any clues as to where the decode failure
happened. Add a backtrace to give us a clue.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 22 Jun 2018 18:22:02 +0000 (14:22 -0400)]
zebra: Add error messages in places where we have a decode problem
When we receive a netlink message from the kernel we have
handler functions for when we send a netlink command, if these
return a failure ( < 0 ) then we output that we had a parse
issue. But if all we get is:
2018-06-21T23:47:45.298156+00:00 qct-ix1-08 zebra[1484]: netlink-cmd (NS 0) filter function error
Then it is not very useful to figure out *where* the error happened.
Add more error code when in a decode path to hopefully allow us
to figure out where this message is coming from.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
G. Paul Ziemba [Sun, 24 Jun 2018 19:39:03 +0000 (12:39 -0700)]
bgpd: don't nexthop-track twice-leaked routes that came from zebra
Issue 2381: interface based routes not marked "up" when they originate
in zebra, redistributed to bgp vrf, then imported to vpn and then
imported by another vrf.
Routes that are redistributed into BGP from zebra should not get
nexthop tracking (the assumption is that the originating protocol
is responsible to export or withdraw the route according to its own
notion of nexthop status).
The vpn-vrf route-leaking code checks the source route sub_type to
decide whether to use nexthop tracking on the resulting leaked route.
A route that is redistributed from zebra into bgp will have
sub_type==BGP_ROUTE_REDISTRIBUTE. If it is leaked to the vpn RIB,
the resulting vpn RIB route will have sub_type==BGP_ROUTE_IMPORTED.
If THAT vpn route is leaked to another vrf, the original code will
examine only the leak-source route sub_type and, since it is
not BGP_ROUTE_REDISTRIBUTE, will wrongly try to use nexthop tracking
on the new route in the final vrf.
This change modifies the leak function to track back up the
parent links to the ultimate parent of the leak source route
and look at that route's sub_type instead.
paco [Fri, 22 Jun 2018 15:14:57 +0000 (17:14 +0200)]
zebra: untrusted array index (2) (Coverity 1470113)
This is a correction over 7f61ea7bd47bfd86a2c873870507281b1837dcdd in order
to avoid the TAINTED_SCALAR Coverity warning (ending in "Untrusted array
index read"). This is equivalent to the previous commit, but avoiding
pointer arithmetic with tainted variables.
projects / mirror / frr.git / log