@dongjunbo What do you mean?
Could you send a real example? I don't see any issues (VyOS 1.3-stable-202207280515).
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Jul 30 2022
Jul 30 2022
Viacheslav changed the subtype of T4375: hairpin nat (nat reflector) "hijacks" all outgoing traffic on specified port to any destination from "Bug" to "Feature Request".
Viacheslav changed the status of T4578: Rewrite show dns forwarding statistics to new format, a subtask of T4564: Root task for rewriting [op-mode] to vyos.opmode format, from Open to In progress.
Viacheslav changed the status of T4578: Rewrite show dns forwarding statistics to new format from Open to In progress.
PR https://github.com/vyos/vyos-1x/pull/1446
vyos@r14:~$ show dns forwarding statistics Cache entries Max cache entries Cache size --------------- ------------------- ------------ 71 10000 20.22 kbytes vyos@r14:~$
Raw:
vyos@r14:~$ /usr/libexec/vyos/op_mode/dns.py show_forwarding_statistics --raw
{
"aggressive-nsec-cache-entries": "0",
"aggressive-nsec-cache-nsec-hits": "0",
"aggressive-nsec-cache-nsec-wc-hits": "0",
"aggressive-nsec-cache-nsec3-hits": "0",
"aggressive-nsec-cache-nsec3-wc-hits": "0",
"all-outqueries": "48",
"answers-slow": "0",
"answers0-1": "0",
"answers1-10": "0",
"answers10-100": "0",
"answers100-1000": "0",
"auth-zone-queries": "0",
"auth4-answers-slow": "0",
"auth4-answers0-1": "0",
"auth4-answers1-10": "0",
"auth4-answers10-100": "20",
"auth4-answers100-1000": "9",
"auth6-answers-slow": "0",
"auth6-answers0-1": "19",
"auth6-answers1-10": "0",
"auth6-answers10-100": "0",
"auth6-answers100-1000": "0",
"cache-entries": "71",
"cache-hits": "0",
"cache-misses": "0",
"case-mismatches": "0",
"chain-resends": "0",
"client-parse-errors": "0",
"concurrent-queries": "0",
"cpu-iowait": "10857",
"cpu-msec-thread-0": "1242",
"cpu-steal": "672",
"dlg-only-drops": "0",
"dnssec-authentic-data-queries": "0",
"dnssec-check-disabled-queries": "0",
"dnssec-queries": "0",
"dnssec-result-bogus": "0",
"dnssec-result-bogus-invalid-denial": "0",
"dnssec-result-bogus-invalid-dnskey-protocol": "0",
"dnssec-result-bogus-missing-negative-indication": "0",
"dnssec-result-bogus-no-rrsig": "0",
"dnssec-result-bogus-no-valid-dnskey": "0",
"dnssec-result-bogus-no-valid-rrsig": "0",
"dnssec-result-bogus-no-zone-key-bit-set": "0",
"dnssec-result-bogus-revoked-dnskey": "0",
"dnssec-result-bogus-self-signed-ds": "0",
"dnssec-result-bogus-signature-expired": "0",
"dnssec-result-bogus-signature-not-yet-valid": "0",
"dnssec-result-bogus-unable-to-get-dnskeys": "0",
"dnssec-result-bogus-unable-to-get-dss": "0",
"dnssec-result-bogus-unsupported-dnskey-algo": "0",
"dnssec-result-bogus-unsupported-ds-digest-type": "0",
"dnssec-result-indeterminate": "0",
"dnssec-result-insecure": "0",
"dnssec-result-nta": "0",
"dnssec-result-secure": "5",
"dnssec-validations": "5",
"dont-outqueries": "0",
"ecs-queries": "0",
"ecs-responses": "0",
"edns-ping-matches": "0",
"edns-ping-mismatches": "0",
"empty-queries": "0",
"failed-host-entries": "0",
"fd-usage": "18",
"ignored-packets": "0",
"ipv6-outqueries": "19",
"ipv6-questions": "0",
"malloc-bytes": "0",
"max-cache-entries": "10000",
"max-mthread-stack": "0",
"max-packetcache-entries": "500000",
"negcache-entries": "4",
"no-packet-error": "0",
"nod-lookups-dropped-oversize": "0",
"noedns-outqueries": "0",
"noerror-answers": "0",
"noping-outqueries": "0",
"nsset-invalidations": "0",
"nsspeeds-entries": "0",
"nxdomain-answers": "0",
"outgoing-timeouts": "0",
"outgoing4-timeouts": "0",
"outgoing6-timeouts": "0",
"over-capacity-drops": "0",
"packetcache-entries": "0",
"packetcache-hits": "0",
"packetcache-misses": "0",
"policy-drops": "0",
"policy-result-custom": "0",
"policy-result-drop": "0",
"policy-result-noaction": "0",
"policy-result-nodata": "0",
"policy-result-nxdomain": "0",
"policy-result-truncate": "0",
"proxy-protocol-invalid": "0",
"qa-latency": "0",
"qname-min-fallback-success": "0",
"query-pipe-full-drops": "0",
"questions": "0",
"real-memory-usage": "21766144",
"rebalanced-queries": "0",
"record-cache-acquired": "1086473",
"record-cache-contended": "0",
"resource-limits": "19",
"security-status": "1",
"server-parse-errors": "0",
"servfail-answers": "0",
"spoof-prevents": "0",
"sys-msec": "1853",
"taskqueue-expired": "0",
"taskqueue-pushed": "0",
"taskqueue-size": "0",
"tcp-client-overflow": "0",
"tcp-clients": "0",
"tcp-outqueries": "0",
"tcp-questions": "0",
"throttle-entries": "0",
"throttled-out": "0",
"throttled-outqueries": "0",
"too-old-drops": "0",
"truncated-drops": "0",
"udp-in-errors": "0",
"udp-noport-errors": "0",
"udp-recvbuf-errors": "0",
"udp-sndbuf-errors": "0",
"unauthorized-tcp": "0",
"unauthorized-udp": "0",
"unexpected-packets": "0",
"unreachables": "0",
"uptime": "8820",
"user-msec": "621",
"variable-responses": "0",
"x-our-latency": "0",
"x-ourtime-slow": "0",
"x-ourtime0-1": "0",
"x-ourtime1-2": "0",
"x-ourtime16-32": "0",
"x-ourtime2-4": "0",
"x-ourtime4-8": "0",
"x-ourtime8-16": "0",
"cache-size": "20.22"
}I can't reproduce it (VyOS 1.4-rolling-202207280217):
Viacheslav changed the status of T4089: Show nat destination rules shows ip address instead of interface 'any', a subtask of T4564: Root task for rewriting [op-mode] to vyos.opmode format, from In progress to Needs testing.
Viacheslav changed the status of T4089: Show nat destination rules shows ip address instead of interface 'any' from In progress to Needs testing.
GitHub <noreply@github.com> committed rVYOSONEX2f2e8125560a: Merge pull request #1445 from sever-sever/T4089 (authored by c-po).
Viacheslav changed the status of T4570: Exception when trying to set up VXLAN over Wireguard from In progress to Needs testing.
Viacheslav closed T4545: Rewrite show nat source rules, a subtask of T4564: Root task for rewriting [op-mode] to vyos.opmode format, as Resolved.
Viacheslav changed the status of T4569: Rewrite show bridge to new format, a subtask of T4564: Root task for rewriting [op-mode] to vyos.opmode format, from In progress to Needs testing.
Viacheslav changed the status of T4569: Rewrite show bridge to new format from In progress to Needs testing.
Viacheslav closed T4562: Rewrite show vrf to new format, a subtask of T4564: Root task for rewriting [op-mode] to vyos.opmode format, as Resolved.
Viacheslav closed T4543: Show source nat statistics shows incorrect interface, a subtask of T4564: Root task for rewriting [op-mode] to vyos.opmode format, as Resolved.
Viacheslav added a comment to T4089: Show nat destination rules shows ip address instead of interface 'any'.
PR https://github.com/vyos/vyos-1x/pull/1445
vyos@r14:~$ show nat destination rules
Rule Source Destination Proto In-Int Translation
------ --------- ------------- ------- -------- -------------
100 0.0.0.0/0 0.0.0.0/0 TCP eth0 192.0.2.40
sport any dport 3389 port 80
380 0.0.0.0/0 203.0.113.5 TCP any 192.0.2.5
sport any dport 443 port 8443
vyos@r14:~$Viacheslav changed the status of T4089: Show nat destination rules shows ip address instead of interface 'any', a subtask of T4564: Root task for rewriting [op-mode] to vyos.opmode format, from Open to In progress.
Viacheslav changed the status of T4089: Show nat destination rules shows ip address instead of interface 'any' from Open to In progress.
Working as expected in VyOS 1.3.1-S1
Viacheslav added a comment to T4519: DHCPv6: "set show dhcpv6 server leases" should show DUID instead of IAID_DUID.
Change DUID to IAID_DUAID was in T1470
Not sure which format we should to use
It's applied but masked by another part, looking into it. A brief workaround is to just change the description on br0 and commit - then the bridge vlan is re-created.
@c-po Bug exists after reboot (tested in 1.4)
@Viacheslav can you save your config and reboot?
We have ssmtp, I think we can use it for notifications
There is an example of configuration
Need to test it and come up with a CLI
I don't know if should it be a part of set service event-handler xxx or some new CLI service like set service monitoring notification mail xxx
Viacheslav renamed T4549: Email notification functionality from Email functionality to Email notification functionality.
Unknown Object (User) added a comment to T4074: Add NETCONF server with YANG data modeling .
+1
OpenConfig should be used as a basic YANG model.
If something is missing, add proprietary ones
https://www.openconfig.net/
Unknown Object (User) changed the status of T4542: route-map: "match prefix-len" incorrect behavior from Confirmed to Needs testing.
If "notice" in CLI and documentation is enough, the task can be closed.
Viacheslav changed the status of T4577: WWAN commit failed which simple config from Open to Needs testing.
Jul 29 2022
Jul 29 2022
jestabro closed T4554: Implement GraphQL resolvers for standardized op-mode scripts, a subtask of T4544: Generate schema definitions from standardized op-mode scripts, as Resolved.
jestabro closed T4544: Generate schema definitions from standardized op-mode scripts, a subtask of T2719: Standardized op mode script structure, as Resolved.
jestabro closed T4544: Generate schema definitions from standardized op-mode scripts, a subtask of T3993: Extend HTTP API GraphQL support, as Resolved.
Viacheslav closed T4518: Add XML for CLI conf mode load-balancing wan , a subtask of T4470: Rewrite load-balancing wan to XML/Python, as Resolved.
GitHub <noreply@github.com> committed rVYOSONEX2a9a2cfa12e8: Merge pull request #1403 from sever-sever/T4518 (authored by c-po).
GitHub <noreply@github.com> committed rVYOSONEX437c73888a49: Merge pull request #1442 from sever-sever/T4575 (authored by c-po).
GitHub <noreply@github.com> committed rVYOSONEX516b86bb970c: Merge pull request #1432 from jestabro/gql-op-mode (authored by jestabro).
GitHub <noreply@github.com> committed rVYOSONEXb5d9ebf16f63: Merge pull request #1438 from sever-sever/T4569 (authored by c-po).
GitHub <noreply@github.com> committed rVYOSONEX9310ed82e1e3: Merge pull request #1440 from sever-sever/T4570 (authored by c-po).
GitHub <noreply@github.com> committed rVYOSONEXbcbfc8cc0ad4: Merge pull request #1441 from sever-sever/T4543 (authored by c-po).
GitHub <noreply@github.com> committed rVYOSONEX0d7ad932d284: Merge pull request #1443 from sever-sever/T4562 (authored by c-po).
GitHub <noreply@github.com> committed rVYOSONEXfafd18c41e33: Merge pull request #1444 from tjjh89017/fix_t4577 (authored by c-po).
Viacheslav renamed T4089: Show nat destination rules shows ip address instead of interface 'any' from Show nat rules shows ip address instead of interface 'any' to Show nat destination rules shows ip address instead of interface 'any'.
n.fort added a comment to T3933: The firewall does not filter incoming traffic on the interface with vrf..
Moving in from forwardto prerouting doesn't seem to be a good idea. Filtering in prerouting will also filter local traffic.
Also, as remarked in previous entry, I would try to avoid using marks in mangle, since it may lead to mayor problems/incompatibilities when PBR also present in configuration.
Jul 29 2022, 2:27 PM · Bugs, VyOS 1.3 Equuleus (1.3.9), VyOS 1.4 Sagitta (1.4.0-GA), Restricted Project
PR https://github.com/vyos/vyos-1x/pull/1443
vyos@r14:~$ show vrf foo
Name State MAC address Flags Interfaces
------ ------- ----------------- ------------------------ ------------
foo up aa:de:40:58:2e:dd noarp,master,up,lower_up eth1.2
vyos@r14:~$
vyos@r14:~$
vyos@r14:~$
vyos@r14:~$ /usr/libexec/vyos/op_mode/vrf.py show --name bar --raw
[
{
"ifname": "bar",
"operstate": "UP",
"address": "ce:c1:4f:e8:dc:9a",
"flags": [
"NOARP",
"MASTER",
"UP",
"LOWER_UP"
]
}
]
vyos@r14:~$Jul 28 2022
Jul 28 2022
Viacheslav changed the status of T4575: vyos.utill add new wrapper "rc_cmd" to get the return code and output from Open to In progress.
Viacheslav renamed T4575: vyos.utill add new wrapper "rc_cmd" to get the return code and output from vyos.utill add new wrapper "rc_cmd" to get te return code and output to vyos.utill add new wrapper "rc_cmd" to get the return code and output.
Viacheslav added a comment to T4575: vyos.utill add new wrapper "rc_cmd" to get the return code and output.
PR https://github.com/vyos/vyos-1x/pull/1442
>>> from vyos.util import rc_cmd
>>>
>>> rc_cmd('uname')
(0, 'Linux')
>>>
>>> rc_cmd('ip link show dev fake')
(1, 'Device "fake" does not exist.')
>>>Ex2
>>> rc, command = rc_cmd('ip link show dev eth999')
>>>
>>>
>>> print(rc)
1
>>> print(command)
Device "eth999" does not exist.
>>>Viacheslav changed the subtype of T4575: vyos.utill add new wrapper "rc_cmd" to get the return code and output from "Bug" to "Feature Request".
zsdc added a comment to T3933: The firewall does not filter incoming traffic on the interface with vrf..
True, marking packets can help. I would only be very careful because we use marks a lot for PBR, LB, etc. Not sure if they can conflict with each other. Also, the performance is the question - better to check how marking each packet on an interface affects it.
Jul 28 2022, 9:13 PM · Bugs, VyOS 1.3 Equuleus (1.3.9), VyOS 1.4 Sagitta (1.4.0-GA), Restricted Project
The reason I set an MTU is because I get the following error when unset:
WARNING: RFC7348 recommends VXLAN tunnels preserve a 1500 byte MTU
VyOS 1.3-stable-202207280515 is not affected and works as expected
vyos@r14:~$ show vpn ipsec sa Connection State Uptime Bytes In/Out Packets In/Out Remote address Remote ID Proposal ------------------------- ------- -------- -------------- ---------------- ---------------- ----------- -------------- peer-192.0.2.2-tunnel-0 up 9s 0B/0B 0/0 192.0.2.2 N/A AES_GCM_16_256 peer-2001:db8::2-tunnel-0 up 9s 0B/0B 0/0 2001:db8::2 N/A AES_GCM_16_256 vyos@r14:~$
SAs
vyos@r14:~$ sudo swanctl -l
peer-2001:db8::2-tunnel-0: #4, ESTABLISHED, IKEv2, bae267e189f183be_i 008bf75c872ced6a_r*
local '2001:db8::1' @ 2001:db8::1[500]
remote '2001:db8::2' @ 2001:db8::2[500]
AES_GCM_16-256/PRF_HMAC_SHA2_256/MODP_2048
established 25s ago, rekeying in 85328s
peer-2001:db8::2-tunnel-0: #3, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-256
installed 25s ago, rekeying in 28178s, expires in 28775s
in c762627a, 0 bytes, 0 packets
out c2278f63, 0 bytes, 0 packets
local 2001:db8:1111::/64
remote 2001:db8:2222::/64
peer-192.0.2.2-tunnel-0: #3, ESTABLISHED, IKEv2, c923210fb14e11d5_i 2450ab183218d566_r*
local '192.0.2.1' @ 192.0.2.1[500]
remote '192.0.2.2' @ 192.0.2.2[500]
AES_GCM_16-256/PRF_HMAC_SHA2_256/MODP_2048
established 25s ago, rekeying in 85526s
peer-192.0.2.2-tunnel-0: #4, reqid 2, INSTALLED, TUNNEL, ESP:AES_GCM_16-256
installed 25s ago, rekeying in 27722s, expires in 28775s
in c1892b7b, 0 bytes, 0 packets
out c8fbbb2f, 0 bytes, 0 packets
local 100.64.0.0/24
remote 100.64.55.0/24
vyos@r14:~$I have it working between VyOS 1.4-rolling-202207280217 (kernel 5.10.133) and VyOS 1.3-stable-202207280515 (kernel 5.4.205)
Viacheslav added a comment to T4572: Add an option to force interface MTU to the value received from DHCP.
Will it work if you replace this https://github.com/vyos/vyos-1x/blob/4168e03721b2a9595de4090fddf1280d39ccce4c/python/vyos/ifconfig/interface.py#L1378-L1379
sudo nano -c +1385 /usr/lib/python3/dist-packages/vyos/ifconfig/interface.py
with:
Viacheslav changed the status of T4562: Rewrite show vrf to new format, a subtask of T4564: Root task for rewriting [op-mode] to vyos.opmode format, from Open to Needs testing.
jestabro updated the task description for T4554: Implement GraphQL resolvers for standardized op-mode scripts.
Viacheslav renamed T4551: IPsec rekeying collisions bug from IPsec rekeying collisions with IPv6 peers to IPsec rekeying collisions bug.
Viacheslav changed the status of T4543: Show source nat statistics shows incorrect interface, a subtask of T4564: Root task for rewriting [op-mode] to vyos.opmode format, from Open to In progress.
Viacheslav changed the status of T4543: Show source nat statistics shows incorrect interface from Open to In progress.
PR https://github.com/vyos/vyos-1x/pull/1441
vyos@r14:~$ show nat source statistics Rule Packets Bytes Interface ------ --------- ------- ----------- 10 5 380 eth0 20 0 0 any 30 0 0 any 40 0 0 eth0 40 0 0 eth0 vyos@r14:~$
zsdc added a comment to T4572: Add an option to force interface MTU to the value received from DHCP.
I have no proof now of any obvious negative issues. Moreover, in my personal opinion - if some protocol or interface type requires a default MTU that is not assigned to it by the kernel, this is the problem that should be solved by configuration script for that particular interface.
aserkin added a comment to T4409: route received via Framed-Route radius attribute is installed into default table when terminating connection to VRF.
Is there any chance to fix that ?
The latest version of the demo can be found here:
Viacheslav closed T4531: NAT op-mode errors with exclude rules, a subtask of T4564: Root task for rewriting [op-mode] to vyos.opmode format, as Resolved.