PR https://github.com/vyos/vyos-1x/pull/1042

vyos@gw-1:~$ show interfaces ethernet eth1 physical
Settings for eth1:

Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g

:...skipping...
Settings for eth1:

Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
                       drv probe link
Link detected: yes

driver: igb
version: 5.6.0-k
firmware-version: 0. 6-1
expansion-rom-version:
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
~
vyos@gw-1:~$ show interfaces ethernet eth2 physical
Settings for eth2:

Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Full 
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
                       drv probe link
Link detected: yes

driver: igb
version: 5.6.0-k
firmware-version: 0. 6-1
expansion-rom-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
vyos@gw-1:~$

What is the hardware used? It's weird that ethtool can not detect the NIC driver.

To reproduce:

[edit vpn sstp]
vyos@r4-epa1# compare 
[edit vpn sstp]
+authentication {
+    local-users {
+        username foo {
+            password bar
+        }
+    }
+    mode local
+}
+client-ipv6-pool {
+    prefix 2001:db8::/48 {
+    }
+}
+gateway-address 192.168.122.14
+ssl {
+    ca-cert-file /config/user-data/sstp/ca.crt
+    cert-file /config/user-data/sstp/server.crt
+    key-file /config/user-data/sstp/server.key
+}
[edit vpn sstp]
vyos@r4-epa1# commit
[ vpn ]
Note: the IPsec process will not start until you configure some tunnels, profiles, or L2TP/IPsec settings

PR https://github.com/vyos/vyos-1x/pull/1037

Draft PR: https://github.com/vyos/vyos-1x/pull/1033

PR https://github.com/vyos/vyos-1x/pull/1032

All subnets that share the same physical network should be declared within a shared-network declaration

Oct 18 22:24:01 r1-roll dhcpd[4985]: Interface eth2 matches multiple shared networks

As for me we shouldn’t allow to downgrade images. So there are no “downgrade migration scripts”. Each downgrade - good point to get a brick.
At least we should generate a warning.

let's do it but not in syslog section

WAN interface is eth2. It set to DHCP
LAN interface is eth3. It set to static address

What is on the eth3 interface?

Considered while implementing T3642 to have a general LE availability.

Tested on VyOS 1.3.0-epa1

Tested in VyOS 1.2.8, VyOS 1.3.0-epa1, VyOS 1.4-rolling-202109190558

Tested in VyOS 1.3.0-epa1 & VyOS 1.4-rolling-202109190558

https://github.com/vyos/vyos-1x/pull/1028 — though probably needs some tests developed?

Tested on VyOS 1.3.0-epa1.
Confirm IBGP reflection to non-RR-Client
Lab Topology:

Sorry for the late reply, I've been waiting for a maintenance window to test this in. Again as this is a production device I only have limited debug info before having to roll back to the working version. I installed 1.4-rolling-202110150613 and on booting show interfaces does indeed show all the interfaces. The igb driver interfaces were showing as up (u/u). The i40e interfaces were showing as down (u/D).

In the real-world to avoid it they used cluster-id / a session BGP between them , it's the idea of RR :

@francis Sorry, I don't understand the problem.
Agree that route received from one IBGP peer should not be forwarded to another IBGP peer. Except for the RR client.

@NikolayP The concern here is solely this: IBGP neighbors that do not have route-reflector-client set should not received learned routes. Currently, they do. If this in intentional, then the docs should be updated to clarify this.

@maznu Can you create a PR?

If Cluster ID is not used, full IBGP mesh must be used. Exception is RR client, they should only have peering with RR.
Router 10.0.0.21 has no peering with 10.0.0.3.
This is incorrect IBGP design.

For this we create text files as the group-config includes (they contain route and other per group config directives, generally around security).

In T3008#78303, @jack9603301 wrote:

Does anyone understand the meaning of these performance data? I don’t know the unit of these data

In T3896#107997, @Viacheslav wrote:

@SquirePug Can you share more details, which templates and parameters did you edit?

Present in 1.4 and 1.3.0-epa1

set service pppoe-server authentication radius server 192.0.2.1 acct-port
Possible completions:
   <1-65535>    Numeric IP port (default: 1813)

@SquirePug Can you share more details, which templates and parameters did you edit?

not yet , we 've been trying with different CT but it's not solve the main problem . I understand that disabling conntrack is not possible because is used for nat.

@dmbaturin Did you get my email? If not, please let me know and I will send it again

Is any work around for this scenario ?

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'

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

@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

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 :

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 .

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.

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

The same bug described there T2845

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

new uefi style