currently:
when as-path-loop-detection is set on a peer-group.
members of the peer-group are not using that functionnality.
analysis:
the as-path-loop-detection, is not using the peer's flags
related framework.
fix:
use the peer's flag framework for as-path-loop-detection.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
If OAD is not set or set at least for one peer in peer-group, then split, and
create a separate update-group for those peers.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When added OAD support, it's handy to know peer->sub_sort also when printing
update-group debug messages.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
At each EBGP boundary, BGP path attributes are modified as per [RFC4271], which includes stripping any IBGP-only attributes.
Some networks span more than one autonomous system and require more flexibility in the propagation of path attributes. It is worth noting that these multi-AS networks have a common or single administrative entity. These networks are said to belong to One Administrative Domain (OAD). It is desirable to carry IBGP-only attributes across EBGP peerings when the peers belong to an OAD.
This document defines a new EBGP peering type known as EBGP-OAD, which is used between two EBGP peers that belong to an OAD. This document also defines rules for route announcement and processing for EBGP-OAD peers.
https://datatracker.ietf.org/doc/html/draft-uttaro-idr-bgp-oad
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Modify bgp_fsm_change_status to be connection oriented and
also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection
oriented as well. Attempt to make peer_xfer_conn a bit more
understandable because, frankly it was/is confusing.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When using `addpath-tx-all` BGP announces all known paths instead of announcing
only an arbitrary number of best paths.
With this new command we can send N best paths to the neighbor. That means, we
send the best path, then send the second best path excluding the previous one,
and so on. In other words, we run best path selection algorithm N times before
we finish.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Not sure why it's here, but looks like it was since the beginning, let's see
if we can drop it.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Effectively a massive search and replace of
`struct thread` to `struct event`. Using the
term `thread` gives people the thought that
this event system is a pthread when it is not
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is a first in a series of commits, whose goal is to rename
the thread system in FRR to an event system. There is a continual
problem where people are confusing `struct thread` with a true
pthread. In reality, our entire thread.c is an event system.
In this commit rename the thread.[ch] files to event.[ch].
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a hash_clean_and_free() function as well as convert
the code to use it. This function also takes a double
pointer to the hash to set it NULL. Also it cleanly
does nothing if the pointer is NULL( as a bunch of
code tested for ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
It was hard to catch those unless using higher values than uint32_t, but
already hit, it's time to fix completely.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Before this patch, we needed to explicitly define a neighbor to be SOLO
(= separate update-group). Let's ease this functionality for an operator to
avoid confusions.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
==1179738== 48 (40 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 13 of 29
==1179738== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==1179738== by 0x493C8D5: qcalloc (memory.c:116)
==1179738== by 0x208F0C: ecommunity_dup (bgp_ecommunity.c:267)
==1179738== by 0x2B300C: conf_copy (bgp_updgrp.c:170)
==1179738== by 0x2B35BF: peer2_updgrp_copy (bgp_updgrp.c:277)
==1179738== by 0x2B5189: update_group_find (bgp_updgrp.c:826)
==1179738== by 0x2B70D0: update_group_adjust_peer (bgp_updgrp.c:1769)
==1179738== by 0x23DB7D: update_group_adjust_peer_afs (bgp_updgrp.h:519)
==1179738== by 0x243B21: bgp_establish (bgp_fsm.c:2129)
==1179738== by 0x244B94: bgp_event_update (bgp_fsm.c:2597)
==1179738== by 0x26B0E6: bgp_process_packet (bgp_packet.c:2895)
==1179738== by 0x498F5FD: thread_call (thread.c:2008)
==1179738== by 0x49253DA: frr_run (libfrr.c:1198)
==1179738== by 0x1EEC38: main (bgp_main.c:520)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Let's convert to our actual library call instead
of using yet another abstraction that makes it fun
for people to switch daemons.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
BGP SoO is a tag that is appended on BGP updates to allow a peer to mark
a particular peer as belonging to a particular site. In certain MPLS L3 VPN
configurations, the BGP AS-Path may not provide the granularity needed
prevent a loop in the control-plane. With this in mind, BGP SoO is designed
to fill this gap and prevent a routing loop that may occur.
If we configure for example, `neighbor soo 65000:1` at PEs, routes won't be
announced between CPEs if soo matches. This is especially needed when using
as-override or allowas-in.
Also, this is the automated way of the same behavior as configuring route-maps
for each peer like:
```
bgp extcommunity-list cpe permit soo 65000:1
!
route-map cpe permit 10
set extcommunity soo 65000:1
...
route-map cpe deny 10
match extcommunity cpe
route-map cpe permit 20
...
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The new outbound filter to apply conditional advertisement policy was
not working properly due to complications with update groups. The two
routemaps were properly copied into the update group peer filter but not
the conditional advertisement state.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
Handle ORF REMOVE_ALL events as well, because now we just silently return, and
a stale dynamic prefix-list is used instead of the new one.
Before this, soft clear/route refresh was needed. Don't know the reason, but
we didn't send updates when modifying the filters.
Probably due to a massive change of filters and to avoid automatic updates :/
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Just convert all uses of thread_cancel to THREAD_OFF. Additionally
use THREAD_ARG instead of t->arg to get the arguement. Individual
files should never be accessing thread private data like this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The GCC extended printf format checking plugin runs into some GCC
shortcomings regarding casts on printf function parameters. While this
can be fixed with a small GCC patch, patching GCC is "nontrivial" to say
the least. Luckily, it happens that this is /almost/ not an issue for
the FRR source base.
Since we fix SA "misunderstandings" too, let's just fix places where the
format checking plugin runs into this limitation to keep things working
extra smoothly.
(It's not a huge effort either, these two spots in bgpd are the only
places that trigger the plugin limitation, and it's been "clean" before
that for more than a year if my memory is right.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Description:
- When there is change in route-map properties after
setting the route-map with default route, changes
will not reflect.
- When route-map associated with default-originate is
deleted, default route doesn't get withdrawn.
- When there is change in route-map default-originate flow
does not get triggered.
Fix:
- One of the flags needs to be unset for default-originate
flow to get triggered after change in route-map.
Have unset the flag, so that default originate flow can
be triggered.
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
