|
Reference Number: AA-02216
// Views: 5
// Created: 2023-08-28 08:36:05
// Last Updated: 2023-08-28 09:47:00
General Article
[EXata] Having Different Subnets / Network Range in EXata (+ With Hardware-In-The-Loop) [EXata] Having Different Subnets in EXata (+ With Hardware-In-The-Loop)
Description:
This article explains how to setup subnets in EXata, in a co-simulation with RT-LAB or HYPERSIM and with an external device (a Raspberry Pi running a TCP Server script in this example).
Context:
In simple telecommunication network, all the devices are typically in the same network range (in the example below, all the nodes are in the 10.10.1.xxx range). This is typical for LAN network.
However, once the network starts to get bigger, then it often needs to be split into smaller networks, with one demarcation point (DMARC) with the rest of the network. A simple comparison would be a house that have several devices. All those devices are in a specific range (often 192.168.10.xxx) and can talk to each other directly. However, to talk to, e.g. Google, the packets needs to be sent to the router (the DMARC point of the house) and then forwarded to Google, which is in a completely different network as the house. This is done by configuring the gateway.
What is a Gateway?
Simply put, a gateway is the interface between to discrete networks. In other words, if I am a device, and I don't know where a packet is going, I will send it to the gateway.
Part 1 - Different Subnets in EXata
Here is an example in EXata:
Node 1 (190.0.2.2) is in a completely different range than Node 2 (10.10.1.101) and the point of contact between the two is the router (which has two interfaces, Node 5).
If we want traffic to flow, we need to configure the gateways for both Node 1 and Node 2. Right-click on Node 1 > Properties. Then in Node Configuration > Routing Protocol, configure the default gateway to 190.0.2.1 (the address of Node 5, the router).
What it means is: if Node 1 receives a packet and does not know what to do with it, then it forwards it to 190.0.2.1 and the router will handle it.
The same must be done with Node 2.
Part 2 - In a Co-Simulation Setup (RT-LAB or HYPERSIM with EXata)
NOTE: Part 1 must be done before doing part 2.
Let's say we have a setup where there is a TCP-Server and TCP-Client on the OPAL-RT side, going through EXata to communicate together (instead of the lo interface). The complete path would look as follow:
Now, the problem is the following: if I am the client, I am running in the default namespace and I see veth4 and the linked interface ex_veth4 BUT I do not see what is happening inside the EXata software. So if the model tells me 'here is a packet for 10.10.1.101, send it through veth4', then I will drop it, since I do not see 10.10.1.101 through veth4. The same applies to the server through veth5, it does not see the 190.0.2.x subnet.
The solution is to configure the gateway / routing rules for those interfaces.
In human words, the rule will look like (for the client): 'If you receive a packet that is for 10.10.1.101 to send through veth4, then send it to ex_veth4, and it will handle it'.
In Linux command line words, it will be:
route add 10.10.1.101/32 gw 190.0.2.3 dev veth4
Notice here the /32, which is a netmask of 255.255.255.255. In other words, it means that this rule applies only to that specific address 10.10.1.101 on interface veth4 and no one else. The gw stands for gateway.
For the server, the logic is the same (otherwise the packets won't come back):
route add 190.0.2.2/32 gw 10.10.1.99 dev veth5
IMPORTANT! : We want to be sure that, in the ns_exata namespace, it does not bypass the EXata process completely, so we also need to disable ipv4 forward feature. This can be done with the command:
ip netns exec ns_exata sysctl –w net.ipv4.ip_forward=0
IMPORTANT TOO!: Do not forget that the ns_exata gets created when we load the RT-LAB or HYPERSIM model, and destroyed once we reset. So we need to define those rules every time we load the model.
Part 2 - Summary
In short:
1- load the RT-LAB or HYPERSIM model (Do not execute EXata yet!)
2- connect via MobaXterm (or any other SSH tool) and execute the following commands:
ip netns exec ns_exata sysctl –w net.ipv4.ip_forward=0 route add 10.10.1.101/32 gw 190.0.2.3 dev veth4 route add 190.0.2.2/32 gw 10.10.1.99 dev veth5
(The exact IP addresses and virtual ports will change depending on the setup).
Those commands need to be ran after every load for the setup to work.
Part 3 - Subnets with Hardware-In-The-LoopSimilarly to part 2, let's say we have a setup with a TCP client (RT-LAB or HYPERSIM) but this time talking to an external device, such as a Raspberry PI through eno2:
NOTE: For any HIL setup, do not forget to setup the ARP entry in the EXata CPS Configurator in RT-LAb / HYPERSIM.
The same logic as before applies, we need to disable the ip forward feature inside the ns_exata namespace using:
ip netns exec ns_exata sysctl –w net.ipv4.ip_forward=0 Then, we need to configure the gateway / routing rule for veth4, as before:
route add 10.10.1.101/32 gw 190.0.2.3 dev veth4
Lastly, we also need to configure the gateway / routing rule on the external device too. NOTE: This will vary from device to device. This example is for reference only, but the logic remains the same.
In human words, it is: 'If you have a packet for the address 190.0.2.2, send it to 10.10.1.99 and it will handle it'.
In command line words, it will be:
sudo route add -net 190.0.2.2 gw 10.10.1.99 dev eth1 netmask 255.255.255.255
Where eth1 is the NIC name of the interface connected to eno2 of the simulator. The netmask of 255.255.255.255 is equivalent to the /32 from part 2.
|
