This moves all the DFLT_BGP_* stuff over to the new defaults mechanism.
bgp_timers_nondefault() added to get better file-scoping.
v2: moved everything into bgp_vty.c so that the core BGP code is
independent of the CLI-specific defaults. This should make the future
northbound conversion easier.
Signed-off-by: David Lamparter <equinox@diac24.net>
There's no good reason to have this in bgpd.c; it's just there
historically. Move it to bgp_vty.c where it makes more sense.
Signed-off-by: David Lamparter <equinox@diac24.net>
The sender side AS path loop detection code was implemented since the
import of Quagga code, however it was always disabled by a `ifdef`
guard.
Lets allow the user to decide whether or not to enable this feature on
run-time.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Add -s X or --socket_size X to the bgp cli to allow
the end user to specify the outgoing bgp tcp kernel
socket buffer size.
It is recommended that this option is only used on
large scale operations.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This change addresses the following:
1) Ensures logs under DEBUG macro checks are categorized
as zlog_debug instead of zlog_info.
2) Error logs are categorized as zlog_err instead of zlog_info.
3) Rephrasing certain logs to make them appear more intuitive.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
There was a silly bug introduced when the command to show failed sessions
was added. A missing "," caused the wrong error message to be printed.
Debugging this led down a path that:
- Led to discovering one more error message that needed to be added
- Providing the error code along with the string in the JSON output
to allow programs to key off numbers rather than strings.
- Fixing the missing ","
- Changing the error message to "Waiting for Peer IPv6 LLA" to
make it clear that we're waiting for the link local addr.
Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
We have this crash:
2019-08-18T07:58:44.831656-04:00 rch2-140-fwK2b bgpd[1791]: %NOTIFICATION: sent to neighbor 10.73.248.8 4/0 (Hold Timer Expired) 0 bytes
2019-08-18T07:58:44.832164-04:00 rch2-140-fwK2b bgpd[1791]: Assertion `!((peer->thread_flags) & ((1 << 0)))' failed in file bgpd.c, line 2173, function peer_delete
2019-08-18T07:58:44.832548-04:00 rch2-140-fwK2b bgpd[1791]: Backtrace for 11 stack frames:
2019-08-18T07:58:44.832942-04:00 rch2-140-fwK2b bgpd[1791]: [bt 0] /usr/lib/libfrr.so.0(zlog_backtrace+0x3a) [0x7f5503c7c31a]
2019-08-18T07:58:44.833311-04:00 rch2-140-fwK2b bgpd[1791]: [bt 1] /usr/lib/libfrr.so.0(_zlog_assert_failed+0x61) [0x7f5503c7c891]
2019-08-18T07:58:44.833684-04:00 rch2-140-fwK2b bgpd[1791]: [bt 2] /usr/lib/frr/bgpd(peer_delete+0x4d5) [0x1432ceea15]
2019-08-18T07:58:44.834095-04:00 rch2-140-fwK2b bgpd[1791]: [bt 3] /usr/lib/frr/bgpd(+0x430e9) [0x1432cfc0e9]
2019-08-18T07:58:44.834479-04:00 rch2-140-fwK2b bgpd[1791]: [bt 4] /usr/lib/frr/bgpd(bgp_event_update+0x121) [0x1432cfe1c1]
2019-08-18T07:58:44.834852-04:00 rch2-140-fwK2b bgpd[1791]: [bt 5] /usr/lib/frr/bgpd(+0x453f1) [0x1432cfe3f1]
2019-08-18T07:58:44.835388-04:00 rch2-140-fwK2b bgpd[1791]: [bt 6] /usr/lib/libfrr.so.0(thread_call+0x60) [0x7f5503c9e3c0]
2019-08-18T07:58:44.835829-04:00 rch2-140-fwK2b bgpd[1791]: [bt 7] /usr/lib/libfrr.so.0(frr_run+0xb8) [0x7f5503c79de8]
2019-08-18T07:58:44.836292-04:00 rch2-140-fwK2b bgpd[1791]: [bt 8] /usr/lib/frr/bgpd(main+0x229) [0x1432ce4a69]
2019-08-18T07:58:44.836729-04:00 rch2-140-fwK2b bgpd[1791]: [bt 9] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f550271bb45]
2019-08-18T07:58:44.837198-04:00 rch2-140-fwK2b bgpd[1791]: [bt 10] /usr/lib/frr/bgpd(+0x2cefc) [0x1432ce5efc]
2019-08-18T07:58:44.837670-04:00 rch2-140-fwK2b bgpd[1791]: Current thread function (bgp_holdtime_timer), scheduled from file bgp_fsm.c, line 380
This is the code:
bgp_reads_off(peer);
bgp_writes_off(peer);
assert(!CHECK_FLAG(peer->thread_flags, PEER_THREAD_WRITES_ON));
assert(!CHECK_FLAG(peer->thread_flags, PEER_THREAD_READS_ON));
The line crashing is the first assert. We know in bgp_writes_off we unset this flag:
void bgp_writes_off(struct peer *peer)
{
struct frr_pthread *fpt = bgp_pth_io;
assert(fpt->running);
thread_cancel_async(fpt->master, &peer->t_write, NULL);
THREAD_OFF(peer->t_generate_updgrp_packets);
UNSET_FLAG(peer->thread_flags, PEER_THREAD_WRITES_ON);
}
We also know that the keepalives are not being turned off until we call
bgp_fsm_change_status(peer, Deleted);
later in the function. We know that the keepalive pthread will
write to individual peers and issue a bgp_write_on(), which sets
this flag.
Modify the code base so that we explicitly turn off the keepalives
immediately before the turning of writes off.
Ticket: CM-26119
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
"show bgp l2vpn evpn neighbors <neighbor> [advertised-routes|routes]' did
not work due to various bugs. First, the command only accepted IPv4
addresses as valid neighbor ID, thereby rejecting unnumbered BGP and IPv6
neighbor address. Second, the SAFI was hardcoded to MPLS_VPN even though
we were passing the safi. Third, "all" made no sense in the command context
and to make the command uniform across all address families, I removed the
"all" keyword from the command.
Signed-off-by: Dinesh G Dutt <ddps4u@gmail.com>
Both of these hooks are necessary for proper operation of extensions
that need to latch on to a particular instance.
- without the delete hook, it's impossible to get rid of stale
references, leading to crashes with invalid instance pointers.
- the config-write hook is necessary because per-instance config needs
to be written inside the "router bgp" block to have the appropriate
context; adding a separate config node can't do that.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This code is not returned anywhere in the system as that bgp
is by default multiple-instance 'only' now. So remove
the last remaining bits of it from the code base.
Remove BGP_ERR_MULTIPLE_INSTANCE_USED too.
Make bgp_get explicitly return BGP_SUCCESS
instead of 0.
Remove the multi-instance error code too.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
A router-id change that isn't explicitly configured (a change
from zebra, for example) should not replace a configured vpn
RD/RT.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
the vrf_id parameter is replaced by struct vrf * parameter.
this impacts most of the daemons that look for an interface based on the
name and the vrf identifier.
Also, it fixes 2 lookup calls in zebra and sharpd, where the vrf_id was
ignored until now.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* When the bgp is being deleted and routes are in clear workqueue
and new aggregate address being allocated
* Added flag BGP_FLAG_DELETE_IN_PROGRESS in bgp structure to
bgp instance is being deleted
* When adding aggregate route check this flag and peer_self is valid
Signed-off-by: Soman K S <somanks@vmware.com>
The BGP_OPT_CONFIG_CISCO command could no longer be set
as such remove it from the system as a viable option to
be used.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Since we no-longer allow you to select multiple-instance
or not from the cli, let's completely remove the flag
as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
It doesn't make much sense for a hash function to modify its argument,
so const the hash input.
BGP does it in a couple places, those cast away the const. Not great but
not any worse than it was.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This fix aims to reduce the load on BGPD when certain
exisiting configurations are replayed.
Specifically, the fix prevents BGPD from processing
routes when the following already existing configurations
are replayed:
1) A match criteria is configured within a route-map.
2) When "call" is invoked within a route-map.
3) When a route-map is tied to a BGP neighbor.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
Prevent IPv6 routes received via a ibgp session with one of its own interface
ip as nexthop from getting installed in the BGP table.
Implemented IPV6 HASH table, where we need to add any ipv6 address as they
gets configured and delete them from the HASH table as the ipv6 addresses
get unconfigured. The above hash table is used to verify if any route learned
via BGP has nexthop which is equal to one of its its connected ipv6 interface.
Signed-off-by: Biswajit Sadhu sadhub@vmware.com
Co-authored-by: Donald Sharp <sharpd@cumulusnetworks.com>
Co-authored-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This makes the instance bearing the advertise-all-vni config option
register to zebra as the EVPN one, forwarding it the option.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
VRF route leak auto RD and RT uses router-id,
when a router-id changes for a bgp instance, change
associated vpn RD and RT values. Withdraw
old RD/RT routes from vpn and with new
RD/RT values advertise new routes to vpn.
One of the sceanrio is restarting frr:
A router-id change may not have reflected
for bgp vrf instance X, while import vrf X
under bgp vrf instance Y.
Once router-id changes for bgp VRF X,
change RD and RTs from export VRF and
imported VRFs. Readvertise routes with new
values to VPN.
Ticket:CM-24149
Reviewed By:CCR-8394
Testing Done:
Validated via configured multiple bgp VRF instances
and enable route leaks among them, restart frr
and all instance received correct RD and RT values.
Checked 'show bgp vrf all ipv4 unicast route-leak'
and vpn table 'show bgp ipv4 vpn all' output.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The "show bgp ipv6 summary" output displays incorrect number of peers count.
sonic# show bgp ipv6 summary
IPv6 Unicast Summary:
BGP router identifier 10.1.0.1, local AS number 65100 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 5, using 103 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2003::1 4 65099 0 0 0 0 0 never Active
2088::1 4 65100 0 0 0 0 0 never Active
3021::2 4 65100 0 0 0 0 0 never Active
Total number of neighbors 3
sonic#
In the above output, the peers count displays as 5 but the actual peer count is 3, i.e.. 3 neighbors are activated in ipv6 unicast address family.
Displayed peer count (5) is the number of the neighbors activated in a BGP instance.
Fix : Now the peers count displays the number of neighbors activated per afi/safi.
After Fix:
sonic# show bgp ipv6 summary
IPv6 Unicast Summary:
BGP router identifier 10.1.0.1, local AS number 65100 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 3, using 62 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2003::1 4 65099 0 0 0 0 0 never Active
2088::1 4 65100 0 0 0 0 0 never Active
3021::2 4 65100 0 0 0 0 0 never Active
Total number of neighbors 3
sonic#
Signed-off-by: Akhilesh Samineni <akhilesh.samineni@broadcom.com>
