@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

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

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

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

https://forum.openwrt.org/t/ingress-traffic-shaping-with-snat/40226

Note: New xl2tpd package does not work with the followings params in options.xl2tpd

crtscts
lock

At this stage, I can't realize the automatic configuration of NDP proxy. On the other hand, although I don't know what additional application scenarios will be in addition to nat66, I hope to give full play to the full potential of NDP proxy, so I don't want to bind it to nat66 artificially.

Still wondering why ndp-proxy can not be part of the nat66 tree.
When a NAT66 translation is added we know the prefix (src and dst), the in/out-bound interface - so another CLI option (ndp-proxy) could probably be added to not open up an additional service node.

@c-po Request merge https://github.com/vyos/vyos-1x/pull/556

In T2943#76739, @runar wrote:

as a workaround you could add this to a post-boot script on the device.

This is disallowed by design by the VyOS team. the reason for this is partly because of the configuration order done by VyOS and how the dns lookup is handled by Wireguard.
Yes, the wg configuration utillity DOES handle DNS lookups, but NO, Wireguard does not handle them. This means that the DNS lookups is done once (and only once) when the wg command is executed on creation of the tunnel and then the resulting ip result is stored in wireguard. this results in the dns lookup will fail after a reboot of the VyOS device because it cant resolve the dns of the endpoint at that point (this is done before routing is enabled on the device)

PR for Rolling https://github.com/vyos/vyos-1x/pull/559

Already basically ready to merge

PR for crux https://github.com/vyos/vyos-1x/pull/558

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

https://github.com/vyos/vyos-1x/pull/556

Write redundant and intrusive code for all interface types, which may introduce unknown errors (I can’t guarantee 100% accuracy without testing)

@c-po I am thinking about a problem. Placing proxy-ndp under the child node of interface may generate redundant implementation code and is intrusive. In fact, for proxy-ndp, only one configuration file is needed. Is this Reasonable? I don't even know how to fully test whether the intrusive code affects the basic functions of the router.

It looks like this problem is around here
https://github.com/vyos/vyatta-cfg/blob/current/etc/bash_completion.d/vyatta-cfg#L280-L290

Yes that's correct. And there is already some sort of check implemented for the node traffic-policy, so it does not fail when the pppoe interface does not exist yet. It just shows a warning: https://github.com/vyos/vyatta-cfg-qos/blob/bbf2b2f06b7a0f883f7134df5e2b3e089015738e/scripts/vyatta-qos.pl#L198

I think I know what's happening here.

https://forum.vyos.io/t/limit-download-and-upload-on-wan-for-every-vlan/5608/51

PR for rolling https://github.com/vyos/vyatta-cfg-vpn/pull/38

It declared 2 times, because there is 2 checks

PR https://github.com/vyos/vyatta-ravpn/pull/16

This is the output of this line

@c-po If I want to be an interface-ethernet.xml.in Add custom configuration actions (such as proxy NDP) with certain extensibility (its configuration can be extended in other places). What should I do?

In T2898#75677, @jack9603301 wrote:

@Cheeze_It

I also take into account the specific situation of the ndp proxy, the configuration of this link prompts, the configuration format of the ndp proxy is like this.

https://manpages.debian.org/buster/ndppd/ndppd.conf.5.en.html

I also take into account the specific situation of the ndp proxy, the configuration of this link prompts, the configuration format of the ndp proxy is like this.

No arp proxy option is found in the configuration path, ndp proxy can manage multiple address rules under one interface

vyos@vyos# set interfaces ethernet eth0 ip 
Possible completions:
   arp-cache-timeout
                ARP cache entry timeout in seconds
   disable-arp-filter
                Disable ARP filter on this interface
   enable-arp-accept
                Enable ARP accept on this interface
   enable-arp-announce
                Enable ARP announce on this interface
   enable-arp-ignore
                Enable ARP ignore on this interface
   enable-proxy-arp
                Enable proxy-arp on this interface
 > ospf         Open Shortest Path First (OSPF) parameters
   proxy-arp-pvlan
                Enable private VLAN proxy ARP on this interface
 > rip          Routing Information Protocol (RIP)
   source-validation
                Policy for source validation by reversed path, as specified in RFC3704

