Pascal Mathis [Wed, 16 May 2018 17:17:42 +0000 (19:17 +0200)]
bgpd: Implement new adjacent route show commands
This commit changes the behavior of `show bgp [afi] [safi] neighbor
<neighbor> received-routes [json]` to return all received prefixes
instead of filtering rejected/denied prefixes.
Compared to Cisco and Juniper products, this is the usual way how this
command is supposed to work, as `show bgp [afi] [safi] neighbor
<neighbor> routes` will already return all accepted prefixes.
Additionally, the new command `show bgp [afi] [safi] neighbor <neighbor>
filtered-routes` has been added, which returns a list of all prefixes
that got filtered away, so it can be roughly described as a subset of
"received prefixes - accepted prefixes".
As the already available `filtered_count` variable inside
`show_adj_route` has not been used before, the last output line
summarizing the amount of prefixes found was extended to also mention
the amount of filtered prefixes if present.
Pascal Mathis [Tue, 15 May 2018 17:22:25 +0000 (19:22 +0200)]
bgpd: Improve route-map matching for INET(6) AF
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.
Pascal Mathis [Sun, 13 May 2018 00:29:40 +0000 (02:29 +0200)]
bgpd: Improve JSON support for large communities
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.
Pascal Mathis [Sun, 13 May 2018 17:11:43 +0000 (19:11 +0200)]
lib: Moved no-password warnings into header file
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.
Pascal Mathis [Sat, 12 May 2018 18:19:49 +0000 (20:19 +0200)]
lib: Improved warnings for 'no (enable) password'
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.
Donald Sharp [Fri, 11 May 2018 17:46:59 +0000 (13:46 -0400)]
pimd: Cleanup the deletion event a tiny bit
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>
vivek [Mon, 7 May 2018 19:04:26 +0000 (12:04 -0700)]
bgpd: Set NEXT_HOP attribute for EVPN imported routes
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.
vivek [Wed, 9 May 2018 05:16:04 +0000 (22:16 -0700)]
bgpd: Update parent entry's refcount for imported routes
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.
Pascal Mathis [Thu, 10 May 2018 21:35:37 +0000 (23:35 +0200)]
bgpd: fix and improve snmp peer lookups
The previous implementation of bgp_peer_lookup_next did not consider the
internal ordering of peers when using peer groups, which led to all
standalone peers being skipped that had a lower IP address than the
highest IP address of a peer belonging to a group.
As the ordering of peers can not be arbitrary due to SNMP requiring
increasing OIDs when walking an OID tree, this commit fixes the bug by
properly looping through all peers and detecting the next highest IP
address.
Additionally, this commit improved both bgp_peer_lookup_next and
peer_lookup_addr_ipv4 by using the socketunion stored within the peer
struct (peer->su) instead of calling inet_pton for each peer during
comparison.
Donald Sharp [Fri, 11 May 2018 11:40:55 +0000 (07:40 -0400)]
bgpd: Respect ability to reach nexthop if available
When bgp is thinking about opening a connection to a peer,
if we are connected to zebra, allow that to influence our
decision to start the connection.
Found Scenario:
Both bgp and zebra are started up at the same time. Zebra is
being used to create the connected route through which bgp
will establish a peering relationship. The machine is a
bit loaded due to other startup conditions and as such bgp
gets to the connection stage here before zebra has installed
the route. If bgp does not respect zebra data when it does
have a connection then we will attempt to connect. The
connect will fail because there is no route. At that time
we will go into the connect timeout(2 minutes) and delay
connection.
What this does. If we have established a zebra connection and
we do not have a clear path to the destination at this point
do not allow the connection to proceed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 11 May 2018 11:34:24 +0000 (07:34 -0400)]
bgpd: Cleanup messages from getsockopt
The handling of the return codes for getsockopt was slightly wrong.
getsockopt returns -1 on error and errno is set.
What to do with the return code at that point is dependent
on what sockopt you are asking about. In this case
status holds the error returned for SO_ERROR.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Pascal Mathis [Fri, 11 May 2018 00:54:30 +0000 (02:54 +0200)]
lib: Ported 'no (enable) password' from stable/3.0
The pull request #1545 from @donaldsharp introduced the command 'no
password' to remove an existing terminal connection password.
Additionally, warnings have been added to both 'no password' and 'no
enable password' to make the user aware of any security implications.
It seems that this specific pull request was never merged against master
and got lost. This commit is a cherry-pick of d4961273cb with fixed
conflicts and updated documentation.
Thanks to @donaldsharp and @pogojotz for the original PR.
Chirag Shah [Tue, 1 May 2018 14:36:53 +0000 (07:36 -0700)]
ospfd: packet fifo init in interface create
Currently, interface packet transmit queue is created/deleted
as part of Interface UP/Down event. This results in
a rare condition where port came up but queue
was not created. The creation of queue occupies only few bytes.
Moving fifo queue creation to interface create
would add few bytes of fifo creation but at least it guaranteed
to be available during Up/down -->Up event.
Initialize ospf packet fifo queue during ospf
interface creation.
Drain queue during interface down event.
Drained and free the queue as part of the interface
delete/cleanup.
Ticket:CM-20744
Testing Done:
Bring up ospfv2 topology with multiple neighbors.
1) Trigger multiple shut/no shut events and validate
all queues are freed.
2) configure/deconfigure router ospf and validate
all ospf instance and interface underneath are freed.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Pascal Mathis [Thu, 10 May 2018 22:03:23 +0000 (00:03 +0200)]
debianpkg: improve VTYSH_PAGER environment check
The current post-installation scripts for all Debian packages execute
grep 'VTYSH_PAGER=/bin/cat' to check if the VTYSH_PAGER variable is
present within /etc/environment.
While presence of that environment variable should be checked, the
current implementation does not handle this line being a comment (and
therefor not active) or the user picking a different VTYSH_PAGER than
/bin/cat.
This commit ensures that the environment variable can be freely changed
by the user, while still guaranteeing that it is present in the file
without being a comment.
Don Slice [Thu, 10 May 2018 13:10:18 +0000 (09:10 -0400)]
bgpd: fix auto-completion for neighbors and peer-groups
Before this fix, both real neighbors and peer-groups were lumped
together in auto-completion and it didn't work at all for
peer-groups. This fix changes that behavior to do the right
thing.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Quentin Young [Wed, 9 May 2018 19:12:07 +0000 (15:12 -0400)]
doc: move Debian packaging docs to dev docs
Updated the doc to cross-reference build documentation as well and
reformatted to RST. Removed stub section on how to configure daemons and
whatnot, as that's the domain of the user docs.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Ensure that the next hop of the leaked VRF is not overwritten when the
route is being imported into the target VRF from the VPN table. Also, in
the case of multipath routes, ensure that the nexthop's ifindex is not
inadvertently reset.
zebra: Increase recvmsg buffer size for picking up netlink messages
Netlink messages from the kernel need to be received in a buffer larger
than 8K in order to handle some types of info - for example, the VLAN
information. Define a separate size for receive and set it to 32K, which
is the value used by other netlink receivers like iproute2.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 7 Jul 2017 17:42:40 +0000 (13:42 -0400)]
zebra: Fixup crash with vlan interfaces attempted to be used
When zebra starts up it receives from the kernel a full dump of
interface information. Unfortunately it is in no particular order.
As such we sometimes receive data from the kernel about interfaces
we do not know about yet.
In this bug, we are attempting to use the interface pointer(->link)
for a vlan interface that we have not properly resolved.
This fix ensures that we will not attempt to call zvni_map_svi
if we have a NULL pointer. There are other places in the code
we are already checking for the fact that the ->link pointer
is valid before calling this function, so I believe that this
is correct.
We do need to come back and resolve all ->link pointers
after we have received the full table. This can be
done in another commit.
Ticket: CM-17041 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Fri, 13 Oct 2017 22:46:23 +0000 (15:46 -0700)]
bgpd: Don't generate spurious warning on VNI deletion
There are situations in which zebra may issue more than one delete
notification, so BGP should not warn when it can't locate the VNI
at delete. This is comparable to the situation when a withdraw is
received but the route isn't present locally.
bgpd: set NEXTHOP_UNCHANGED for l2vpn evpn by default for all BGP peers
This flag needs to be set by default for l2vpn evpn address-family.
We needed to find a place in the code which gets called by all peers
at somepoint in the statemachine and before the routes are advertised.
peer_new seems like the right place for this
as we are setting other default af_flags here as well.
bgpd: enable neighbor-nexthop-self for l2vpn evpn address family
In the FRR implementation of EVPN,
eBGP leaf-spine peering for EVPN is fully supported by allowing
the next hop to be propagated and not rewritten at each hop.
There are other changes also related to route import to facilitate this.
However, propagating the next hop is not correct in some cases.
Specifically, if the DC is comprised of multiple PODs
with distinct intra-POD and inter-POD VxLAN tunnels,
EVPN routes received from an adjacent POD by a border/exit leaf
must be propagated into the local POD with the next hop rewritten (to self).
bgpd: modify route install/withdraw logic for evpn type-5 routes in vrf
We install type-5 routes as ipv4/ipv6 unicast routes in the vrf table.
along with these routes, we also install the RMAC
and the nexthop Neigh entries.
There might be scenarios were the bestpath has changed and
we are now pointing to a new nexthop with a different RMAC.
As per BGP logic, we just send an update for the route and the nexthop
is replaced. However, this causes problem because the RMAC and neigh entry
corresponding to the previous nexthop are still lingering in the system.
We need to clear those entries for proper functoning.
bgpd: apply advertise ipv4 unicast route-map while advertising type-5 routes
A newly added ipv4/ipv6 route in BGP RIB might be advertised as type-5 EVPN route.
The user might have configured a route-map for advertising type-5 routes.
We need to apply this route-map while advertising ipv4/ipv6 routes as type-5.
bgpd: write route-map to config for advertise type5 commands
We enable/disable type-5 routes by following commands:
advertise ipv4 unicast [route-map <route-map>]
advertise ipv6 commands [route-map <route-map>]
the route-map part was writtem to conf file.
vivek [Wed, 1 Nov 2017 23:57:55 +0000 (16:57 -0700)]
bgpd: Display table version for EVPN routes
Display the table version for EVPN routes like it is done for other
address families. Note that this is really relevant only for the
per-VNI routing table.
zebra: vni [prefix-routes-only] should also be provided for the 'no' cmd
We have a command to enable symmetric routing only for type-5 routes.
This command is provided under vrf <> option in zebra as follows:
vrf <VRF>
vni <VNI> [prefix-routes-only]
We need the corresponding no version of the command as well as follows:
vrf <VRF>
no vni <VNI> [prefix-routes-only]
zebra: remote RMAC for EVPN ipv6 hosts should be programmed against the ipv4 nexthop
For ipv6 host, the next hop is conevrted to ipv6 mapped address.
However, the remote rmac should still be programmed with the ipv4 address.
This is how the entries will look in the kernel for ipv6 hosts routing.
vrf routing table:
ipv6 -> ipv6_mapped remote vtep on l3vni SVI
projects / mirror_frr.git / log