The bgp_nexthop must be the source bgp structure. It cannot be the
destination bgp one.
Use bgp_orig source bgp struct by default.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The "struct bgp" variable names in the mplsvpn bgp code do not
explicitly say whether they refer to a source or destination BGP
instance. Some variable declarations are commented out with "from" and
"to" but this does not avoid confusion within the functions. The names
of "struct bgp" variables are reused in different functions but their
names sometimes refer to a source instance and sometimes to a
destination instance.
Rename the "struct bgp" variable names to from_bgp and to_bgp.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
==175785== 0 bytes in 1 blocks are definitely lost in loss record 1 of 88
==175785== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==175785== by 0x492EB8E: qcalloc (in /usr/local/lib/libfrr.so.0.0.0)
==175785== by 0x269823: bgp_notify_decapsulate_hard_reset (in /usr/lib/frr/bgpd)
==175785== by 0x26C85D: bgp_notify_receive (in /usr/lib/frr/bgpd)
==175785== by 0x26E94E: bgp_process_packet (in /usr/lib/frr/bgpd)
==175785== by 0x4985349: thread_call (in /usr/local/lib/libfrr.so.0.0.0)
==175785== by 0x491D521: frr_run (in /usr/local/lib/libfrr.so.0.0.0)
==175785== by 0x1EBEE8: main (in /usr/lib/frr/bgpd)
==175785==
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
`attr.rmac` is not set in debug as expected for its wrong place in code.
Just move the debug process (`bgp_debug_zebra(NULL)`) after possible `rmac`
value is set.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Description:
- When there are multiple policies configured with
route-map then the first matching policy is not
getting applied on default route originated with
default-originate.
- In BGP we first run through the BGP RIB and then
pass it to the route-map to find if its permit or
deny. Due to this behaviour the first route in
BGP RIB that passes the route-map will be applied.
Fix:
- Passing extra parameter to routemap_apply so that
we can get the preference of the matching policy,
keep comparing it with the old preference and finally
consider the policy with less preference.
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
Description:
- On removing just the route-map from the default-originate config,
update message is not sent to the peer,
and the properties set by route-map persists on peer's end,
until we do a clear bgp.
Fix:
- The flag which is set when default route is originated,
should be unset once "neighbor X.X.X.X default-orginate",
to remove route-map from "neighbor X.X.X.X default-orginate route-map Y",
so as to trigger the flow for sending an update.
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
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>
Description:
Change is intended for fixing the inconsistencies present
while adjusting the SNT counters with default originate.
- SNT counter gets incremented on every change of policy associated
with default-originate, leading to inconsistencies.
- This fix has been added to ensure that the SNT counters gets
incremented and decremented only once during the creation and
deletion workflow of default-originate, and prevents
incrementing the counter during update flow.
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
These values were named WITHDRAW and UPDATE. Yeah, you guessed it, those
are already #define's elsewhere (bgp_debug.h). Hilarity ensues.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
Just adding a support for peer-groups, because now it's not possible to
configure BGP role for peer-groups.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The default keepalive/hold timers are always exposed via this commit:
```
commit 9b1b96233d (origin/bgp_timer_always_on)
Author: Trey Aspelund <taspelund@nvidia.com>
Date: Mon Jun 27 23:20:33 2022 +0000
bgpd: always display keepalive/hold intervals
`show bgp neighbors <peer> [json]` was only displaying the configured
keepalive and holdtime intervals when they differed from the default
values. Since default config is still config, let's make sure these
values are always displayed.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
```
However it mistakenly changed the logic to only display the peer's
timers if the configured value was non-zero. This updates the logic to
check PEER_FLAG_TIMER to determine if the values were configured,
given 0 is a valid value (to disable keepalives).
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
`show bgp neighbors <peer> [json]` was only displaying the configured
keepalive and holdtime intervals when they differed from the default
values. Since default config is still config, let's make sure these
values are always displayed.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
The command `debug bgp allow-martian` is not actually
a debug command it's a command that when entered allows
bgp to not reset a peering when a martian nexthop is
passed in the nlri.
Add the `bgp allow-martian-nexthop` command and allow it to be
used.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Coverity SA thinks that the `struct prefix`.u.prefix4 is limited
to actually 4 bytes of memory at that spot, but it's in a union
and it can be treated as a prefix6 as well. Just change the
pointer assignment to something that covers both easily.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
bgp_rpki_validation2str implements a switch statement to determine the
correct string response from the validation state. So, switch to a
switch statement when getting a name by role for code consistency.
Signed-off-by: Eugene Bogomazov <eb@qrator.net>
Roles cannot be applied to iBGP sessions, so we can move this check to
the top of the role configuration method. Thus, we simplify the internal
logic of branching.
Signed-off-by: Eugene Bogomazov <eb@qrator.net>
BGP Role is currently defined only for eBGP session. So, we don't
need to consider which roles can be applied on iBGP session and
thus simplify code fragment.
Signed-off-by: Eugene Bogomazov <eb@qrator.net>
RFC 9234 mandates that role rules apply only to IPv4/IPv6 unicast bgp
sessions. If the OTC attribute appears in other sessions, it will remain
untouched.
Signed-off-by: Eugene Bogomazov <eb@qrator.net>
If we have more CLI options configured and the last cache server is removed,
then the whole RPKI section is dropped.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
