@dmbaturin Did you get my email? If not, please let me know and I will send it again
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 8 2021
@RyVolodya can you check a new image and close this task if it was fixed?
Is any work around for this scenario ?
Oct 7 2021
We usually communicate via https://vyos.slack.com
or matrix
sure I will just create a separate VM with a clean VyOS and the card - you got some sort of irc or discord to communicate?
Although a cluster ID might be helpful the real problem is that the routes are reflected to all peers – not just ones that are route reflector clients:
and It's the way to set on Vyos:
set protocols bgp <asn> parameters cluster-id <id>
there is a recommendation that if you use RR in the same hierarchy and avoid loop , we need to set 'cluster-id'
Any chance to get remote access to the system to debug this?
This creates routing loops on all BGP neighbors as they are all advertising the same routes
Neighbors that are not route-reflector-client should not receive learned routes, only routes that are explicitly set in the config. So in the example above, I would not expect to have multipath routes for 10.0.0.1 and 10.0.0.2, and I would not expect to see any route for 10.0.0.6
RR1 - BGP Peer / Route Reflector / 10.0.0.1
RR2 - BGP Peer / Route Reflector / 10.0.0.2
RR3 - BGP Peer / Route Reflector / 10.0.0.3
Problem solved and it was my mistake.
@francis It is not clear. Can you provide an example of configuration? What do you get and what do you expect?
Also tested 1.4-rolling-202110020217 and it exhibits the same issue
Oct 6 2021
The question how to disable connection tracking.
yes, It is an issues related with the conntrack+ nat/vrf leak , I share something where the problem is clearer :
Suricata IPS with ipset
Hello Everyone,
I am testing 1.4 vrf leak from vrf x to default with NAT and is not working as expected. Outbound traffic is get forwarded to gateway NAT applied, but REPLY never forwarded to originator .
Oct 5 2021
Yeah, that seems reasonable to me. I would prefer not add clutter to the system node if it can be avoided.
Should we expose a system-level DUID at all? If a user wants to customize it, they could always set it on a per-interface basis using the existing configuration node.
That seems fair, basically make the DUID generation deterministic. There is some defined structure to the DUID format, I think this would be a "type 3 DUID" per this document: https://www.juniper.net/documentation/en_US/junose15.1/topics/concept/dhcp-unique-id-servers-clients-overview.html.
Oct 4 2021
Can we close it @Viacheslav?
what about the following:
- Add a new system ipv6 duid CLI node which acts as the general DUID used on the system and renders /var/lib/dhcpv6/dhcp6c_duid, if not overwritten at the "interface" level set interfaces ethernet eth0 dhcpv6-options duid
- If system ipv6 duid is not configured, we "generate" the DUID using the eth0 MAC address automatically and store it in /var/lib/dhcpv6/dhcp6c_duid - thus no issue on image upgrades anymore
Hi c-po,
The same bug described there T2845
Submitted this PR: https://github.com/vyos/vyatta-cfg/pull/42
Not sure why we should check the primary ip address, but to fix it possible to change:
if is_subnet_connected(subnet, primary=False)
It was described there T3610 and requires more tests.
Acknowledged. Tested on 1.3.0-epa1
Oct 3 2021
new uefi style
Can you check the MAC address of the card not that the interface got mixed up in their naming?
Oct 2 2021
Package was upgraded to PDNS 4.5 should be fixed - can you please retest with ANY release AFTER
- vyos-1.4-rolling-202110020217-amd64.iso
- vyos-1.3-beta-202110020342-amd64.iso