PR https://github.com/vyos/vyos-1x/pull/1442
>>> from vyos.util import rc_cmd
>>>
>>> rc_cmd('uname')
(0, 'Linux')
>>>
>>> rc_cmd('ip link show dev fake')
(1, 'Device "fake" does not exist.')
>>>Ex2
>>> rc, command = rc_cmd('ip link show dev eth999')
>>>
>>>
>>> print(rc)
1
>>> print(command)
Device "eth999" does not exist.
>>>True, marking packets can help. I would only be very careful because we use marks a lot for PBR, LB, etc. Not sure if they can conflict with each other. Also, the performance is the question - better to check how marking each packet on an interface affects it.
The reason I set an MTU is because I get the following error when unset:
WARNING: RFC7348 recommends VXLAN tunnels preserve a 1500 byte MTU
VyOS 1.3-stable-202207280515 is not affected and works as expected
vyos@r14:~$ show vpn ipsec sa Connection State Uptime Bytes In/Out Packets In/Out Remote address Remote ID Proposal ------------------------- ------- -------- -------------- ---------------- ---------------- ----------- -------------- peer-192.0.2.2-tunnel-0 up 9s 0B/0B 0/0 192.0.2.2 N/A AES_GCM_16_256 peer-2001:db8::2-tunnel-0 up 9s 0B/0B 0/0 2001:db8::2 N/A AES_GCM_16_256 vyos@r14:~$
SAs
vyos@r14:~$ sudo swanctl -l
peer-2001:db8::2-tunnel-0: #4, ESTABLISHED, IKEv2, bae267e189f183be_i 008bf75c872ced6a_r*
local '2001:db8::1' @ 2001:db8::1[500]
remote '2001:db8::2' @ 2001:db8::2[500]
AES_GCM_16-256/PRF_HMAC_SHA2_256/MODP_2048
established 25s ago, rekeying in 85328s
peer-2001:db8::2-tunnel-0: #3, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-256
installed 25s ago, rekeying in 28178s, expires in 28775s
in c762627a, 0 bytes, 0 packets
out c2278f63, 0 bytes, 0 packets
local 2001:db8:1111::/64
remote 2001:db8:2222::/64
peer-192.0.2.2-tunnel-0: #3, ESTABLISHED, IKEv2, c923210fb14e11d5_i 2450ab183218d566_r*
local '192.0.2.1' @ 192.0.2.1[500]
remote '192.0.2.2' @ 192.0.2.2[500]
AES_GCM_16-256/PRF_HMAC_SHA2_256/MODP_2048
established 25s ago, rekeying in 85526s
peer-192.0.2.2-tunnel-0: #4, reqid 2, INSTALLED, TUNNEL, ESP:AES_GCM_16-256
installed 25s ago, rekeying in 27722s, expires in 28775s
in c1892b7b, 0 bytes, 0 packets
out c8fbbb2f, 0 bytes, 0 packets
local 100.64.0.0/24
remote 100.64.55.0/24
vyos@r14:~$I have it working between VyOS 1.4-rolling-202207280217 (kernel 5.10.133) and VyOS 1.3-stable-202207280515 (kernel 5.4.205)
Will it work if you replace this https://github.com/vyos/vyos-1x/blob/4168e03721b2a9595de4090fddf1280d39ccce4c/python/vyos/ifconfig/interface.py#L1378-L1379
sudo nano -c +1385 /usr/lib/python3/dist-packages/vyos/ifconfig/interface.py
with:
PR https://github.com/vyos/vyos-1x/pull/1441
vyos@r14:~$ show nat source statistics Rule Packets Bytes Interface ------ --------- ------- ----------- 10 5 380 eth0 20 0 0 any 30 0 0 any 40 0 0 eth0 40 0 0 eth0 vyos@r14:~$
I have no proof now of any obvious negative issues. Moreover, in my personal opinion - if some protocol or interface type requires a default MTU that is not assigned to it by the kernel, this is the problem that should be solved by configuration script for that particular interface.
Is there any chance to fix that ?
The latest version of the demo can be found here:
Tested locally and receive sflow with agent IP of the configured ip/interface/vrf.
Will it affect also tunnels/openvpn/wireguard/vxlan etc?
If you get rid of the default MTU values you get more pain.
I can reproduce it:
Here is my WG config:
set interfaces wireguard wg2 address 'REDACTED_IPV6/64' set interfaces wireguard wg2 peer mypeer address 'REDACTED_IPV4' set interfaces wireguard wg2 peer mypeer allowed-ips '::/0' set interfaces wireguard wg2 peer mypeer persistent-keepalive '60' set interfaces wireguard wg2 peer mypeer port '51820' set interfaces wireguard wg2 peer mypeer public-key 'REDACTED' set interfaces wireguard wg2 private-key 'REDACTED' set interfaces wireguard wg2 vrf 'test'
VyOS config:
set nat source rule 10 destination address '192.0.2.0/24' set nat source rule 10 exclude set nat source rule 10 outbound-interface 'any' set nat source rule 10 protocol 'all' set nat source rule 10 source address '0.0.0.0/0' set nat source rule 100 outbound-interface 'eth0' set nat source rule 100 source address '203.0.113.0/24' set nat source rule 100 translation address masquerade
The bug is still here:
vyos@r14# run show nat source rules
Traceback (most recent call last):
File "/usr/libexec/vyos/op_mode/nat.py", line 157, in <module>
res = vyos.opmode.run(sys.modules[__name__])
File "/usr/lib/python3/dist-packages/vyos/opmode.py", line 118, in run
res = func(**args)
File "/usr/libexec/vyos/op_mode/nat.py", line 152, in show_rules
return _get_formatted_output_rules(nat_rules, direction)
File "/usr/libexec/vyos/op_mode/nat.py", line 103, in _get_formatted_output_rules
sport {sport}'''
UnboundLocalError: local variable 'sport' referenced before assignment
[edit]
vyos@r14#It seems not related to kernel and definitely another bug
vyos@r14# run show conf com | match bri set interfaces bridge br0 enable-vlan set interfaces bridge br0 member interface eth1 allowed-vlan '5-50' set interfaces bridge br0 member interface eth1 native-vlan '5' [edit] vyos@r14# [edit] vyos@r14# run show bridge vlan port vlan-id br0 1 PVID Egress Untagged [edit] vyos@r14#
@aderouineau Describe please all steps of how to reproduce it (with commands set xxx)
I don't have any issues with it
set interfaces vxlan vxlan0 group '239.0.0.241' set interfaces vxlan vxlan0 mtu '1370' set interfaces vxlan vxlan0 port '4789' set interfaces vxlan vxlan0 source-interface 'wg0' set interfaces vxlan vxlan0 vni '123' set interfaces wireguard wg0 address '100.64.0.1/24' set interfaces wireguard wg0 peer PEER01 allowed-ips '0.0.0.0/0' set interfaces wireguard wg0 peer PEER01 public-key 'VVfR5S0yi+QPEJRLr25ZAfzFnwZM40G5WCZ/7ou7h3k=' set interfaces wireguard wg0 private-key 'yGOy08Kv8KUe8rsO6WHeo5jC7YdOAzQK0SJkDFQWlmA='
PR https://github.com/vyos/vyos-1x/pull/1435
vyos@r14:~$ show bridge Bridge interface br0: Member State MTU Flags Prio -------- ---------- ----- ------------------------------- ------ dum0 forwarding 1500 broadcast,noarp,up,lower_up 32 eth1.30 forwarding 1500 broadcast,multicast,up,lower_up 32 eth1.55 forwarding 1500 broadcast,multicast,up,lower_up 32
Mark as resolved as a i have tested it on 1.4-rolling-202207260217 and has been merged
@n.fort source-address is useful especially when more precision is needed. At the moment its use is cumbersome as it does not provide help hint on the addresses assigned to the router, forcing an operator to first list those addresses.
As of 1.4-rolling-202207250217 this is still not resolved.
I can confirm that at least as of version 1.4-rolling-202207250217the op commands have been merged:
vyos@vyos-lab:~$ reset bgp Possible completions: <x.x.x.x> BGP IPv4/IPv6 neighbor to clear <h:h:h:h:h:h:h:h> 1-4294967295 Reset peers with the AS number all Clear all peers external Reset all external peers ipv4 IPv4 Address Family ipv6 IPv6 Address Family l2vpn Layer 2 Virtual Private Network Address Family peer-group Reset all members of peer-group prefix Clear bestpath and re-advertise vrf Virtual Routing and Forwarding (VRF)
@c-po which one is the new syntax?
@Viacheslav i believe this one can be closed ge and le where inverted order until i found out the error.
Agree that both options are not available in cli.. But, you can use source-address: