| Age | Commit message (Collapse) | Author |
|---|
|
T2044: RPKI doesn't boot properly
|
|
|
|
T671: do not preserve old tech-support report implementation
|
|
|
|
T5576: Add BGP remove-private-as all option
|
|
op-mode: T5581: add "show ip nht" command (IPv4 nexthop tracking table)
|
|
vyos@vyos:~$ show ip nht
172.18.254.202
resolved via ospf
via 172.18.201.254, eth0.201 (vrf default), weight 1
Client list: bgp(fd 28)
|
|
frr: T5239: fix process startup order
|
|
Add the ability to use the option all for remove-private-as.
Remove private ASNs in outbound updates.
all - Apply to all AS numbers
set protocols bgp neighbor <tag> address-family ipv4-unicast remove-private-as all
|
|
T4309: Conntrack ignore fix to handle interface any
|
|
Interface 'any' not expected in nft rules, it means that option
iifname shouldn't exist at all
set system conntrack ignore ipv4 rule 10 inbound-interface 'any'
table ip raw {
chain VYOS_CT_IGNORE {
iifname "any" counter packets 0 bytes 0 notrack comment "ignore-10"
return
}
}
Fix it
|
|
|
|
- Reuse existing utility functions to check if a boot is ongoing
(boot_configuration_complete())
- Run system_frr.py script to configure FRR daemon before initial launch
- Add safety net to always have FRR running on the system
This does yet not solve the error in T5239 but it's a small step towards
the solution.
|
|
|
|
|
|
|
|
|
|
vxlan: T3700: Revert change to `vyos.utils.process.cmd`
|
|
|
|
T3655: Fix NAT problem with VRF
|
|
Linux netfilter patch https://patchwork.ozlabs.org/project/netfilter-devel/patch/d0f84a97f9c86bec4d537536a26d0150873e640d.1439559328.git.daniel@iogearbox.net/
adds direction support for conntrack zones, which makes it possible to
do NAT with conflicting IP address/port tuples from multiple, isolated tenants on a host.
According to the description of the kernel patch:
> ... overlapping tuples can be made unique with the zone identifier in
original direction, where the NAT engine will then allocate a unique
tuple in the commonly shared default zone for the reply direction.
I did some basic tests in my lab and it worked fine to forward packets
from eth0 to pppoe0.
- eth0 192.168.1.1/24 in VRF red
- pppoe0 dynamic public IP from ISP VRF default
- set vrf name red protocols static route 0.0.0.0/0 interface pppoe0 vrf 'default'
- set protocols static route 192.168.1.0/24 interface eth0 vrf 'red'
`conntrack -L` shows something like:
```
tcp 6 113 ESTABLISHED src=192.168.1.2 dst=1.1.1.1 sport=58946 dport=80 zone-orig=250 packets=6 bytes=391 src=1.1.1.1 dst=<my-public-ip> sport=80 dport=58946 packets=4 bytes=602 [ASSURED] mark=0 helper=tns use=1
```
It would be much appreciated if someone could test this with more
complex VRF setup.
|
|
|
|
T5567: Increase allowed range for maximum-object-size to 1GB for webproxy
|
|
T5564: Fix show firewall group and show firewall summary
|
|
The `rule` key could be not exists in the entry of the dictionary
for examppe `{'default_action': 'drop'}`
Fix it
|
|
T4309: Fix conntrack teamplate group
|
|
|
|
T5518: pim6: Fix smoketests
|
|
|
|
webproxy service
|
|
T5518: Add basic MLD support
|
|
T5562: Cleanup netns for smoketest load-balancing wan
|
|
Cleanup nets for the smoketest load-balancing
Remove deleting container interfaces from default netns as those
interfaces leave inly in netns.
|
|
|
|
container: T5563 Fix environment replaced by label
|
|
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'
|
|
|
|
T4072: add firewall bridge filtering.
|
|
T5554: Disable sudo for PAM RADIUS
|
|
Revert Sonar "Create build.yml"
|
|
login: T4754: show configured 2FA OTP key
|
|
Disable sudo for PAM RADIUS template that slows down the CLI commands
To fix it add:
session [default=ignore success=2] pam_succeed_if.so service = sudo
|
|
This reverts commit 7a99a59b338fecd73d34819a0a95646c054a0f12.
SonarCloud is not configured for now properly. Revert this
commit until we confiugre all properly if we'll use it in
the future.
|
|
Currently VyOS has `protocol igmp` option to enable IGMP querier and reports through FRR's pimd.
I would like to add support for IPv6 as well since FRR's IPv6 multicast functionality has significantly improved.
Enabling both MLD and IGMP on a VyOS router will allow us to turn on multicast snooping on layer-3 switches in dual-stack networks.
Example commands:
```
// Enable on interface eth0
set protocols pim6 interface eth0
// Explicitly join multicast group ff18::1234 on interface eth1
set protocols pim6 interface eth1 mld join ff18::1234
// Explicitly join source-specific multicast group ff38::5678 with source address 2001:db8::1 on interface eth1
set protocols pim6 interface eth1 mld join ff38::5678 source 2001:db8::1
```
|
|
smoketest: T5558: Extend configtest to allow checking of migration script results
|
|
forward chain and few matchers. Should be extended in the future.
|
|
results
|
|
|
|
T5412: Add support for extending config-mode dependencies in add-on packages
|
|
system: T5555: Fix time-zone migrator changing valid time-zones to UTC
|
