Typically, this is to accept it, drop it, or reject it (which sends an error back to the sender). Targets: A target is a decision of what to do with a packet.The outcome, where a packet is sent, is called a target. Rules can block one type of packet, or forward another type of packet. Rules: A rule is a statement that tells the system what to do with a packet.When a packet is received, iptables finds the appropriate table, then runs it through the chain of rules until it finds a match. Tables: Tables are files that join similar actions.Iptables identifies the packets received and then uses a set of rules to decide what to do with them. Data is broken up into smaller pieces (called packets), sent over a network, then put back together. Access to a terminal window/command line (Ctrl-Alt-T, Ctrl-Alt-F2).(Note: this is a super-esoteric, very specific question, so I did wonder if Network Engineering might be more appropriate, but Linux local multicast egress follows FORWARD chain when smcroute is active 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. 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.
Ncoghlan Asks: iptables NETMAP not reliably adjusting source address of multicast UDP packets
0 kommentar(er)
