I actually can not reproduce this issue after fixing T2740. Please retry with the latest rolling which was just uploaded: vyos-1.3-rolling-202008031114-amd64.iso
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Aug 3 2020
I have to apologize here: While working on https://phabricator.vyos.net/T2653 I knew I must change this and did it on PPPoE but I totally forgot about this on all other interfaces as PPPoE has a special case here.
Please provide a full configuration for replication
Aug 2 2020
I also propose migrating the CLI interface from a bitmask (which IMHO no user understands)
This was actually drafted as a PR (https://github.com/vyos/vyos-1x/pull/461) but this PR changed the general incluide file and added only a PPPoE server implementation and left out all the others.
I like the idea of adding our own implementation which mimics jmespath.search() so this definately a +1.
Aug 1 2020
@moepman please checkout the next rolling ISO - at least it works as expected in my LAB
When connected via SSH to the router in question every command is run inside the VRF, thus a regular add system image will already run in the VRF. Nevertheless it would make sense to execute the command from another VRF.
I ask myself if it not would make more sense to get the prefix translation working again and then add new features here?
Jul 31 2020
Well I would just have plumbed up the commands locally before doing any templating. Please keep us updated if it works.
Jul 30 2020
Have you tested the latest codebase? It more or less follows your design for the member ports.
The last bug mentioned could be due to: https://phabricator.vyos.net/T2746
TSM support has been droppen in 1.3
Jul 29 2020
The problem is that vti interfaces are only created when VPN is configured this is done very late with priority 900. VXLAN, bridge etc (also in 1.2) use a lower priority. The only solution will be that the vti interface is added imediately and then later bound to the VPN.
That configuration does not work in 1.2.5 either - we probably should exclude vti from VXLAN source interface?
In latest rolling releases this will break b/c of: