@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?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 21 2020
Sep 20 2020
In T2898#75677, @jack9603301 wrote: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
Sep 19 2020
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?
Sep 18 2020
Sep 16 2020
Sep 14 2020
Sep 8 2020
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.
Sep 3 2020
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
Sep 2 2020
@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.
Sep 1 2020
Aug 31 2020
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
Aug 30 2020
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).
Aug 28 2020
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:
@marekm
Can you check your BGP configuration if "router-id" is declared?
Also, what is with interface names?
ppp-lot29 ppp-jmg22 ppp-rol81 ppp-rod8
Do you use scripts with renaming? How to reproduce it?
/usr/libexec/vyos/op_mode/version.py:
Built on: Thu 13 Aug 2020 11:57 UTC
Happens also when just using the booted image without install. Investigating.
Aug 27 2020
It crashed again after 5 days in 1.2.6-epa1, in the same function, also when a dynamic PPPoE interface was deleted.
It happens less frequently after the former customers who repeatedly failed authentication have been physically disconnected.
Again, BGP no longer works after watchfrr has restarted the bgpd process. All works again after reboot.
Aug 26 2020
Is probably fixed in https://phabricator.vyos.net/T1291 according to cpo on slack
Aug 25 2020
Aug 22 2020
Maybe related - https://github.com/FRRouting/frr/issues/6439
Aug 20 2020
Aug 19 2020
This happens only when in config before migration exists nodes system 'ntp' without other params.
Aug 18 2020
Aug 16 2020
Aug 14 2020
Aug 13 2020
Aug 12 2020
Aug 11 2020
Fixed int the latest rolling, VyOS 1.3-rolling-202008110118
Aug 8 2020
I am giving up with HFSC. I have been studying it for a long time, I have tested it in many different ways, without VyOS too. The only thing I have found is that this is is not a problem of VyOS.
Aug 3 2020
Jul 31 2020
Jul 30 2020
related to T1699
@Merijn Have such problems been repeated?
Jul 29 2020
The issue did not reproduce neither in 1.2.5 nor in 1.3 version.
Try in the new release and re-open the ticket if any new information appeared.
@olofl I can't confirm this bug int the 1.2.5 LTS version.
I can't confirm this bug.
vyos@vyos# set vpn ipsec ike-group IKEv2_DEFAULT mobike disable [edit] vyos@vyos# commit [edit] vyos@vyos# run show version Version: VyOS 1.2.5 Built by: Sentrium S.L. Built on: Sun 12 Apr 2020 15:18 UTC Build UUID: 1695c660-d785-4b16-a54b-66d6a02ea24f Build Commit ID: 48cc9fc46569e6
Jul 24 2020
I thought the problem could be related to VyOS, but now I have found the same behavior when using directly tc hfsc.
Jul 23 2020
Jul 21 2020
show interfaces vrrp
I have tried the above scenario in the VyOS 1.3-rolling-202007200117 which is the latest version and the issue did not reproduce. So I would request you to try in the latest version and share your feedback.
Jul 20 2020
Jul 14 2020
Jul 13 2020
Jul 12 2020
Jul 11 2020
Can confirm that the image now contains wireguard.ko.
Understood, will re-check and close the report once confirmed.
@linuxgemini we do not support DKMS.
Did a rebuild and found the silent error:
While I was checking my old build, I have seen this on /live/filesystem.packages: