we have a version updated , this case should be closed:
azureuser@vyos-support:~$ sudo /usr/sbin/waagent -version WALinuxAgent-2.2.45 running on debian 10.12 Python: 3.7.3 Goal state agent: 2.2.45
we have a version updated , this case should be closed:
azureuser@vyos-support:~$ sudo /usr/sbin/waagent -version WALinuxAgent-2.2.45 running on debian 10.12 Python: 3.7.3 Goal state agent: 2.2.45
I've tested our last rolling-realase , it's working as expected :
I couldn't open those files, but it can be related our firewall refactor :
I confirm this warning message , although, on Linux doesn't affect or at least with our server/client work as expected :
yes, but it's in process to merge : https://github.com/vyos/vyos-documentation/pull/1035
Could you share the full configuration ? so we can analyze what is the source of this problem .
Adding comments : maybe discontinue show ip bgp gives some issues / problems with automation tools (ansible o some custom script)While thinking out loud, it can be useful for new users create to alias.
show ip bgp is an old command, it comes from quagga ...So in my point of view , adding more command to do the same , could generate more confusion . show bgp address-family should be used.
information that can be useful for this feature request :
cool! it's interesting understand this complex scenery and how it works an real environment ,Additionally, the way it handle the zebra with the next-hop group ,int fact , I genuinely appreciate your valuable feedback so far!
as I recall ,this case can be associate with this task : https://vyos.dev/T5077
yes , sorry!
I've summited an issues case on FRR , where explain the problematic :
well , I've had an idea how to make a workaround , I've used explicit-null label to add next-hop from the network-address connected sudo ip route add 10.0.0.1/32 encap mpls 0 via 10.0.0.2 dev eth1
I've done extra test , I confirm this behavior is associated transport label that can't be allocated when using interfaces directed connected to created ldp session without IGP protocols(ospf/isis) . let's see what is going on :
basic configuration :
you are right , I seems to be working :
I've tested it, but it works partially... if you have more than a match (for example, the same class id if necessary to match more than one DSCP),it brakes the configuration again :
I've found the reason why this command fails, it' happens because the logic to match the dscp parameter is missing. So, it tries to apply the basic policy with the tc filter parameters by default :
this issues was resolved on https://vyos.dev/T5127. It happens when FRR tries to calculate the auto-rd per vrf . it can be solved by using router-id on each vrf or interface dummy in the VRFs ,
Thanks Viacheslav , for this clarification . Veths /Netns are strong powerful , using this technology we can use to join different hypervisor or bridge technology . leave some example namespaces /veth / bridging.
I've done test , regarding the original issues that it was nat+route-leaking (default + foo) , which is working on the last rolling (VyOS 1.4-rolling-202305140317). however, I've tried some test using two vrf+route-leaking and NAT , I can replicated the issue:
thanks for the contribution , I've done some test , it seems to work like a champ . @dmbaturin @c-po this script to do the steps necessary to compile the kernel module to use ovpn-dco . Could you check if it's correct or something needs to be improved :
bfd is able to monitoring static routes , using profiles and multi-hop to reached a peer :
Thanks for clarifying. Yes , I also saw the possibility of extending role based IAM to add on-premise image (that could be interesting for VyOS).
Could you share configuration ? where attached RM and BGP settings:
@unity when you need AWS credential , will they be automatically deployed from SSM or will we have to add those credentials in the virtual machine? ? shouldn't aws-cli be integrated?
Yes, I forgot to add this task. I'll make the PR
merge done, it fixed the issues :
sorry , but it seems files doesn't share .
confirm, it's working :
I would like to make some question. this prefix 10.0.0.0/24 on PE2 is a connected network or learned from another routing protocol (static or BGP)
cool , it could be useful.
I don't see it as bug , this information can be obtained from OSPF database using LSA or summary:
frr 8.5 LSP is working as expected:
this fix was added 8.5 :
vyos@cust-pe2:~$ show bgp ipv4 vpn 172.16.80.0/24
BGP routing table entry for 1:2:172.16.80.0/24, version 0
not allocated
Paths: (1 available, no best path)
Not advertised to any peer
Local
0.0.0.0 from 0.0.0.0 (1.1.1.1) vrf customer(6) announce-nh-self
Origin IGP, metric 0, weight 32768, invalid, sourced, local
Extended Community: RT:1:2
Originator: 1.1.1.1
Remote label: 80
Last update: Wed Mar 29 13:17:24 202Great 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
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 .
Could we use something like Dannil proposes? https://vyos.dev/T4883 , as you said FRR staticd don't allow this option but it could be useful when we have different mtu over the interface.
Add another feature that is improved if we're thinking of moving to KEA :
including information about Netopee2/sysrepo services, how to integrate it with FRR, where we can utilize the advantages netconf/yang :
@ordex nice your reply here , we're planning to introduce it in our last upgrade version( we need to upgrade openvpn version to work with opvn-dco ) , Di you try it on Debian 12? My current environment was over Debian 11, if you have any suggestion it will good to know.
pfsense implements it , however , they explain that it has some limitations :
VyOS 1.4.x
VyOS config 1.3.2 :
######### Router 01: master #########