| Age | Commit message (Collapse) | Author |
|---|
|
In a service provider network a service provider typically supports multiple
bridge domains with overlapping vlans. One bridge domain per customer. Vlans in
each bridge domain are mapped to globally unique VXLAN VNI ranges assigned to
each customer.
Without the ability of VNI filtering, we can not provide VXLAN tunnels
with multiple tenants all requiring e.g. VLAN 10.
To Test:
set interfaces vxlan vxlan987 parameters external
set interfaces vxlan vxlan987 source-interface eth0
set interfaces vxlan vxlan987 parameters vni-filter
set interfaces vxlan vxlan987 vlan-to-vni 50 vni 10050
set interfaces vxlan vxlan987 vlan-to-vni 51 vni 10051
set interfaces vxlan vxlan987 vlan-to-vni 52 vni 10052
set interfaces vxlan vxlan987 vlan-to-vni 53 vni 10053
set interfaces vxlan vxlan987 vlan-to-vni 54 vni 10054
set interfaces vxlan vxlan987 vlan-to-vni 60 vni 10060
set interfaces vxlan vxlan987 vlan-to-vni 69 vni 10069
set interfaces bridge br0 member interface vxlan987
Add new op-mode command: show bridge vni
Interface VNI
----------- -----------
vxlan987 10050-10054
vxlan987 10060
vxlan987 10069
(cherry picked from commit 35f6033d21053fa420e837f157cd9377a4ccd26a)
|
|
In order to minimize the flooding of ARP and ND messages in the VXLAN network,
EVPN includes provisions [1] that allow participating VTEPs to suppress such
messages in case they know the MAC-IP binding and can reply on behalf of the
remote host. In Linux, the above is implemented in the bridge driver using a
per-port option called "neigh_suppress" that was added in kernel version 4.15.
[1] https://www.rfc-editor.org/rfc/rfc7432#section-10
(cherry picked from commit ec9a95502daa88b9632af12524e7cefebf86bab6)
|
|
As we have a bunch of options under "paramteres" already and "external" is
clearly one of them it should be migrated under that node as well.
(cherry picked from commit cc7ba8824a5e9ec818f0bbe7fb85e1713a591527)
|
|
(cherry picked from commit 719a3622f35a0596ffd8a0bd28c071fdaf930153)
|
|
FRR supports a new way of configuring VLAN-to-VNI mappings for EVPN-VXLAN, when
working with the Linux kernel. In this new way, the mapping of a VLAN to a VNI
is configured against a container VXLAN interface which is referred to as a
'Single VXLAN device (SVD)'.
Multiple VLAN to VNI mappings can be configured against the same SVD. This
allows for a significant scaling of the number of VNIs since a separate VXLAN
interface is no longer required for each VNI.
Sample configuration of SVD with VLAN to VNI mappings is shown below.
set interfaces bridge br0 member interface vxlan0
set interfaces vxlan vxlan0 external
set interfaces vxlan vxlan0 source-interface 'dum0'
set interfaces vxlan vxlan0 vlan-to-vni 10 vni '10010'
set interfaces vxlan vxlan0 vlan-to-vni 11 vni '10011'
set interfaces vxlan vxlan0 vlan-to-vni 30 vni '10030'
set interfaces vxlan vxlan0 vlan-to-vni 31 vni '10031'
(cherry picked from commit 7f6624f5a6f8bd1749b54103ea5ec9f010adf778)
|
|
cpo@leaf-02# show interfaces vxlan
+vxlan vxlan1 {
+ mtu 1500
+ parameters {
+ nolearning
+ }
+ port 4789
+ source-interface dum1
+ vni 100
+}
cpo@leaf-02# commit
[ interfaces vxlan vxlan1 ]
Group, remote or source-address must be configured
[[interfaces vxlan vxlan1]] failed
Extend verify() check to also honor source-interface definition.
|
|
`leaf_node_changed` returns `[]` (empty list) after a leaf node is
added.
e.g. Setting `source-interface` doesn't work on an existing vxlan
interface.
Steps to reproduce:
- Add a vxlan interface without `source-address` or `source-interface` options set:
```
set interfaces vxlan vxlan999 vni 999
set interfaces vxlan vxlan999 remote 192.168.100.100
commit
```
- Then set `source-address` or `source-interface`:
```
set interfaces vxlan vxlan999 source-interface eth0
commit
```
Actual result:
Source address or source-interface are not set:
```
ip -d link show dev vxlan999
76: vxlan999: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 56:08:ba:4d:4e:a8 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
vxlan id 999 remote 192.168.100.100 srcport 0 0 dstport 8472 tos inherit ttl 16 ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode none numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
```
Expected result:
```
77: vxlan999: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 9e:05:d9:58:1a:af brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
vxlan id 999 remote 192.168.100.100 dev eth0 srcport 0 0 dstport 8472 tos inherit ttl 16 ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode none numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
```
All invocations of leaf_node_changed() should be migrated to is_node_changes() if you are only interested in if something changed and don‘t care what exactly changed (content).
|
|
In some cases `source_address` can be not defined in the conf
So we should to check list of `remote` vxlanX addresses
If remote address is IPv6 - add overhead +20 bytes to default
overhead 50. I.e. +70 bytes for IPv6
|
|
|
|
ConfigTreeQuery()
When VyOS is booting and an interface is brought up (PPPoE) which requires a
user callback script that is executed asynchronously when the interface is up
we can not use Config(). The problem is, Config() is not available when
the system starts and the initial commit is still processed.
We need to move to ConfigTreeQuery() which was build for this exact same
purpose. TO reduce side effects and also dependencies on the entire
vyos.configdict library the set_level()/get_level() calls got eliminated
from within the library. All calls to functions like:
* get_removed_vlans()
* is_node_changed()
* leaf_node_changed()
* is_mirror_intf()
* ...
Now require that the full config path to the node is passed.
|
|
set interfaces vxlan vxlan0 parameters ip df <set|unset|inherit>
set interfaces geneve gnv0 parameters ip df <set|unset|inherit>
|
|
|
|
|
|
|
|
When changing "general" parameters like:
- interface IP address
- MTU
- description
the interface is destroyed and recreated ... this should not happen!
|
|
|
|
VXLAN does support using multiple remotes but VyOS does not. Add the ability
to set multiple remotes and add their flood lists using "bridge" command.
|
|
|
|
|
|
|
|
Background information [1]. Specifies whether an external control plane
(e.g. ip route encap/EVPN) or the internal FDB should be used.
[1]: https://legacy.netdevconf.info/2.2/slides/prabhu-linuxbridge-tutorial.pdf
|
|
|
|
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.
|
|
|
|
Introduced in commit 818a75c024e ("ifconfig: T2653: get_mtu() should return
int() for easier comparison") where the variable used in the formatted string
has not been adjusted.
|
|
Using an MTU less then the required 1280 bytes (as per RFC) on an interface
where IPv6 is not explicitly disabled by:
- set interfaces ethernet eth1 ipv6 address no-default-link-local
- not having any other IPv6 address configured
Will now trigger a commit error via verify() instead of raising
FileNotFoundError!
|
|
|
|
A lot of derived classes from Interface implemented their own get_config()
method which more or less was the same everywhere. We also hat different
qualifiers like @staticmethod or @classmethod.
This is now changed to only have the @classmethod in Interface base class which
will return the necessary dictionary keys for the required interfaces. This
change is a mid reduction in lines of code which is always a very nice thing!
|
|
|
|
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.
|
|
airbag must now be explicitly installed.
the patch also allow to fully disables the installation of the logging
code at setup (and not just installing and doing nothing)
|
|
To make SLAAC and DHCPv6 work when forwarding=1, accept_ra must be 2
(default for accept_ra is 1).
|
|
|
|
- make error output more user friendly
- replace .format with f-strings
- split into lines less than ~80 characters long
|
|
Previously, the interface was always deleted and recreated, which
removed it from the bridge.
- always re-add the interface back to any bridge it is part of
|
|
Bridge members should not have any addresses assigned.
|
|
- rewrite the function to support both bridge and bonding interface types,
if the type is passed it searches only that type, otherwise it searches
both
- move is_member check out of the deleted condition
- move is_member check to intf_from_dict for interfaces that use it
|
|
|
|
|
|
|
|
|
|
|
|
This is a base requirement for l2vpn evpn. When source-address is configured,
the option "local <source-addr> nolearning" is appended when creating the
interface as mentioned here: https://vincent.bernat.ch/en/blog/2017-vxlan-bgp-evpn
|
|
This reverts commit 195e1da6a518ee3a2cbc0e1d454317e3c05e3e6e.
|
|
|
|
Interfaces enslaved to a bridge are not allowed to be deleted. If an interface
is deleted from the config but it is still enslaved to a bridge will cause a
configuration error on the subsequent boot.
|
|
This is a low level requirement for supporting l2vpn evpn.
|
|
|
|
Autoconfigure addresses using Prefix Information in Router Advertisements.
|
|
|
