You can get duid data from python
https://github.com/vyos/vyos-1x/blob/44b1bdd3273dce4e74a5474c401ac7107950635b/src/op_mode/show_dhcpv6.py#L95-L97
Replace format_hex_string(lease.host_identifier_string) to `lease.duid
and lease_display_fields['iaid_duid'] = 'IAID_DUID'
https://github.com/vyos/vyos-1x/blob/44b1bdd3273dce4e74a5474c401ac7107950635b/src/op_mode/show_dhcpv6.py#L44
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 8 2022
I've been running TAYGA inside VyOS with absolutely no problems for the last several years.
I would suggest going with tayga if this feature is planned to be implemented.
In T2664#126031, @Viacheslav wrote:As we have the 1.3 LTS release (where it is fixed) I propose to close it.
It is a big change for 1.2 that we should avoid.
As we have the 1.3 LTS release (where it is fixed) I propose to close it.
It is a big change for 1.2 that we should avoid.
I downloaded
Jul 7 2022
Output plugins that we use in 1.4
"github.com/influxdata/telegraf/plugins/outputs/azure_data_explorer" "github.com/influxdata/telegraf/plugins/outputs/influxdb_v2" "github.com/influxdata/telegraf/plugins/outputs/prometheus_client" "github.com/influxdata/telegraf/plugins/outputs/http"
Feature backport: https://github.com/vyos/vyos-1x/pull/1400
@dsummers I strongly believe we should not publish bleeding edge HEAD revisions and stick bleeding edge releases only.
Jul 6 2022
After doing some research, it appears this is a known bug in PowerDNS Recursor 4.7 (amazing to me).
This feature would be very helpfull for hairpin nat as we can see from the mentions.
Might also be helpfull for ipv6 as well.
I am aware its a different product but edgeos from ubiquiti does something like this (looks to be a managed address group that populates dynamically) for nat and fw:
Confirmed working on "current" branch.
Is anyone else seeing this same problem? It is keeping me from being able to use VyOS in an IPv6-only environment.
OK, I just noticed the merge to "current" branch.
I'd be glad to help test it, but I checked the repos and didn't see where it got merged in?
I think there's still a problem possible with /var/log/messages handling:
I re-created a new VM and it is Not reproducing
I closed it
Interface virtio
vyos@r1# run show interfaces ethernet eth1 physical Settings for eth1: Supported ports: [ ] Supported link modes: Not reported Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: Unknown! Duplex: Unknown! (255) Port: Other PHYAD: 0 Transceiver: internal Auto-negotiation: off Link detected: yes Ring parameters for eth1: Pre-set maximums: RX: 256 RX Mini: 0 RX Jumbo: 0 TX: 256 Current hardware settings: RX: 256 RX Mini: 0 RX Jumbo: 0 TX: 256
Confirmed issue, seems to be a problem in rsyslog/logrotate. Possibly related to T4250
In T3933#124952, @sandwichdoge wrote:@Viacheslav I tested your fix in my environment. The inbound filtering worked as expected after the fix. However it did not work correctly for the case we where we want both inbound and outbound firewalls on a single vrf member interface (or any case that has more than 2 directions on the same interface).
table ip filter { chain VYOS_FW_LOCAL { type filter hook input priority filter; policy accept; oifname "ONE" counter packets 63 bytes 6024 jump NAME_FOO # <<< Problem here, oifname should be eth0, not vrf name iifname "ONE" counter packets 63 bytes 6024 jump NAME_FOO jump VYOS_POST_FW } ... chain NAME_FOO { ip saddr 8.8.8.8 counter packets 79 bytes 6636 drop comment "FOO-10" counter packets 3 bytes 984 return comment "FOO default-action accept" } }
@a.apostoliuk Could you create PR for 1.3?
I see that the pull request was accepted. I just tested it with the latest rolling and it seems to work as expected.
Thanks a lot!
Jul 5 2022
Confirmed that issue is resolved.
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1392
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1392
I dug a little deeper, it appears that calling 2 http APIs in parallel results in vyos-http-api library crash.
Jul 5 08:47:39 cxr vyos-http-api[107198]: Configuration modified via HTTP API using key 'ccube-dev' Jul 5 08:47:39 cxr vyos-http-api[107198]: INFO: None:0 - "POST /configure HTTP/1.0" 200 OK Jul 5 08:47:39 cxr netplugd[907]: br4: can't get flags: No such device Jul 5 08:47:39 cxr vyos-http-api[107198]: processing form data Jul 5 08:47:39 cxr netplugd[907]: br4: can't get flags: No such device Jul 5 08:47:39 cxr netplugd[907]: message repeated 3 times: [ br4: can't get flags: No such device] Jul 5 08:47:39 cxr netplugd[907]: br5: can't get flags: No such device Jul 5 08:47:39 cxr netplugd[907]: br4: can't get flags: No such device Jul 5 08:47:39 cxr netplugd[907]: message repeated 27 times: [ br4: can't get flags: No such device] Jul 5 08:47:40 cxr vyos-http-api[107198]: INFO: None:0 - "POST /config-file HTTP/1.0" 200 OK Jul 5 08:47:40 cxr vyos-http-api[107198]: processing form data Jul 5 08:47:40 cxr vyos-http-api[107198]: INFO: None:0 - "POST /retrieve HTTP/1.0" 400 Bad Request Jul 5 08:47:40 cxr vyos-http-api[107198]: processing form data Jul 5 08:47:40 cxr vyos-http-api[107198]: processing form data Jul 5 08:47:40 cxr ntpd[3893]: Listen normally on 87 vti1 169.254.231.46:123 Jul 5 08:47:40 cxr ntpd[3893]: new interface(s) found: waking up resolver Jul 5 08:47:41 cxr kernel: [104872.825731] vyos-http-api-s[107280]: segfault at 1020 ip 00007f792d30391d sp 00007f792dce93e0 error 4 in libvyosconfig.so.0[7f792d2ae000+10c000] Jul 5 08:47:41 cxr kernel: [104872.825745] Code: 20 48 83 c4 08 c3 e8 f2 d9 fa ff eb c6 48 83 ec 48 48 8b 40 10 48 89 44 24 18 48 8b 40 20 48 8b 58 20 48 8b 5b 20 48 8b 7b 20 <48> 8b 77 20 48 89 74 24 10 48 8b 56 20 48 89 54 24 20 48 8b 7f 08 Jul 5 08:47:41 cxr kernel: [104872.833057] net_ratelimit: 24 callbacks suppressed Jul 5 08:47:41 cxr kernel: [104872.833059] IPv4: martian source 10.10.10.18 from 10.10.10.1, on dev eth2 Jul 5 08:47:41 cxr kernel: [104872.833061] ll header: 00000000: ff ff ff ff ff ff 6a 2c d7 cd 51 fd 08 06 Jul 5 08:47:41 cxr systemd[1]: vyos-http-api.service: Main process exited, code=killed, status=11/SEGV
I'm also getting the same error when calling the https API from localhost. In my case it only happens occasionally.
Will be resolved in https://github.com/vyos/vyos-1x/pull/1391
PR (backport) for 1.3 https://github.com/vyos/vyos-1x/pull/1391
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1391
Sorry just to clarify these are mostly web domains, not DCs, so there is no DNS running on them just HTTP.
Jul 4 2022
I wanted to ask you guys if this is an appropriate change to make. Considering it's on BGP, it's going to be a change in a crucial part but I think this one is probably a good one to make just to reduce ambiguity.