It was implemented around a year ago https://github.com/vyos/vyos-1x/commit/e201454f073c9a92fb56b65f497eae55fc634521
Just need to check if it works as expected.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Apr 12 2024
In T6222#183247, @Chrisc-c-c wrote:Wouldn’t your suggested fix to https://vyos.dev/T6223 also apply here? If the plan is to validate interface name lengths and allow custom names this would be a non-issue.
CPU Quota and ipt_netflow are different tasks.
CPU limits could be part of this task https://vyos.dev/T3706
Apr 11 2024
Propose to add names for the interfaces:
set interfaces ethernet eth2 vif-s 100 vif-c 300 name if9999
An additional found old dhcp-client issue, does not properly support interface names with length > 13
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858580
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704072
@dex can you re-check?
It should execute the stop script if disable in config https://github.com/vyos/vyos-1x/blob/5d890037b177ce6971ac00f52e4cce2cac898f46/src/conf_mode/high-availability.py#L204-L206
Can someone re-check it in 1.5/1.3.6?
It can be working with set service dhcp-relay disable
Recheck and close it iff it was solved
Apr 10 2024
The minimal configuration to reproduce:
set interfaces ethernet eth0 address '192.168.122.14/24'
set policy local-route rule 101 destination '0.0.0.0/0' set policy local-route rule 101 set table 'local' set policy local-route rule 102 destination '0.0.0.0/0' set policy local-route rule 102 set table 'main' set policy local-route rule 104 destination '0.0.0.0/0' set policy local-route rule 104 set table '170'
@greywolfe, let us know if you have tested it.
Reopen if you still have the issue.
Close the task as there is no response from the author. And we don't have reports like this.
@vfreex Can you re-check to see if everything works as you expected?
It is another bug, it should be a separate bug report https://vyos.dev/T6223
I don't have any issues with your config, but my addresses (of course, I don't have all BGP VPN connections, etc.)
vyos@r4# set vrf name foo table 10101 [edit] vyos@r4# commit [edit] vyos@r4# [edit] vyos@r4# run show ver Version: VyOS 1.5-rolling-202404090019 Release train: current
@d.shleg As I mentioned the config is not applied by FRR
r4# show run bgpd Building configuration...
Could you try the latest rolling?
Your initial configuration and adding a new peer is not acceptable by FRR
vyos@r4# run show ver Version: VyOS 1.5-rolling-202404090019 Release train: current
vyos@r4# compare
[protocols bgp neighbor]
+ 10.177.75.2 {
+ peer-group "OVERLAY"
+ remote-as "64542"
+ }Probably the same task https://vyos.dev/T6097
Apr 9 2024
Mark it as resolved, reopen the task if required.
Was it fixed?
@MattK Could you re-check and close it?
@tjh Any updates?
By the way there is a new option
vyos@r4# set service conntrack-sync disable-syslog [edit] vyos@r4#
https://conntrack-tools.netfilter.org/manual.html#sync-aa
conntrackd allows you to deploy an symmetric Active-Active setup based on a static approach. For example, assume that you have two virtual IPs, vIP1 and vIP2, and two firewall replicas, FW1 and FW2. You can give the virtual vIP1 to the firewall FW1 and the vIP2 to the FW2.
@trae32566 Can you provide the next output?
sudo conntrackd -C /run/conntrackd/conntrackd.conf -s && echo "conntrack_count: " && sudo conntrack -C sudo conntrackd -C /run/conntrackd/conntrackd.conf -s network sudo conntrackd -C /run/conntrackd/conntrackd.conf -s cache sudo conntrackd -C /run/conntrackd/conntrackd.conf -s runtime sudo conntrackd -C /run/conntrackd/conntrackd.conf -s link sudo conntrackd -C /run/conntrackd/conntrackd.conf -s queue
PR https://github.com/vyos/vyos-1x/pull/3280
vyos@r15-left:~$ show conntrack statistics CPU Found Invalid Insert Insert fail Drop Early drop Errors Search restart ----- ------- --------- -------- ------------- ------ ------------ -------- ---------------- -- -- 0 0 280 0 1 1 0 1 0 2 0 1 0 73 0 0 0 0 126 0 1 0 vyos@r15-left:~$
Apr 8 2024
After deleting and adding the firewall, it looks good
So, for some reason, the rule 10 and default action accept were applied 2 times to the firewall
chain VYOS_FORWARD_filter {
type filter hook forward priority filter; policy accept;
counter packets 928376 bytes 1800341472 flow add @VYOS_FLOWTABLE_FLOWTABLE comment "ipv4-FWD-filter-10"
counter packets 928376 bytes 1800341472 accept comment "FWD-filter default-action accept"
counter packets 0 bytes 0 flow add @VYOS_FLOWTABLE_FLOWTABLE comment "ipv4-FWD-filter-10"
ct state { established, related } counter packets 0 bytes 0 flow add @VYOS_FLOWTABLE_FLOWTABLE comment "ipv4-FWD-filter-20"
counter packets 0 bytes 0 accept comment "FWD-filter default-action accept"
}Apr 7 2024
@Daya @trae32566 Any updates?
@indrajitr Can we close it?
@indrajitr Can we close it?
@Giggum Can you check it on 1.5?