If we attempt to register nexthops before we have the zebra
connection, they will not be installed. After we have noticed
that we are up, re-install them.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problems were reported with the name of the default vrf and the
default bgp instance being different, creating confusion. This
fix changes both to "default" for consistency.
Ticket: CM-21791
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-7658
Testing: manual testing and automated tests before pushing
The ->hash_cmp and linked list ->cmp functions were sometimes
being used interchangeably and this really is not a good
thing. So let's modify the hash_cmp function pointer to return
a boolean and convert everything to use the new syntax.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Recent changes to the nht code in bgp caused us to actually
keep a true count of v6 nexthop paths when using v4 over v6.
This change introduced a race condition on shutdown on who
got to the bnc cache first( the v4 table or not ). Effectively
we were allowing the continued existence of the path->nexthop
pointing to the freed bnc. This was especially true when
we had route leaking. So when we free the bnc make sure
we clean up the path->nexthop variables pointing at it too.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When cleaning up a interface string, from the linked list we were
dropping the name pointer which held the allocated martian address
intf string.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Track the memory type associated with the bartian address
interface a bit better, instead of using MTYPE_TMP.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_nexthop_cache data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_connected_ref data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Track the refcount a bit differently as that it is possible
to get into situations where we have multiple calls for the
same ifc. So let's just keep a list of the ifc's off of
each `struct bgp_addr` and then keep the hash entry based
upon list count or not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The `struct bgp_addr` is not needed for anything other than
the address hash. Isolate this data structure so that it
is not polluting up the name space.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit removes various parts of the bgpd implementation code which
are unused/useless, e.g. unused functions, unused variable
initializations, unused structs, ...
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
When we are shutting down, there exists a code path
where the connected table leaks some memory. Cleanup
the code to remove the memory.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We have 2 code paths that were duplicating a bunch of code
for the deletion of connected prefixes.
This simplifies the code path and makes the code look a bit
cleaner.
I did not touch the _add path because the v4 if statement
had some code I did not have time to look into. Future project.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Routes that have labels must be sent via a nexthop that also has labels.
This change notes whether any path in a nexthop update from zebra contains
labels. If so, then the nexthop is valid for routes that have labels.
If a nexthop update has no labeled paths, then any labeled routes
referencing the nexthop are marked not valid.
Add a route flag BGP_INFO_ANNC_NH_SELF that means "advertise myself
as nexthop when announcing" so that we can track our notion of the
nexthop without revealing it to peers.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Perf results at scale( >1k peers) showed a non-trivial
amount of time spent in bgp_multiaccess_check_v4. Upon
function examination we are looking up the nexthops
connected node in each call as well as having to unlock
it after each iteration. Rewrite to lookup the nexthop
node once.
This should reduce the node lookup by aproximately 1/2
which should yield some performance results. There are
probably better things to do here but would require
deeper thought.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem with not finding the correct bgp instance when doing the command
"show ip bgp vrf <vrf> nexthop" resolved by setting up the arg values
correctly. Manual testing fine. bgp-smoke had no new failures.
Ticket: CM-17454
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-6664
1) Add hash names to all hash_create calls
2) Fix community_hash, ecommunity_hash and lcommunity_hash key
creation
3) Fix output of community and lcommunity iterators( why would
we want to see the memory location of the backet? ).
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There are two parts to this commit:
1. create a database of self tunnel-ip for used in martian nexthop check
In a CLAG setup, the tunnel-ip (VNI UP) notification comes before the clag-anycast-ip comes up in the system.
This was causing our self next hop check to fail and we were instaling routes with martian nexthop in zebra.
We need to keep this info in a seperate database for all local tunnel-ip.
This database will be used in parallel with the self next hop database to martian nexthop checks.
2. When a local VNI comes up, update the tunnel-ip database and filter routes in the RD table if necessary
In case of EVPN we might receive routes from clag peer before the clag-anycast ip and VNI is up on the system.
We will store the routes in the RD table for later processing.
When VNI comes UP, we loop thorugh all the routes and install them in zebra if required.
However, we were missing the martian nexthop check in this code path.
From now onwards, when a VNI comes UP,
we will first update the tunnel-ip database
We then loop through all the routes in RD table and apply martian next hop filter if required.
Things not covered in this commit but are required:
This processing is needed in general when an address becomes a connected address.
We need to loop through all the routes in BGP and apply martian nexthop filter if necessary.
This will be taken care in a seperate bug
Ticket:CM-17271/CM-16911
Reviewed By: ccr-6542
Testing Done: Manual
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Ensure that the check for martian next hop is correct, including for MP
nexthops, if IPv4.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
The FSF's address changed, and we had a mixture of comment styles for
the GPL file header. (The style with * at the beginning won out with
580 to 141 in existing files.)
Note: I've intentionally left intact other "variations" of the copyright
header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
1) Make [<view|vrf> WORD] consistent
2) Fix inconsistent help string
3) Fix the show .. vrf all command
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
thread.c fails to build properly on systems that do
not have a CLOCK_MONOTONIC. Therefore there is
no need for bgp to have knowledge of it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Additionally:
* Add [ip] to a couple bgp show commands
* Quick refactor of a couple ISIS commands
* Quick refactor of a couple OSPF6 commands
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
