Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
appropriate transfer procedure
|
|
transfer functions
|
|
|
|
As we can also use the TunnelIf() class from op-mode we must ensure that read-only
access to the class works even if required configuration keys as "encapsulation"
are not passed to the class on invokation.
This fixes an isse where "show interfaces tunnel" returned:
Traceback (most recent call last):
File "/usr/libexec/vyos/op_mode/show_interfaces.py", line 313, in <module>
args.vrrp
File "/usr/libexec/vyos/op_mode/show_interfaces.py", line 48, in handled_function
function(*args, **kwargs)
File "/usr/libexec/vyos/op_mode/show_interfaces.py", line 222, in run_show_intf_brief
for interface in filtered_interfaces(ifnames, iftypes, vif, vrrp):
File "/usr/libexec/vyos/op_mode/show_interfaces.py", line 77, in filtered_interfaces
interface = klass(ifname, create=False, debug=False)
File "/usr/lib/python3/dist-packages/vyos/ifconfig/tunnel.py", line 99, in __init__
if self.iftype in ['gretap', 'ip6gretap']:
AttributeError: 'TunnelIf' object has no attribute 'iftype'
|
|
Commit e5b335830ef ("vyos.ifconfig: T1579: remove calls to
vyos.ifconfig.Interface.get_config()") removed the PPPoEIf class as it seemed
to be unused. It turns out it is required by the op-mode commands for e.g. "show
interfaces".
|
|
dhcp: T3300: add DHCP default route distance
|
|
|
|
Support setting additional options to the GENEVE tunnel like:
- ttl
- tos
- do not fragment bit
- ipv6 flowlabel
|
|
Verify proper configuration of VXLAN parameters for
- source-interface
- source-address
- remote
- vni
- group
Before it was only verified if the VXLAN tunnel interface was configured
at all but not if the parameters are correct, too.
|
|
When a VIF/VLAN interface is placed in admin down state but the lower
interface, serving the vlan, is moved from admin down -> admin up, all its
vlan interfaces will be placed in admin up state, too.
This is bad as a VLAN interface will become admin up even if its specified as
admin down after a reboot.
To reproduce:
set interfaces ethernet eth1 vif 20 disable
set interfaces ethernet eth1 disable
commit
delete interfaces ethernet eth1 disable
commit
Now check the interface state and it returns UP,LOWER_UP
7: eth1.20@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:50:56:b3:09:07 brd ff:ff:ff:ff:ff:ff
inet6 fe80::250:56ff:feb3:907/64 scope link
valid_lft forever preferred_lft forever
|
|
There had been four implementations of "ip -d -j link show interface" scattered
accross the codebase. Those implementations have now been combined into a new
helper:
vyos.util.get_json_iface_options()
|
|
|
|
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.
|
|
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
|