Just an update on this... I _had_ two systems with this problem, but have found a possible workaround?

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.

Successfully tested on VyOS 1.2.6-epa1

@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.

I created PR https://github.com/vyos/vyos-build/pull/118

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?

Fixed int the latest rolling, VyOS 1.3-rolling-202008110118

In T125#51628, @Dmitry wrote:

I propose in this case use set vpn l2tp remote-access outside-address 0.0.0.0. It works in current rolling.

Good. Things are getting better. Thank you @ronie

In general, Service Providers implement IS-IS, not OSPF, as IGP in the Core. Maybe it is a good idea to develop VYOS support to IS-IS in order to make it more attractive as an immediate solution as P router to SPs.

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