| Age | Commit message (Collapse) | Author |
|
Add input-queue-limit and output-queue-limit CLI nodes to expose global FRR
"bgp input-queue-limit" and "bgp output-queue-limit" commands via our CLI.
Parameters control the maximum number of queued messages for all BGP peers
during message parsing. FRR default is 10000 which we honor.
Note that this is a global option and can only be set for the global/default
BGP instance.
|
|
`advertise-all-vni` is globally active
When `advertise-all-vni` is configured in the global/default BGP instance,
VyOS generated a `vni <id>` sub-block under each VRF BGP `address-family
l2vpn evpn` context. This conflicts with advertise-all-vni: FRR already
owns all kernel VNIs and returns `% Failed to create VNI` when frr-reload.py
attempts to apply the VRF-level vni sub-block. FRR then performs an early
exit from config processing, silently dropping the entire l2vpn evpn
address-family for all subsequent VRF BGP instances.
|
|
bgp: T5526: Fix BGP neighbor validation not raising when interface does not exist
|
|
|
|
exist
Validation of interface-based BGP neighbors relied on checking physical
interface existence, which silently skipped the check when interface didn't
exist yet, letting invalid config reach FRR. Fix by checking whether the
neighbor is not an IP address instead, and improve the error messages to
show the correct command.
|
|
VRF route leaking via VPNv4/VPNv6 caused all imported (leaked) routes to
be withdrawn and reinstalled on every commit - even commits unrelated to
BGP, VRF or routing - briefly blackholing traffic that depends on them.
Root cause: the BGP address-family template rendered the route-target
using the "route-target vpn ..." alias. FRR accepts that alias on input
but its config writer only ever emits the canonical "rt vpn ..." form.
frr-reload.py diffs the generated config against FRR's running config
line by line and has no normalisation for this, so the route-target lines
never matched and were deleted and re-added on every reload. Re-applying
the route-target runs FRR's vpn_leak_prechange()/postchange(), a
non-atomic withdraw-all then reinstall-all of every leaked route.
Emit the canonical "rt vpn" keyword so the rendered config round-trips
through frr-reload unchanged. FRR also folds an identical import+export
route-target into "both" (an order-sensitive, byte-identical match), so
do the same to stay idempotent; reordered or differing lists stay split
on both sides.
Add test_bgp_33_vpn_route_target_idempotency covering both / identical
export+import / asymmetric route-target, reading the generated FRR config
(getFRRconfig/vtysh returns FRR's already-canonical form and cannot catch
the alias).
|
|
simultaneously
FRR only allows one BGP instance to hold `advertise-all-vni` at a time
(FRR issue #9405). When a default BGP instance is present it is always
started before named VRF instances, so if a named VRF holds
the flag FRR silently rejects it on every boot (regardless of default
EVPN config), causing the running config to diverge from what is
stored in VyOS.
Enforce the following policy in verify():
- Default BGP instance may always hold `advertise-all-vni`.
- A named VRF may hold it only when no default BGP instance exists.
- Only one BGP instance (default or named VRF) may hold it at a time.
The default BGP verify path additionally scans dependent VRFs so that
adding or modifying the default BGP instance while a named VRF already
holds the flag is caught even when the VRF node is not part of the
current commit.
|
|
|
|
|
|
|
|
We explicitly omit the "plain" option, as it is the implicit default in FRR
We also do not want to add "plain" as VyOS default value and emit it by default
as this makes the config a bit ugly (frr puts it in the router line so you get
"router bgp <AS> as-notation plain").
Additionally, setting plain as default value and emitting it by default would
break pretty much all BGP tests, as they commonly do
self.getFRRconfig(f'router bgp {ASN}', stop_section='^exit')
and getFRRConfig does a "^<content>$" match, which breaks when you add the
"as-notation plain"
|
|
FRR implemented a new know to learn the peers remote ASN from the BGP OPEN
message from https://github.com/FRRouting/frr/pull/16345.
|
|
T7664: support FRR 10.5
|
|
|
|
In FRR 10.5 'bgp reject-as-sets' became default
(https://frrouting.org/release/10.5.0/):
> BGP rejects AS_SET by default
> Until 10.5.0, it was disabled by default, and since RFC 9774 was
> published, we switched this on by default (to reject).
Add 'no bgp reject-as-sets' when VyOS option reject_as_sets is not set.
|
|
While working on task T7664 (FRR 10.4 upgrade), I identified the need for
additional validation and safeguards around the FRR management daemon. The
most appropriate place for this logic is in the setUp() and tearDown() methods
of the smoketest base class, VyOSUnitTestSHIM.
However, during implementation, it became apparent that test cases do not
consistently invoke the base class's setup and teardown methods. This
inconsistency complicates the process of capturing the FRR mgmtd PID at the
start of a test and verifying that it remains unchanged by the end - a key step
in detecting crashes or unexpected terminations (e.g., SIGSEGV) of the FRR
management daemon during tests.
|
|
Rathern then re-inventing the wheel by outself we import the frr-reload.py
script and their read-in function of the current vtysh configuration.
|
|
|
|
This reverts commit d871fe9c4c65de87232802ed54b263c9b2824391.
|
|
|
|
When smoketest debugging is enabled (by creating the file
/tmp/vyos.smoketest.debug), all available smoketests will fail fast instead
of running to completion. This helps reduce test time when something is
broken or undergoing refactoring, as it avoids waiting for the full test suite
to finish.
|
|
bgp: T7760: remove per vrf instance system-as node
|
|
- Added solo leafNode to peer-group config
- Added solo.xml.i to reduce code duplication
- Added solo option to peer-group smoketests
|
|
Originating from the bug in T7665. To avoid potential issues down the line - and
given that there's no compelling technical reason to retain the system-as CLI
node under per-VRF BGP configuration, which cannot be achieved through
alternative means - the maintainers have collectively decided to deprecate the
following command:
set vrf name <name> protocols bgp system-as <asn>
Starting with VyOS 1.4.4, this CLI command will be considered deprecated. While
it will still be accepted, it will no longer have any operational effect. A
deprecation warning will be displayed at commit time, indicating that the BGP
ASN from the global BGP configuration is now used instead.
A migration script will handle the transition and perform the following actions:
* Ensure a global BGP configuration exists; if not, initialize one.
* Iterate over all configured VRFs to determine whether a BGP instance exists
* For any insance, update the configuration to use the global system-as
and apply the local-as ASN no-prepend replace-as option on all affected
neighbors to preserve existing behavior.
* If a neighbor is already configured with a local-as directive, that neighbor
will be excluded from the migration process, as it already follows a custom
configuration.
* Add allowas-in per neighbor option. Required to not deny prefix received
updates due to as-path contains our own global ASN.
|
|
|
|
The legal team says years are not necessary so we can go ahead with it, since
it will simplify backporting.
Automatically removed using: git ls-files | grep -v libvyosconfig | xargs sed -i -E \
's/^# Copyright (19|20)[0-9]{2}(-[0-9]{4})? VyOS maintainers.*/# Copyright VyOS maintainers and contributors <maintainers@vyos.io>/g'
In addition we will error-out during "make" if someone re-adds a legacy
copyright notice
|
|
|
|
* bgp: T7157: Allow using route-maps for VRF route leaking in BGP
Added the possibility of using route-map in route leaking.
* Improve the constraint error message
---------
Co-authored-by: Daniil Baturin <daniil@baturin.org>
|
|
Added the ability to redistribute NHRP routes to:
OSPF
BGP
Babel
RIP
IS-IS
|
|
* set protocols bgp address-family <ipv4-unicast|ipv6-unicast> redistribute
table <n> [metric <n>] [route-map <name>]
|
|
Re-use existing XML constraint added via commit 8f6246da6 ("xml: T7161: provide
re-usable building block for alternative routing tables") and add handy CLI
completion helper.
FRRouting supports redistribution of multiple non-main tables, thus make this
a multi node in addition, too.
|
|
* smoketest: T6747: call wait after commit() only for FRR related tests
Commit 702a60a8de28 ("smoketest: T6746: wait after commit() until frr-reload
is no longer running") added a guard timeout for every commit executed via CLI
smoketests. This commit changes the bahavior to only add the guard timeout
for FRR related testscases.
This improves the overall smoketest time.
* configd: T6747: use one long-lived instance of FRRender
Previously there was one FRRender() instance per config session. This resulted
in re-rendering the FRR configuration every time a new config session was
created.
Example:
vyos@vyos:~$ configure
vyos@vyos# set interfaces dummy dum0 description foo
vyos@vyos# commit
vyos@vyos# exit
vyos@vyos:~$ configure
vyos@vyos# set interfaces dummy dum0 description bar
vyos@vyos# commit
vyos@vyos# exit
In the past this caused a re-render of the FRR configuration as the delta check
added in commit ec80c75d6776 ("frrender: T6746: only re-render FRR config if
config_dict did change") evaluated to false, as it operated on a new instance
of the FRRender class.
With this change there is no FRR re-render, as there is nothing to update
in FRR.
|
|
* smoketest: T6746: add substring search in getFRRconfig()
Some daemons (e.g. bgpd) have several nested substrings/sections like
router bgp 100
address-family ipv4 unicast
..
exit-address-family
exit
We can now use getFRRconfig() with the substring option to extract only
address-family ipv4 unicast
..
exit-address-family
Making config validation more granular
* frrender: T6746: only re-render FRR config if config_dict did change
* frrender: T6746: fix naming glitch isis/eigrp
* frrender: T6746: add --stdout option when running with debug flags
* smoketest: T6746: remove unneeded commit_guard time
It was an invalid workarround as the underlaying issue seems to be a race
condition in CStore.
The commit process is not finished until all pending files from
VYATTA_CHANGES_ONLY_DIR are copied to VYATTA_ACTIVE_CONFIGURATION_DIR. This is
done inside libvyatta-cfg1 and the FUSE UnionFS part. On large non-interactive
commits FUSE UnionFS might not replicate the real state in time, leading to
errors when querying the working and effective configuration.
TO BE DELETED AFTER SWITCH TO IN MEMORY CONFIG
|
|
Do not use custom daemon definitions like bgpd - re-use them from e.g.
vyos.frrender.bgp_daemon
|
|
|
|
|
|
|
|
|
|
|
|
Fixed using 'route-map', 'as-set' and 'summary-only' together in
aggregation in BGP
|
|
bgp: T6151: Allow configuration of disable-ebgp-connected-route-check
|
|
peer-group
changed exception condition
Improved route_reflector_client test
|
|
|
|
|
|
peer-group
handle vtysh bgp error
|
|
bgp: T6032: add EVPN MAC-VRF Site-of-Origin support
|
|
In some EVPN deployments it is useful to associate a logical VTEP's Layer 2
domain (MAC-VRF) with a Site-of-Origin "site" identifier. This provides a BGP
topology-independent means of marking and import-filtering EVPN routes
originated from a particular L2 domain. One situation where this is valuable
is when deploying EVPN using anycast VTEPs
set protocols bgp address-family l2vpn-evpn mac-vrf soo
|
|
|
|
* set protocols bgp parameters labeled-unicast <explicit-null | ipv4-explicit-null | ipv6-explicit-null>
* set protocols bgp parameters allow-martian-nexthop
* set protocols bgp parameters no-hard-administrative-reset"
|
|
set protocols bgp address-family ipv4-unicast nexthop vpn export <ipv4-address|ipv6-address>
set protocols bgp address-family ipv6-unicast nexthop vpn export <ipv4-address|ipv6-address>
|