fix: use Provider peering in k8s_nano_internet for cross-IX routing#459
Open
Ssqe2 wants to merge 2 commits intoseed-labs:k8sfrom
Open
fix: use Provider peering in k8s_nano_internet for cross-IX routing#459Ssqe2 wants to merge 2 commits intoseed-labs:k8sfrom
Ssqe2 wants to merge 2 commits intoseed-labs:k8sfrom
Conversation
Ssqe2
force-pushed
the
k8s
branch
6 times, most recently
from
a49c3bb to
c3f6e35
Compare
added 2 commits
April 2, 2026 23:47
The original interface_setup script renames interfaces by matching IP addresses from ifinfo.txt to SEED topology names (e.g. net0, ix100). In Docker mode, interfaces start as eth0/eth1/..., so renaming works correctly. In K8s+Multus mode, Multus pre-assigns interfaces sequentially as net1/net2/...; when the script tries to rename net1 to the SEED name net2, that name is already held by another Multus interface. Linux rejects the rename; worse, the script has already brought the interface down with `ip link set down` and does not recover it on failure, leaving the node with no network connectivity. Fix: KubernetesCompiler._addFile() now intercepts /interface_setup and generates a K8s-specific two-phase rename script. Phase 1 renames all Multus interfaces to temporary names (tmp_net1, tmp_net2, ...) to vacate the namespace; Phase 2 renames each temporary name to the correct SEED topology name via IP matching. This eliminates the naming conflict. After the script completes, interfaces carry their SEED topology names and BIRD configs work without modification. Also fix DNS-1035 compliance: resource name generation in _compileNode and _compileNodeKubeVirt now strips dots in addition to underscores, as SEED network names may contain dots that are invalid in K8s resource names.
…te peering B29 email_realistic.py: fix unclosed triple-quote syntax error. 6 K8s examples (k8s_hybrid_kubevirt_demo, k8s_mini_internet, k8s_mini_internet_with_visualization, k8s_multinode_demo, k8s_nano_internet, k8s_transit_as): replace addRsPeer/addRsPeers with addPrivatePeering(s) + explicit PeerRelationship. RS-based peering does not carry Provider/Peer relationship semantics -- the RS treats all peers symmetrically, making routing policy semantically incorrect for transit AS topologies. Direct private peering with explicit relationship semantics (Provider or Peer as appropriate) fixes this. Files missing Ibgp() and Ospf() layers now add them -- required for iBGP next-hop resolution via OSPF loopback reachability.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The original k8s_nano_internet.py used addRsPeer (Peer relationship)
to connect ASes via IX Route Servers. Under valley-free routing policy,
routes learned from Peer sessions are tagged PEER_COMM and will not be
re-exported to other Peers. This caused cross-IX routing failure: AS3
would not forward routes learned from IX101 to IX100, so AS150 could
not reach AS151/AS152.
Fix by switching to addPrivatePeering with PeerRelationship.Provider,
consistent with the Docker-based A20 nano-internet example. This
replaces Route Server peering with direct bilateral peering, where AS3
acts as a transit provider for AS150/151/152. Routes are now tagged
CUSTOMER_COMM and correctly propagated through the export filter.
Add Ibgp and Ospf layers for AS3 internal routing.
The Route Server approach was dropped because cross-IX unreachability
under Peer relationships is expected BGP behavior, not a bug.
Achieving cross-IX connectivity requires a Provider/Customer
relationship, which is also how the Docker A20 example is designed.
Verified: cross-IX ping AS150<->AS151<->AS152 all pass, all routes
carry CUSTOMER_COMM, valley-free policy fully preserved.