this new command was merge in order to solved this problem :
vyos@vrf-test:~$ show configuration commands | match disable set protocols bgp parameters disable-ebgp-connected-route-check
this new command was merge in order to solved this problem :
vyos@vrf-test:~$ show configuration commands | match disable set protocols bgp parameters disable-ebgp-connected-route-check
it think that we can use also something similar to what we use ocserv to generate ssl certificates:
it makes seens , agree with add a Config Error to do not allow both options simultaneously ,.
as I mentioned , it was added in 9.1 as default behavior :
this command was added by default in FRR , but it's supported on lasted version (9.1):
i've re-checked with the new image from GCP and new cloud-init version , it seems to be working as expexted :
this fix is not merge yet : https://github.com/vyos/vyatta-op-vpn/pull/37
some improvements were added in this task , enable or disable the http security headers in the openconnect configuration :
when it's merge , I will test with the controller to see if we are able to get BMP with the new FRR version.
tested on 1.5/1.4 :
PR 1.5/1.4 : https://github.com/vyos/vyos-1x/pull/2564
Do you tested it ? using our current rolling-release
I'll hava a lab with PIM SSM and BFD , I'll update our documentation with those feature with example.
I've tested this flag in both version 1.4 / 1.5 , it seems to work as expected :
tested on 1.4-rolling-202311080309
it's not a bug, this command are able in ospf :
after merge this ldp bug fixed , I saw that now it's already working . Could you check it ? I've tested on a lab and it seems to work :
tested /resolved
@jvoss thanks to confirm !
I've tested this issues in our lasted rolling-realese , after last commit , it seems works without problems :
vyos@vyos# load test.conf Loading configuration from 'test.conf' Load complete. Use 'commit' to make changes effective. [edit] vyos@vyos# compare [policy] + route-map TEST { + rule 10 { + action "permit" + set { + community { + add "65001:1" + } + large-community { + add "4200000000:100:1" + } + } + } + }
exactly , i'll give an example of what is the improving (or new cli) , we have a policy where we can mach different DSCPs associate with REAL TIME or VIOCE . Current in our cli , it would be something like this :
this case was resolved lasted configuration done .
this task is a re-definition from a traffic class , I think it could be more clear if we separate tc-filter in a class-map , so we can define different profiles in our cli based on services :
I think we can do something similar to it : https://alestic.com/2018/12/aws-ssm-parameter-store-git-key/
for me , it's ok . I didn't see another issue related it . we can close
@sdev greats !!!
command on 1.5 :
@vfreex I've tested in my labs related this issues , I can confirm that it work as expected . this original zone solved the problem when there was a src-nat /dst-nat with different VRFs or leaking with them ,Thanks you for this contribution .
@sdev take a look over these repository :
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 :