Donald Sharp [Fri, 31 May 2019 12:51:07 +0000 (08:51 -0400)]
lib, zebra: Ensure route encoding has enough space
When you have compiled FRR with a large multipath number
then encoding large ecmp routes between zebra and the
routing daemons. There exists a theoritical size
of multipath that will cause the encoding to be larger
than the ZEBRA_MAX_PACKET_SIZ. In the cases where
we have allocated streams that will encode routes
then let's ensure that whatever size we have will
auto-fit what we say we can send.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
lib: Introducing a 3rd state for route-map match cmd: RMAP_NOOP
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
Action: Apply route-map match and return the result (RMAP_MATCH/RMAP_NOMATCH)
State1: Receveived RMAP_MATCH
THEN: If Routemap type is PERMIT, execute other rules if applicable,
otherwise we PERMIT!
Else: If Routemap type is DENY, we DENYMATCH right away
State2: Received RMAP_NOMATCH, continue on to next route-map, otherwise,
return DENYMATCH by default if nothing matched.
With reference to PR 4078 (https://github.com/FRRouting/frr/pull/4078),
we require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP (or another enum) to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR
as the 3rd state (or create a new enum like RMAP_NOOP)?
RMAP_OKAY and RMAP_ERROR are used to return the result of set cmd.
We chose to go with RMAP_NOOP (but open to ideas),
as a way to bypass the rmap filter
As a result we have a 3rd state:
State3: Received RMAP_NOOP
Then, proceed to other route-map, otherwise return RMAP_PERMITMATCH by default.
Sarita Patra [Thu, 16 May 2019 16:58:28 +0000 (09:58 -0700)]
pimd: new cli command show ip mroute summary
Introduced a new command "show ip mroute summary"
to display total number of (*, G) and (S, G) mroutes
created and number of mroutes installed in the kernel.
Christian Franke [Wed, 29 May 2019 12:44:07 +0000 (14:44 +0200)]
isisd: Remove unnecessary use of strcpy
`strcpy` is a dangerous function and should not be used. In this
particular place, there is no need for copying strings at all, so let's
just stick to referencing static strings.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Martin Winter [Mon, 18 Feb 2019 15:57:24 +0000 (07:57 -0800)]
snapcraft: Disable libyang CACHE for snap package (Temp workaround)
There seems to be a bug in latest libyang running when running in
a snap container which causes a failure of the cache logic. Disable
CACHE for now as it's not yet needed. Will be re-enabled in a later
release
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
Mark Stapp [Fri, 5 Apr 2019 14:38:35 +0000 (10:38 -0400)]
zebra: share rib processing of updates and notifications
Use some common handling for both route update results
processing and dataplane notification processing. Use the
fib-specific nexthop-group if the update to a route results
in different nexthop status than the default rib-provided
nexthop-group.
Use the fib-specific nexthop-group, if present, to provide
the output of 'show ip fib'.
Mark Stapp [Tue, 2 Apr 2019 16:25:33 +0000 (12:25 -0400)]
zebra: add source plugin info to dplane context
Some updates may be the result of a plugin's actions - such
as an async notification. Add accessor so that we can
identify that an update was generated by a plugin.
Mark Stapp [Wed, 20 Mar 2019 18:44:29 +0000 (14:44 -0400)]
zebra: set nexthop install state more accurately
When setting route nexthops' installation state based on a
dataplane context struct, unset the installed state if a
nexthop was not present in the dataplane context.
Mark Stapp [Wed, 20 Mar 2019 15:27:20 +0000 (11:27 -0400)]
zebra: add api to locate route-node from dplane ctx
Create a helper api that locates a zebra route-node from info
in a dplane context struct. Moved code from the results handler
to make a more-general api that could be used in other paths.
Mark Stapp [Tue, 19 Mar 2019 20:18:42 +0000 (16:18 -0400)]
zebra: add api to update route from dplane ctx
Add an api to update the status of a route based on info
from a dplane context object. Use the api when processing
route update results from the dataplane.
Donald Sharp [Mon, 27 May 2019 01:51:59 +0000 (21:51 -0400)]
bgpd: convert a couple of debug strings in rpki to prefix2str
Was getting a couple of compile errors with newer compilers
when compiling rpki around the prefix length. Convert
them over to prefix2str as that is all it is doing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 24 May 2019 12:30:53 +0000 (08:30 -0400)]
bgpd, lib: Remove SO_MARK
The SO_MARK socket option was being used pre vrf to allow for the
separation of the front panel -vs- the management port. This
was facilitated by a ip rule. Since this is undocumented anywhere
in our system( other than old commits see ed40466af80c9d0b88436c637a1d54b28a669b1c ). We should remove this
because this will cause interference with people using rules
and are not aware of this offshoot of functionality.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>