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:~$
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:
I can't reproduce it (VyOS 1.4-rolling-202207220217):
set policy prefix-list BARRA32 rule 5 action 'permit' set policy prefix-list BARRA32 rule 5 ge '32' set policy prefix-list BARRA32 rule 5 le '32' set policy prefix-list BARRA32 rule 5 prefix '0.0.0.0/0' set policy prefix-list UTRSv4s25 rule 5 action 'permit' set policy prefix-list UTRSv4s25 rule 5 le '25' set policy prefix-list UTRSv4s25 rule 5 prefix '0.0.0.0/0' set policy prefix-list6 BARRA128 rule 5 action 'permit' set policy prefix-list6 BARRA128 rule 5 ge '128' set policy prefix-list6 BARRA128 rule 5 le '128' set policy prefix-list6 BARRA128 rule 5 prefix '::/0' set policy prefix-list6 UTRSv6s49 rule 5 action 'permit' set policy prefix-list6 UTRSv6s49 rule 5 le '49' set policy prefix-list6 UTRSv6s49 rule 5 prefix '::/0'
Will be fixed with syntax migration in T4118
@NikolayP Try the next command:
It will be fixed in T4545
PR https://github.com/vyos/vyos-1x/pull/1426