vyos-1x.git/python/vyos/ifconfig, branch currentVyOS command definitions, scripts, and utilities (mirror of https://github.com/marekm72/vyos-1x.git)
https://git.amelek.net/marekm72/vyos-1x.git/atom?h=current2024-10-17T09:30:28+00:00T4583: Rewrite VRRP op-mode to vyos.opmode format2024-10-17T09:30:28+00:00khramshinrkhramshinr@gmail.com2024-10-17T09:30:28+00:00urn:sha1:a5a484a50f976b4df7abd0a00a89dfb1512d84cb
reformat file by linter rules
T4583: Rewrite VRRP op-mode to vyos.opmode format2024-10-17T09:11:45+00:00khramshinrkhramshinr@gmail.com2024-10-15T11:37:13+00:00urn:sha1:e42e32d48489329686ce6642848b189c0d262196op-mode: T4833: Include wireguard peer name in interface summary report2024-09-20T10:46:10+00:00Nataliia Solomkonatalirs1985@gmail.com2024-09-20T10:13:26+00:00urn:sha1:c6062ef100f20e2cc3e5ed9c4d145d4d969741e4wireless: T6709: fix missing wpa_supplicant configuration2024-09-19T19:26:38+00:00Christian Breunigchristian@breunig.cc2024-09-19T19:26:38+00:00urn:sha1:58dfd957fd8ec24caeca73105f7823148ef8c8bf
Commit 0ee8d5e35 ("ethernet: T6709: move EAPoL support to common framework")
added support to also have EAPoL on other interface types then ethernet. This
introduced a regression where the wireless interface wpa_supplicant configuration
would get deleted.
ethernet: T6709: move EAPoL support to common framework2024-09-14T20:50:20+00:00Christian Breunigchristian@breunig.cc2024-09-14T20:18:54+00:00urn:sha1:0ee8d5e35044e7480dac6a23e92d43744b8c5d36
Instead of having EAPoL (Extensible Authentication Protocol over Local Area
Network) support only available for ethernet interfaces, move this to common
ground at vyos.ifconfig.interface making it available for all sorts of
interfaces by simply including the XML portion
#include <include/interface/eapol.xml.i>
Merge pull request #3221 from lucasec/t58732024-08-01T11:08:36+00:00Christian Breunigchristian@breunig.cc2024-08-01T11:08:36+00:00urn:sha1:962ead698e191ff413aaa1585270dfed48100547
T5873: ipsec remote access VPN: support VTI interfaces.T5873: vpn ipsec: re-write of ipsec updown hook2024-07-27T01:26:30+00:00Lucas Christianlucas@lucasec.com2024-07-04T06:14:45+00:00urn:sha1:376e2d898f26c13a31f80d877f4e2621fd6efb0finterface: T6592: remove interface from conntrack ct_iface_map on deletion2024-07-23T17:03:07+00:00Christian Breunigchristian@breunig.cc2024-07-23T17:03:07+00:00urn:sha1:17c12bde5c6f314311e7524842fd1ddc254009b4
We always have had stale interface entries in the ct_iface_map of nftables/
conntrack for any interface that once belonged to a VRF.
This commit will always clean the nftables interface map when the interface
is deleted from the system.
interfaces: T6592: moving an interface between VRF instances failed2024-07-20T09:46:28+00:00Christian Breunigchristian@breunig.cc2024-07-20T08:35:44+00:00urn:sha1:452068ce78581bb6fba2df4dba197e95b9aeb33d
To reproduce:
set vrf name mgmt table '150'
set vrf name no-mgmt table '151'
set interfaces ethernet eth2 vrf 'mgmt'
commit
set interfaces ethernet eth2 vrf no-mgmt
commit
This resulted in an error while interacting with nftables:
[Errno 1] failed to run command: nft add element inet vrf_zones ct_iface_map { "eth2" : 151 }
The reason is that the old mapping entry still exists and was not removed.
This commit adds a new utility function get_vrf_tableid() and compares the
current and new VRF table IDs assigned to an interface. If the IDs do not
match, the nftables ct_iface_map entry is removed before the new entry is added.
vxlan: T6505: Support VXLAN VLAN-VNI range mapping in CLI (#3756)2024-07-08T15:51:40+00:00Nataliia S81954790+natali-rs1985@users.noreply.github.com2024-07-08T15:51:40+00:00urn:sha1:115e99630a317cab62c6f99e0461f6ce2c1edaf3