Could you share an example how to ise that? I then can test it in my code.

Regarding (1) which is about changing the default. No issues, I was trying to break any code until someone had more time than me to test it, as the devil is always in the details.

From John on github:

The document has been updated and moved to a more suitable location

I would like to test as well. I have successfully setup link local peering with 2 vyos routers using the new "interface v6only" option. However, I am unable to establish a link local session when peering with a different vendor.

An initial version has been merged with initial support for some Crystalfontz LCDs. This is in alpha state.

This is a good bug report

@tux great informative bug report!

PR https://github.com/vyos/vyos-1x/pull/525 add a default for dhclient via vrf.

Great news! I can confirm, after update, it is working. Thank you!

@tux, this has been fixed in the current rolling.

@jmbwell thanks for the PoC. Please not that this will break existing configurations as this alters the syntax and thus a migrator is required (e.g. https://github.com/vyos/vyos-1x/blob/current/src/migration-scripts/interfaces/9-to-10)

I've done the following hacking to get multiple delegations, FWIW.

PR: https://github.com/vyos/vyatta-cfg-quagga/pull/54

@Penguin
I can't say exactly about 1 point.

2. It will be fixed with additional functions/pkgs UPnP/miniupnp, STUN/coturn. Need to test it.
3. It will be fixed with local PBR (ip rules) T439 T2196 and work-around in T2747

Hi @dongjunbo , could you try the package for 1.2.5 with fixing this issue?

I am on version 1.3-rolling-202008090118 and so far I have not encountered the issue again. I will keep an eye out and will report if this happen again.

No idea. It just sat there for a while so I closed it. I assumed there was no interest.

Reason is that dhclient will admin-up the interface. This issue has been there for a long long time!

For the time being I have created a document with the current limited possibilities.

In theory, service providers use OSPF and ISIS for IGPs. LDP in theory shouldn't really care which protocol is used for the next hop as long as the next hop resolves and the label is there for the next hop for that LSP. Albeit I will admit I am not sure how it is organized in FRR. OSPF and ISIS should both be able to work though for next hops, and they should be consistent.

It was all a confusion on interface naming. When Cisco says Ethernet, they mean an Ethernet interface of 10M, that's not the case for VyOS. In VyOS eth means the interface uses the Ethernet protocol, but it could have any speed.

Yes the GCC preprocessors is limited (but works for the current use case) and m4 is indeed more powerful but not a user-friendly tool IMHO.

Fixed, VyOS 1.3-rolling-202008120118
nhrp not configured:

vyos@r4-roll:~$ show nhrp interface 
OpenNHRP is not running.
vyos@r4-roll:~$ 
vyos@r4-roll:~$ show nhrp tunnel 
OpenNHRP is not running.
vyos@r4-roll:~$ conf

In T2786#72841, @Viacheslav wrote:

@ronie For OSPF bandwidth use command:

vyos@r4-roll# set interfaces ethernet eth0 ip ospf bandwidth 
Possible completions:
   <1-100000>   Bandwidth in megabits/sec (for calculating OSPF cost)

@Viacheslav I supposed that by default Ethernet Interfaces/10Mbits should be assigned a cost of 10 without changing any parameter. So it is not a bug? Should I cancel this request?

Not speed interface.

@ronie For OSPF bandwidth use command:

I guess it'll be easy to integrate it into VyOS CLI, as it exists in FRR.

PR https://github.com/vyos/vyos-nhrp/pull/5

This problem may have been resolved for a few months, and I am currently using VyOS 1.3-rolling-202007190117
If no problem is found, I will close this question. If other problems are found, I will reopen it.

@jack9603301 can you check it with the latest rolling?

Fixed, VyOS 1.3-rolling-202008110118

show lldp neighbors interface ethX

was fixed in https://phabricator.vyos.net/rVYOSONEXe9b954a9e4d0a7af907c5add4c706591c50d2297 and T2779
@jjakob can you test/close it?