Issue: bgpd got kill due to out of memory, when show bgp
neighbor json and show ip bgp neighbor <ip> routes json
commands executed multiple times in a setup having 320554
routes.
RCA: Heap allocated for bgpd keeps increasing. This is verified
using top command and show memory command.
Memleak Fix-1: show ip bgp route json command
When dumping a large bit of table data via bgp_show_route
and if there is no information to display for a particular
struct bgp_node *` the data allocated via json_object_new_array()
is not freed. This is resolved now.
Memleak Fix-2:
The function bgp_peer_counts() doesn't free the memory allocated for
json_loop when there is No such neighbor or address family. This is
fixed now.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When debugging in bgp is turned on for route-map processing
it would be awful nice to know what afi-safi we are working on
for the particular route-map. Especially when using a route-map
across different peers and different afi/safi's
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The `struct ecommunity` structure is using an int for a size value.
Let's switch it over to a uint32_t for size values since a size
value for data can never be negative.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In the function bgp_adj_out_set_subgroup, the attr pointer
is already derefed in all paths leading to a test for NULL.
You cannot pass a NULL attribute in since the whole function
would just immediately crash.
CID -> 1500604
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The command `neighbor PGROUP ttl-security hops X` was being
accepted but ignored. Allow it to be stored. I am still
not sure that this is applied correctly, but that is another
problem.
Fixes: #7848
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Talking w/ Chirag and he indicated that we can just backout the command
to the original and things would `work` and they do( at least a quick test does )
Put this in place until a proper fix can be done.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
A bgp neighbor remains in Idle state in the event that the number
of received prefixes exceeds the configured maximum prefix for the
neighbor. The neighbor remains in idle state even after de-configuring
the maximum prefix limit for the neighbor.
The fix is to clear the neighbor overflow state if set, after
de-configuring the neighbor maximum-prefix commnd.
This allows the neighbor to establish without having to perform a
clear operation. It also avoids the misleading neigbor summary
indicating that the neighbor is in prefix overflow state (PfxCt)
when no limit is configured for the neighbor.
Signed-off-by: Dewi Morgan <dewi.morgan@intl.att.com>
a missing '!' operator meant that correct rd strings were being
rejected in the destroy callback, making it impossible to remove
once configured.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
in the nortbound callback for the boolean leaf multi-path-as-set, the
actual value of the leaf was being ignored. As a result, going from
as-set to no-as-set was having no effect.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
- Move vtysh handler to DEFPY
- Convert neighbor route-map command to transactional cli.
- After nb conversion, remove not used apis.
- Implement NB callbacks for afi-safis
Signed-off-by: Chirag Shah <chirag@nvidia.com>
- Move vtysh handler to DEFPY
- Convert neighbor prefix-list command to transactional cli.
- After nb conversion, remove not used apis.
- implement NB apis for ipv4 afi-safis
Signed-off-by: Chirag Shah <chirag@nvidia.com>
When adding/removing some peer's flag we need to make sure we FORCE updates
to avoid suppressing critical updates.
Like entering `no neighbor x.x.x.x send-community large` would suppress
updates by default and another side will have stale large communities.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
In bgp_zebra_announce we do work to apply the table map.
This is the same for both v4 and v6 but we have the code
duplicated in both v4 and v6 if statements. Move outside
to reduce the duplications.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
BGP has created some redundant checks in bgp_zebra_announce()
Reduce the multiple if statements and consolidate a bit.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
`lcommunity_gettoken` expects a space-delimeted list of 0 or more large
communities. `lcommunity_list_valid` can perform this check.
`lcommunity_list_valid` now validates large community lists more
accurately based on the following condition: Each quantity in a standard bgp
large community must:
1. Contain at least one digit
2. Fit within 4 octets
3. Contain only digits unless the lcommunity is "expanded"
4. Contain a valid regex if the lcommunity is "expanded"
Moreover we validate that each large community list contains exactly 3
such values separated by a single colon each.
One quirk of our validation which is worth documenting is:
```
bgp large-community-list standard test2 permit 1:c:3
bgp large-community-list expanded test1 permit 1:c:3
```
The first line will throw an error complaining about a "malformed community-list
value". The second line will be accepted because the each value is each treated as
a regex when matching large communities, it simply will never match anything so
it's rather useless.
Signed-off-by: Wesley Coakley <wcoakley@nvidia.com>
When bgp is using wait for install semantics it would be nice
to be able to debug it when it is running.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This was somewhy under bgp_debug_udpate() guard and others are under
bgp_debug_neighbor_events().
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Fix `peer_default_originate_unset` so default route can be withdrawn
when `default-originate` option is being unset from a peer-group.
The loop calling `bgp_default_originate` is clearing default-originate
from the peer-group peer `peer` instead of the peer-group member peer
`member`.
Signed-off-by: zyxwvu Shi <shiyuchen.syc@bytedance.com>
The check for the return code for zclient_send_get_label_chunk is
reversed and therefore the pending count does not get incremented
for each successful label chunk request.
This has the effect of requesting a 50 label chunk per label request
from BGP i.e we request 50 times the labels we require.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
when we de-register for a label associated with a prefix then release
it back to the labelpool to clean up the stale reference held in the
ledger and inuse lists.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
To prepare for fixing an issue where labels do not get released back
to the labelpool when the route is deleted some refactoring is
necessary. There are 2 parts to this.
1. restructure the code to remove the circular nature of label
allocations via the labelpool and decouple the label type decision
from the notification fo the FEC.
The code to notify the FEC association to zebra has been split out
into a separate function so that it can be called from the synchronous
path (for registration of index-based labels and de-registration of all
labels), and from the asynchronous path where we need to wait for a
callback from the labelpool code with a label allocation.
The decision about whether we are using an index-based label or an
allocated label is reflected in the state of the BGP_NODE_LABEL_REQUESTED
flag so the checks on the path_info in the labelpool callback code are
no longer required.
2. change the owned of a labelpool allocated label from the path info
structure to the bgp_dest structure. This allows labels to be released
(in a subsequent commit) when the owner (bgp_dest) goes away.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
when the path info information is queued on the work queue it
is protected by a lock to avoid the rug being pulled whilst it
resides on the queue add an unlock in the error case where we do
no queue the reference to the workqueue.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
There exists a path where we could possibly have a NULL deref
of a pointer. Prevent this from happening.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
