Problem related to Grafana metrics UI

[hakegard]

Hello,

I try to run the Grafana metric UI following the guide in the documentation. When enabling reporting metrics in JSON format in the gnb configuration file by inserting the four lines from the guide, I get the error: "INI was not able to parse metrics.enable_json_metrics" when starting the gnb. Leaving the enable_json_metrics parameter empty passes, while setting it to true or false leads to the same error. Does anyone have an explanation or solution?

[brendan-mcauliffe]

Hey @hakegard,

Are you using the latest version of the code? This was added in a recent update.

[hakegard]

Hi brendan,

Thanks, you were correct. I thought I had the last version, but I did not. Now it works perfectly!

[hakegard]

There is however one problem. When Installing grafana, internet connectivity is lost. Using wireshark, it appears that when pinging an external IP-address, the ICMP packets don't reach the WAN interface. Completely removing docker solves the problem. Maybe it is something obvious I'm missing, but I'm not able to see it.

I'm setting up the tun interface and WAN connectivity as follows:
$sudo ip tuntap add name ogstun mode tun
$sudo ip addr add 10.45.0.1/16 dev ogstun
$sudo ip addr add 2001:db8:cafe::1/48 dev ogstun
$sudo ip link set ogstun up

$sudo sysctl -w net.ipv4.ip_forward=1
$sudo sysctl -w net.ipv6.conf.all.forwarding=1
$sudo iptables -t nat -A POSTROUTING -s 10.45.0.0/16 ! -o ogstun -j MASQUERADE
$sudo ip6tables -t nat -A POSTROUTING -s 2001:db8:cafe::/48 ! -o ogstun -j MASQUERADE

The routing tables without docker installed looks like this:

 $route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 enp67s0f0
10.45.0.0       0.0.0.0         255.255.0.0     U     0      0        0 ogstun
10.219.45.0     0.0.0.0         255.255.255.192 U     100    0        0 enp67s0f0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 enp67s0f0

With grafana/docker installed, it looks like this:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 enp67s0f0
10.45.0.0       0.0.0.0         255.255.0.0     U     0      0        0 ogstun
10.53.1.0       0.0.0.0         255.255.255.0   U     0      0        0 br-96a56d86f651
10.219.45.0     0.0.0.0         255.255.255.192 U     100    0        0 enp67s0f0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 enp67s0f0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.19.1.0      0.0.0.0         255.255.255.0   U     0      0        0 br-88a994db56f9

[asaezper]

hey!

In the docker-compose, there are two docker networks defined:

networks:
  ran:
    ipam:
      driver: default
      config:
        - subnet: 10.53.1.0/24
  metrics:
    ipam:
      driver: default
      config:
        - subnet: 172.19.1.0/24

After a docker compose up, docker will create those two networks. That's the reason why you see entries for them in your routing table. I don't see how they can overlap with your previously existing ones, but looks like that's what happening.

I'd say:

• Check first that everything works after docker is installed and before creating those networks.
• Change subnet ranges in docker-compose.yml to different ones, picking an empty range for you. They should be in private range.
• If you have issues, you don't need to remove docker, it should be enough to remove the network with docker network rm <name> Also, you could use docker system prune -a --volumes -f which removes containers, images and networks.

[pgawlowicz]

@hakegard any update on this issue?

[hakegard]

@pgawlowicz No updates. Docker (and grafana) can be installed and works without breaking internet connectivity until the computer is rebooted. After reboot, interconnectivity is broken as described above. So a workaround is to uninstall grafana and docker before rebooting and reinstalling after reboot. Not very convenient, but works if the machine is not rebooted too often...

[pgawlowicz]

How do you start grafana? It should be like this:

sudo docker compose up grafana

Also, do you use 10.53.1.0/24 or 172.19.1.0/24 addresses in your network?

[hakegard]

No, I don't. And as I tried to explain below, the problem occurs wtihout grafana, or any other containers, installed. So it is a problem related to docker and not grafana. Installing docker and rebooting routes the packets from the UE to the lo interface instead of to the ethernet interface.

[hakegard]

Hi @asaezper,

Thanks for the response. Unfortunately, the problem occurs also without any containers or images. The routing table is as expected:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 enp67s0f0
10.45.0.0       0.0.0.0         255.255.0.0     U     0      0        0 ogstun
10.219.45.0     0.0.0.0         255.255.255.192 U     100    0        0 enp67s0f0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 enp67s0f0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

I was wondering if it the problem was related to postrouting, as docker0 appers in iptables:

$ sudo iptables -t nat -v -L POSTROUTING -n --line-number
[sudo] password for sep5g: 
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0           
2        0     0 MASQUERADE  all  --  *      !ogstun  10.45.0.0/16         0.0.0.0/0  

However, when pinging external IP-addresses from the UE with docker installed, I see that the ICMP (ping request) packets are routed to the lo interface using wireshark, while they are correctly routed to the ethernet interface without docker installed. Is it possible that docker intervene with the routing, or that the srsran code detects that docker is installed and changes the routing?