| 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.
|
|
|
|
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).
|
|
Replace two-word "can not" / "Can not" with "cannot" across comments,
ConfigError messages, CLI help text, and op-mode output.
Standard SNMP MIB files under mibs/ are left unchanged.
|
|
|
|
|
|
Co-authored-by: Christian Breunig <christian@breunig.cc>
|
|
|
|
FRR (#4994)
* sr-te: T6750: Adding Segment Routing Traffic Engineering portion of FRR
---------
Co-authored-by: Cheeze_It <none@none.com>
Co-authored-by: Christian Breunig <christian@breunig.cc>
|
|
|
|
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"
|
|
|
|
Co-Authored-by: Christian Breunig <christian@breunig.cc>
|
|
|
|
|
|
|
|
T7664: support FRR 10.5
|
|
isis: T8158: fix lsp-timers
|
|
T8046: traffic-engineering: support link-params
|
|
There are three configuration values in VyOS isis XML:
* lsp-gen-interval
* lsp-refresh-interval
* max-lsp-lifetime
In FRR they have the following restrictions in yang model:
* refresh-interval, default 900
* maximum-lifetime >= refresh-interval + 300 (350-65535), default 1200
* generation-interval < refresh-interval (1..120), default 30
When setting these values in separate steps we can get error e.g.:
libyang: Must condition ". >= ../refresh-interval + 300" not satisfied.
even when all restrictions are satisfied.
To fix the issue:
1. Write default values in our XML.
2. Check these restrictions in protocol_isis.py
3. Use FRR command `lsp-timers` that sets all these values in one go
|
|
Add 'traffic-engineering' commands under 'protocols'.
set protocols traffic-engineering admin-group ADMINGROUP bit-position 1
set protocols traffic-engineering interface INTERFACE admin-group ADMINGROUP
set protocols traffic-engineering interface INTERFACE max-bandwidth 1280
set protocols traffic-engineering interface INTERFACE max-reservable-bandwidth 1280
Also add
set protocols isis traffic-engineering export
|
|
|
|
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.
|
|
Co-authored-by: Christian Breunig <christian@breunig.cc>
|
|
This reverts commit d871fe9c4c65de87232802ed54b263c9b2824391.
|
|
bgp: T7760: remove per vrf instance system-as node
|
|
- Added 'rpki-extcommunity' match condition
- Added test to test_policy.py smoketest for rpki-extcommunity match
|
|
ospf: T7297: fix redistribute-table
|
|
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.
|
|
Requires FRR to support `redistribute table-direct` for ospf
|
|
Added interface fast-reroute configuration commands
|
|
|
|
|
|
T7432: RPKI VRF Support
|
|
|
|
* zebra: T7349: Added importing routes from non to the kernel routing table
Added importing routes from non to the kernel routing table.
---------
Co-authored-by: Christian Breunig <christian@breunig.cc>
|
|
|
|
Removed unused opennhrp files and configurations
|
|
|
|
If a router has not formed an LDP neighbor adjacency yet, it
answers all received LDP Hello packets from non-neighbors with
new Hello packets.
This leads to flooding LDP packets to all routers for each LDP
incoming packet.
Add configuration option to disable this behavior
```
set protocols mpls ldp interface eth0 disable-establish-hello
```
|
|
* 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 match source-vrf to route-map
|
|
|
|
* 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.
|
|
T7089: Fix static route when using PPPoE default route
|
|
Removed an unnecessary command that caused an error
when creating a configuration with VRF and NHRP.
|
|
|
|
|
