| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
VyOS 1.2 (crux) rejected prefixes other then of site /64.
[ interfaces ethernet eth0 ipv6 address eui64 2006:ab00:abe1::2/127 ]
Error: Prefix lenght is 127. It must be 64.
Same should be done on VyOS 1.3 and newer
|
|
|
|
As the amount of include files now has reached a certain amount, it is getting
more and more crowsded, thuse introducing "per topic" subdirectories on the
filesystem to keep a clean structure makes sense.
|
|
As the amount of include files now has reached a certain amount, it is getting
more and more crowsded, thuse introducing "per topic" subdirectories on the
filesystem to keep a clean structure makes sense.
|
|
As the amount of include files now has reached a certain amount, it is getting
more and more crowsded, thuse introducing "per topic" subdirectories on the
filesystem to keep a clean structure makes sense.
|
|
As the amount of include files now has reached a certain amount, it is getting
more and more crowsded, thuse introducing "per topic" subdirectories on the
filesystem to keep a clean structure makes sense.
|
|
conf-mode: T2425: Add XML for policy-lists
|
|
We must ensure that an interface is already added to a VRF before it is
referenced inside a VRF context, e.g. OSPF.
|
|
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.
|
|
When including XML files they all contained a comment from where the snipped
had actually been included from. The comment had been "included start" and
"included end" instead of "include start" and "include end".
This commit corrects the glitch.
|
|
|
|
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
!
|
|
As the amount of include files now has reached a certain amount, this also
introduces "per topic" subdirectories on the filesystem to keep a clean
structure.
This commit is related to the change in the OSPF structure done in 952c52ef01
("vrf: ospf: T2271: re-arrange xml include building blocks").
|
|
|
|
|
|
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
!
|
|
In order to fully re-use the XML based OSPF CLI definition for per-VRF routing,
the file structure needs to be reorganized and the common OSPF definition is
moved to its dedicated ospf-common-config.xml.i file, which can then be fully
re-included at the VRF level.
As the amount of include files now has reached a certain amount, this also
introduces "per topic" subdirectories on the filesystem to keep a clean
structure.
|
|
|
|
set protocols bgp 65010 address-family l2vpn-evpn vni 100 route-target both 516:10516
set protocols bgp 65010 address-family l2vpn-evpn vni 100 rd 192.168.0.1:514
Todo: add verify() step to check if at least one evpn enabled BGP neighbor
exits, else FRR will error out with: This command is only supported under EVPN VRF
|
|
|
|
The completion helper was directly called on the /dev/serial/by-bus directory,
but it was not verified if the directory exists at all.
|
|
nptv6: T2518: Support IPv6 address translation
|
|
|
|
|
|
* set protocols bgp ASN address-family ipv4-unicast maximum-paths
* set protocols bgp ASN address-family ipv4-unicast maximum-paths-ibgp
* set protocols bgp ASN address-family ipv6-unicast maximum-paths
* set protocols bgp ASN address-family ipv6-unicast maximum-paths-ibgp
|
|
VyOS 1.2 had a default ttl of 16 hardcoded to the node.def file [1], so until
this is handled via a migration script we have to obey that particular
setting.
[1]: https://github.com/vyos/vyatta-cfg-system/blob/crux/templates/interfaces/vxlan/node.def#L23
|
|
|
|
dhcp: T3300: add DHCP default route distance
|
|
|
|
* 'T3379' of https://github.com/sever-sever/vyos-1x:
dhcpv6-server: T3379: Add option global-parameters name-server
|
|
Support setting additional options to the GENEVE tunnel like:
- ttl
- tos
- do not fragment bit
- ipv6 flowlabel
|
|
|
|
|
|
Rename CLI options local-ip to source-address and remote-ip to remote to
get a consistent CLI experience for the user.
|
|
|
|
|
|
|
|
Streamline the CLI configuration where we try to use remote on other interfaces
like vxlan, geneve.
|
|
Streamline the CLI configuration where we try to use source-address when
creating connections which are especially sourced from a discrete address.
|
|
The following list shows the mapping of VyOS tunnel encapsulation modes to the
corresponding Linux modes.
VyOS Linux
gre gre
gre-bridge gretap
ipip ipip
ipip6 ipip6
ip6ip6 ip6ip6
ip6gre ip6gre
sit sit
Besides gre-bridge this is pretty consistent. As bridge interfaces are also
called tap interfaces gre-bridge will be renamed to gretap to make the
post-processing much easier.
This means (in detail) that there are no more child classes of _Tunnel and
there will be now one geneirc TunnelIf class handling all sorts of encapsulation.
|
|
A VXLAN tunnel may now get a TTL, TOS, Flowlabel option specified. It is also
possible to disable learning of unknown addresses into the forwarding database.
|
|
Commit 4bf55f97 ("BGP: T2100: Adding RFC8212 option toggle.") added a CLI option
to enable RFC8212 ebgp-requires-policy checks. The extended smoketests assumed
that this will lead to an FRR configuration line of "bgp ebgp-requires-policy" -
which is not the case as this is a default option and FRR hides default
options from the config.
In order to properly verify this functionality we must conduct the negative test
and ensure the option is not present in the CLI at all.
|
|
bgp: T2100: Changing RFC8212 behavior and option toggle
|
|
In this commit we add the default operation within BGP
to have RFC8212 disabled for eBGP routes. This default
should preserve the normal behavior for VyOS from earlier
releases of FRR to the current latest release. Another
option that we add is the ability to toggle whether or
not RFC8212 is enabled or disabled.
|
|
|
|
As thought in the beginning the dhcp-interface route option can not be
superseeded by the interface option. When a route is installed for a DHCP
interface, that interface is usually a broadcast interface which can not be
used for plain interface-based routes.
The old Vyatta logic was migrated to Python where the current received
next-hop address from the DHCP interface is installed as next-hop address.
|
