| Age | Commit message (Collapse) | Author |
|---|
|
tools: fix reload script for SRv6 locators and formats
|
|
Current code implementation does not have a "no" form of handling for
the following commands under segment-routing srv6
- no formats
- no locators
- no prefix <> under locator XYZ
Fix the handling of segment-routing srv6 locators and formats commands
- Ignore "no formats" and "no locators" command
- replace "no prefix" under locator XYZ as "no locator XYZ" as prefix
is a mandatory property of locator
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
|
|
Adding a `-N` pathspace option to the generate_support_bundle.py
to support FRR running in a non-default namespace with a prefix
on the config/socket options.
The same pathspace will be prepended to the output log files (if
specified)
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
|
|
Clean up -Wshadow warnings in these components
Signed-off-by: Mark Stapp <mjs@cisco.com>
|
|
Adding option --logfile to specify a different logfile instead of
the default /var/log/frr/frr-reload.log
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
|
|
```
[...]
segment-routing
srv6
static-sids
sid fcbb:bbbb:1::/48 locator MAIN behavior uN
sid fcbb:bbbb:1:fe10::/64 locator MAIN behavior uDT4 vrf Vrf10
sid fcbb:bbbb:1:fe20::/64 locator MAIN behavior uDT6 vrf Vrf20
sid fcbb:bbbb:1:fe30::/64 locator MAIN behavior uDT46 vrf Vrf30
sid fcbb:bbbb:1:fe40::/64 locator MAIN behavior uA interface sr0 nexthop 2001::2
[...]
```
When the user has a configuration like the one above and runs the
command `frr-reload.py --reload`, the following error occurs:
```
[1129654|mgmtd] sending configuration
line 17: % Unknown command[76]: sid fcbb:bbbb:1::/48 locator MAIN behavior uN
line 23: % Unknown command[76]: sid fcbb:bbbb:1:fe10::/64 locator MAIN behavior uDT4 vrf Vrf10
line 29: % Unknown command[76]: sid fcbb:bbbb:1:fe20::/64 locator MAIN behavior uDT6 vrf Vrf20
line 35: % Unknown command[76]: sid fcbb:bbbb:1:fe30::/64 locator MAIN behavior uDT46 vrf Vrf30
line 41: % Unknown command[76]: sid fcbb:bbbb:1:fe40::/64 locator MAIN behavior uA interface sr0 nexthop 2001::2
```
The problem is that in `frr-reload-py` all commands that start a new
multi-line context must be included in the `ctx_keyword` dictionary.
However, the `static-sids` command is not part of the `ctx_keyword`
dictionary.
This commit fixes the problem by adding `static-sids` to `ctx_keyword`.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
|
|
tools: add logfmt option for frr-reload.py
|
|
Add the option of printing logs in logfmt format.
Additional machine readable information can be printed via the `extra`
argument.
Example:
```python
log.debug("exit context"), extra={"line": line, "ctx_keys": ctx_keys})
log.error(f"Failed to execute command {' '.join(cmd)}", extra={"cmd": cmd})
```
Signed-off-by: Giovanni Tataranni <g.tataranni@gmail.com>
|
|
watchfrr is currently being started with $frr_global_options
This is problematic as that it has a entirely different cli
than the rest of the daemons and we have no plans to make
this equivalent.
Fixes: #18107
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
In ebgp-multihop, there is a difference in reload behavior when TTL is
unspecified (meaning default 255) and when 255 is explicitly specified.
For example, when reloading with 'neighbor <neighbor> ebgp-multihop
255' in the config, the following difference is created. This commit
fixes that.
Lines To Delete
===============
router bgp 65001
no neighbor 10.0.0.4 ebgp-multihop
exit
Lines To Add
============
router bgp 65001
neighbor 10.0.0.4 ebgp-multihop 255
exit
The commit 767aaa3a8048 is not sufficient and frr-reload needs to be
fixed to handle both unspecified and specified cases.
Signed-off-by: Nobuhiro MIKI <nob@bobuhiro11.net>
|
|
tools: fix reload interface deletion
|
|
When support for new style `get()` was added inadvertently stopped
generating other callbacks and prototypes. Fix this.
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
The frr-reload script currently deletes configurations
line-by-line under an interface context, if the interface was removed.
This approach fails when the interface has already been removed from the system.
This change enables whole interface removal using a single command
(no interface <interface-name>), simplifying the reload process and
reducing reload errors.
Signed-off-by: Julian Klaiber <jklaiber@open-systems.com>
|
|
When a bgp neighbor removed from associated to peer-group,
the neighbor is fully deleted, subsequent deletion of any
configuration related to the neighbor leads to failure
in frr-reload.
Handle any 'no neighbor ...' part of lines_to_del list
Testing:
Below first line would delete the neighbor swp1.10,
the existing code before the change handles to remove
config starts with 'neighbor swp1.10 ...' but not
'no neighbor swp1.10 ...'.
(Pdb) (lines_to_del)
(('router bgp 100',), 'neighbor swp1.10 interface peer-group dpeergrp_2'),
(('router bgp 100',), 'neighbor swp1.10 advertisement-interval 1'),
(('router bgp 100',), 'neighbor swp1.10 timers 3 9'),
(('router bgp 100',), 'neighbor swp1.10 timers connect 1'),
(('router bgp 100',), 'no neighbor swp1.10 capability dynamic'),
Before fix:
(Pdb) (lines_to_del)
[(('router bgp 100',), 'neighbor swp1.10 interface peer-group dpeergrp_2'),
(('router bgp 100',), 'no neighbor swp1.10 capability dynamic')]
frr-reload log:
2025-01-13 05:13:11,172 INFO: Executed "router bgp 100 no neighbor swp1.10 interface peer-group dpeergrp_2 exit"
2025-01-13 05:13:11,227 ERROR: Failed to execute router bgp 100 neighbor swp1.10 capability dynamic exit
2025-01-13 05:13:11,228 ERROR: "router bgp 100 -- neighbor swp1.10 capability dynamic -- exit" we failed to remove this command
After fix:
(Pdb)(lines_to_del)
[(('router bgp 100',), 'neighbor swp1.10 interface peer-group dpeergrp_2')]
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
Adopt f-string for printing log message, so that appropriate formatting can be
applied.
Signed-off-by: Giovanni Tataranni <g.tataranni@gmail.com>
|
|
improve error handling of operational state walk callback
|
|
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
When reloading the following configuration:
```
vrf red
rpki
rpki cache tcp 172.65.0.2 8282 preference 1
exit
exit-vrf
```
frr-reload.py does not properly enter the `rpki` context
within a `vrf`. Because of this, it fails to apply RPKI
configurations.
Signed-off-by: Jonathan Voss <jvoss@onvox.net>
|
|
tools: Add missing formats keyword to segment-routing in frr-reload
|
|
When reloading the following configuration:
```
segment-routing
srv6
formats
format usid-f3216
wide-local-id-block explicit start 100
exit
!
format uncompressed-f4024
exit
!
exit
!
exit
!
exit
```
frr-reload.py does not properly enter the `formats` context. Because of this,
it fails with an unknown command error when applying new or updating format
configuration.
Signed-off-by: Jonathan Voss <jvoss@onvox.net>
|
|
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
python3 -m black tools/frr_babeltrace.py
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
Ticket: #4127810
Testing:
2024-11-20T01:52:10.073 frr_zebra:netlink_neigh_update_msg_encode
{'mac': '00:00:00:00:00:00', 'ip': '27.0.0.4', 'nhg': 0, 'flags': 2,
'state': 192, 'family': 'bridge', 'type': 0, 'op': 23}
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
Consider the following scenario.
You start from the configuration below:
```
!
segment-routing
srv6
encapsulation
source-address fc00:0:1::1
!
!
!
```
Then you change the source address:
```
r1# configure
r1(config)# segment-routing
r1(config-sr)# srv6
r1(config-srv6)# encapsulation
r1(config-srv6-encap) source-address 1::1
```
And finally, reload the configuration
`python3 frr-reload.py --reload /etc/frr/frr.conf`
frr-reload returns the error below:
```
Failed to execute segment-routing srv6 no source-address 1::1 exit exit
"segment-routing -- srv6 -- no source-address 1::1 -- exit -- exit" we failed to remove this command
% Unknown command: no source-address 1::1
[79975|mgmtd] sending configuration
line 3: % Unknown command[76]: source-address fc00:0:1::1
[79975|mgmtd] Configuration file[/etc/frr/frr.conf] processing failure: 2
```
The reason is that the keyword `encapsulation` is missing in frr-reload.
This patch adds the missing keyword `encapsulation`.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
|
|
Fix the error below:
```
[58564|mgmtd] sending configuration
[58565|zebra] sending configuration,
line 14: % Unknown command[52]: max-segs-left 3
line 18: % Unknown command[52]: max-end-pop 3
line 22: % Unknown command[52]: max-h-encaps 2
line 26: % Unknown command[52]: max-end-d 5
[58573|isisd] sending configuration
[58565|zebra] Configuration file[/etc/frr/frr.conf] processing failure: 2
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
|
|
Fix the error below:
```
[58564|mgmtd] sending configuration
[58565|zebra] sending configuration,
line 10: % Unknown command[52]: node-msd
[58573|isisd] sending configuration
[58565|zebra] Configuration file[/etc/frr/frr.conf] processing failure: 2
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
|
|
Add more data gathering for pim and pim6 support bundles
Signed-off-by: Corey Siltala <csiltala@atcorp.com>
|
|
The support bundle was not gathering any msdp data
for pim at all. Let's add a bit to allow us to
have more data here when a suppport bundle is generated
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
There were no zebra show commands related to mpls labels
being generated for support bundles. Let's rectify that
situation.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
When a support bundle is created no isis commands were
issued to attempt to gather data about what is going
on in isis. Let's rectify that
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Add a bit of bmp data gathering for bgp support bundle generation
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
`checkpatch` has sufficiently annoyed me to fix this.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
Need to have arrays as a stop condition in this type normalization
function, like pointers and function pointers. Actual arrays as
argument types are extremely rare to see because C has this
array-decay-to-pointer thing, but it can happen.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Mgmtd makes use of libyang's internal ietf-yang-library module to add
support for said module to FRR management. Previously, mgmtd was loading
this module explicitly; however, that required that libyang's
`ietf-yang-library.yang` module definition file be co-located with FRR's
yang files so that it (and ietf-datastore.yang) would be found when
searched for by libyang using FRRs search path. This isn't always the
case depending on how the user compiles and installs libyang so mgmtd
was failing to run in some cases.
Instead of doing it the above way we simply tell libyang to load it's
internal version of ietf-yang-library when we initialize the libyang
context.
This required adding a boolean to a couple of the init functions which
is why so many files are touched (although all the changes are minimal).
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
The issue is we can't remove all pim configurations including some
special configurations (e.g., `no ip pim bsm`) for one interface.
For one pim-disable interface, all such pim depdendent options
(including `ip pim ` and `no ip pim `) should be completely removed.
Also append `no ip multicast` for the same purpose, it is no use at present,
but for future use.
The running config:
```
interface A
ip pim
no ip pim bsm
exit
```
Reload the new config:
```
interface A
exit
```
Before:
```
2024-10-05 20:52:33,467 INFO: Executed "interface A no ip pim exit"
2024-10-05 20:52:33,482 INFO: Executed "interface A ip pim bsm exit"
```
And the pim configurations in running configuration are not removed after reloading:
```
interface A
ip pim <- Wrong
exit
```
After:
```
2024-10-05 20:56:27,489 INFO: Executed "interface A no ip pim exit"
```
And all the pim configuration are removed.
Signed-off-by: anlan_cs <anlan_cs@126.com>
|
|
Without checking interfaces, the other interfaces' changes will be wrongly
lost.
Running config:
```
interface A
ip pim
ip pim use-source 11.0.0.1
exit
!
interface B
ip pim
ip pim use-source 22.0.0.1
exit
!
```
Reload the new config:
```
interface A
exit
!
interface B
ip pim
exit
```
Before:
```
2024-09-29 10:08:27,686 INFO: Executed "interface A no ip pim exit"
```
After:
```
2024-09-29 10:05:01,356 INFO: Executed "interface A no ip pim exit"
2024-09-29 10:05:01,376 INFO: Executed "interface B no ip pim use-source 22.0.0.1 exit"
```
Signed-off-by: anlan_cs <anlan_cs@126.com>
|
|
tools: fix invalid escape on regex string
|
|
fix usage of regex string without proper escaping
Signed-off-by: Giovanni Tataranni <g.tataranni@gmail.com>
|
|
The new config option --disable-python-runtime allows make install to proceed
without installing any of the python scripts. When installing from deb/rpm
packages those are bundled as frr-pythontools, which is independent from the
frr binaries and can already be skipped. I.e, this PR gives the option to skip
those scripts when building/installing from sources too.
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
|
|
When using a regex (or anything that uses `\?` escapes) in python, raw
strings (`r"content"`) should be used so python doesn't consume the
escapes itself. Otherwise we get either broken behavior and/or
`SyntaxWarning: invalid escape sequence '\['`
Fixes: 8916953b534f64a7545860ad5b4b36dc2544f33a ("build: fix a few python string escape warnings")
Fixes: https://github.com/FRRouting/frr/issues/16522
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Allow using "+1" when meaningful (i.e. cmd_graph_merge wants -1 or +1)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
If pim_vrfs is empty, we append [] into the lines array, and the reload is broken
since it expects only strings, but gets an array inside at the end.
```
Traceback (most recent call last):
File "/usr/lib/frr/frr-reload.py", line 2227, in <module>
log.debug("New Frr Config\n%s", newconf.get_lines())
File "/usr/lib/frr/frr-reload.py", line 436, in get_lines
return "\n".join(self.lines)
TypeError: sequence item 45: expected str instance, list found
```
Fixes: 98d47f43fbba4e376c8351c724e8c625799805f7 ("tools: Fix frr-reload to support legacy pim configuration from file")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Fix load from file in frr-reload to detect and convert legacy pim
configuration so that the tool can continue to be used with legacy
configurations.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
|
|
pimd uses "v4/v6 dispatch" typedefs. Don't complain about those in
checkpatch.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
The plugin was already catching attempts to print `time_t` without
casting it first (there is no valid printf specifier without a cast),
but `__suseconds64_t` needs the same treatment. (Probably
`__suseconds_t` too, if it exists, which I'm not sure it does - but that
doesn't matter, the plugin ignores non-existing types.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
