Age | Commit message (Collapse) | Author |
|
The following options one can specify in a route-map not got rendered as they
have been missed out:
* set comm-list
* set community
* set extcommunity (both route-target and site-of-origin)
* set table
|
|
* community-list gained proper valueHelp nodes
* route-map set community gained proper valueHelp nodes
* route-map set comm-list now has a completion helper searching in
"policy community-list"
|
|
|
|
|
|
get_config_dict()
|
|
|
|
|
|
* 't2425-policy' of github.com:c-po/vyos-1x:
policy: T2425: re-implement "policy" tree from vyatta-cfg-quagga in XML/Python
|
|
|
|
smoketest: T2216: Containers set ip to test01
|
|
|
|
|
|
|
|
T3472: Move over commit-confirm-notify.py from vyatta-config-mgmt
|
|
|
|
config: T3481: add switch to prevent mangling of tag node values
|
|
|
|
util: T3356: Fix password variables
|
|
containers: T2216: Static ip for conteiner smoketest
|
|
|
|
|
|
|
|
As all routing protocol definitions have been moved from the soon deprecated
vyatta-cfg-quagga package to vyos-1x, we also need to take care about all the
dependencies.
Add missing frr-rpki-rtrlib and frr-snmp dependency and enforce a FRR version
of at least 7.5 which holds all the features we currently support.
|
|
In the vyatta-cfg-quagga days the access-list(6) or prefix-list(6) sequence
numbers have been made up artifically. The new implementation from vyos-1x will
re-use the rule number specified on the CLI as the sequence number, this we have
to alter the tast cases to get a proper match from the beginning - covering
both the old and new world.
This can be done by using rule numbers that are multiples of 5.
|
|
containers: T2216: Add smoketest
|
|
|
|
In this commit we add more address families within
BGP. This should bring VyOS the ability to enable
the rest of the capabilities within FRR.
Co-authored-by: Cheeze_It <none@none.com>
|
|
dhclient: T3392: Changed dhclient-script hooks for VRF
|
|
There were two problems with VRF support inside dhclient-script:
- VRF check inside the `01-vyos-cleanup` hook was needless because it will be done inside the `03-vyos-ipwrapper` anyway;
- VRF was ignored for in-kernel routes in `03-vyos-ipwrapper`. Theoretically, there must be no situation now when this can leads to a real problem, but better will be to keep both kernel and FRR backends in sync.
Also, the way to get and use a VRF name was changed to an easier one.
|
|
|
|
ipsec: T3333: Fix status for SA state op-mode
|
|
|
|
|
|
dhclient: T3471: Fixed dhclient processes search
|
|
Since in some cases a dhclient command may not end with an interface name, the way to find out a list of dhclients running for a current interface was replaced to catch PIDs regardless of the exact command syntax.
|
|
|
|
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.
|
|
|
|
|
|
For an unknown reason this regularely fails on the QEMU builds, thus the test
for reading back IP addresses is temporary disabled. There is no big deal here,
as this uses the same methods on 802.1q and here it works and is verified.
|
|
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
|
|
|