use CHECK_FLAG
fix comment spaces
change zlog_debug to zlog_warn
safeguard on updated_route
added doc/developer/bmp.rst to subdir.am
other qol changes
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
moved loc-rib uptime field "bgp_rib_uptime" to struct bgp_path_info_extra for memory concerns
moved logic into bgp_route_update's callback bmp_route_update
written timestamp in per peer header
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
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>
Add the redistribute table/table-direct command in the
user guide.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
For now it includes only FQDN capability, because other capabilities can be
resend using specific knobs.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
With the deprecation of the global "bgp enforce-first-as" command back
in https://github.com/FRRouting/frr/pull/2259 the newly introduced
option to enable that setting on a specific peer was not documented.
This commit adds the necessary documentation and states the command's
default.
Signed-off-by: Manuel Schweizer <manuel.schweizer@cloudscale.ch>
Add the new command "show debugging labeltable" to show allocated label
chunks in the label table managed with label_manager.c
Signed-off-by: Farid Mihoub <farid.mihoub@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
requirements.txt was pinning sphinx at a very old version. This version
doesn't work in recent versions of Python; the new RTD configuration
made RTD respect our requirements file, breaking the build.
Signed-off-by: Quentin Young <qlyoung@qlyoung.net>
As of Sep 25 2023, RTD projects require config files to build. This
patch is necessary for docs to continue to build.
Signed-off-by: Quentin Young <qlyoung@qlyoung.net>
No such thing exists.
/root/frr/doc/user/ospfd.rst:624: WARNING: Cannot analyze code. No Pygments lexer found for "frr".
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
/root/frr/doc/user/ospfd.rst:609: WARNING: Bullet list ends without a blank line; unexpected unindent.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Provide a paragraph for srv6 multiple segs SIDs in documentation
to describe the multiple segs functionality.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
This patch includes:
* Implementation of RFC 5709 support in OSPF. Using
openssl library and FRR key-chain,
one can use SHA1, SHA256, SHA384, SHA512 and
keyed-MD5( backward compatibility with RFC 2328) HMAC algs.
* Updating documentation of OSPF
* add topotests for new HMAC algorithms
Signed-off-by: Mahdi Varasteh <varasteh@amnesh.ir>
Subset: doc and tests
doc
PBR section updated with new fields and some copy-editing
tests
pbr_topo1: ensure new vlan fields arrive at zebra
Changes by:
Josh Werner <joshuawerner@mitre.org>
Eli Baum <ebaum@mitre.org>
G. Paul Ziemba <paulz@labn.net>
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Useful to have it for datacenter profile only, disabled for traditional.
If the peer is not established or established, but has no description set,
we will show the FRR version instead, which is kinda handy to have instead of
nothing.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
User can now use 'show ip ospf route detail' command to distinguish
intra-area stub network and transit network.
Transit network will be displayed as 'N T prefix ...'.
NOTICE: Json output format has been changed, intra-area transit networks
will have a new attribute 'transit' and value is 'true'.
And 'adv' (means advertise router) change to 'advertisedRouter'.
Example output:
bsp-debianrt-exp1# show ip ospf route detail
Codes: N - network T - transitive
IA - inter-area E - external route
D - destination R - router
============ OSPF network routing table ============
N T 10.0.0.0/24 [32] area: 0.0.0.0
via 192.168.124.67, ens192
adv 10.0.0.5
N 10.0.30.0/24 [33] area: 0.0.0.0
via 192.168.124.67, ens192
adv 10.0.0.5
...
Signed-off-by: Zhiyuan Wan <h@iloli.bid>
The yang model does not handle the table identifier in IS-IS.
For each redistributed each address family, a new list of
table elements is added to store the table identifier to
redistribute, and also the optional metric and route-map values
for each table identifier.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There is no route-map set action to replace any ASN,
or a part of an ASN, with a configured ASN.
The current commit adds a new command to use a configured
ASN as replacement, instead of using the local as number.
> set as-path replace any 65500
Update the 'bgp_set_aspath_replace' test.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add support for "[no] ip ospf capbility opaque" at the interface
level with the default being capability opaque enabled. The command
"no ip ospf capability opaque" will disable opaque LSA database
exchange and flooding on the interface. A change in configuration
will result in the interface being flapped to update our options
for neighbors but no attempt will be made to purge existing LSAs
as in dense topologies, these may received by neighbors through
different interfaces.
Topotests are added to test both the configuration and the LSA
opaque flooding suppression.
Signed-off-by: Acee <aceelindem@gmail.com>
It is not possible to flush all the incoming as-path list
from a given BGP update.
Add a route-map set command to remove all as-paths
from a given AS path. Add the necessary tests.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Looks like people don't find what does it mean (Policy) at first shot, let's
try giving more hints here.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Currently, delayed reflooding on P2MP interfaces for LSAs received
from neighbors on the interface is unconditionally (see commit
c706f0e32b). In some cases, this
change wasn't desirable and this feature makes delayed reflooding
configurable for P2MP interfaces via the CLI command:
"ip ospf network point-to-multipoint delay-reflood" in interface
submode.
Signed-off-by: Acee <aceelindem@gmail.com>
`ccls` needs information from FRR build configuration to work,
so allow creation of a custom ccls config during autoconf.
Paraphrasing the doc entry: ccls is a very powerful tool that allows
dev environments to provide sophisticated IDE functionality, e.g.,
semantically aware jumps and code refactoring...
Signed-off-by: Christian Hopps <chopps@labn.net>
This command makes unplanned GR more reliable by manipulating the
sending of Grace-LSAs and Hello packets for a certain amount of time,
increasing the chance that the neighboring routers are aware of
the ongoing graceful restart before resuming normal OSPF operation.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In practical terms, unplanned GR refers to the act of recovering
from a software crash without affecting the forwarding plane.
Unplanned GR and Planned GR work virtually the same, except for the
following difference: on planned GR, the router sends the Grace-LSAs
*before* restarting, whereas in unplanned GR the router sends the
Grace-LSAs immediately *after* restarting.
For unplanned GR to work, ospf6d was modified to send a
ZEBRA_CLIENT_GR_CAPABILITIES message to zebra as soon as GR is
enabled. This causes zebra to freeze the OSPF routes in the RIB as
soon as the ospf6d daemon dies, for as long as the configured grace
period (the defaults is 120 seconds). Similarly, ospf6d now stores in
non-volatile memory that GR is enabled as soon as GR is configured.
Those two things are no longer done during the GR preparation phase,
which only happens for planned GRs.
Unplanned GR will only take effect when the daemon is killed
abruptly (e.g. SIGSEGV, SIGKILL), otherwise all OSPF routes will be
uninstalled while ospf6d is exiting. Once ospf6d starts, it will
check whether GR is enabled and enter in the GR mode if necessary,
sending Grace-LSAs out all operational interfaces.
One disadvantage of unplanned GR is that the neighboring routers
might time out their corresponding adjacencies if ospf6d takes too
long to come back up. This is especially the case when short dead
intervals are used (or BFD). For this and other reasons, planned
GR should be preferred whenever possible.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In practical terms, unplanned GR refers to the act of recovering
from a software crash without affecting the forwarding plane.
Unplanned GR and Planned GR work virtually the same, except for the
following difference: on planned GR, the router sends the Grace-LSAs
*before* restarting, whereas in unplanned GR the router sends the
Grace-LSAs immediately *after* restarting.
For unplanned GR to work, ospf6d was modified to send a
ZEBRA_CLIENT_GR_CAPABILITIES message to zebra as soon as GR is
enabled. This causes zebra to freeze the OSPF routes in the RIB as
soon as the ospfd daemon dies, for as long as the configured grace
period (the defaults is 120 seconds). Similarly, ospfd now stores in
non-volatile memory that GR is enabled as soon as GR is configured.
Those two things are no longer done during the GR preparation phase,
which only happens for planned GRs.
Unplanned GR will only take effect when the daemon is killed
abruptly (e.g. SIGSEGV, SIGKILL), otherwise all OSPF routes will
be uninstalled while ospfd is exiting. Once ospfd starts, it will
check whether GR is enabled and enter in the GR mode if necessary,
sending Grace-LSAs out all operational interfaces.
One disadvantage of unplanned GR is that the neighboring routers
might time out their corresponding adjacencies if ospfd takes too
long to come back up. This is especially the case when short dead
intervals are used (or BFD). For this and other reasons, planned
GR should be preferred whenever possible.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Until now, the bgp local paths were using the default null label
defined. It was not possible to select the null label for the ipv4
or the ipv6 address families.
This commit addresses this issues by adding two extra-parameters
to the BGP labeled-unicast command.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Let users know about the RIP BFD integration commands and increment the
used RFCs reference.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Debugging-isis tag was moved.
Move it to right place.
Fixes: 9389175b75 ("doc: add documentation for IS-IS Segment Routing")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
1. Added interface name, group address and detail option to existing
"show ip igmp groups" so that user can retrieve all the groups
or a particular group for an interface. Detail option shows the source
information for the group. With that, the show command
looks like:
"show ip igmp [vrf NAME$vrf_name] groups [INTERFACE$ifname [GROUP$grp_str]] [detail$detail] [json$json]"
2. Changed pim_cmd_lookup_vrf() to return empty JSON if VRF is not present
3. Changed "detail" option to print non pretty JSON
4. Added interface name and group address to existing
"show ip igmp sources" so that user can retrieve all the sources for
all the groups or, all the sorces for a particular group for an
interface. With that, the show command looks like:
"show ip igmp [vrf NAME$vrf_name] sourcess [INTERFACE$ifname [GROUP$grp_str]] [json$json]"
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
In BGP labeled unicast address-family, it is not possible to
send explicit-null label values with redistributed or network
declared prefixes.
A new CLI command is introduced:
> [no] bgp labeled-unicast explicit-null
When used, the explicit-null value for IPv4 ('0' value) or
IPv6 ('2' value) will be used.
It is necessary to reconfigure the networks or the
redistribution in order to inherit this new behaviour.
Add the documentation.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Since mgmtd no longer supports the frr_startup.json, removing the
documentation related to that. Proper documentation will be added
when/if the frr_startup.json is ever supported.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
Implement NSSA address ranges as specified by RFC 3101:
NSSA border routers may be configured with Type-7 address ranges.
Each Type-7 address range is defined as an [address,mask] pair. Many
separate Type-7 networks may fall into a single Type-7 address range,
just as a subnetted network is composed of many separate subnets.
NSSA border routers may aggregate Type-7 routes by advertising a
single Type-5 LSA for each Type-7 address range. The Type-5 LSA
resulting from a Type-7 address range match will be distributed to
all Type-5 capable areas.
Syntax:
area A.B.C.D nssa range A.B.C.D/M [<not-advertise|cost (0-16777215)>]
Example:
router ospf
router-id 1.1.1.1
area 1 nssa
area 1 nssa range 172.16.0.0/16
area 1 nssa range 10.1.0.0/16
!
Since regular area ranges and NSSA ranges have a lot in common,
this commit reuses the existing infrastructure for area ranges as
much as possible to avoid code duplication.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add the "default-information-originate" option to the "area X nssa"
command. That option allows the origination of Type-7 default routes
on NSSA ABRs and ASBRs.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This commit adds user documentation for the new MGMT daemon and
new FRR Management Framework.
Co-authored-by: Yash Ranjan <ranjany@vmware.com>
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Co-authored-by: Ujwal P <ujwalp@vmware.com>
Signed-off-by: Pushpasis Sarkar <pushpasis@gmail.com>
It's not allowed to install routes with zero distance, let's disallow this
for route-maps as well.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There are some specific edge-cases when is a need to run FRR and another FRR
and/or another BGP implementation on the same box. Relaxing 127.0.0.0/8 for
this case might be reasonable.
An example below peering via 127.0.0.0/8 between FRR and GoBGP:
```
% ss -ntlp | grep 179
LISTEN 0 4096 127.0.0.1:179 0.0.0.0:*
LISTEN 0 128 127.0.0.2:179 0.0.0.0:*
% grep 127.0.0.2 /etc/frr/daemons
bgpd_options=" -A 127.0.0.1 -l 127.0.0.2"
% grep local /etc/gobgp/config.toml
local-address-list = ["127.0.0.1"]
donatas-pc# sh ip bgp summary
IPv4 Unicast Summary (VRF default):
BGP router identifier 192.168.10.17, local AS number 65001 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 725 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
127.0.0.1 4 65002 7 7 0 0 0 00:02:02 0 0 N/A
Total number of neighbors 1
donatas-pc#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This option is useful to dump detailed information about the LSDB using
a single command (instead of one command per LSA type).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Combine all variations of this command into a single DEFPY to
improve maintainability. No behavioral changes intended.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
