My last comment was wrong, here are the outputs for bridge fdb show dev vxlan122:

I can't reproduce it with VyOS 1.3-rolling-202010170146 and other october releases

source-interface cannot be used as the routers are not in the same multicast group, neither can communicate via multicast

In T2987#77730, @Viacheslav wrote:

@tom.siewert
What will be if you delete the source-address on "October" node?

@tom.siewert
What will be if you delete the source-address on "October" node?

We should avoid having a constellation of exporters, but favour having a single one. I feel like starting and stopping those would be pretty icky.

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

Must this command be executed from docker now?

This will break builds in out Docker environment where we ship a packer version. See T2792 and https://github.com/vyos/vyos-build/commit/e2dd9db8a2539b6d13c98d89e18872336cf8f974

Also very interested in this. Ready and willing to test.

@Cheeze_It thanks, works fine.

PR https://github.com/vyos/vyos-build/pull/128

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

That would be a workaround only - see IPv6 syntax above. Using the refactored interface handling (T2653) makes this a low-hanging fruit.

I'll be giving those a test once T2981 is done. I'll report back here with results :)

PR is added here...

Quite interesting, support, in fact some information can not be captured from SNMP very well

How about this?

@D0peX That's correct? I updated pr

Thank you Viacheslav

@c-po @dmbaturin It can be safely cherry-picked to the "crux".
I tested this on 1.2.6-s1, it works.

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

@trae32566 Will be added in the next rolling release.
Check, please.

The possible reason, that it can't get the lease file, because that directory not present in the LiveCD

lease_file = "/config/dhcpd.leases"

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

That sounds great to me! I actually like that more.

Proposed cli
One of them

It was fixed in the rolling T2573
https://phabricator.vyos.net/rVYOSONEXf812c5d1ce01efa8323bfb797c57f68f474665bb

@Robot82
It will be by default in the new BGP implementation.
https://github.com/vyos/vyos-1x/blob/current/data/templates/frr/bgp.frr.tmpl#L5

Proposed CLI

reset mpls ldp neighbor x.x.x.x

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

awesome, thanks!

https://forum.vyos.io/t/limit-bandwith-for-indivindual-ips-on-1-2-5/5947/30?u=s.lorente

Also submitted PR for FRR 7.3 series https://github.com/FRRouting/frr/pull/7318

OK, thank you. I will test this. This should probably be made as default.

@runar The preliminary integration of tinc is basically completed, please see

Yes, both clients configured as DHCP clients.
Client 1 - eth0 - 50:00:00:06:00:00
Client 2 - eth0 - 50:00:00:07:00:00

This has come up multiple times before, see https://phabricator.vyos.net/T1698 for the solution.

I can confirm.
It happens after update procedure.

If I do a clean install of 1.2.6-s1 from iso, the rollback works fine.
If deploy from a qcow2 image, I see a similar error.

I should add that building the package on arm64 hardware (pi3/4) works fine. Building in the docker container fails.

Just my thoughts - there are situations where rp_filter is not sufficient, and it was not clear to me how to do this cleanly with the zone firewall, so I ended up hacking a few iptables commands in rc.local instead.

the issue is verified by soxrok2122 by using a stock ubuntu 20 host with the stock vyos/vyos-build:current-arm64 docker image

I'm reopening this issue as this seams to still be an issue. reported by user soxrok2212 on slack (#vyos-on-arm64)

It seems Client1 and Client2 only DHCP-clients.