I run all tests locally and in GitHub Actions (Azure cloud) using: cd test/ I've whipped up a test case for this in preparation for the next release (v2.5). There is a very similar problem reported in the SMCRoute issue tracker, only difference from you is they don't use 1:1 NAT with netmap (yet). We use this exact approach, albeit with actual HW and not network namespaces, for various customers at work. I'm less clear on the boundaries between Server Fault and the Unix & Linux stack exchange when it comes to configuring Linux servers, though) (Note: this is a super-esoteric, very specific question, so I did wonder if Network Engineering might be more appropriate, but made it clear that that is for working with commercial routers etc, not for Linux network namespace config. there's something else that needs to be configured (or not configured) in the kernel, iptables, or smcroute to keep the misbehaviour from happening.this isn't expected to work, compensating at the application layer is the best that can be done (which seems unlikely given the use of network namespaces in Linux container environments).The goal of asking the question is to help figure out which of the following applies: I haven't so far been able to determine what causes the transition between the two states, only work around the problem at the application layer by adjusting based on the active network namespace or the source network interface when the source address information looks wrong. The source filter on the mroute from peer1 rule in the smcroute configuration is there to prevent a multicast routing loop that otherwise starts when the server flips into the second set of behaviour. Instead, either subscribers in both namespaces see the pre-NETMAP 192.168.0.x source addresses, or else they see the 192.168.1.x post-NETMAP addresses. UDP multicast subscriptions inside the root namespace will see the modified post-NETMAP 192.168.1.x source addresses.UDP multicast subscriptions inside the network namespace will see the unmodified pre-NETMAP 192.168.0.x source addresses.
The actual topic of this question is that there's a weird glitch in the NETMAP source IP adjustment that I haven't been able to explain, only work around. Ns1 example smcrouted config rules for a supported multicast group: mgroup from eth1 group 239.255.60.60 Ns1 example NETMAP rules for the static IP subnets: sudo -n ip netns exec ns1 iptables -t nat -A PREROUTING -d 192.168.1.0/24 -i peer1 -j NETMAP -to 192.168.0.0/24 To try to visualise the traffic flows: embedded network a separate IP address in a distinct (non-NAT) subnet for the root namespace side of the peer links to work around the topic of this question (call it 192.168.(x+100).1).an smcrouted instance inside each network namespace to forward multicast group registrations.an iptables NETMAP rule in each namespace to map the conflicting static IP subnet (call it 192.168.0.x) to a non-conflicting set of static IP subnets (call them 192.168.1.x, 192.168.2.x, etc).a peer link between each network namespace and the root namespace (call them peer1, peer2, etc from the network namespace side and veth1, veth2, etc from the root namespace side).a separate Linux network namespace for each different embedded network (call them ns1, ns2, etc).network links for each embedded network (call them eth1, eth2, etc).This mostly works fine, including for UDP multicast traffic, given: In an embedded/IoT use case, I have a management host running Linux that needs to be able to talk to multiple networks that each use a common set of static IP addresses.
0 kommentar(er)
