LENA - Different subnets at S1-U interfaces

[bruno....@i2cat.net]

Hi everyone,

working with the LENA module for NS3 3.28, I'm trying to externalize the S1-U link among different networks. The initial setup, as per the LENA guide, looks like the diagram below:

   eNB               S1-U            EPC

10.0.0.1/8  <------------------->  10.0.0.101/24

      (veth0)                              (veth1)

Working with this scenario, the connectivity between EPC and eNB is working properly. On the next diagram, using an intermediate physical Router, the appropriate routing table and updating the "listening" interfaces to eth0.X, I'm changing the subnets on the EPC and eNB for the S1 (src/lte/helper/emu-epc-helper.cc):

        eNB                  S1-U                EPC

192.168.6.1/24 <------------------->  192.168.18.2/24

      (eth0.6)                                     (eth0.18)

Eth0.6 interface receives the GTP encapsulated traffic correctly, maintaining the remote host and UE IPs and the 192.168.6.1 and 192.168.18.2 for the S1 link. But somehow, once the traffic arrives to eth0.6 is not able to continue to the eNB node.

Regarding the first case, there are mainly two differences:

- Connectivity between eNB and EPC reaches external equipment, so GTP traffic is not processed completely in local anymore. In a traffic flow from EPC to eNB: it goes from the EPC to an external router and then it comes back to the same PC but to the eth0.6 interface (associated with the eNB using the enbDeviceName parameter).

- I'm using a /24 subnetmask instead of a /8 and /24 like in the initial example. Maybe I should use a 192.168.0.0/16 and set the starting IP to 0.0.6.1 and 0.0.18.2 respectively?

Thanks in advance,

B.

[Manuel Requena]

Hi Bruno,

What do you have between the eNB and the EPC?
I assume you have a router with 2 interfaces: one with IP 192.168.18.1
and another one with IP 192.168.6.2.

So, you have to setup two routes:
- One in the EPC saying: to reach network 192.168.6.0/24 use nexthop
192.168.18.1
- Another in the eNB saying: to reach network 192.168.18.0/24 use
nexthop 192.168.6.2

Please, check doxygen doc for the right command. It should be
something related to:
https://www.nsnam.org/doxygen/classns3_1_1_ipv4_static_routing.html#a8bf5eaa7ba49fe33c78c70d5560b6c39

Best regards,
Manuel

> --
> 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 post to this group, send email to ns-3-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/ns-3-users.
> For more options, visit https://groups.google.com/d/optout.

[bruno....@i2cat.net]

Hi Manuel,

thanks a lot for your answer. Yes, there's a Router with the interfaces that you comment.

I have been able to set the static routing configuration both on EPC and eNB modifying lena-simple-epc-emu.cc:

-----------------------------

(...)

//eNB Routing

for (uint32_t enbX = 0; enbX < enbNodes.GetN (); ++enbX)
    {
      Ptr<Node> enbNode = enbNodes.Get(enbX);
      Ptr<Ipv4StaticRouting> enbStaticRouting = ipv4RoutingHelper.GetStaticRouting (enbNode->GetObject<Ipv4> ());

      enbStaticRouting->AddNetworkRouteTo (Ipv4Address ("192.168.18.0"), Ipv4Mask ("255.255.255.0"), Ipv4Address ("192.168.6.2"),2);

    }

//EPC Routing

pgwStaticRouting->AddNetworkRouteTo (Ipv4Address ("192.168.6.0"), Ipv4Mask ("255.255.255.0"), Ipv4Address ("192.168.18.1"), 2);

(...)
-----------------------------

Besides that, I'm still not able to ping 192.168.6.2. Whe sniffing traffic on that interface I can see ICMP requests arriving but no ICMP Reply packets are sent. In case I launch a ping test to the UE station (network 192.168.8.0/24 behind the UE), the same happens: I'm able to see ICMP Packets tunneled in GTP, but there is no trace that the traffic is reaching the eNB once arriving to the eth0.6 adapter.

[bruno....@i2cat.net]

ARP packets reaching 192.168.6.1 (eth0.6) are noticing that there is a problem regarding duplicate use of IPs. We'll check that deeper since only one physical ethernet device and multiple sub interfaces on the same computer are being used (sub interfaces will use the same MAC as the parent ethernet). So this might be a possible source of the conflict.

I'll be updating later.

Thanks a lot again. Appreciate your time,

B.

[bruno....@i2cat.net]

Is there any way to capture the eNB traffic as a pcap file? ARP problem has been solved out but at some point, communication between the virtual interface (eth0.X) and the eNB node fails. I'm using PcapHelperForDevice like:

(...)

#include "ns3/trace-helper.h"

PcapHelperForDevice traceHelper;

traceHelper.EnablePcap ("out", enbLteDevs, true);

But a compilation error comes up. Am I missing something?

Thanks,

B.

[bruno....@i2cat.net]

So, just to clarify, I'm already getting traces for PHY, MAC, RLC  on the LTE Stack protocol, but I'd be interested on the S1-U traces when using the emulated link (instead of the P2P one). Please find attached below an image from: https://www.nsnam.org/tutorials/consortium13/lte-tutorial.pdf:

GTP traffic arrives correctly to the nearest adapter used by the eNB (assuming a traffic flow from right to left) but does not continue to the LTE Radio Protocol Stack. So may be PCAp traces for the eNB node are not the most relevant output here.

B.

[Manuel Requena]

Could you send the pcap traces of the physical eth0.6 device?

Do you get anything in the PDCP traces (DlPdcpTraces.txt and UlPdcpTraces.txt files)?

Manuel

[bruno....@i2cat.net]

Absolutely. Attached file "out.pcap" collect the traces of the physical interface.You will see the encapsulated addressss that we saw before (192.168.18.1 and 192.168.6.2 corresponding to the S1-U link) and 192.168.0.253 & 192.168.8.101 as the source and destination - respectively - end devices (which would be replacing the 11.0.0.0 and 13.0.0.0 networks in the original example.

Regarding PDCP traces, DlPdcpTraces.txt and UlPdcpTraces.txt files are created but only with the headers.

Thanks,

B

[Manuel Requena]

The UE must be the destination for DL traffic.

If not, you will need some kind of NAT in the UE side. And this scenario currently is not supported.

Best regards,

Manuel

[bruno....@i2cat.net]

Yes, the UE Address is currently the DL traffic.

Enabling the flow monitor in lena-simple-epc-emu.cc I get:

Flow ID                  :  1 ; 192.168.18.1 -----> 192.168.6.2

Tx Packets = 184

Rx Packets = 0

Last Received Packet : 0 Seconds

Seems like ns3 is not correctly listening on the eth0.6 interface, assuming that Rx Packets field corresponds to the lowest layer at the eNB. I'll take a deeper look at any issue regarding the interface or packet rejection.

Thanks,

B.

[bruno....@i2cat.net]

It has been finally solved adding a Linux bridge between the physical interface and the NS3 adapter. As both sides of the scheme (eNB and SGW) were installed on the same computer using sub interfaces, the traffic got stuck on the eth0.X interface corresponding to eNB although any MAC/ARP problem was solved. Connecting the eth0.X interface and a veth pair through a bridge (brctl) just solved the problem.

Thanks a lot for your help and time Manuel.

Regards,

B.