Looking at the regex it seems that . (dot) is also allowed. Is that right? If so, the error message should be altered accordingly.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 8 2023
As you can see LNS/MPLS-PE is being built on VyOS 1.4. MPLS-P are NSN (aka Alcatel Lucent) boxes as far as i know.
There is the regex
It seems don't validate correctly if only one letter before the hyphen, underscores
vyos@r14# set firewall group domain-group a_aa
Great project! As I understand it, you're using BGP label-unicast to transport labels, and I'm curious about the operating systems your PEs/Ps are running on - are they Cisco, Juniper, or other vendors? I'm particularly interested in learning about the interoperability between different vendors so that I can incorporate it into my testing. @aserkin
For "SSH" we have dynamic-protection
vyos@r14# set service ssh dynamic-protection Possible completions: + allow-from Always allow inbound connections from these systems block-time Block source IP in seconds. Subsequent blocks increase by a factor of 1.5 (default: 120) detect-time Remember source IP in seconds before reset their score (default: 1800) threshold Block source IP when their cumulative attack score exceeds threshold (default: 30)
BTW this configuration takes almost 20 minutes to load. I wonder if there's a way to speed up this process?
+1 for implementation
Thank you, @c-po. Will try raising limits to 4096.
Well in this project we're trying to implement L2TP network server with MPLE-PE functionality with our partner mobile operator. This is for b2b projects with a number of customers connecting their mobiles to corporate resources for some reasons.
So the config has three groups of BGP peers: four of ipv4-unicast peers (10.228.134.34, 10.228.134.36, 10.228.134.38, 10.228.134.40) for connection to L2TP LACs (actually they are mobile gateways - GGSN/PGW) and AAA servers, another pair is ipv4-vpn multihop peers (10.5.72.1,10.5.72.2) where customer's L3VPN connections are terminated, And one more peer connecting to 3d party carrier grade NAT solution for the customers who need Internet access.
The LNS and NAT nodes are implemented on a single server with KVM virtual machines interconnected with each other and with external world by OpenVSvitch/DPDK.
The VRF names are assigned by AAA server for each subscriber with Accel-VRF-Name attribute.
This is also where the defect https://github.com/FRRouting/frr/issues/12919 comes from. Just to spot on it)
Let me know if you nedd additional info.
I can confirm that after adding the aforementioned code block to my scripts everything works as expected.
Mar 7 2023
@aserkin WOW that is a huge VRF config. With that amount you definately reach the max FD limit.
Backport PR:
https://github.com/vyos/vyos-1x/pull/1874
Backport PR for this and T4872:
https://github.com/vyos/vyos-1x/pull/1874
This was a meta-task for conformance to coding guidelines for inclusion of scripts in vyos-configd. Those guidelines are documented and checked in the smoketest test_configd_inspect.py for both Sagitta and Equuleus, and will be closed.
This is potentially a useful feature, but has no current use, so there is no reason to backport it for 1.3.3. I wil add a 1.3.4 tag to keep it in mind in case it is needed for a future backport.
As mentioned above, there were two separate issues here:
(1) the issue of quoting of hw-id values is resolved in this task, for both Sagitta and Equuleus
In T3655#143947, @fernando wrote:it doesn't seem the same problem as here, this logic that was applied over this version was vrf not on the table . Could you share full configuration ? there is some point over vrfs / vrf default /leaking that are not clear. So I can replicate the scenery and we see what is going on .
I'll take a look at the guidelines to contribute, thank you!
@dex Update please the documentation if you want to help project or we'll do it later.
Thanks
The same task T5047
Thank you for the clarification, I will edit my scripts accordingly. I was under the impression that VRRP transition scripts are called with the vyattacfg group out of the box, since there is an example in the documentation which has the sg part missing: https://docs.vyos.io/en/latest/automation/command-scripting.html#run-configuration-commands
We cannot disable keepalived as it is used not only for VRRP and also for virtual-server
set high-availability virtual-server xxxx
So it should be something like set high-availability disable
Or just clean the VRRP configuration with set high-availability vrrp disable
To make sure that a script is not accidentally called without the vyattacfg group, the script can be safeguarded like this:
if [ "$(id -g -n)" != 'vyattacfg' ] ; then exec sg vyattacfg -c "/bin/vbash $(readlink -f $0) $@" fi
https://docs.vyos.io/en/latest/automation/command-scripting.html#executing-configuration-scripts
In T5045#144137, @aserkin wrote:
Thank you for the hint, @c-po
Attached the entire config we have on the node.
There're not much BGP peers, but quite a number of VRFs which terminate remote access l2tp subscribers.
I'd really appreciate any advice on the system optimization for that particular task - ideally i'd like this node to terminate up to 20k l2tp subscribers with very low traffic (not exceeding 0.5gbps i guess).
Well there should be no harm in lifting the limit of open file descriptors for FRR as its a huge process tree.
Can you share your entire protocols configuration tree so we see what else is configured?
Mar 6 2023
The bfdd process did not start until i changed LimitNOFILE=1024 to LimitNOFILE=2048 in /lib/systemd/system/frr.service
That did the trick, but i'm not sure it's a good solution.
What do you think, @Viacheslav ?
The limits look like standard
root@nn-vlns-3-1:~# ulimit -Hn
1048576
root@nn-vlns-3-1:~# ulimit -Sn
1024
root@nn-vlns-3-1:~# sysctl fs.file-max
fs.file-max = 9223372036854775807
@n.fort I apologize for the late entry here - could this also be exposed for NAT rules?
Edit: wow you guys worked so fast on this it got pulled before I could add this request :D
PR https://github.com/vyos/vyos-1x/pull/1870
>>> from vyos.template import range_to_regex >>> >>> range_to_regex(['11-12', '14-15']) '(1[1-2]|1[4-5])' >>> >>>
I created a separate task for it T5057
The second bug is interface Regex does not work
Get:
interface=re:eth1\.\d+
Expect:
interface=re:^eth1\.(200\d|20[1-9]\d|2[1-9]\d{2}|3000)$
PR https://github.com/vyos/vyos-1x/pull/1869
vyos@r14# run show conf com | match ipoe set service ipoe-server authentication mode 'noauth' set service ipoe-server interface eth1 client-subnet '100.64.24.0/24' set service ipoe-server interface eth1 network 'vlan' set service ipoe-server interface eth1 vlan '2000-3000' [edit] vyos@r14#
Check config:
vyos@r14# cat /run/accel-pppd/ipoe.conf | grep "\[ipoe" -A 7 [ipoe] verbose=1 interface=re:eth1\.\d+,shared=0,mode=L2,ifcfg=1,range=100.64.24.0/24,start=dhcpv4,ipv6=1 noauth=1 proxy-arp=1
It is incompatible with static entries.
Maybe it should be fixed after migrating to KEA-DHCP T3316
The similar task T5042
Mar 5 2023
Mar 4 2023
In T3655#143947, @fernando wrote:it doesn't seem the same problem as here, this logic that was applied over this version was vrf not on the table . Could you share full configuration ? there is some point over vrfs / vrf default /leaking that are not clear. So I can replicate the scenery and we see what is going on .
Mar 3 2023
Needs final testing before PR
https://github.com/vyos/vyos-1x/compare/current...jestabro:literal
it doesn't seem the same problem as here, this logic that was applied over this version was vrf not on the table . Could you share full configuration ? there is some point over vrfs / vrf default /leaking that are not clear. So I can replicate the scenery and we see what is going on .
Possible completions:
<0-4294967295> DHCP lease time in seconds
Standard lease I have in the configuration is "lease 4294967295"
That is a static reservation. Ensures I have the same IP for a specific host.