subscribe to our Youtube


14455 questions

17168 answers


0 members

We are migrating to our new platform at Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
698 views 1 comments
by anonymous
Platform RUTXR1 fw version RUTX_R_00.07.03.

We have a hub and spoke topology network with the RUTXR1 acting as spokes. They are interconnected with the hub through a GRE-tunnel. From the hub we advertise a default route through the GRE-tunnel towards the spokes. The default route is received on the spokes but not installed in the routing table. We see that the BGP process installs BGP advertised routes with a metric of 20 as we advertise by means of test also the network that is installed in the routing table.
The RUTXR1 is connected to a mobile datanetwork through the MOB1S1A1-interface (wwan0). Once it is connected the RUTXR1 automatically installs a default route with metric 4 that I manually raised to 254. Although this route is now configured with a metric of 254 and the BGP-received default route should be installed with an expected metric of 20 we see that the latter default route is not installed in the routing table and the router still takes the automatically installed default one.
Any idea how this can be corrected? In my opinion the RTUXR1 firmware has no sense of administrative distance, so metric is the only parameter to play with.

 route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         U     254    0        0 wwan0       UG    20     0        0 gre4-Tunnel0 U     2      0        0 wwan0 UH    2      0        0 wwan0 U     1      0        0 eth0.15 U     1      0        0 eth0.5 U     1      0        0 eth0.3 U     1      0        0 eth0.4 UH    254    0        0 wwan0 U     1      0        0 eth0.6   U     0      0        0 gre4-Tunnel0


 sh ip route

Codes: K - kernel route, C - connected, S - static, R - RIP,

       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,

       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,

       F - PBR,

       > - selected route, * - FIB route

B [200/0] via, gre4-Tunnel0, 00:15:38

K>* [0/254] is directly connected, wwan0, 00:15:38

B>* [200/0] via, gre4-Tunnel0, 00:15:38

K>* [0/2] is directly connected, wwan0, 00:15:38

K>* [0/2] is directly connected, wwan0, 00:15:38

K * [0/1] is directly connected, eth0.15, 02:00:50

C>* is directly connected, eth0.15, 02:00:50

K * [0/1] is directly connected, eth0.5, 02:00:50

C>* is directly connected, eth0.5, 02:00:50

K * [0/1] is directly connected, eth0.3, 02:00:50

C>* is directly connected, eth0.3, 02:00:50

K * [0/1] is directly connected, eth0.4, 02:00:50

C>* is directly connected, eth0.4, 02:00:50

K * [0/254] is directly connected, wwan0, 00:15:38
by anonymous
In my opinion this is a buggy implementation of routing.

Anyone from Teltonika that can advise?

1 Answer

+1 vote
by anonymous


The issue is rather unique and it's hardly solvable in an easy manner. It is certainly possible to resolve this, but for now a workaround will have to be used. I have raised an issue for our RND to look into this issue and possibly implement a fix in the future firmware version so that it wouldn't be required to resort to using custom scripts.

To explain this issue in better detail, there are several unfavorable factors at play here which cause this specific problem to appear:

  1. BGP type that's being used is IBGP - this means administrative distance of 200 is the default AD
  2. By default, Linux kernel doesn't "know" about AD and it doesn't interpret it in any way. Only the dynamic routing package FRR has the ability to interpret it ]on Teltonika Networks devices], properly understand its meaning and provide routing services according to networking standards
  3. In order for FRR to implement a static route with AD of 200 (or higher), network configuration must be aware of metric values, which exceed value of 2147483648 (for additional reference, please read the following article to understand how FRR and Linux kernel interact with each other:
  4. The network configuration file (at /etc/config/network) currently cannot process any value higher than 2147483647. If we use any value higher than specified here (example: 2147483647+5), the metric will be defaulted down to 2147483647 for that specific interface
  5. A custom hotplug script would have to be implemented as one of the few options to workaround this issue right now

Regarding the hotplug script - I've crafted a very basic draft, please test it in a test environment. It is supposed to get the primary default gateway of your router, delete the default route and add it again with a higher metric. In my example, the higher metric will set the AD of static route to 254 and metric to 254 as well. 

The "iproute" delete action is necessary, because metric cannot be changed with "ip route change" command. The proposed hotplug script is as follows:

Note - you may copy and paste all of this directly into CLI. The script will be created and made executable automatically and the 'wan' interface will be brought down and then, after 3 seconds, back up to ensure 

cat << 'EOF' >> /etc/hotplug.d/iface/96-default-route-custom-metric


[ "$ACTION" = ifup ] || exit 0

/etc/init.d/frr enabled || exit 0

if [ "$ACTION" == "ifup" ]; then

  # Get the primary default gateway

  GATEWAY="$(ip route | grep default | awk '{print $3}')"

  # Set the desired metric value

  #This value will translate to 254 AD/254 metric to FRR


  # Change the metric of the default gateway

  ip route del default via "$GATEWAY" 

  ip route add default via "$GATEWAY" metric "$METRIC"

  logger -t iface-hotplug "$GATEWAY" has been 



chmod +x /etc/hotplug.d/iface/96-default-route-custom-metric && ifdown wan && sleep 3 && ifup wan

If you would like to remove or edit this script for any reason, it will be located at: