Sorry, I don't have a GitHub account (I try hard to avoid centralized systems). If what you want is a git repo/branch to pull from, I can setup one somewhere and commit the patch there, though.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 22 2021
In T3338#87770, @zsdc wrote:And it is necessary to leave a bug-report on the Proxmox bug tracker to lead this to the logical end. Could you do this?
Any chance you can send this as GitHub PR?
and indeed the fix works, I'm now able to add more than 215 dnat rules, and still fetch the config over the vyos http api! Thanks a lot everyone.
In T3337#87766, @c-po wrote:
- adding a cli node that passes raw config values from cli to the daemon is bad (we inherited this for dhcp and openvpn and it caused more harm then good in the last 2 years) - is this mandatory?
If I disable Xen PV drivers using "xen_platform_pci=0" from the host/dom0 side, and thus I get emulated e1000 NICs in the Xen HVM guest, then setting address to ethernet interfaces works ok..
It seems it works now
The ISC DHCP relay in VyOS is completely broken for my (non-GRE) use case, I would really like to see it get tossed out for something that works. This might not be the best place to describe my relay problems, but I might as well (skip this paragraph it you're not interested). My setup basically consists of the (ISC) DHCP server host connected to the VyOS router (running on a Dell R320), directly connected to a Cisco ASR920 router. Both VyOS and the ASR are directly connected to user VLANs (VyOS for firewalled/NATed zones and ASR for high-traffic users) and have DHCP relays set up targeting the DHCP server, such that the relayed messages from the ASR passes through the VyOS router towards the DHCP server and should get routed normally (i.e. ignored by the VyOS relay). The VyOS DHCP relay doesn't like this and starts spamming the DHCP messages up to ten or more times, causing wired clients to have to wait maybe ten seconds before getting an IPv4 address and wireless clients to just time out and abort the connection. I can provide the relay logs (mainly screenshots unless i dig up the disk I used) and VyOS config if anyone wants them, but as they have sensitive addresses, I don't intend to post them publicly. EDIT: I should mention that I didn't notice any problems while testing it with only myself, it was when 200 people started connecting the problems started occurring. And the DHCP server VM was not showing any noticable load.
@Viacheslav Looks like it is already fixed with newer release then VyOS 1.4-rolling-202102141111.
I can also add the interface with newer release.
As we use 7.5 in 1.4 now, we can implement that feature.
Start implementing this draft
Feb 21 2021
Hmmm I retract that, apparently not in my configs. But that review indicates that a common pattern is to define the VRF at a global level, then specify an instance at the BGP level...
@c-po not in constrat to other verndors - I know that Juniper ERX allowed for different ASNs if in a VRF. I'll see if I still have some old configs.
Unfortunately I can not connect the dots between "still the same process" and set protocols bgp <asn> vs. set protocols vrf <vrf> bgp <asn> (I explicitly left the "move bgp tagNode to node with local-as" topic out of the discussion as this is something different and is addressed via a different task)
Ahh.. yea, i see that now.. i've never done this, so cant say how it work.. but as i can se this is still the same process, so my answer is still the same.... Actually this migth be a good reason for migrating set protocols bgp <asn> to its own local-as <asn> subnode, so the AS is not hardcoded in the configpath
FRR actually supports configuring a different ASN per VRF in contrast to other vendors
On 1.3-beta-202102210443 and 1.4-rolling-202102202002 all work properly and don't require any changes, mark as resolved.
I found a similar issue related to this topic in 1.2.6-S1, script on-dhcp-event.sh can't to determine pdns_recursor PID
vyos@vyos# ps ax | grep pdns 6626 ? Ssl 0:00 /usr/sbin/pdns_recursor --daemon=no --write-pid=no --disable-syslog --log-timestamp=no [edit] vyos@vyos# pgrep "pdns_recursor" [edit] vyos@vyos# pgrep pdns_recursor [edit] vyos@vyos#
We need to use pgrep pdns
vyos@vyos# pgrep pdns 6626 [edit]
In T3344#87831, @runar wrote:@Viacheslav in you example, what does set protocols bgp <asn> vrf do? if i'm reading it correctly it makes no sense as you do not start a new process, and the ASN for the vrf will be the asn of the global bgp process
@Viacheslav in you example, what does set protocols bgp <asn> vrf do? if i'm reading it correctly it makes no sense as you do not start a new process, and the ASN for the vrf will be the asn of the global bgp process
using set protocols ospf vrf ... makes it harder to show that this is actually multiple processes that co-exist on the router, but on the other hand if we are thinking about the config scripts that are going to execute all this the syntax set protocols ospf vrf.... makes more sense, because the normal ospf config_mode script can program both "global" and all the vrf's
There are differences on vrf support in ospf,++ and BGP. the largest difference is that in IGP's you start a new process for each and every vrf you use. then the syntax set protocols vrf ospf.... makes kinda sense, but on BGP you are only using ONE process and the vrf is only a address-family inside the current process. and there the syntax set protocols bgp X vrf X makes most sense.
I prefer more option2