| Age | Commit message (Collapse) | Author |
|---|
|
|
|
No need to have two distinct include blocks as one superseeds the other. Also
this makes the entire behavior of "description" CLI node simpler.
|
|
<name> interface <ifname>`
* Include refactor to policy route to allow for deletion of mangle table instead of complex cleanup
* T4605: Rename mangle table to vyos_mangle
|
|
Reduce CPU time when spawning the python interpreter. Same can be done by the
numeric validator.
|
|
firewall node
* Refactor firewall and zone-policy rule creation and cleanup
* Migrate interface firewall values to `firewall interfaces <name> <direction> name/ipv6-name <name>`
* Remove `firewall-interface.py` conf script
|
|
This PR adds an config option to enable/disable IGMP/MLD snooping.
```
set interfaces bridge brN igmp snooping
```
|
|
|
|
"set traffic-policy" now becomes "set qos policy"
"set interface ethernet eth0 traffic-policy" now bvecomes "set qos interface eth0"
|
|
|
|
Since introducing the XML <defaultValue> node it was common, but redundant,
practice to also add a help string indicating which value would be used as
default if the node is unset.
This makes no sense b/c it's duplicated code/value/characters and prone to
error. The node.def scripts should be extended to automatically render the
appropriate default value into the CLI help string.
For e.g. SSH the current PoC renders:
$ cat templates-cfg/service/ssh/port/node.def
multi:
type: txt
help: Port for SSH service (default: 22)
val_help: u32:1-65535; Numeric IP port
...
Not all subsystems are already migrated to get_config_dict() and make use of
the defaults() call - those subsystems need to be migrated, first before the new
default is added to the CLI help.
|
|
There is spelling mistake in "advertisement" of hello-time option's
completion help
|
|
|
|
|
|
|
|
|
|
Private VLAN, also known as port isolation, is a technique in computer
networking where a VLAN contains switch ports that are restricted such that
they can only communicate with a given "uplink". The restricted ports are
called "private ports".
Each private VLAN typically contains many private ports, and a single uplink.
The uplink will typically be a port (or link aggregation group) connected to a
router, firewall, server, provider network, or similar central resource.
Q: https://en.wikipedia.org/wiki/Private_VLAN
|
|
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.
|
|
|
|
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
|
|
|
|
1. Due to the previous focus on the implementation of VLAN filter, it was not considered to include MTU settings, which will lead to MTU setting errors in some cases
2. In order to make VLAN aware of the work of the bridge, it is necessary to specify the allowed VLAN ID range for the bridge itself, and forget to join it before
|
|
|
|
|
|
This reduces duplicated #include statements as each interface type already
contained the individual includes.
|
|
The current implementation for bridge based interfaces has an issue which is
caused by priority inheritance. We always assumed that the bridge interface will
be created last, but this may not be true in all cases, where some interfaces
will be created "on demand" - e.g. OpenVPN or late (VXLAN, GENEVE).
As we already have a bunch of verify steps in place we should not see a bridge
interface leak to the underlaying infrastructure code. This means, whenever an
interface will be member of a bridge, and the bridge does yet not exist, we will
create it in advance in the interface context, as the bridge code will be run
in the same commit but maybe sooner or later.
This will also be the solution for T2924.
|
|
|
|
The current VyOS CLI parser code written in Python contains a ton of duplicates
which I can also hold myself accountable for - or maybe mainly me - depends on
the angle of judge.
While providing a new update() method in vyos.ifconfig.interfaces() this is
extended for bridge interfaces in the derived bridge class.
Signed-off-by: Christian Poessinger <christian@poessinger.com>
|
|
|
|
|
|
Every interface on the system can be a member of a bridge - thus the bridge
interface must be the one interface which has the highest priority
compared to all other interfaces - incl. l2tpv3.
With this change the system boots up fine with also l2tpv3 interfaces
participating as bridge members. This change was needed as a l2tpv3 interface
requires proper configured routing oin the system, else adding the
interface will fail miserably:
FileNotFoundError: [Errno 2] ip l2tp add tunnel tunnel_id 200
peer_tunnel_id 100 udp_sport 4000 udp_dport 3000 encap udp
local 172.18.201.10 remote 172.18.203.10
returned: RTNETLINK answers: Network is unreachable
|
|
Autoconfigure addresses using Prefix Information in Router Advertisements.
|
|
... to new XML and Python based frontend/backend.
|
|
|
|
|
|
Provide an XML/Python abstraction to
* ip disable-arp-filter
* ip enable-arp-accept
* ip enable-arp-announce
* ip enable-arp-ignore
The old implementation can co-exist until the last interfaces have been
migrated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
As 219779b ("T1843: run interface-definitions though GCC preprocessor")
implemented the foundation of using the GCC preprocessor to make our XML
definitions more lightweight this commit transforms the configuration of DHCP/
DHCPv6 configuration options to this new style. It implementes it for the
following interface types:
* bonding
* bridge
* ethernet
* wireless
* vif/vif-s interfaces
|
|
|
|
As 219779bc6151 ("T1843: run interface-definitions though GCC preprocessor")
implemented the foundation of using the GCC preprocessor to make our XML
definitions more lightweight this commit transforms the configuration of
an IPv4/IPv6 address to this new style. It implementes it for the following
interface types:
* bond
* bridge
* dummy
* ethernet
* geneve
* loopback
* vxlan
* wireguard
* wireless
|
|
A lot of XML code is duplicated (VLAN, interface address) for instance. Such
XML definitions should be moved to feature.xml.i files and then just pulled in
via GCC preprocessor #include definition in e.g. bond or ethernet definitions.
This will give us the ability to single-source repeating node definitions as:
* Interface Address
* Interface Description
* Interface Disable
* VLAN (both vif-s and vif-c)
The .in suffix of the interface-definitions is a marker that those files are
input files to the GCC preprocessor. They will be rendered into proper XML
files in the build directory.
Some node definitions have been reworder to remove escaped double quote
occurances which would have been warned about by the GCC preprocessor.
|
