zipqert.blogg.se

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.