RJ45 Connections when running CORE in Docker

[derkin123]

I am attempting to create an EMANE network using only docker containers where there are 3 separate containers all running Ubuntu 18.04, 1 acts as a router through which the other two children containers will communicate. This is NOT a distributed CORE simulation, only the router container hosts a core daemon, where the simulation looks like this:

The emane network node is stock besides using the IEEE model.

The router container contains VLANs:
eth0.100: ip 10.13.2.5
eth0.101: ip 10.13.3.5

The first child has:
eth0.100: ip 10.13.2.3

The second child has:
eth0.101: ip 10.13.3.3

I have the routing setup in the containers such that I can ping from the first child to the second child through the router as follows:
10.13.2.3 -> 10.13.2.5 -> 10.13.3.5 -> 10.13.3.3

This works fine before I start the core simulation, but when I start the simulation the connection between the router and either child is available even though the connection is not being attenuated by CORE/EMANE. Within a CORE node I can ping between 10.0.0.1 and 10.0.0.2 as well as between 10.13.2.5 and 10.13.3.5. However neither 10.13.2.3 or 10.13.3.3 is reachable after the simulation starts from the router container/ the CORE nodes in the sim.

The nodes seem to be configured properly with their routing:

I also can't seem to find any ip/routing settings removed from any of the containers once the sim has started, only the additional routing settings put on the router container setup by CORE.

To me it seems like something that CORE is setting up is causing an issue with the traffic not being routed to the router container properly but I couldn't find what it would be. Any ideas on what the issue might be?

[bharnden]

Your picture shows eth0.101 and eth0.102, but your text only speaks to eth0.100 and eth0.101.

Either way my assumption on your issue may be a misunderstanding of how RJ45 works. It will remove any addressing that exists on the interface and its goal is to help turn the interface into a passthrough for traffic going in and out of it.

Normally this may be an interface on your physical machine, and you have another external machine directly connected to it. Using an RJ45 node on that interface will now make that external machines traffic flow into the scenario as if it were a part of it.

[derkin123]

Sorry about the interface names, I mistyped the names with 100-> 101 and 101->102. So I've used rj45 to get the behavior that I am hoping for with the same setup I described but using VMs instead of containers.

I believe I am trying to use rj45 connectors similarly to how you mentioned they work, although I don't know if they will work with containers like I want.

I want traffic to flow from the two other containers into the one running the core daemon and I want this connection to be cut when the connection between the mdr nodes in the simulation is cut. I have a shared vlan that each RJ45/container pair shares (eth0.101/eth0.102) and this is what I want the traffic to flow through.

I made this diagram to show what I am hoping to achieve, where the dotted lines and the connections that can be cut.

Does this make sense/seem like something that can be achieved via rj45 connectors or will this require something else?

[bharnden]

Not sure the EMANE network node in the diagram above is the best way to represent it, because it is not a true entity in the path of traffic. It is just a process N2 and N3 are running, that theoretically lets them talk to one another, but I get the point.

In theory the above should work, the containers may be a factor and issue, as you are trying something new I have not toyed with. You could run tcpdump on the path of traffic and follow it to see where things go wrong etc, which may provide a clue as to what is going wrong.

I would also eliminate EMANE for now and use a standard wired link between N2 and N3. If you can prove that out to work, then potentially your issue is with EMANE and its configuration (since that adds a ton of complexity to how everything works).

[derkin123]

To preface I'm not very network experienced and haven't used tcpdump before so I may be missing helpful information but I'm testing using a situation like you mentioned:

where I am pinging from the router container to the ip 10.13.3.3 before stating a core simulation where the ping goes through and the tcpdump -i eth0.102 for the router and other container looks like:

router:

10.13.3.3 container:

When I stop this ping, start the simulation, then try to restart the ping I get only ARP replies/requests:

router:

10.13.3.3 container:

To me this seems like the ping is not routing through correctly, I check the routing and it doesn't change on either container before or after starting the simulation.

router:

10.13.3.3 container:

node 2:

[derkin123]

For anyone who wants to do something like this, I found that you need to create a bridge (I don't think the subnet matters) that is shared by your containers, and then within each container specify the vlans that you want your rj45 nodes to be connected through.

For instance say you have 3 containers, 1 running core-daemon and 2 you want to use through rj45 nodes, you would set up a network like so:

             Rj45-1 container <-> CORE Container <-> Rj45-2 container

Bridge IP: X.X.X.1 X.X.X.2 X.X.X.3
VLAN 1: Y.Y.Y.1 @ eth0.1 Y.Y.Y.2 @ eth0.1 None
VLAN2: None Z.Z.Z.2 @ eth0.2 Z.Z.Z.1 @ eth0.1

You can set up the VLANs via:

RJ45-1 Container
ip link add link eth0 name eth0.1 type vlan id 1
ip addr add Y.Y.Y.1/24 dev eth0.1
ip link set eth0.1 up

ip route add Y.Y.Y.2 dev eth0.1
ip route add Z.Z.Z.1/24 via Y.Y.Y.2

RJ45-2 Container
ip link add link eth0 name eth0.2 type vlan id 2
ip addr add Z.Z.Z.1/24 dev eth0.2
ip link set eth0.2 up

ip route add Z.Z.Z.2 dev eth0.2
ip route add Y.Y.Y.1/24 via Z.Z.Z.2

CORE Container
ip link add link eth0 name eth0.1 type vlan id 1
ip addr add Y.Y.Y.2/24 dev eth0.1
ip link set eth0.1 up

ip link add link eth0 name eth0.2 type vlan id 2
ip addr add Z.Z.Z.2/24 dev eth0.2
ip link set eth0.2 up