If you add neighbor/commit and after that commit adding "set protocols bgp parameters default no-ipv4-unicast" it can not be accepted. Because neighbor was added before this command.
Re-create neighbor and commit. And check again.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 8 2021
When on VyOS 1.4 please use the show bgp ipv6 command as exposed by FRR. The show ip bgp command is only kept as not all options from show ip bgp are exposed in FRR under the show bgp ipv4 tree.
Apr 7 2021
You can't/don't need to set local-as for neighbor [ if neighbor local as == your global asn ]
Can you send a code error?
I don't understand how DHCP relays work, esp in a pfsense environment. Not worth looking at this.
Apr 6 2021
Apr 5 2021
Fixed. 1.2.7, VyOS 1.3.0-rc3, VyOS 1.4-rolling-202104041918
I wonder if this used to work in the past?
Turns out this is not a VyOS limitation but is a Linux Kernel/iproute2 limitation.
This bug also persists in VyOS 1.2.7
Apr 4 2021
The same with "policy" /usr/libexec/vyos/tests/config/dialup-router-medium-vpn
To reproduce it add firewall and attach it to interface
Usually on delete, the firewall should be detached from the interface first as the logic should go from the highest priority to the lowest one.
It is a priority for configurations
When the system load, the firewall should have configuration, and after configuration is applied to the interface.
So I think we can't delete it in one commit, it tried to delete the firewall before detaching the firewall from the interface.
So I finally stopped being lazy and got VyOS in to GNS3. As with our production routers MPLS remains off after restarting with either 1.3-rolling-202104021041 or 1.4-rolling-202104022042 for VLAN sub interfaces. Ethernet parent interfaces have their mpls state managed correctly.
It seems fixed for rolling release 1.4 because soft has been moved to FRR7.5.1
Of course it is not fixed for rolling release 1.3 (and as I understand won't be) due to FRR7.3.1
Apr 3 2021
@syncer
Sorry to dredge up an old bug, but I believe I've hit this today on 1.2.7-LTS myself. Per @zsdc's original description, It seems that when you configure:
Added minisign package https://github.com/vyos/vyos-build/tree/current/packages/minisign and also included this in vyos-1x dependency list for crux, equuleus and current
We can do some workaround for that level,
It seems that "call" doesn't react to env.
'VYATTA_EDIT_LEVEL': '/system/login'
Apr 2 2021
vyos@vyos:~$ show version
Version: VyOS 1.3-rolling-202005100117
Release Train: equuleus
This can be reproduced with the following config on 1.4
This looks very promising to me for VyOS 1.4-rolling-202104020417, can we please backport this @jestabro ?
show ipv6 route lists you the forwarding path - FIB
show ipv6 bgp or show ipv6 route bgp will show you the rib
I think the presence of the kernel default route may be the problem. It comes from RA through autoconf option on the interface. I will do some more testing.
Could you please try backporting this to 1.3 equuleus branch?
Apr 1 2021
That one just bit me - and actually this is caused by loading the tunnel-broker config from https://github.com/vyos/vyos-1x/blob/b666f8ba97dc792aac90fad4c4c99e47caca7baf/smoketest/configs/tunnel-broker
There are two issues in this task (1) reordering of interfaces (2) redundant hw-id entries due to vyatta_net_name not parsing quoted values. A quick fix for (2) will be a PR for vyatta-cfg-system; the general issues the bug raises, regarding quoted values in configtree, will be addressed in the subtasks.
Chown for saved configuration file should be frr:frr