@jvoss Add the PR, please
Thanks.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 25 2023
Spot on Viacheslav! That absolutely resolved the issue, thanks! I was initially thinking it might have been the key_mangling option. Glad to see there is another option here.
Try to add no_tag_node_value_mangle there https://github.com/vyos/vyos-1x/blob/20b7155f4140f54cf7669256160b6fedd8c1ab7a/src/conf_mode/protocols_static.py#L50
Doing some more digging it turned out that VyOS doesnt support nested routing so the gateway must be reachable (at least IP-address wise) through a physical interface - I have updated the script in the original post to adjust for that (added variable GATEWAY).
@dongjunbo It requires more tests and reviews
Fix for 1.4: https://github.com/vyos/vyos-1x/pull/2109
Would you please backport this feature to VyOS 1.3.x?
Jul 24 2023
I would find something like this very easy to use:
Re opening this task. Migration script needs to be added.
Do you have any idea for the CLI?
But they shouldnt take several minutes and this alone can be a reason for why not putting VyOS into production.
Long commit time does not depend on the number of static routes, but on a size of the configuration or number of lines in the configuration. If a router has a large configuration (not necessarily static routes), committing any changes takes several minutes.
Jul 23 2023
Am I supposed to create data/template/dhcp-client/dhcp6c_daemon-options.j2 by hand? I tried to run make to try and create the template, then go from there & fill out the template like in daemon-options.j2. But my dev env is borked, and I'm starting to think that inside a VyOS instance is also where I'm supposed to do this.
Jul 22 2023
Out of the blue I think its a bad thing to throw stuff into the kernelmode for the fun of it.
My proposal after some testing:
Jul 21 2023
Thank you c-po. When we will get the binary?
Regards,
Vishvas
vyos@nat-lb-july# run show config comm | grep nat set nat destination rule 10 destination port '443' set nat destination rule 10 inbound-interface 'eth3' set nat destination rule 10 protocol 'tcp' set nat destination rule 10 translation load-balance mode 'round-robin' set nat destination rule 10 translation load-balance translation-address 1.1.1.1 hash-value '0' set nat destination rule 10 translation load-balance translation-address 2.2.2.2 hash-value '1' set nat destination rule 10 translation load-balance translation-address 3.3.3.3 hash-value '2' set nat destination rule 10 translation load-balance upper-limit '3' set nat destination rule 20 destination port '53' set nat destination rule 20 inbound-interface 'eth3' set nat destination rule 20 protocol 'udp' set nat destination rule 20 translation load-balance mode 'random' set nat destination rule 20 translation load-balance translation-address 1.1.1.1 hash-value '0-24' set nat destination rule 20 translation load-balance translation-address 2.2.2.2 hash-value '25-49' set nat destination rule 20 translation load-balance translation-address 3.3.3.3 hash-value '50-99' set nat destination rule 20 translation load-balance upper-limit '100' set system host-name 'nat-lb-july' [edit]
Proposed syntax one of them
set system option time-format 12|24 set system option time-format 12-hour|24-hour set system option time-format us|gb
Actually, it should configure:
sudo localectl set-locale LC_TIME="en_GB.UTF-8" sudo localectl set-locale LC_TIME="en_US.UTF-8"
Hmm, fair enough. Maybe just executing the stop script and then committing set high-availability disable is enough for maintenance periods.
One general question though out of curiosity: What are the circumstances in which the stop script is executed in the first place?
PR for 1.3: https://github.com/vyos/vyos-1x/pull/2106
Maybe it is the wrong way. I think it shouldn't touch anything in the disable state.
To reproduce the problem:
PR https://github.com/vyos/vyos-1x/pull/2105
set system sflow interface 'eth0' set system sflow interface 'eth1' set system sflow server 127.0.0.1