| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Interface.get_config() was always a pure helper which exposed a "per interface
type" dictionary which was then fed by the caller to create interfaces by
iproute2 which required additional options during creation time.
Such interfaces had been:
* tunnel
* vxlan
* geneve
* macsec
* wifi
* macvlan / pseudo-ethernet
The code was always duplicated to convert from the VyOS CLI based get_config_dict()
to a dict which can be used to feed iproute2.
This path has been removed and we now always feed in the entire dictionary
retrieved by get_config_dict() or in the interfaces case, it's high-level wrapper
get_interface_dict() to the interface we wan't to create.
This also adds the - personally long awaited - possibility to get rid of the
derived tunnel classes for e.g. GRE, IPIP, IPIP6 and so on.
|
|
|
|
In addition to commit cf1156a60e ("ethernet: T3163: probe driver for maximum
rx/tx ring-buffer size") this extends the logic in a way as not every driver
supports setting the buffers at all so it will properly error out.
When invoking "ethtool -g" both stdout and stderr are captured and no exception
is raised if it's an unsupported driver feature. The verify() section will
inform the user about the illegal operation.
|
|
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.
|
|
|
|
|
|
This helper class could be used to interact and retrieve information from
ethtool. It is not used so far in production code.
|
|
If the subprocess is producing enough data (in this case showConfig on a
large config file), then the construction:
p = subprocess.Popen(.., stdout=subprocess.PIPE, ..)
p.wait()
will deadlock with the subprocess waiting for data to be consumed, while
the Python process waits for its termination. So consume data, then wait
for termination.
|
|
|
|
This will enable more debugging on the frr reload library, changes:
* Adds a /tmp/vyos.frr.debug hook to enable system wide vyos.frr debugging
* Log the initial imported configs
* Log the FRR config submitted to frr-reload
* redirecting frr-reload output to the debug log.
|
|
tunnel: T3030: Add erspan protocol support
|
|
In the past it was possible to configure a vif-s interface and a vif interface
both with the same VLAN ID. VyOS 1.2 reported a Kernel error:
RTNETLINK answers: File exists
Error creating VLAN device eth1.100
so this should not be possible at all in VyOS 1.3
|
|
package type automatic detection)
|
|
|
|
vyos: T3274: Handle EOF in ask_yes_no()
|
|
|
|
|
|
If dhcpv6-options is configured without requesting a DHCPv6 address or PD, the
dhcpv6pd variable is assigned an empty dict.
|
|
A hyphen in a route-map name will be converted to _, take care about this
effect during validation.
|
|
|
|
|
|
The raw key was not copied into the class member variable. Also added a smoketest
to ensure the configured parameters are always set.
|
|
Support a 1:1 or 1:n prefix translation. The following configuration will NAT
source addresses from the 10.2.0.0/16 range to an address from 192.0.2.0/29.
For this feature to work a Linux Kernel 5.8 or higher is required!
vyos@vyos# show nat
source {
rule 100 {
outbound-interface eth1
source {
address 10.2.0.0/16
}
translation {
address 192.0.2.0/29
}
}
}
This results in the nftables configuration:
chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
oifname "eth1" counter packets 0 bytes 0 snat ip prefix to ip saddr map
{ 10.2.0.0/16 : 192.0.2.0/29 } comment "SRC-NAT-100"
}
|
|
|
|
|
|
|
|
|
|
bridge: T3137: Let VLAN aware bridge approach the behavior of professional equipment
|
|
|
|
|
|
|
|
equipment
According to the consensus, the specific behavior of a VLAN aware bridge should conform
to the behavior of professional equipment. This commit makes a significant change to the
behavior of VLAN aware bridge, and has the following behaviors:
1. Disable `vif 1` configuration
2. When the VLAN aware bridge is enabled, the parent interface is always VLAN 1
3. When `native-vlan` is not configured, the default behavior of the device is `native-vlan 1`
4. The VLAN ids forwarded by the bridge are determined by `vif`
5. It has an `enable-vlan` node to enable VLAN awareness
6. VLAN configuration is allowed only when VLAN aware bridge is activated
|
|
After switching to iproute2 in commit 92f36735 ("ifconfig: T2653: use iproute2
commands for alias, mac and mtu set()/get()" it is necessary to return an empty
string as iproute2 returns None.
|
|
|
|
|
|
|
|
|
|
configured SLA-IDs
"data/templates/dhcp-client/ipv6.tmpl" handles the auto-assigning of SLA-IDs on
lines 39, 46, and 52.
|
|
"data/templates/dhcp-client/ipv6.tmpl" handles the auto-assigning of SLA-IDs on
lines 39, 46, and 52.
|
|
VLAN interfaces contain periods, which make them incompatible with
dict_search().
|
|
|
|
|
|
|
|
|
|
- remove redundant code paths apply_mirror() / apply_mirror_of_monitor()
- have single source available
|
|
The Linux Kernel supports enabling more cores for RPS then we actually have.
It does internal clipping/validation so there is no need for us to calculate
the specifc enable mask we can simply throw "all -1" at the Kernel.
|
|
|
|
set interfaces ethernet <interface> offload rps
|
|
|
