| Age | Commit message (Collapse) | Author |
|---|
|
```
[...]
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>
(cherry picked from commit a515de1c46f617ee3608ab55cdef5f2a262d387a)
|
|
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>
|
|
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>
|
|
tools: add iproute2 alias for pathd daemon
|
|
With SRv6 traffic engineering, some ipv6 routes will
be installed by the Pathd daemon.
Populate the iproute2 aliasing table with pathd.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
If frr.conf has bgp as-path access-list clause without sequence number
then upon performing frr-rleoad, the running config clause with sequence
number will always be deleted and the new ones without sequence will
be re-added.
This could lead to blackholing until the config gets reapplied.
Testing:
frr.conf:
bgp as-path access-list important_internet_bgp_as_numbers permit _16509_
Running config:
bgp as-path access-list important_internet_bgp_as_numbers seq 5 permit
_16509_
!
Before fix
Upon frr-reload it deletes and readd line as without seq
2024-04-26 03:16:45,772 INFO: Executed "no bgp as-path access-list
important_internet_bgp_as_numbers seq 5 permit _16509_"
'bgp as-path access-list important_internet_bgp_as_numbers permit
_16509_\n'
After fix:
no form is not executed and no delta determine between frr.conf
and running-config.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
no form of 'ip pm msdp peer <> source <>' does not
accept source argument. Stip the 'source <>' part from
config line being deleted via frr-reload.
Ticket: #3874971
Testing:
Config:
vrf blue
ip msdp peer 1.1.1.1 source 1.1.1.1
frr-reload failure log:
2024-04-23 02:08:32,501 INFO: Failed to execute vrf blue no ip
msdp peer 1.1.1.1 source 1.1.1.1 exit
2024-04-23 02:08:32,501 ERROR: "vrf blue -- no ip msdp peer 1.1.1.1
source 1.1.1.1 -- exit" we failed to remove this command
2024-04-23 02:08:32,501 ERROR: % Unknown command: no ip msdp peer
1.1.1.1 source 1.1.1.1
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
When no ip pim is performed subsequent pim related
configs under the interface also implicitly deleted.
The previous fix was attempting to remove from the same
list which was being integrated.
First collect the lines to remove in separate list
then at the end remove from the original lines_to_del.
commit 623af04e1c does not work properly if tries to delete
an entry from existing list which is being walked on.
Ticket: #3869779
Testing done:
frr.conf:
no interface config
running-config:
--------------
interface swp1
ip pim
ip pim active-active
ip pim allow-rp rp-list sample
ip pim bfd
ip pim use-source 1.1.1.1
ip multicast boundary oil test
exit
frr-reload log pointing only no ip pim config
is removed under interface:
2024-04-18 18:44:37,202 INFO: "frr defaults datacenter" cannot be removed
2024-04-18 18:44:37,202 INFO: "service integrated-vtysh-config" cannot be removed
2024-04-18 18:44:37,504 INFO: Executed "interface swp1 no ip pim exit"
2024-04-18 18:44:37,505 INFO: /var/run/frr/reload-YHS51E.txt content
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
tools: frr-reload strip interface vrf ctx line
|
|
if frr.conf file contains 'interface x vrf <name> config
it causes protocol (like ospf) neighbor session flap,
as it deletes interface base config line ('interface x') from
running config and readds with 'interface x vrf <name>'
line from frr.conf.
This deletion and readdition of lines leads to neighborship
flaps.
This issue is by product of (PR-10411 | https://github.com/FRRouting/frr/pull/10411)
(commit id: 788a036fdb)
where running config for interface config no loger displays associated
vrf line.
Ticket: #3858146
Testing:
frr.conf
interface swp1.2 vrf vrf1012
ip ospf network point-to-point
running-config:
interface swp1.2
ip ospf network point-to-point
exit
Before fix:
frr-reload logs:
2024-04-09 00:28:31,096 INFO: Executed "interface swp1.2 no ip ospf
network point-to-point exit"
'interface swp1.2 vrf vrf1012\n ip ospf network
point-to-point\nexit\n',
After fix:
frr-reload strips vrf line, thus no config change between
frr.conf and running config.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
Python subprocess communication now operates on bytes, not strings.
Signed-off-by: Andrew Cooks <acooks.at.bda@gmail.com>
|
|
Adding them as others: GPL-2.0-or-later
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
checkpatch.pl wants you to use ARRAY_SIZE in a kernel
header file. We don't have access to this kernel header
file for normal compilation. I'm just going to remove it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
