"When building without VNC, automake sees that the `bgpd_bgpd_CFLAGS`
variable exists, although it is only set in the VNC-enabled case... but
since the variable exists, it unconditionally drops `AM_CFLAGS` for the
two bgp targets and uses `bgpd_bgpd_CFLAGS` instead, which will
contain... _nothing_."
This was breaking builds of bgpd binaries with MSAN enabled.
Signed-off-by: David Lamparter <equinox@diac24.net>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Commit b4897fa5 introduced a call to decrement a route-map counter,
applied to a prefix-list in bgp_rfapi_cfg.c. This commit removes
that call.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
there are some cases where the bgp deletion will not be complete, while
the vrf identifier of the bgp instance is not completely identified. The
vrf search based on the bgp name is the better protection, since the bgp
vrf instance is created, even if the vrf identifier is not yet known.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Made changes and updated the routemap applied counter in the following flows.
1.Increment when route map attached to a list.
2.Decrement when route map removed / modified from a list.
3.Increment/decrement when route map create/delete callback triggered.
4.Besides ,This counter need not be updated when a route map is got updated.
i.e changing/adding a match value to the existing routemap.
In BGP , same update api called for all three add/delete/update operation .
But this counter have to be updated only for routemap addition.
Addressed this specific change by identifying the routemap operation based
on routemap pointer.
Signed-off-by: RajeshGirada <rgirada@vmware.com>
- some target_CFLAGS that needed to include AM_CFLAGS didn't do so
- libyang/sysrepo/sqlite3/confd CFLAGS + LIBS weren't used at all
- consistently use $(FOO_CFLAGS) instead of @FOO_CFLAGS@
- 2 dependencies were missing for clippy
Signed-off-by: David Lamparter <equinox@diac24.net>
Executed some evpn related tests with valgrind and saw some errors
related to uninitialized memory and overlapping memcpy. This commit
fixes those.
Ticket: CM-21218
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by: CCR-8249
the list of iprules is displayed in the 'show bgp ipv4 flowspec detail'
The list of iprules is displayed, only if it is installed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
two kind of rules are being set from bgp flowspec: ipset based rules,
and ip rule rules. default route rules may have a lower priority than
the other rules ( that do not support default rules). so, if an ipset
rule without fwmark is being requested, then priority is arbitrarily set
to 1. the other case, priority is set to 0.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
because ip rule creation is used to not only handle traffic marked by
fwmark; but also for conveying traffic with from/to rules, a check of
the creation must be done in the linked list of ip rules.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
adding/suppressing flowspec to pbr is supported. the add and the remove
code is being added. now,bgp supports the hash list of ip rule list.
The removal of bgp ip rule is done via search. The search uses the
action field. the reason is that when a pbr rule is added, to replace an
old one, the old one is kept until the new one is installed, so as to
avoid traffic to be cut. This is why at one moment, one can have two
same iprules with different actions. And this is why the algorithm
covers this case.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
now, ip rule can be created from two differnt ways; however a single
zebra API has been defined. so make it consistent by adding a parameter
to the bgp zebra layer. the function will handle the rest.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Before, it was not possible to create any rules. Now, it is possible to
have flowspec rules relying only on ip rule command. The check is done
here.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
that iprule list stands for the list of fs entries that are created,
based only on ip rule from/to rule.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
instead of using ipset based mechanism to forward packets, there are
cases where it is possible to use ip rule based mechanisms (without
ipset). Here, this applies to simple fs rules with only 'from any' or
'to any'.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
main bgp structure that contains fs information is being cleaned.
some fields are removed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgp instance is disabling the label allocated to reach vrf entity.
previously, only vrf disabling was removing the label. now, when bgp
leaves, bgp instance also frees the label used.
PR=62306
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Acked-by: Julien Floret <julien.floret@6wind.com>
When a interface based peer is setup and if it is part of a peer
group we should ignore this and just use the PEER_FLAG_CAPABILITY_ENHE
no matter what.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
bgp would crash with various `show bgp neighbor json` commands
based upon whether or not it did a pretty print of the output
or not. This is because we were freeing the data 2 times.
Cleanup so that we free the json data 1 time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When an inactive-neigh delete is rxed bgp will not have a local path to
remove (and re-run path selection). Instead it simply re-installs the
current best remote path if any.
Ticket: CM-23018
Testing Done: evpn-min
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Move the info filling for zebra mac-ip install (sent by bgpd) to a
common place.
The commit also fixes missing ROUTER flag for one of the cases
added in a code branch that doesn't have the ROUTER changes -
[
6d8c603a
bgpd: use IP address as tie breaker if the MM seq number is the same
]
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Route-map filtering is based on the value of
"bgp->adv_cmd_rmap[afi][safi].map". For example, we advertise routes in
bgp_evpn_advertise_type5_routes() based on the value of
"bgp->adv_cmd_rmap[afi][safi].map". This variable gets populated in vty
handler bgp_evpn_advertise_type5. This variable will not get populated
if we have not yet applied the route-map configuration. The fix is to
correctly populate "bgp->adv_cmd_rmap[afi][safi].map" in
bgp_route_map_process_update() if it has not been populated before.
Ticket: CM-23263
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by: CCR-8163
Problem reported that with certain sequences of defining the
remote-as on the peer-group and the members, the configuration would
become wrong, with configured remote-as settings not reflected in
the config but peers unable to come up. This fix resolves these
inconsistencies.
Ticket: CM-19560
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
when removing bgp instance, the parsing of rm->info contexts must be
protected. Also, the main level of hierarchy of rds must not be
allocated more than once.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Now that all daemons receive the VRF backend from zebra, we can get
rid of vrf_is_mapped_on_netns() in favor of using the more convenient
vrf_is_backend_netns() function, which doesn't require any argument.
This commit also fixes the following problem:
debian(config)# ip route 50.0.0.0/8 blackhole vrf FAKE table 2
% table param only available when running on netns-based vrfs
Even when zebra was started with the --vrfwnetns, the error
above would be displayed since the VRF FAKE didn't exist, which
would make vrf_is_mapped_on_netns() return 0 incorrectly. Using
vrf_is_backend_netns() this problem doesn't happen anymore.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
strlen is the same as sizeof when the memory is dynamically allocated
but it is not the same when the memory being looked at is an array.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
