@mersl thanks for confirm.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
May 29 2024
just some show commands with test results on my lab
very cool! I just rebuild a 1.5-rolling and upgraded my lab router and voila - works as expected ;-)
we've added this ability to configure the topology on isis :
Are you sure your DHCP server honors the no-default-route option?
I may be wrong, but I think the no-default-route just sets an option in the DHCP request, asking the DHCP server to not send back the default route.
I have the same issue with my ISP, and they told me they will always send a default route via DHCP.
I have solved the issue using DHCP hooks.
We will bind the code to a new command in operating mode (for example show ports). This will allow you to use the nmap command from operating mode. Just a convenient feature.
May 28 2024
Just dont, please see my comment fro april 2024.
@sever what about it?
May 27 2024
tested new cli structure, it combine the new mach-group and old syntax :
May 26 2024
This is actually a "wrong" error, or a real error with a wrong fix.
May 25 2024
cpo@LR5.wue4:~$ show configuration commands | match pki set pki ca STAGING-PEM certificate 'MIIFWzCCA0OgAwIBAgIQTfQrldHumzpMLrM7jRBd1jANBgkqhkiG9w0BAQsFADBmMQswCQYDVQQGEwJVUzEzMDEGA1UEChMqKFNUQUdJTkcpIEludGVybmV0IFNlY3VyaXR5IFJlc2VhcmNoIEdyb3VwMSIwIAYDVQQDExkoU1RBR0lORykgUHJldGVuZCBQZWFyIFgxMB4XDTIwMDkwNDAwMDAwMFoXDTI1MDkxNTE2MDAwMFowWTELMAkGA1UEBhMCVVMxIDAeBgNVBAoTFyhTVEFHSU5HKSBMZXQncyBFbmNyeXB0MSgwJgYDVQQDEx8oU1RBR0lORykgQXJ0aWZpY2lhbCBBcHJpY290IFIzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu6TR8+74b46mOE1FUwBrvxzEYLck3iasmKrcQkb+gy/z9Jy7QNIAl0B9pVKp4YU76JwxF5DOZZhi7vK7SbCkK6FbHlyU5BiDYIxbbfvOL/jVGqdsSjNaJQTg3C3XrJja/HA4WCFEMVoT2wDZm8ABC1N+IQe7Q6FEqc8NwmTSnmmRQm4TQvr06DP+zgFK/MNubxWWDSbSKKTH5im5j2fZfg+j/tM1bGaczFWw8/lSnukyn5J2L+NJYnclzkXoh9nMFnyPmVbfyDPOc4Y25aTzVoeBKXa/cZ5MM+WddjdLbiWvm19f1sYn1aRaAIrkppv7kkn83vcth8XCG39qC2ZvaQIDAQABo4IBEDCCAQwwDgYDVR0PAQH/BAQDAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTecnpI3zHDplDfn4Uj31c3S10uZTAfBgNVHSMEGDAWgBS182Xy/rAKkh/7PH3zRKCsYyXDFDA2BggrBgEFBQcBAQQqMCgwJgYIKwYBBQUHMAKGGmh0dHA6Ly9zdGcteDEuaS5sZW5jci5vcmcvMCsGA1UdHwQkMCIwIKAeoByGGmh0dHA6Ly9zdGcteDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQBgt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCNDLam9yN0EFxxn/3p+ruWO6n/9goCAM5PT6cC6fkjMs4uas6UGXJjr5j7PoTQf3C1vuxiIGRJC6qxV7yc6U0X+w0Mj85sHI5DnQVWN5+D1er7mp13JJA0xbAbHa3Rlczny2Q82XKui8WHuWra0gb2KLpfboYj1Ghgkhr3gau83pC/WQ8HfkwcvSwhIYqTqxoZUq8HIf3M82qS9aKOZE0CEmSyR1zZqQxJUT7emOUapkUN9poJ9zGc+FgRZvdro0XByphWXDaqMYph0DxW/10ig5j4xmmNDjCRmqIKsKoWA52wBTKKXK1na2ty/lW5dhtAxkz5rVZFd4sgS4J0O+zm6d5GRkWsNJ4knotGXl8vtS3X40KXeb3A5+/3p0qaD215Xq8oSNORfB2oI1kQuyEAJ5xvPTdfwRlyRG3lFYodrRg6poUBD/8fNTXMtzydpRgyzUQZh/18F6B/iW6cbiRN9r2Hkh05Om+q0/6w0DdZe+8YrNpfhSObr/1eVZbKGMIYqKmyZbBNu5ysENIK5MPc14mUeKmFjpN840VR5zunoU52lqpLDua/qIM8idk86xGWxx2ml43DO/Ya/tVZVok0mO0TUjzJIfPqyvr455IsIut4RlCR9Iq0EDTve2/ZwCuGhSjpTUFGSiQrR2JK2Evp+o6AETUkBCO1aw0PpQBPDQ==' set pki certificate vyos acme domain-name 'lr5.wue4.mybll.net' set pki certificate vyos acme email 'vyos@vyos.net' set pki certificate vyos acme url 'https://acme-staging-v02.api.letsencrypt.org/directory'
As far as I can tell the test will always error if the remote matches and neither source-interface and source-address are configured differently, including the case where they're both blank (source-interface == None on both tunnels triggers this particular case).
May 24 2024
I've just been picking at this one tonight because it's close to some areas of interest (DMVPNs in VRFs), so hopefully this input is useful and appropriate:
May 23 2024
May 22 2024
Same issue applies to NAT66, too
In T3493#189273, @Viacheslav wrote:Does 1.5 has the same bug?
Does 1.5 has the same bug?
PR merged: https://github.com/vyos/vyos-1x/pull/3499/
May 21 2024
PR merged into vyos-utils:
https://github.com/vyos/vyos-utils/pull/20
and backported. The fix has been tested with migration from 1.3.x with settings as suggested by @trae32566
The argument would be to relax the url validator regex for compatibility with 1.3: since the plan is to replace this mechanism in 1.5 with something similar to @trae32566 suggestion above (brought up for discussion by @Viacheslav recently), and since it is deprecated/not advised anyway (RFC 3986). The simple change will be made to the validator.
May 20 2024
@jestabro could it be that the validator needs an update to allow special characters in the user/password field?
https://github.com/vyos/vyos-utils/blob/0d57cc9a266fe8d6fc87df5a769f42b4a45c7221/src/url.ml
It seems to work basically
Can you manually edit the node and re-check if it will work for acme
sudo nano -c /opt/vyatta/share/vyatta-cfg/templates/pki/certificate/node.tag/acme/listen-address/node.def
replace:
type: txt
help: Local IPv4 addresses to listen on
val_help: ipv4; IPv4 address to listen for incoming connections
allowed: sh -c "${vyos_completion_dir}/list_local_ips.sh --ipv4"
syntax:expression: exec "${vyos_libexec_dir}/validate-value --exec \"${vyos_validators_dir}/ipv4-address \" --value \'$VAR(@)\'"; "Invalid value"to
type: txt help: Local IPv4 addresses to listen on val_help: ipv4; IPv4 address to listen for incoming connections
May 19 2024
@Giggum sure, much appreciated