Although I intended to think that it is easier to write scripts under the protocol, but from an intuitive point of view, it seems that this path is also a good choice (users can use the same command line as the arp proxy to configure) I have written it A sample, then only need to decide how to modify the cli

In T2898#75670, @Cheeze_It wrote:

In T2898#75656, @jack9603301 wrote:

set interfaces ethernet eth0 ip proxy-arp

The more suitable position may be set protocol ndp-proxy

I...really would like to not put it under "protocols" but to put it under the interface. It's *much* easier and more intuitive to see it under the interface/sub-interface than to see it in its' own stanza under "protocol" node.

Also, I'd argue it would be reasonable to separate ARP proxy and NDP proxy. That way one can pick and choose. Of course ARP proxy can't work without an IP address configured. NDP proxy can't be configured without an IPv6 address configured (those could be used as checks against configuring it on an empty interface).

If possible, give your suggested cli path for my reference

In T2898#75656, @jack9603301 wrote:

set interfaces ethernet eth0 ip proxy-arp

The more suitable position may be set protocol ndp-proxy

I can't find how to enable ipv6 connection tracking. Recompiling and modifying the linux kernel switch does not seem to see the module loaded. I think the current nat66 has completed 90%, and only need to implement ndp proxy to make it work normally.

set interfaces ethernet eth0 ip proxy-arp

I think we do need it, we can’t let users manage all IP manually unless we implement stateful NAT66

set interfaces ethernet eth0 ip proxy-arp. Isn‘t the Kernel sysctl interface enough? Do we really need a daemon?

This feature now is in the Cloud-init for 1.3 and must be backported after testing.

@kroy how about testing this in 1.3? It must work now.

Tested with:

set service dns dynamic interface eth0.203 service custom host-name 'test.vyos.net'
set service dns dynamic interface eth0.203 service custom login 'vyos'
set service dns dynamic interface eth0.203 service custom password 'vyos'
set service dns dynamic interface eth0.203 service custom protocol 'dyndns2'
set service dns dynamic interface eth0.203 service custom server 'vyos.io'

This also happens on service deletion

@Viacheslav it happened yesterday again but the stack trace was different. This time it was complaining that BGPD did not respond and the frr watch process tried to restart it, which of course did not help the situation.
I will continue to monitor but i think we can close this issue and wait for more details when it happens again.

Even with customers routes redistributed by OSPF instead of iBGP, it has just crashed again:

I tried unit-cache earlier but it seems to have issues too - I've seen duplicate routes if the same client (all have static IP assigned by RADIUS based on username) connects to a different PPPoE server and the old route is not removed, as if the cached (not removed) PPPoE interfaces were not seen as removed in FRR. But I haven't investigated this in more detail as it's a production setup, can't experiment too much on live customers.
I'm considering if I could go back to redistributing PPPoE customers /32 routes in OSPF instead of iBGP - it has been that way for a few years (using MikroTik, before moving to VyOS), but I've recently changed it following "BGP Best Current Practices" http://www.bgp4all.com.au/pfs/_media/workshops/05-bgp-bcp.pdf which recommends using OSPF only for infrastructure, not customers - seems logical to me as BGP was designed for much larger routing tables (all of the Internet), but perhaps OSPF is still good enough for just a few hundreds of customers.

Hello @marekm, I think [ppp]unit-cache=n might help in this case, but the main issue in FRR. Do you want a package for the test with these improvements?

unit-cache=n
By default is disabled: unit-cache=0

I've just had two different routers (one bare metal and one VM) crash roughly at the same time, triggered by many PPPoE sessions disconnecting at the same time due to a short power failure (routers itself had power all the time, but power was interrupted for about a minute to a switch on the network between the routers and PPPoE clients). Stack traces are very similar (absolute addresses differ, but the same functions and offsets in them). And again, each time watchfrr restarted bgpd but it was not working until reboot. No problems so far with two other BGP routers running a similar configu but without any dynamic interfaces (only OSPF and BGP, no PPPoE servers).

It looks like that the build process messed it up, it did create the version file at the beginning of the build, not at the end. After the file usr/share/vyos/version.json was create, pkg installations took place a few minutes alter, that's why everything in the image is newer than the version file, therefore the command output is absolutely correct. I'll check if I can find out what went wrong during the build, since it appears that only 1.2.6 is affected.

In T2820#74102, @Viacheslav wrote: