Routing issue in 5G-Lena emulated network

[Bruno]

Hi all,

I am trying to set up an emulated 5G NR network using the 5G-Lena module that is connected to my local system with a tab-bridge. It has a relatively simple topology, illustrated in the figure below.

It consists of:
* one enbNode (basestation),
* two ueNodes (mobile devices),
* one remoteHost (connected to the enbNode with point2point),
* and one ghostNode (used to install the tap-bridge, connected to ueNode0 with csma)

The problem is the following:
* I can send pings/traces from WITHIN NS3 from ueNode0 to remoteHost, ueNode0 to ueNode1
* I can send pings from my host machine via the tap bridge to ueNode0, which is the other end of the csma link.
* I cannot ping ueNode1 or remoteHost from my host machine. I believe this to be a static routing issue that I did not manage to resolve so far.

Attached is a list of all nodes with their respective network devices and routes (nodes.txt). Nodes 4, 5, and 6 are not created explicitly by me, but by NrHelper.

I have also attached the code. Be aware that this requires the 5G-Lena module, to which access needs to be requested (but there are mirrors of the repo, not sure if legal).

To run the code: install 5G-Lena in the contrib folder, put new.cc in your scratch folder,  build with enable-sudo and run with the following:
NS_LOG="5gEmu=level_all|prefix_level" ./ns3 run new --enable-sudo

I am thankful for any tips on how to configure static routing or other ways to fix this.

Kind regards,

Bruno

[Tommaso Pecorella]

I haven't checked everything, but this did catch my eyes:

RemoteHost                                    
        Interfaces:                            
                0: 127.0.0.1 (Loopback)
                1: 1.0.0.2
        Routes:                                
                127.0.0.0 (255.0.0.0) --> 0.0.0.0 (interface 0)
                1.0.0.0 (255.0.0.0) --> 0.0.0.0 (interface 1)
                7.0.0.0 (255.0.0.0) --> 0.0.0.0 (interface 1)
                10.1.1.1 (255.255.255.255) --> 1.0.0.1 (interface 1)

I.e., the remotehost is (probably) thinking that the whole 1.0.0.0/8 is attached to its local network. It goes to 10.1.1.1 just because there is a special rule too.

My suggestion is to double check the network prefixes in the routing tables.

[Bruno]

Hey Tomm, thanks for your reply.

The 1.0.0.0/8 is the point2point between pgw and remoteHost. pgw is a node created by NrHelper.
10.1.1.0/24 is the csma between ghostNode and ueNode0.

I am not sure what you mean, one starts with 1 and the other with 10. The whole 1.0.0.0/8 is attached to remoteHost, since there are only two interfaces in that range.

[Tommaso Pecorella]

My bad... 1 != 10 except (maybe) in javascript. In my defence I was tired (and left unsupervised).

I'll have to double check it. In the meantime you could enable the traces, or the PCAPs, and check where the packets are lost. That should give a good clue on where the missing rule is.

Mind that you could find 2 different behaviours:

1. A node thinks that the network is attached to a local network (and it isn't). You'll see ARP requests for a prefix that is "wrong"
2. A node lacks totally the way to forward the packet. Here you see the packet vanishing in thin air.

[Tim Upthegrove]

Hi Bruno,

Which IP address is being used on the host? Are the routes for the ICMP replies in the direction from UE1 back to the host all set up in the ns-3 nodes? If you enable PCAPs by calling EnablePcapIpv4 [1] on the internet stack helper and passing in a pointer to the Ipv4 stack for the node and the index of the interface, how far can you see traffic get when you try to ping? You should be able to pinpoint how far in the forward and reverse path traffic is getting before getting dropped, which might make it easier to narrow in on the issue.

Thanks,

Tim

[1] https://www.nsnam.org/doxygen/classns3_1_1_pcap_helper_for_ipv4.html#a90f0bbea2e43dd6b3106232809c6de41

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/a4860d61-bf4e-4177-a65a-b86d8afd78a4n%40googlegroups.com.

--

 

Tim Upthegrove

[Bruno]

Hello,

Thank you Tim for the details on how to collect traces. I previously did not succeed in enabling them for all interfaces because I was trying to enable them on the nrHelper directly, like one can do on the csmaHelper.
This did the trick: internetStackHelper.EnablePcapIpv4 ("prefix", NodeContainer::GetGlobal ());

Looking at the traces, I found that the packets are not send correctly when they reach the PGW node. The illustration below illustrates it.

I will now try to modify and forward the IPv4 packets when they reach ueNode0: replace origin and destination, then forward the packet. Kind of like NAT I guess.

Thanks Tomm and Tim for the time you have taken to help!

Kind regards,

Bruno

​

[kaouthar ouali]

Hi Bruno,

Did you manage to ping the remotehost from the ghostnode ?

Regards,