- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Aug 24 2022
PR https://github.com/vyos/vyos-1x/pull/1491
set nat66 destination rule 100 destination address '2001:1111:1111:1111::10' set nat66 destination rule 100 inbound-interface 'eth0' set nat66 destination rule 100 translation address 'fd00:1111:1111:1111::10' set nat66 source rule 100 destination prefix '!fd00:2222:2222:2222::/64' set nat66 source rule 100 outbound-interface 'eth0' set nat66 source rule 100 source prefix 'fd00:1111:1111:1111::/64' set nat66 source rule 100 translation address '2001:1111:1111:1111::10' set nat66 source rule 120 destination prefix '2001:db8:2222::/64' set nat66 source rule 120 outbound-interface 'eth0' set nat66 source rule 120 source prefix '2001:db8:1111::/64' set nat66 source rule 120 translation address 'masquerade' set nat66 source rule 130 destination prefix '2001:db8:2222::/64' set nat66 source rule 130 outbound-interface 'eth0' set nat66 source rule 130 source prefix '2001:db8:2244::/64' set nat66 source rule 130 translation address 'masquerade'
show
vyos@r14:~$ show nat66 source rules
Rule Source Destination Proto Out-Int Translation
------ ------------------------ ------------------------- ------- --------- -----------------------
100 fd00:1111:1111:1111::/64 !fd00:2222:2222:2222::/64 IP6 eth0 2001:1111:1111:1111::10
sport any dport any
120 2001:db8:1111::/64 2001:db8:2222::/64 IP6 eth0 masquerade
sport any dport any
130 2001:db8:2244::/64 2001:db8:2222::/64 IP6 eth0 masquerade
sport any dport any
vyos@r14:~$
vyos@r14:~$
vyos@r14:~$ show nat66 destination rules
Rule Source Destination Proto In-Int Translation
------ --------- ----------------------- ------- -------- -----------------------
100 ::/0 2001:1111:1111:1111::10 any eth0 fd00:1111:1111:1111::10
sport any dport any
vyos@r14:~$I am more +1 on set system ip(v6) nht because what happens if out of random another protocol will support this? Also it's a zebra option as you described, not a bgpd option.
Aug 23 2022
While reading the FRR docs I see it is only used in BGP and nowhere else. That would make something like set protocols bgp parameters next-hop-track resolve-via-default logical.
I prefer to get this option configurable if it is possible
For IPv6 and VRFs - nice to have.
As it is used in BGP, I see something like set protocols bgp parameters next-hop-track resolve-via-default
Or, as it was mentioned in T3500
set routing-options next-hop-track resolve-via-default but it will be an additional node with only one option, needs to think
@Viacheslav Do you just want this option added to the zebra config, or you it also be possible to enable/disable this via the conf mode?
PR https://github.com/vyos/vyos-1x/pull/1489
vyos@r14:~$ show conntrack statistics CPU Found Invalid Insert Insert fail Drop Early drop Errors Search restart ----- ------- --------- -------- --------------- ------ ------------ -------- ----------------- cpu=0 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 cpu=2 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 cpu=3 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=48 vyos@r14:~$
Check NGINX address/port before applying/committing service https
PR https://github.com/vyos/vyos-1x/pull/1488
@daniil, could you check/test this PR https://github.com/vyos/vyos-1x/pull/1487 (only for IPv4)
Aug 22 2022
I have confirmed that this issue is now resolved when building from equuleus. I've attached a screenshot showing the table for the dynamic interface has a default route after the interface get's an IP. I used the following commands to build the ISO.
I've create a PR which does the retry part. It retries 10 time every 0.5 seconds until it succeeds or it's out of retries.
Tested via:
This is what I did (forgot to write it here) with the difference that my sleep timer is 60s as my config has many lines.
Would be good to have this fixed properly.
I think I found the "problematic" commit.
https://github.com/vyos/vyos-1x/commit/41477cc85208507be55f8db4e412ad78eae764eb#diff-8e6f3b9122c8406707eb59334978290d083995acf7de0323111d4eed1656693dL311
The problem here seems to be that keepalived is started before the complete commit is finished. So conf.get_config_dict() fails to get the config.
With an older version:
vagrant@s1:~$ sudo bridge vlan
port vlan-id
eth1 1000 PVID Egress Untagged
eth2 1001 PVID Egress Untagged
br0 1 PVID Egress Untagged
1000
1001
vagrant@s1:~$ show versionI guess it the task T4632
Can confirm.
Created PR for this https://github.com/vyos/vyos-build/pull/256
Hi, I've created https://github.com/vyos/vyos-1x/pull/1483 for this one.
Aug 21 2022
Aug 20 2022
@c-po @itspngu , as mentioned above, we have held off on implementing the fix, as there is a compelling argument to disallow whitespace in tag node names, just as it is disallowed in node names in general; making an exception in the case of tag node names invites problems going forward. On the other hand, thanks to the details that you provided, @itspngu, we can implement a workaround for the case of ssh-copy-id; I know of no other instance of the problem. If we do find a necessary use case of whitespace in tag node names in the future, the simple fix can then be implemented.
PR https://github.com/vyos/vyos-1x/pull/1482
set nat66 destination rule 120 description 'foo' set nat66 destination rule 120 destination port '4545' set nat66 destination rule 120 inbound-interface 'eth0' set nat66 destination rule 120 protocol 'tcp' set nat66 destination rule 120 source address '2001:db8:2222::/64' set nat66 destination rule 120 source port '8080' set nat66 destination rule 120 translation address '2001:db8:1111::1' set nat66 destination rule 120 translation port '5555'
@itspngu you might try tomorrows rolling release and upgrade again. The issue should be resolved - it also helps us to see of the fix works!
There is a bug with such implementation check for openconnect
It is not possible to create the second user in another commit (as port already bonded)
vyos@r14# run show conf com | match vpn set vpn openconnect authentication local-users username foo password 'bar' set vpn openconnect authentication mode local 'password' set vpn openconnect listen-ports tcp '8443' set vpn openconnect listen-ports udp '8443' set vpn openconnect network-settings client-ip-settings subnet '100.64.0.0/24' set vpn openconnect network-settings name-server '100.64.0.1' set vpn openconnect ssl ca-certificate 'ca-ocserv' set vpn openconnect ssl certificate 'srv-ocserv' [edit] vyos@r14# commit No configuration changes to commit [edit] vyos@r14# sudo netstat -tulpn | grep 8443 tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 23880/ocserv-main tcp6 0 0 :::8443 :::* LISTEN 23880/ocserv-main udp 0 0 0.0.0.0:8443 0.0.0.0:* 23880/ocserv-main udp6 0 0 :::8443 :::* 23880/ocserv-main [edit] vyos@r14# set vpn openconnect authentication local-users username foo2 password 'bar2' [edit] vyos@r14# commit [ vpn openconnect ] "tcp" port "8443" is used by another service
In T4628#129192, @jestabro wrote:Note that a fix for 1.4 will address the user's issue, as he is updating to 1.4-rolling, so the migration will take place upon booting into 1.4.
It seems after this commit https://github.com/vyos/vyos-1x/commit/1b637f78b870f8ecc4971de5baf0a6fda54c40f7 for T4597
As the port already listens by ocserv itself, maybe we should revert it or change the logic to check that the port bind is not ocserv service
I can confirm this has been the reason I've had issues upgrading from 1.2.x to 1.3.x.
Removing this statement before attempting, I can now upgrade from 1.2 to 1.3 smoothly, no OOM errors or other problems.
Aug 19 2022
This is on hold, pending discussion on whether whitespace should be allowed in tag node names in 1.4.
The show command worked:
Note that a fix for 1.4 will address the user's issue, as he is updating to 1.4-rolling, so the migration will take place upon booting into 1.4.