PR https://github.com/vyos/vyos-1x/pull/968

No, I am assuming it will be created when they have implemented a fix. In the meantime, I guess VyOS 1.4 could pin the package back to the previous 4.3.7-1pdns.buster version which is what we are doing locally for the moment. The developer on the pdns thread said that he hopes to have a fix out in a few days.

I don't see the repo for "bullseye"
http://repo.powerdns.com/

PR for current https://github.com/vyos/vyos-1x/pull/967

Fixed, thanks.

@Viacheslav we have other "objects" in VyOS which also require deletion first under certain circumstances.

It seems impossible to delete network and container and add a new one in one commit

Fixed by PR966

Duplicate of T3499

It appears things are in such a state where that network doesn't actually exist:

To add to this, it looks like I'm not going to be able to get rid of that without rebooting:

You can comment in the sections. it only creates an error when deleting vrf bgp instances

Waiting on 3rd party fix: https://github.com/FRRouting/frr/issues/9384
https://github.com/vyos/vyos-1x/pull/965

Another bug.
From time to time I get errors in debug mode ("touch /tmp/vyos.frr.debug" and "sudo systemctl stop vyos-configd") when changing lsp-mtu size

vyos@r1-roll# set protocols isis lsp-mtu 1308
[edit]
vyos@r1-roll# commit
[ protocols isis ]

We have this problem in more then one case. The solution so gar is to use " as quote which we later on render in Jinja2

Sounds like a missing validator. Wo should prevent users from doing such things ;)

@Viacheslav, when we use a migrator we should enable the ipv4 afi for each and every ipv4 neighbor if its not configured explicitly. What do you think? If a peer group is configured for that neighbour, too - that will be no issue.

Thanks for you comment ! it's good consider that options

Similar task T2315, also there is bug related T1976, etc.
It should be a migration script that determines ip/ipv6 neighbor and set neighbor to properly afi.
So there is one question, how to determine which afi we should to use if we see "peer-group" in configuration?
I don't think that we can implement it in 1.3 as it uses an old codebase.

This will be merged, pending discussion on pros/cons of preprocessing vs. relaxing schema restriction.

Gotcha. Thanks. Will wait.

Hi @paunadeu yeah that is an open issue (https://github.com/vyos/vyos-1x/commit/d77709252de54757d3f3e76ce6c52492ba967488) it got disabled recently.

OK. Seeing VyOS output now:

I think wasn't a problem. Not defined VNI in VRF, in L3 respects config in L2 don't, asked for the behavior in FRR Slack.

@raphielscape Are there still problems after updating PR? Please provide the configuration and I'll take the time to check it

As Workaround in T3350 set raw option "config /path/to/config/file"

@fernando Thanks.

i've been testing this new feature in our last release and it works well :

A bit of background: the error here is is a result of the Relax-NG schema requiring a leaf node to have a 'properties' entry; that is considered a sanity check by the schema author, but emerges as an issue when we moved to a modular structure for the *.xml.i include files. Leaving that restriction as-is, the solution of merging leaf nodes in the lxml script should be straightforward (the general case more intricate), so I will look at amending the override-default script.

Sure ! i'll test this feature and let you know !

@fernando Can you check this feature in the next rolling release?

set service snmp community public client 127.0.0.1
set service snmp oid-enable route-table

PR: https://github.com/vyos/vyos-1x/pull/961

PR https://github.com/vyos/vyos-1x/pull/960

PR for Equuleus https://github.com/vyos/vyos-1x/pull/959