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

Currently the only application of VyOS LDP is as P router (backbone router in an MPLS cloud).

Additionally, sometimes the Peer ID and Local ID are not correctly formatted. for example:

It seems a parser issue. We are reviewing the script https://github.com/vyos/vyatta-op-vpn/blob/current/scripts/vyatta-op-vpn.pl

When the configuration provided is reproduced, the problem occurs: show ike sa is "down" while show ipsec sa is "up".

ref T2747

And script

#!/usr/bin/env bash

Sounds good thanks.

Your rolling release is from a time where the interface configuration changed heavily. An entire new concept was added, please retry with one of the latest rollings.

FRR 7.4 has been released, and the default behaviour has been changed, commit 62282e8379. @Viacheslav, when we update to this version, I can work with you to update the migration script.

As discussed in above comment, this is understandable behaviour, but will be re-investigated after the move to fastapi, re T2397.