vcswatch reports that
this package seems to have a new changelog entry (version
1.0.8, distribution
UNRELEASED) and new commits
in its VCS. You should consider whether it's time to make
an upload.
Here are the relevant commit messages:
commit 6b3e09e13abb5b4cbc6aa17c4a8049b97a4a0aa2
Author: Thomas Goirand <zigo@debian.org>
Date: Sat Nov 14 22:48:12 2026 +0100
Disable rp_filter on the switch VMs
Write net.ipv4.conf.all.rp_filter=0 and
net.ipv4.conf.default.rp_filter=0 to
/etc/sysctl.d/99-rp-filter.conf on every switch VM, as neutron's
own BGP CI (tempest-multinode-with-bgp, roles/leaf and
roles/spine) does: the kernel's reverse path validation, loose
mode included, drops the asymmetric return traffic of
BGP-2-the-host floating IPs whenever the chassis advertising the
/32 host route differs from the one egressing the reply. Named
99- so that it applies after Debian's 10-network-security.conf,
whose default.rp_filter=2 would otherwise win the key.
commit d2e6e021340e18bbd6e2b010fc3c1a4fbbd53784
Author: Thomas Goirand <zigo@debian.org>
Date: Fri Nov 13 13:23:29 2026 +0100
Update the README to the enp0sN interface names
The q35 machine type renamed the guests' NICs: adapt the link-local
connectivity examples and the DHCP server port range of the README.
commit eb3d38734f690d54208e844f6b3c76fc745f750d
Author: Thomas Goirand <zigo@debian.org>
Date: Fri Nov 13 13:23:13 2026 +0100
Auto-login root on the switch consoles
The VGA and serial consoles of the switch VMs are only reachable from
the ikvswitch host (VNC and IPMI SOL), yet they still asked for the
root password on every login. Build the template with bodi's
--tty-autologin yes and --add-serial-getty ttyS0: the VGA getty and
both serial gettys then auto-login root, and the kernel console lands
on ttyS0 so the SOL also shows the boot messages.
commit 58def83817789b3db906d7a0d1618bce0bd2633b
Author: Thomas Goirand <zigo@debian.org>
Date: Fri Nov 13 13:20:23 2026 +0100
Run the switch VMs with the q35 machine type
Mirror what the OCI PoC did for its own VMs: -machine q35 instead of
the default i440fx, with the PCI address of every device pinned (the
virtio-scsi controller at 0x3, then one slot per NIC from 0x4 on), so
the guest interface names are predictable: enp0s4, enp0s5, and so on.
The q35 PCIe root bus gives faster virtio defaults and drops the
legacy floppy controller.
The generated /etc/network/interfaces and FRR configurations follow
the rename: every ensN becomes enp0sN with the same N, since the slots
numbering is unchanged. No template rebuild is needed: the machine
type and the addresses are runtime-only qemu parameters.
commit 5792e847269ffb182c5831277581ebaefd8211f4
Author: Thomas Goirand <zigo@debian.org>
Date: Fri Nov 13 12:19:00 2026 +0100
Make test_mgmt_subnets executable
pkgos-run-tests runs each test file directly, so the mode must be
0755 like the other tests, otherwise the Jenkins build fails with
"Permission denied".
commit 157419aa10ac04a87f905dd3a547f08144192fbd
Author: Thomas Goirand <zigo@debian.org>
Date: Fri Nov 13 12:15:54 2026 +0100
Skip speaker peers of undefined VLAN prefixes
The 5-peer speaker block dereferenced VLAN_SBUNET6_PREFIX without a
guard. On a host upgraded from 1.0.7, whose conffile only defines
VLAN_SBUNET1 to 5, the generated frr.conf gained literal "neighbor
.200 remote-as external" lines. Build the peer list with per-group
guards instead, skipping the prefixes a configuration file doesn't
define.
commit 36920fcf9203a9e605fc681eb90288e34931801c
Author: Thomas Goirand <zigo@debian.org>
Date: Fri Nov 13 12:15:51 2026 +0100
Create exactly VLAN_SUBNETS_NUM pool bridges
VLAN_END was computed as VLAN_START + VLAN_SUBNETS_NUM and fed to an
inclusive seq, so every run created NUM+1 pools and bridges: with the
new default of 8, a 9th brvlan19 bridge was added on 192.168.121,
overlapping the cl1 management /26 the leaves now originate as a
blackhole, and the knob validation accepted the phantom 121 octet.
Bound the pool loops at VLAN_START + VLAN_SUBNETS_NUM - 1 and shrink
the knob validation range to match.
commit 280f3ffa072cb682cefa68fd73cbf13269a9cfdd
Author: Thomas Goirand <zigo@debian.org>
Date: Fri Nov 13 12:15:45 2026 +0100
Keep mgmt statics out of the leaf BGP block
The 1.0.8 management subnet origination emitted the backing blackhole
statics inside the "router bgp" context, between the spine peer-group
members and the leaf ones. bgpd (FRR 10.3, traditional integrated
config) stops reading frr.conf at such an unowned command: every leaf
lost its leaf peer-group members, both address-families, the network
statements and the route-maps, so no session could come up and the
leaves originated nothing (spine-facing sessions dying with
"Configured AFI/SAFIs do not overlap with received MP capabilities").
Emit the statics before the BGP block instead, where bgpd demonstrably
tolerates foreign lines (as it does for "ip address"). Found live on
bdbdev-oci-3: leaf1's "show running-config" ended at the first static,
with "show bgp summary" reporting no neighbors at all.
commit 041c3c12256508153fa8d28a75b62b7852453aba
Author: Thomas Goirand <zigo@debian.org>
Date: Thu Nov 12 14:23:35 2026 +0100
Extend the VLAN leaf's BGP speaker peers to cl3's controllers
The VLAN-enabled leaf's FRR template hardcoded two BGP speaker
peers, cl1's network nodes on the legacy speaker VLAN (113.200 and
113.201). The cl3 OVS-mode cluster hosts its BGP speakers on its
three controllers instead, whose transport VLAN (16, 192.168.118)
is L2-adjacent to the same leaf. Accept their sessions too, by
hardcoding 192.168.118.200, .201 and .202 as additional eBGP peers
with the same vm-in/vm-out route-maps, so controller-hosted speakers
can peer and announce routed networks for the fabric.
Both neighbor blocks are now generated by a loop over the five peer
addresses, and a new unit test asserts all five land in the
generated leaf2 frr.conf with their route-maps, while leaf1 stays
free of them.
commit c569695191ac8f22e202c3f4184f623481f9f8c4
Author: Thomas Goirand <zigo@debian.org>
Date: Thu Nov 12 13:32:29 2026 +0100
Bump VLAN_SUBNETS_NUM default to 8
The 1.0.8 example configuration ships VLAN_SBUNET1 to VLAN_SBUNET8
prefix variables, but kept VLAN_SUBNETS_NUM=6, so a default install
never created the 7th pool the same release advertised, and nothing
created the 8th. Bump the default to 8, creating VLAN 11 to 18 with
192.168.113.0/24 to 192.168.120.0/24, keeping the octet = VLAN + 102
pairing. The 8th pool carries cl3's Octavia transport network in the
OCI PoC, which freed 192.168.120.0/24 by moving cl1's Octavia
management network to 192.168.127.0/24 on the OCI side.
Existing labs keep their edited configuration (the /etc file is a
conffile), so raise VLAN_SUBNETS_NUM there before the PoC rebuild.
commit c2cd695e2a08193797ada2be2012b7bc534a06eb
Author: Thomas Goirand <zigo@debian.org>
Date: Thu Nov 12 10:55:40 2026 +0100
Make VLAN subnet BGP origination configurable
Add the --map-redistribute-vlan-subnets option to the start command,
with all|none|<list> values (all being the default, keeping the
historical behavior), controlling whether the VLAN-enabled leaf
switch redistributes the per-VLAN subnets as connected routes into
BGP. These subnets are for the OVS mode: its network nodes are
L2-attached to these VLANs and source their SNAT traffic and BGP
next-hops from these subnets, so the default of all keeps the SNAT
return path working. For OVN BGP-2-the-host clusters, reachability
instead comes from the /32 host route announced by the compute
hosting each floating IP, and a covering /24 would shadow it on the
compute nodes, hence the opt-out.
Also:
- originate the cluster management subnets (CLUSTER_MGMT_SUBNETS)
from every leaf, untagged, so the OVN chassis router can route
floating IP replies back to management-source clients, adding the
missing cl3 management /26 (192.168.123.0/26);
- extend the VLAN subnets to 7 (VLAN 11 to 17, 192.168.113 to
192.168.119), for a 7th pool usable as a second external network;
- rehome the IPMI bridge inside the /19 (192.168.200.1 to
192.168.109.1), derive DHCP_RELAY_DESTINATION and
CLUSTER_MGMT_SUBNETS from HOST_VIRTUAL_SUBNET_START_PREFIX, and fix
the hardcoded 113.201 peer address of the VLAN leaf's FRR template.