Jessie based VyOS - Crux
PR for rolling https://github.com/vyos/vyatta-cfg-vpn/pull/38
It declared 2 times, because there is 2 checks
This is the output of this line
Mon, Sep 21
Sun, Sep 20
@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?
Sat, Sep 19
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
If possible, give your suggested cli path for my reference
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
Fri, Sep 18
Wed, Sep 16
Mon, Sep 14
Tue, Sep 8
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.
Thu, Sep 3
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
Wed, Sep 2
@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.
Tue, Sep 1
Mon, Aug 31
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