This is helpful for migrations, etc.
The neighbor is configured with:
```
router bgp 65000
neighbor X local-as 65001 no-prepend replace-as dual-as
```
Neighbor X can use either 65000, or 65001 to peer with.
Closes: https://github.com/FRRouting/frr/issues/13928
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
```
ton# sh ip bgp peer-group
BGP peer-group pg-a
Peer-group type is auto
Configured address-families: IPv4 Unicast;
BGP peer-group pg-e, remote AS 0
Peer-group type is external
Configured address-families: IPv4 Unicast;
BGP peer-group pg-i, remote AS 65001
Peer-group type is internal
Configured address-families: IPv4 Unicast;
ton#
```
`auto` should be handled accordingly.
Fixes: 0dfe25697f ("bgpd: Implement neighbor X remote-as auto")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Currently, when SRv6 is enabled in BGP, BGP requests a locator chunk
from Zebra. Zebra assigns a locator chunk to BGP, and then BGP can
allocate SIDs from the locator chunk.
Recently, the implementation of SRv6 in Zebra has been improved, and a
new API has been introduced for obtaining/releasing the SIDs.
Now, the daemons no longer need to request a chunk.
Instead, the daemons interact with Zebra to obtain information about the
locator and subsequently to allocate/release the SIDs.
This commit extends BGP to use the new SRv6 API. In particular, it
removes the chunk throughout the BGP code and modifies BGP to
request/save/advertise the locator instead of the chunk.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
If the neighbor is not configured with `neighbor X default-originate route-map ...`,
then this timer is useless.
Change the logic to be it disabled by default, but enabled automatically once the
route-map is configured for default-originate command.
Automatically assigned timer value is as before, 5 seconds.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
```
==1145965==ERROR: AddressSanitizer: heap-use-after-free on address 0x6030007159c0 at pc 0x55ade8d962d1 bp 0x7ffec4ce74c0 sp 0x7ffec4ce74b0
READ of size 8 at 0x6030007159c0 thread T0
0 0x55ade8d962d0 in no_router_bgp bgpd/bgp_vty.c:1701
1 0x7efe5aed19ed in cmd_execute_command_real lib/command.c:1002
2 0x7efe5aed1da3 in cmd_execute_command lib/command.c:1061
3 0x7efe5aed2303 in cmd_execute lib/command.c:1227
4 0x7efe5af6c023 in vty_command lib/vty.c:616
5 0x7efe5af6d2d2 in vty_execute lib/vty.c:1379
6 0x7efe5af77df2 in vtysh_read lib/vty.c:2374
7 0x7efe5af64c9b in event_call lib/event.c:1996
8 0x7efe5af03887 in frr_run lib/libfrr.c:1232
9 0x55ade8cd9850 in main bgpd/bgp_main.c:555
10 0x7efe5aa29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
11 0x7efe5aa29e3f in __libc_start_main_impl ../csu/libc-start.c:392
12 0x55ade8cdc314 in _start (/usr/lib/frr/bgpd+0x16f314)
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
json_peers is allocated in the above if statement block
for json but is not freed in this code path. Noticed
by running Address Sanitizer.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fixes the crash:
```
(gdb) bt
0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=124583315603008) at ./nptl/pthread_kill.c:44
1 __pthread_kill_internal (signo=11, threadid=124583315603008) at ./nptl/pthread_kill.c:78
2 __GI___pthread_kill (threadid=124583315603008, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
3 0x0000714ed0242476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
4 0x0000714ed074cfb7 in core_handler (signo=11, siginfo=0x7ffe6d9792b0, context=0x7ffe6d979180) at lib/sigevent.c:258
5 <signal handler called>
6 0x000060f55e33ffdd in route_table_get_info (table=0x0) at ./lib/table.h:177
7 0x000060f55e340053 in bgp_dest_table (dest=0x60f56dabb840) at ./bgpd/bgp_table.h:156
8 0x000060f55e340c9f in is_route_injectable_into_vpn (pi=0x60f56dbc4a60) at ./bgpd/bgp_mplsvpn.h:331
9 0x000060f55e34507c in vpn_leak_from_vrf_update (to_bgp=0x60f56da52070, from_bgp=0x60f56da75af0, path_vrf=0x60f56dbc4a60) at bgpd/bgp_mplsvpn.c:1575
10 0x000060f55e346657 in vpn_leak_from_vrf_update_all (to_bgp=0x60f56da52070, from_bgp=0x60f56da75af0, afi=AFI_IP) at bgpd/bgp_mplsvpn.c:2028
11 0x000060f55e340c10 in vpn_leak_postchange (direction=BGP_VPN_POLICY_DIR_TOVPN, afi=AFI_IP, bgp_vpn=0x60f56da52070, bgp_vrf=0x60f56da75af0) at ./bgpd/bgp_mplsvpn.h:310
12 0x000060f55e34a692 in vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3737
13 0x000060f55e3d91fc in router_bgp (self=0x60f55e5cbc20 <router_bgp_cmd>, vty=0x60f56e2d7660, argc=3, argv=0x60f56da19830) at bgpd/bgp_vty.c:1601
14 0x0000714ed069ddf5 in cmd_execute_command_real (vline=0x60f56da32a80, vty=0x60f56e2d7660, cmd=0x0, up_level=0) at lib/command.c:1002
15 0x0000714ed069df6e in cmd_execute_command (vline=0x60f56da32a80, vty=0x60f56e2d7660, cmd=0x0, vtysh=0) at lib/command.c:1061
16 0x0000714ed069e51e in cmd_execute (vty=0x60f56e2d7660, cmd=0x60f56dbf07d0 "router bgp 100\n", matched=0x0, vtysh=0) at lib/command.c:1227
17 0x0000714ed076faa0 in vty_command (vty=0x60f56e2d7660, buf=0x60f56dbf07d0 "router bgp 100\n") at lib/vty.c:616
18 0x0000714ed07719c4 in vty_execute (vty=0x60f56e2d7660) at lib/vty.c:1379
19 0x0000714ed07740f0 in vtysh_read (thread=0x7ffe6d97c700) at lib/vty.c:2374
20 0x0000714ed07685c4 in event_call (thread=0x7ffe6d97c700) at lib/event.c:1995
21 0x0000714ed06e3351 in frr_run (master=0x60f56d1d2e40) at lib/libfrr.c:1232
22 0x000060f55e2c4b44 in main (argc=7, argv=0x7ffe6d97c978) at bgpd/bgp_main.c:555
(gdb)
```
Fixes https://github.com/FRRouting/frr/issues/16484
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If we send a notification, there is no point setting the last_reset, because
bgp_notify_send() sets last_reset to PEER_DOWN_NOTIFY_SEND (almost everywhere).
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Auto created VRF instances does not have any config, so it's not relevant
depending on them.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When using e.g. `adverise-all-vni`, and/or `import vrf ...`, the VRF instance
is created with a default's VRF ASN and tagged as AUTO_VRF. We MUST skip them
here also.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If we create a new BGP instance (in this case VRF instance), it MUST be marked
as auto created, to avoid bgpd changing VRF instance's ASN to the default VRF's.
That's because of the ordering when FRR reload is happening.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In some cases (large scale) it's desired to avoid changing configurations, but
let the BGP to automatically handle ASN changes.
`auto` means the peering can be iBGP or eBGP. It will be automatically detected
and adjusted from the OPEN message.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add a new start option "-K" to libfrr to denote a graceful start,
and use it in zebra and bgpd.
zebra will use this option to denote a planned FRR graceful restart
(supporting only bgpd currently) to wait for a route sync completion
from bgpd before cleaning up old stale routes from the FIB. An optional
timer provides an upper-bounds for this cleanup.
bgpd will use this option to denote either a planned FRR graceful
restart or a bgpd-only graceful restart, and this will drive the BGP
GR restarting router procedures.
Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
Introduce BGP-wide flags to denote if BGP has started gracefully
and GR is in progress or not. Use this for setting of the R-bit in
the GR capability, and not a timer which is set for any new
instance creation. Mark graceful restart is complete when the
deferred path selection has been done and route sync with zebra as
well as deferred EOR advertisement has been initiated.
Introduce a function to check on F-bit setting rather than just
base it on configuration.
Subsequent commits will extend these functionalities.
Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
Streamline the BGP graceful-restart configuration at the global and
peer level some more. Similar to many other neighbor capability
parameters like MP and ENHE, reset the session immediately upon a
change to the configuration. This will be more aligned with the
transactional UI model also and will not require a separate 'clear'
command to be executed.
Note: Peer-group graceful-restart configuration is not yet supported.
Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
Add support for a BGP-wide setting for graceful restart modes and
parameters. This setting will apply to all BGP peers across all BGP
instances, but per-neighbor configuration can override it.
Per-instance configuration is disallowed if the BGP-wide setting
is in effect.
Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
The default DSCP used for BGP connections is CS6. The DSCP value is
not part of the TCP header.
When setting the IP_TOS or IPV6_TCLASS socket options, the argument
is not the 6-bit DSCP value, but an 8-bit value for the former IPv4
Type of Service field or IPv6 Traffic Class field, respectively.
Fixes: 425bd64be8 ("bgpd: Allow bgp to control the DSCP session TOS value")
Signed-off-by: David Ward <david.ward@ll.mit.edu>
When a bgp neighbor graceful-restart config mode change
is applied, after accepting the config if it does not
take effect instead of throwing vtysh error code,
return the success to vtysh and warn the user.
The debug log is already present at critical code point
where GR failure is seen during config apply.
Ticket: #3761481
Testing Done:
root@tor-1:# vtysh -c 'config t' -c 'router bgp 65564
vrf VRF2' -c 'neighbor 20.1.1.1 graceful-restart'
As part of configuring graceful-restart, capability send to zebra failed
root@tor-1:# echo $?
0
Signed-off-by: Chirag Shah <chirag@nvidia.com>
When we are cycling through all peers and looking for
dampening data to dump, do not consider non-configed
peers( dopplegangers ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Additional cli commands to add dampening profiles to peers / peer groups
and functions to save dampening configurations.
Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
Description:
-----
Deleting a peer group also deletes its associated BGP listen range.
This behaviour is undesired as it could cause unintended configuration changes.
Fix :
-----
-Do not allow peer group deletion until they are no longer associated with any listen range.
-Check the count of listen ranges attached to the group.
If any listen ranges are found, returns a configuration warning, preventing the deletion.
Signed-off-by: Pooja Rathore <rathorepo@vmware.com>
Today, with the following bgp instance configured, the
local VRF label is allocated even if it is not used.
> router bgp 65500 vrf vrf1
> address-family ipv4 unicast
> label vpn export allocation-mode per-nexthop
> label vpn export auto
> rd vpn export 444:1
> rt vpn both 52:100
> export vpn
> import vpn
The 'show mpls table' indicates that the 16 label value
is allocated, but never used in the exported prefixes.
> r1# show mpls table
> Inbound Label Type Nexthop Outbound Label
> -----------------------------------------------------
> 16 BGP vrf1 -
> 17 BGP 192.168.255.13 -
> 18 BGP 192.0.2.12 -
> 19 BGP 192.0.2.11 -
Fix this by only allocating new label values when really
used. Consequently, only 3 labels will be allocated instead
of previously 4.
> r1# show mpls table
> Inbound Label Type Nexthop Outbound Label
> -----------------------------------------------------
> 16 BGP 192.168.255.13 -
> 17 BGP 192.0.2.11 -
> 18 BGP 192.0.2.12 -
Fixes: 577be36a41 ("bgpd: add support for l3vpn per-nexthop label")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The 'table-direct' redistribute command is available for ipv4 unicast but
not for ipv6 unicast.
Add the command to ipv6 unicast as well.
Fixes: b6367f8460 ("bgpd: add redistribute table-direct support")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Prompt nothing for an empty (and failed) operation. Take
`bgp graceful-restart` as an example:
Before:
```
anlan(config-router)# bgp graceful-restart
Graceful restart configuration changed, reset all peers to take effect
anlan(config-router)# bgp graceful-restart
Graceful restart configuration changed, reset all peers to take effect
anlan(config-router)#
```
After:
```
anlan(config-router)# bgp graceful-restart
Graceful restart configuration changed, reset all peers to take effect
anlan(config-router)# bgp graceful-restart
anlan(config-router)#
```
Signed-off-by: anlan_cs <anlan_cs@tom.com>
The 'show bgp neighbors' output appends additional lines after GR mode
helpers.
> # show bgp neighbors
> [..]
> End-of-RIB received: IPv4 VPN
> Local GR Mode: Helper*
>
> Remote GR Mode: Helper
>
> R bit: True
>
Fix this by not appending the extra line feed.
> # show bgp neighbors
> [..]
> End-of-RIB received: IPv4 VPN
> Local GR Mode: Helper*
> Remote GR Mode: Helper
> R bit: True
Fixes: 0e4e879b40 ("bgpd: fix silly format string SNAFU")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This will allow a consistency of approach to adding/removing
pi's to from the workqueue for processing as well as properly
handling the dest->info pi list more appropriately.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Dynamic capability provides more value without resetting the sessions for some
important other capabilities to exchange, like: graceful-restart, addpath, orf,
fqdn, etc.
Since we support it already, enable it by default.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
The capability should be untouched, and send 0 (unlimited) instead.
Otherwise, we miss the capability and things are broken later until the
session reset.
Fixes: 72f0e06824 ("bgpd: Implement Paths-Limit capability")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
It's very annoying when testing and instead of looking for true/false, you
have to check if the field exists.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If `bgp default software-version-capability` is enabled, allow unsetting this
for a single neighbor also.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
By default, iBGP and eBGP-OAD peers exchange RPKI extended community by default.
Add a command to disable sending RPKI extended community if needed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
cisco routers are not dealing fairly whith unsupported capabilities.
When a cisco router receive an unsupported capabilities it reset the
negociation without notifying the unmatching capability as described in
RFC2842.
Cisco suggest the use of
neighbor x.x.x.x capability fqdn
to avoid the use of fqdn in open message.
this new command is to remove the use of fqdn capability in the
open message with the peer "x.x.x.x".
Link: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/116189-problemsolution-technology-00.pdf
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
Before:
```
ton# sh bgp summary
IPv4 Unicast Summary (VRF default):
BGP router identifier 0.0.0.2, local AS number 65001 VRF default vrf-id 0
```
After:
```
ton# sh bgp summary
IPv4 Unicast Summary:
BGP router identifier 0.0.0.2, local AS number 65001 VRF default vrf-id 0
```
After 5be4ee9634, we don't need to duplicate that
info.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The vrf name was not being displayed in this output.
New output:
eva# show bgp vrf all ipv4 uni summ
BGP router identifier 0.0.0.0, local AS number 99 VRF RED vrf-id 14
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 20 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.168.119.1 4 0 0 0 0 0 0 never Active 0 N/A
Total number of neighbors 1
BGP router identifier 0.0.0.0, local AS number 99 VRF GREEN vrf-id 15
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 20 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.168.119.1 4 0 0 0 0 0 0 never Active 0 N/A
Total number of neighbors 1
BGP router identifier 192.168.122.1, local AS number 99 VRF default vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 20 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.168.119.1 4 0 0 0 0 0 0 never Active 0 N/A
Total number of neighbors 1
BGP router identifier 0.0.0.0, local AS number 99 VRF GrEEn vrf-id -1
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 20 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.168.119.1 4 0 0 0 0 0 0 never Idle 0 N/A
Total number of neighbors 1
eva#
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Implement proper memory cleanup for SRv6 functions and locator chunks to prevent potential memory leaks.
The list callback deletion functions have been set.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.asan.bgpd.4180
=================================================================
==4180==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 544 byte(s) in 2 object(s) allocated from:
#0 0x7f8d176a0d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f8d1709f238 in qcalloc lib/memory.c:105
#2 0x55d5dba6ee75 in sid_register bgpd/bgp_mplsvpn.c:591
#3 0x55d5dba6ee75 in alloc_new_sid bgpd/bgp_mplsvpn.c:712
#4 0x55d5dba6f3ce in ensure_vrf_tovpn_sid_per_af bgpd/bgp_mplsvpn.c:758
#5 0x55d5dba6fb94 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:849
#6 0x55d5dba7f975 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:299
#7 0x55d5dba7f975 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3704
#8 0x55d5dbbb6c66 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3164
#9 0x7f8d1716f08a in zclient_read lib/zclient.c:4459
#10 0x7f8d1713f034 in event_call lib/event.c:1974
#11 0x7f8d1708242b in frr_run lib/libfrr.c:1214
#12 0x55d5db99d19d in main bgpd/bgp_main.c:510
#13 0x7f8d160c5c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 296 byte(s) in 1 object(s) allocated from:
#0 0x7f8d176a0d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f8d1709f238 in qcalloc lib/memory.c:105
#2 0x7f8d170b1d5f in srv6_locator_chunk_alloc lib/srv6.c:135
#3 0x55d5dbbb6a19 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3144
#4 0x7f8d1716f08a in zclient_read lib/zclient.c:4459
#5 0x7f8d1713f034 in event_call lib/event.c:1974
#6 0x7f8d1708242b in frr_run lib/libfrr.c:1214
#7 0x55d5db99d19d in main bgpd/bgp_main.c:510
#8 0x7f8d160c5c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
The MTYPE_BGP memory type was being over used as
both the handler for the bgp instance itself as
well as memory associated with name strings.
Let's separate out the two.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The headers associated with netlink code
really only belong in those that need it.
Move these headers out of lib/zebra.h and
into more appropriate places. bgp's usage
of the RT_TABLE_XXX defines are probably not
appropriate and will be cleaned up in future
commits.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
It's been for a while disabled by default, but this seems reasonable to flip it.
We had `bgp enforce-first-as` as a global BGP knob to enable/disable this
behavior globally, later we introduced `enforce-first-as` per neighbor, with disabled
by default. Now let's enable this by default by bringing a global `bgp enforce-first-as`
command back.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There is no cli command to prevent the router to send traps
implemented in the rfc4273. If not done, when introducing
the traps from bgp4v2mib, traps will be send for each of
the two mibs: there will be redundancy in the sent information.
Add a new command:
- [no] bgp snmp traps rfc4273
Using this command will allow or not the notification of
the following traps:
- bgpEstablishedNotification
- bgpBackwardTransNotification
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
Add the 'redistribute table-direct' command under the bgp address-family
node. Handle the table-direct support wherever needed in the BGP code.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
For instance, it's not possible to resend FQDN capability without resetting
the session, so let's create some more elegant way to do that.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add an ability to enable/disable ORF capability dynamically without tearing
down the session.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Today, when configuring BGP L3VPN mpls, the operator may
use that command to hardset a label value:
> router bgp 65500 vrf vrf1
> address-family ipv4 unicast
> label vpn export <hardset_label_value>
Today, BGP uses this value without checks, leading to potential
conflicts with other control planes like LDP. For instance, if
LDP initiates with a label chunk of [16;72] and BGP also uses the
50 label value, a conflict arises.
The 'label manager' service in zebra oversees label allocations.
While all the control plane daemons use it, BGP doesn't when a
hardset label is in place.
This update fixes this problem. Now, when a hardset label is set for
l3vpn export, a request is made to the label manager for approval,
ensuring no conflicts with other daemons. But, this means some existing
BGP configurations might become non-operational if they conflict with
labels already allocated to another daemon but not used.
note: Labels below 16 are reserved and won't be checked for consistency
by the label manager.
Fixes: ddb5b4880b ("bgpd: vpn-vrf route leaking")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The original 'bgp label vpn export' code is confusing,
the 'no form' actions are mixed with the positive form.
Fix this by rewriting the code.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
Changing Addpath type, and or disabling RX (receiving) flag, we can do this
without tearing down the session, and using dynamic capabilities.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add the "show bgp link-state link-state" following commands:
> r3# show bgp link-state link-state ?
> <cr>
> all Display the entries for all address families
> detail-routes Display detailed version of all routes
> json JavaScript Object Notation
> neighbors Detailed information on TCP and BGP neighbor connections
> regexp Display routes matching the AS path regular expression
> summary Summary of BGP neighbor status
> version Display prefixes with matching version numbers
> wide Increase table width for longer prefixes
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add the "bgp default link-state" command to the "router bgp" context.
> router bgp 65000
> bgp default link-state
When this command is set, the "link-state/link-state" AFI/SAFI is
activated on all neighbors that are directly specified within the
"router bgp" unless explicitly deactivated:
> router bgp 65000
> bgp default link-state
> neighbor 10.0.0.1 remote-as 65001
> address-family link-state link-state
> no neighbor 10.0.0.1 activate
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
To show the TCP MSS value per neighbor you have to configure it, otherwise you
don't see the actual value.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
following crash occurs:
at ./nptl/pthread_kill.c:44
at ./nptl/pthread_kill.c:78
at ./nptl/pthread_kill.c:89
context=0x7ffd06d3d300)
at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:246
length=0x7ffd06d3da88, exact=1, var_len=0x7ffd06d3da90, write_method=<optimized out>)
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_snmp_bgp4v2.c:364
vp=vp@entry=0x7f7c88b584c0 <bgpv2_variables>, vp_len=vp_len@entry=102,
ename=ename@entry=0x7f7c88b58440 <bgpv2_trap_oid>, enamelen=enamelen@entry=8,
name=name@entry=0x7f7c88b58480 <bgpv2_oid>, namelen=namelen@entry=7,
iname=0x7ffd06d3e7b0, index_len=1, trapobj=0x7f7c88b53b80 <bgpv2TrapBackListv6>,
trapobjlen=6, sptrap=2 '\002')
at /build/make-pkg/output/_packages/cp-routing/src/lib/agentx.c:382
vp_len=vp_len@entry=102, ename=ename@entry=0x7f7c88b58440 <bgpv2_trap_oid>,
enamelen=enamelen@entry=8, name=name@entry=0x7f7c88b58480 <bgpv2_oid>,
namelen=namelen@entry=7, iname=0x7ffd06d3ec30, inamelen=16,
trapobj=0x7f7c88b53b80 <bgpv2TrapBackListv6>, trapobjlen=6, sptrap=2 '\002')
at /build/make-pkg/output/_packages/cp-routing/src/lib/agentx.c:298
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_snmp_bgp4v2.c:1496
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_fsm.c:48
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_fsm.c:1314
event=Receive_NOTIFICATION_message)
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_fsm.c:2665
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:3129
at /build/make-pkg/output/_packages/cp-routing/src/lib/event.c:1979
at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1213
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:510
it's due to function bgpv2PeerErrorsTable returning
return SNMP_STRING(msg_str);
with msg_str NULL rather the string ""
this commit avoid the issue.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
The 'redistribute table' command can be used by configuration on a
non default BGP instance, but this command does not work for multiple
reasons:
- The route entries configured on a given table are always configured
from the default vrf. This constraint prevents from redistributing a
prefix from the default vrf to an other non default bgp instance.
- The importation of route entries requires 'ip import-table' on vrfs
and this command is not available
Fix this by preventing from configuring this kind of redistribution
on non default bgp instances.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
LLGR stale time is exchanged using OPEN messages. In order to
reduce stal time before doing an actual graceful restart + LLGR, it might be useful
to increase the time, but this is not possible without resetting the session.
With this change, it's possible to send dynamic capability with a new value, and
GR will respect a new reset time value when LLGR kicks in.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
