srl: ipv6 link-local address conflict between parent (srbase) and child (srbase-default) breaks unnumbered bgp #2280
Comments
|
Unfortunately I can't seem to reproduce this issue. I took your config examples and created a self-contained containerlab topology: name: v6lla
topology:
nodes:
leaf1:
kind: nokia_srlinux
image: ghcr.io/nokia/srlinux:24.7.2
startup-config: |
interface ethernet-1/51 {
description "To SPINE:e1-1"
admin-state enable
subinterface 0 {
type routed
ipv6 {
admin-state enable
router-advertisement {
router-role {
admin-state enable
max-advertisement-interval 120
min-advertisement-interval 30
}
}
}
}
}
network-instance default {
admin-state enable
interface ethernet-1/51.0 {
}
protocols {
bgp {
autonomous-system 65001
router-id 100.65.32.4
dynamic-neighbors {
interface ethernet-1/51.0 {
peer-group underlay_fabric
allowed-peer-as [
65004
]
}
}
afi-safi ipv4-unicast {
admin-state enable
multipath {
allow-multiple-as true
maximum-paths 8
}
}
afi-safi ipv6-unicast {
admin-state disable
}
group underlay_fabric {
admin-state enable
}
}
}
}
spine1:
kind: nokia_srlinux
image: ghcr.io/nokia/srlinux:24.7.2
startup-config: |
interface ethernet-1/1 {
description "To Leaf:e1-51"
admin-state enable
subinterface 0 {
type routed
ipv6 {
admin-state enable
router-advertisement {
router-role {
admin-state enable
max-advertisement-interval 120
min-advertisement-interval 30
}
}
}
}
}
network-instance default {
admin-state enable
interface ethernet-1/1.0 {
}
protocols {
bgp {
admin-state enable
autonomous-system 65004
router-id 100.65.32.1
dynamic-neighbors {
interface ethernet-1/1.0 {
peer-group underlay_fabric
allowed-peer-as [
65001
]
}
}
afi-safi ipv4-unicast {
admin-state enable
multipath {
allow-multiple-as true
maximum-paths 8
}
}
afi-safi ipv6-unicast {
admin-state disable
}
group underlay_fabric {
admin-state enable
failure-detection {
enable-bfd true
fast-failover true
}
}
}
}
}
links:
- endpoints: [leaf1:e1-51, spine1:e1-1]This topology embeds the configs, so that you should have the nodes boot with the corresponding config bits applied. Once I deployed this topo I see the bgp established just fine: fwiw, my v6 LLA are different in the two net nses: |
|
Hi @hellt and thanks for your reply, That's interesting, because in your case you also have the same MAC address but the LLA are different, with the one on the srbase side derived from a different MAC address. It is my understanding that i'm experiencing the issue because the LLA are the same. I tried to load a new topology from the file you shared on the same host system, and i observe the same than you: So it looks like something in my topology is preventing the LLA from being derived from that different MAC address, but it is not clear why and how i can avoid it. A key difference is that i'm bootstraping the containers with their default config, and load the actual config to be tested only later. This is because my config files are too big to be loaded using the I'll make further tests to try to narrow this further down. |
can you share more details about it? I can see how you might now want to include it in the topology file due to the size, but you should be able to use |
|
i think we will pause this because we are under heavy time pressures to complete additional testing for a new deployment imminently. if you dont mind leaving this open a few weeks, we can come back to the deep dive, for now, we have a workaround that works well enough |
|
So the way the configuration is loaded (either directly using The following is a reproducing topology: Results: The issue no longer happens if the |
|
FYI i'm using the latest clab version: |
|
I can imagine how doing the delayed start between the nodes that share the same link might cause some issues. Do you need this stage after all? Can you live without it? Stages work best when you either delay creation of nodes that do not connect one with another (like islands of your topology) or if they do not share the same link segment, like connecting over a bridge. |
|
Its to manage the delivery of the topology inside a nominal host. our full topology is like 50 nodes and even with a decent sized host, it gets very sad during the initial standup because the cpus are murdered with all the provisioning. stages allow to break up the startup hit, when the running topology sits happily inside the hardware we have on hand |
|
Stages were also meant to have certain parts of the network start before others, e.g. have a ready core layer before starting fabrics. I've tried removing those and replacing with |
|
As expected, after removing the |
|
Well even without So this all looks like a race condition when creating containers and wiring up. Do we ever need to have an LLA on the parent (srbase) interface? If not maybe this can be avoided using the workaround described in my first post. |
I've hit this issue while trying to test an unnumbered bgp session (ipv6 link local addresses) between two srl containers running 24.7.2 or 23.10.
It can be reproduced with the following minimal setup comprised of a leaf (srl/ixrd2l) and a spine (srl/ixrd3l). Port e1-51 of the leaf is connected to port e1-1 of the spine.
Configuration as in the attached files:
spine.txt
leaf.txt
The BGP session fails to establish, packet capture between the two containers shows that the ICMPv6 RA are correctly exchanged and one side attempt to establish the session. However, the other side replies with both SYN/ACK and RST before any OPEN has been sent which ends up the session prematurely.
Additionally, ping on the peer's link-local address reports duplicates:
After further investigation i believe this is because the parent interface inside the srbase container has a link-local address enabled, that happens to be the same than the child inside srbase-default. For example:
Therefore, the SYN is received inside both containers, srbase rejects it with RST (which causes the issue) and srbase-default accepts it.
To confirm, i ran the following commands, in order to get rid of the link-local address on the parent interface:
After this, the BGP session establishes successfully, and ping no longer shows duplicate packets, which confirm the aforementioned assumptions.
As another workaround, using vlan-tagging on the p2p interfaces prevent the issue from happening.
The text was updated successfully, but these errors were encountered: