The buffer size was insufficiently sized to hold the
entirety of the data being passed in.
Modify the nht code to use a bit bigger buffer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The required packages list should be easier to parse. Updated the style so it's more similar to the ``./configure`` style later in the document.
Signed-off-by: Jarad Olson <brotherdust+github@gmail.com>
Names of the MPLS kernel modules changed slightly in recent kernel. Uses underscore instead of dash.
Signed-off-by: Jarad Olson <brotherdust+github@gmail.com>
While the current implementation does pay attention to the AF
(inet/inet6) when comparing the IPv4/v6 address against an address-list
/ prefix-list inside a route-map, the AF check is being done rather
late, which leads to CPU cycles being wasted due to unnecessary list
lookups / address matching.
This commit checks the address family of a prefix right inside the
`route_match_ip(v6)_` functions before looking up any address- and/or
prefix-list, which should improve performance.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The current implementation does not respect the AFI+SAFI combination of
a peer when executing a non-soft (hard) clear. An example would be the
command `clear bgp ipv4 unicast *`, which will clear all BGP peers, even
those that do not have IPv4-Unicast activated.
This commit fixes that behavior by applying the same rules to both soft
and hard clear commands, so that peers without a matching AFI+SAFI
combination will be no longer modified.
Additionally, this commit adds warning messages to all `clear bgp
[<afi>] [<safi>] <target>` commands when no matching peers with the given
AFI+SAFI combination could be found.
Both existing and new warning messages have been extended to also
mention the AFI+SAFI combination that is missing, which is more helpful
to the user than a generic expression 'No peer configured'.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The current implementation of building JSON output is greatly different
for large communities compared to standard communities. This is mainly
noticeable by the missing 'list' attribute, which usually offers an
array of all communities present on a BGP route.
This commit adds the missing functionality of properly returning a
'list' attribute in JSON output and also tries a similar approach like
the standard communities are using to implement this feature.
Additionally, the 'format' specifier has been completely removed from
large communities string/JSON rendering, as the official RFC8092 specifies that
there is only one canonical representation:
> The canonical representation of BGP Large Communities is three
> separate unsigned integers in decimal notation in the following
> order: Global Administrator, Local Data 1, Local Data 2. Numbers
> MUST NOT contain leading zeros; a zero value MUST be represented with
> a single zero. Each number is separated from the next by a single
> colon. For example: 64496:4294967295:2, 64496:0:0.
As the 'format' specifier has not been used/checked and only one
canonical representation exists per today, there was no reason to keep
the 'format' parameter in the function signature.
Last but not least, the struct attribute 'community_entry.config' is no
longer being used for large communities and instead 'lcommunity_str' is
being called to maintain a similar approach to standard communities.
As a side effect, this also fixed a memory leak inside 'community_entry_free'
which did not free the allocated memory for the 'config' attribute when
dealing with a large community.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The warning string which appears when the users executes 'no (enable)
password' was moved into command.h and declared as a constant named
'NO_PASSWD_CMD_WARNING'.
This avoids duplicate code and makes it easy to change the warning
message in all places at once.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
Currently, "vtysh -c" interface does not provide a logic to parse
commands ending with '?' character. In consequence, the following behavior
is observed:
$ vtysh -c "show bgp ?"
% Unknown command.
With these changes, i'm extending FRR's parser to be able to handle
these commands, which allow a more friendly interaction with users
that rely on "vtysh -c" interface. The typical use-case here is for
scenarios in which the final users relie on external/their-own CLI and
require a friendly interface to FRR's vtysh cli.
$ vtysh -c "show bgp ?"
<cr>
A.B.C.D Network in the BGP routing table to
display
A.B.C.D/M IPv4 prefix
X:X::X:X Network in the BGP routing table to display
X:X::X:X/M IPv6 prefix
attribute-info List all bgp attribute information
cidr-only Display only routes with non-natural netmasks
community Display routes matching the communities
community-info List all bgp community information
...
Signed-off-by: Rodny Molina <rmolina@linkedin.com>
When the user executes one of the commands 'no password' or 'no enable
password', a warning message gets shown to inform the user of the
security implications.
While the current implementation works, a warning message gets printed
once for each daemon, which can lead to seeing the same message many
times. This does not affect functionality, but looks like an error to
the user as it can be seen within issue #1432.
This commit only prints the warning message inside lib when vtysh
dispatch is not being used. Additionally, the warning message was copied
into the vtysh command handlers, so that they get printed exactly once.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
Cleanup the pim->rpf_hash after upstream cleanup is done
since upstream cleanup uses the rpf_hash to cleanup itself.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pim_upstream_free command was leaving slag by
not deleting data associated with the upstream
data structure. Modify the code to explicitly free
all data associated with an upstream on a pim instance
deletion event. Additionally the end result is that
the pim_upstream_free command is not needed anymore
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ensure that when EVPN routes are imported into a VRF as IPv4 routes,
the NEXT_HOP attribute is set. In the absence of this, this attribute
is currently not generated when advertising the route to peers in the
VRF. It is to be noted that the source route (the EVPN route) will only
have the MP_REACH_NLRI attribute that contains the next hop in it.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Imported routes in a VRF routing table have a reference to their parent
route entry which resides in the EVPN or IPVPN routing table. Ensure that
this reference uses appropriate locking so that the parent entry doesn't
get freed prematurely.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 13cb6b22ba9d558b1b4a1e8752f63f13242462a7)
Conflicts:
bgpd/bgp_mplsvpn.c
Ticket: CM-20471
Testing Done:
a) Ran vrf_route_leak tests without fix and hit crash, ran twice with fix
and did not see the crash.
b) Ran evpn-smoke and ensured there were no new failures.
