| Age | Commit message (Collapse) | Author |
|---|
|
|
|
login: T3455: Fix edit level configuration for user
|
|
containers: T2216: Add podman for containers
|
|
|
|
Removing the Zebra/Linux Kernel route-map added by "set protocols static route-map"
was not removed once applied. This was because the removal must happen within
the zebra daemon and not staticd.
|
|
Removing the Zebra/Linux Kernel route-map added by "set protocols rip route-map"
was not removed once applied. This was because the removal must happen within
the zebra daemon and not ripd.
|
|
Removing the Zebra/Linux Kernel route-map added by "set protocols isis route-map"
was not removed once applied. This was because the removal must happen within
the zebra daemon and not isisd.
|
|
Removing the Zebra/Linux Kernel route-map added by "set protocols ospf route-map"
was not removed once applied. This was because the removal must happen within
the zebra daemon and not ospfd.
|
|
Removing the Zebra/Linux Kernel route-map added by "set protocols bgp route-map"
was not removed once applied. This was because the removal must happen within
the zebra daemon and not bgpd.
|
|
|
|
|
|
It is only possible to set one local-as override per BGP neighbor/peer-group.
In addition to this, the override AS number is not allowed to be the same as
the one from the global BGP process.
If this would still be the case frr-reload would error out:
> frr-reload output: 184 % Cannot have local-as same as BGP AS number
|
|
|
|
The introduction of key_mangling=('-', '_') when working with get_config_dict()
caused more harm then good. This commit extends common helpers and adds new
helpers when verifying the existence of route-maps, access-lists or prefix-lists.
|
|
Commit 548d9057e3e (vrf: T3344: move dynamic routing protocols under "vrf name
<name> protocols") temporary removed the possibility to specify the VNI for a
given VRF to to changing of the CLI configuration nodes.
As VNI is set inside zebra, we can re-use the now widely deployed frr python
library to configure and change the configuration without any interference to
other FRR daemons.
|
|
Instead of having a dedicated ERSPAN interface type, rather move the specifics
into "interface tunnel". A migrator is not needed as there is yet no LTS release
with this feature and this is considered experimental.
|
|
When configuring a BGP neighbor via an interface, FRR requires that the
peer-group and remote-as node from under the interface statement is used.
This is now enforced by a verify() check.
|
|
|
|
|
|
bgp: T1711: remove ASN tagNode and move to "local-as"
|
|
Every time when set configuration bgp, you need set AS number. There is very
less benefit in this system so the AS number is moved from a tagNode level down
to a leafNode with the name "local-as", same as on the neighbor or peer-group
level.
This changes the CLI configuration from:
set protocols bgp 100 neighbor 10.10.1.2 remote-as 200
to
set protocols bgp local-as 100
set protocols bgp neighbor 10.10.1.2 remote-as 200
|
|
|
|
This reverts commit d89455ee7f5dc21d00bbeddd57eaee2e32f45f99.
|
|
routing: T3217: Save configs of daemon per commit
|
|
Allows Dynamic DNS services with custom names to use the zone field if
the protocol is set to cloudflare
(cherry picked from commit 5ab6c20f8acd4dda1870b9a71fe73129d2f78b24)
|
|
|
|
As we and FRR do not support multiple FRR process instances, there is no need
to make this configurable for a user. We rather rely on a solid default "VyOS".
|
|
|
|
We need to adjust the regex pattern for the default VRF as a trailing whitespace
is required due to an FRR issue: https://github.com/FRRouting/frr/issues/8300
|
|
|
|
|
|
Instead of multiple if/else paths, use a common vrf string variable which is
either populated or not. In addtion when interfaces are configured for a given
VRF, harden the regex for config reload.
|
|
VRF support can be tested using:
set vrf name red table 1000
set vrf name red protocols isis domain FOOO
set vrf name red protocols isis net 49.0001.1921.6800.1002.00
set vrf name red protocols isis interface eth1
|
|
As there can only be one running IS-IS process (FRR limitation) there is no need
in having a tagNode here. This adds artifical restrictions/limitations when
moving on to support VRFs for IS-IS protocol.
|
|
|
|
When leaking routes to a VRF ensure that the VRF we are leaking to exists.
|
|
Re-issuing the same iproute2 commands can lead to errors, simply ignore
them and not raise a Python exception.
|
|
During assembly of the required config changes we also must move the
interfaces_removed assignemnt to an earlier stage so the value is also populated
when the entire process is removed to cleanup all remaining OSPF process assigned
interfaces.
This was yet not the case and when deleting OSPF I still got my "interface eth0"
with the area key configured.
|
|
|
|
conf-mode: T2425: Add XML for policy-lists
|
|
VRF: support for dynamic routing protocols OSPF and BGP
|
|
|
|
Instead of having the dynamic routing protocols OSPF and BGP residing under
the "protocols vrf <name> [ospf|bgp]" nodes, rather move them directly under
the "vrf name <name> protocols [ospf|bgp]" node. Now all VRF related parts
are placed under the same root node.
This eases the verify steps tremendously, as we do not need to check wheter a
VRF eists or not, it will always exist as we operate under a child node.
|
|
nat66: T2518: Modify the command line description of NAT/NAT66
|
|
The following VyOS CLI config
vrf red {
bgp 100 {
neighbor 1.1.1.1 {
peer-group foo
}
peer-group foo {
passive
password bar
remote-as 200
}
}
}
Will generaste the FRR configuration:
!
router bgp 100 vrf red
no bgp ebgp-requires-policy
no bgp network import-check
neighbor foo peer-group
neighbor foo remote-as 200
neighbor foo password bar
neighbor foo passive
neighbor 1.1.1.1 peer-group foo
!
|
|
VyOS CLI config:
vrf red {
ospf {
default-information {
originate {
always
}
}
default-metric 30
passive-interface default
}
}
Will create the FRR configuration snippet:
!
router ospf vrf red
auto-cost reference-bandwidth 100
timers throttle spf 200 1000 10000
passive-interface default
default-metric 30
default-information originate always
!
|
|
|
|
A user can specify both "set system console device ttyS0 speed '9600'" and
"set service console-server device ttyS0 speed 9600". A serial interface can
not be used multiple times.
commit now produces an error:
vyos@vyos# commit
[ service console-server ]
Port "ttyS0" requires speed to be set!
(cherry picked from commit 7620a8a1d6d20d4bf16e714a9d40b7bdfb133b39)
|
|
|
|
|
