How to use the RJ45 tool in the CORE network emulator?

0
votes

I have recently installed the CORE Network Emulator, and have already read the relevant parts of the the docs. CORE promises to be able to connect the virtual networks you create in it with physical once. However, I am having trouble connecting my virtual network to the physical one, which the RJ45 tool promises to do. From what I have read, in the CORE NetEm you can assign a network interface to the RJ45 tool, which then bridges your physical device to the network.

I have tried creating a basic topology, with one virtual host, a router, and then my computer with the RJ45 tool and I am trying to see if I can reach my computer from the host or vice versa with a ping command, but all I get is "network is unreachable."

Unfortunately, the CORE docs don't go into detail in how to use this tool and I wasn't able to find any other sources on the internet which have to do anything with it.

Here you can find the documenation: http://coreemu.github.io/core/usage.html#connecting-with-physical-networks

Does anyone have any experience with CORE and can help me out with this?

Many thanks!

2
networkingemulationsimulator
You bridge with the same network, but you must route between networks. A router must know how to reach a destination network, and it can do that in three ways: directly connected network, statically configured route, or through a routing protocol with neighbor routers. – Ron Maupin
Hi Ron, thanks for the answer. Not sure if I understood correctly what you mean by bridging with the same network. But I tried connecting the RJ45 host to a router which is then connected to some other virtual hosts. I added an entry to the router's routing table with the physical IP address and which path to use, but I still couldn't reach the physical host. I added a virtual host to the same switch as the physical host, and was able to reach that without any problem from the other hosts, just not the RJ45 one. – Rudy Ailabouni
"you can assign a network interface to the RJ45 tool, which then bridges your physical device to the network." If you are dealing with two different networks, then bridging is not appropriate. You must route between networks. – Ron Maupin
I did try to add a router and was able to communicate with hosts on the 2nd network without a problem, but not with the physical host... – Rudy Ailabouni
But your post says that you are trying to bridge to the physical host. – Ron Maupin

2 Answers

1
votes

The CORE RJ45 tool creates a Linux bridge between a virtual interface and a physical one.

Example: if you have node n1 linked to an RJ45 node assigned to eth0, after pressing "Start", on the underlying host you'll have a bridge with the n1:eth0 veth0 pair device and your host's eth0 device enslaved.

You'll need to configure routing between your virtual and physical networks. In the above example, suppose n1:eth0 is 10.0.0.1/24. When you plug a physical device into eth0, that device needs a route back to 10.0.0.1. That device may be on the same subnet, for example if it has the address 10.0.0.2/24. If your physical device has an address on a different subnet, you'll need to manually add a route to reach the 10.0.0.0/24 network, via the connecting interface.

1
votes

I had the same problem. My CORE version is v.5.3.0 (20190615) on Ubuntu 18.04 LTS w/ Linux 5.0.0-37 generic on x86_64. Have OSPF v2, v3, Zegra, and IPForward correctly configured at r1, so that vpc1 can send and receive data successfully.

The RJ45 port of a built-in physical interface on the CORE host was mapped to a virtual endpoint for connecting the 2nd real computer, rpc 192.168.10.10/24 with a virtual switch sw1. Another virtual PC, vpc1 192.168.10.20/24 and a router r1 with 192.168.10.1/24 and 10.0.10.1/24 two interfaces.

Can ping from rpc to vpc1 and to r1 at 192.168.10.1 but not 10.0.10.1 or beyond. However, using the two-node tool or virtual terminal of vpc1, I can also traceroute and ping r1 and beyond.

The reason why the traffic of the real remote PC rpc could not be routed by r1 from 192.168.10.1 to 10.0.10.1 and back was because its WiFi was left on with the gateway configured to a FiOS router. You cannot have two gateways. Once the WiFi got turned off, the traceroute and ping can reach r1 and beyond.

This could also be the root cause of your problem.