Basic Babel and OSPF combination


Print version

5. Basic Babel and OSPF combination

Example 5 – Babel and OSPF diagram

Fig. 5.1: Example 5 – Babel and OSPF diagram

5.1. Description

This example shows a network combining Babel and OSPF. OSPF is configured in RipEX_A and RipEX_D units, whereas Babel is configured in RipEX_A, B and C. These two protocols are neighboring in one Autonomous System Border Router “ASBR” (RipEX_A) which divides the whole network into two parts. Bandwidth optimized Babel on the Radio segment and standardized, widely-used and fast OSPF on the Ethernet segment.

These two parts are interconnected together utilizing default gateways. E.g., Radio network is completely routed by Babel and all other routes are routed to ETH4 interface of RipEX_A via a default gateway rule ( In other words, there is no other export of routing rules.

Without dynamic protocols, all routes would need to be filled manually and statically.

Startup configurations are taken from Example 1. See the required changes below. It is required to change RipEX_A and RipEX_D settings only.

5.2. RipEX_A Configuration

Add a 2nd IP/Mask to the “bridge” Ethernet interface. A new IP address will be used for Ethernet connection to RipEX_D and OSPF. You could also detach a particular ETH port and assign this IP to this designated port.

RipEX_A – Ethernet bridge

Fig. 5.2: RipEX_A – Ethernet bridge

Add a new “default route” to current Babel Static rules. This default route will be used between OSPF and Babel network segments.

RipEX_A – Babel Static rules (def. gateway)

Fig. 5.3: RipEX_A – Babel Static rules (def. gateway)

Go to the OSPF Routing menu and enable OSPF dynamic protocol. The Router ID is shared among all dynamic protocols.

RipEX_A – OSPF activation

Fig. 5.4: RipEX_A – OSPF activation

Create a new OSPF Area ID (so called “backbone area” which has to be used in OSPF and all other areas must be directly connected to it).

RipEX_A – New OSPF backbone Area

Fig. 5.5: RipEX_A – New OSPF backbone Area

Add a new interface under this backbone Area. Change the following parameters:



Network IP/Mask

Network type


  • Multiple OSPF routers on a link on which all participants can hear each other. The link allows both broadcast and multicast for OSPF mechanism. All participants vote for one Designated Router (DR) and one Backup Designated Router (BDR) which are responsible for resending routing updates among other routers (to limit protocol overhead data).

Hello interval


  • Ethernet is a fast link so the interval can be low (i.e., fast OSPF processes).

Other parameters stay in default values.

RipEX_A – New OSPF interface

Fig. 5.6: RipEX_A – New OSPF interface

Go to the Static rules tab and add two rules.


    • Metric type 2

    • Metric 1000


    • Metric type 2

    • Metric 1000

It is not important if the metric type is “1” or “2” in this example, but it is used to distinguish rules which came to OSPF from Babel (and cannot be exported back to Babel).

RipEX_A – OSPF static rules

Fig. 5.7: RipEX_A – OSPF static rules

Go to the last required tab and add an Import filter with the following settings. Only the “Local preferred source address” is to be filled – with local ETH IP so that packets generated in this RipEX2 unit use as their Source IP.

RipEX_A – OSPF Import filter

Fig. 5.8: RipEX_A – OSPF Import filter

There is no change required in RipEX_B and RipEX_C units.

5.3. RipEX_D Configuration

Add a 2nd IP/Mask to the “bridge” Ethernet interface. A new IP address will be used for Ethernet connection to RipEX_A and OSPF. You could also detach a particular ETH port and assign this IP to this designated port.

RipEX_D – Ethernet configuration

Fig. 5.9: RipEX_D – Ethernet configuration

Disable the Radio protocol so there is no Radio/RF communication, only Ethernet connection to RipEX_A.

RipEX_D – Radio communication disabled

Fig. 5.10: RipEX_D – Radio communication disabled

Disable Babel protocol.

RipEX_D – Babel protocol disabled

Fig. 5.11: RipEX_D – Babel protocol disabled

Enable OSPF with the same Router ID

RipEX_D – OSPF protocol enabled

Fig. 5.12: RipEX_D – OSPF protocol enabled

Add one OSPF interface within a new backbone Area ID



Network IP/Mask

Network type


Hello interval


RipEX_D – New OSPF Area and Interface

Fig. 5.13: RipEX_D – New OSPF Area and Interface


RipEX_D – OSPF interface details

Fig. 5.14: RipEX_D – OSPF interface details

Add one Static rule so that local is propagated through OSPF protocol. Set the same Metric type (2) and Metric (1000) as in RipEX_A.

RipEX_D – OSPF Static rules

Fig. 5.15: RipEX_D – OSPF Static rules

Finally, add one Import filter with Local preferred source address equal to

RipEX_D – OSPF Import filter

Fig. 5.16: RipEX_D – OSPF Import filter

5.4. Diagnostics and Testing

You can attach your laptops to RipEX2 units and do some PING tests. You can also configure some SCADA protocol traffic simulation.

The “issue” with testing this scenario on the desk is that each radio can hear each other (except RipEX_D). Thus, it is not possible to force Babel and Radio channel to send traffic via a repeater by default and only if this fails, sending data directly. The traffic always uses a direct connection. Only if you had some attenuators or you use it in the field, there should be situations in which traffic goes via two radio hops.

Also, the OSPF and Babel are neighboring in one ASBR router (RipEX_A) – so if you turn off RipEX_A, then RipEX_D loses its connection to the radio segment (and vice versa). There is no other way.

So, check the correct routing is set and used in all routers and also check the ping works among all units. Typical outputs you should see are:

RipEX_A – System routing

Fig. 5.17: RipEX_A – System routing

RipEX_A should have /24 routes to all LANs behind every other RipEX2 in this example.

RipEX_A – Babel routing

Fig. 5.18: RipEX_A – Babel routing

In the Babel output, you should see two neighbors and a direct metric to each with a cost of 100.

RipEX_A – OSPF output

Fig. 5.19: RipEX_A – OSPF output

There should be one neighbor with state either Full/DR or Full/BDR.

RipEX_B – Babel routing

Fig. 5.20: RipEX_B – Babel routing

RipEX_B should have routes to its Radio neighbors ( and with Metric equal to 100 and one default gateway rule back to RipEX_A (also with a Metric equal to 100). The same is for RipEX_C.

RipEX_D – System routing

Fig. 5.21: RipEX_D – System routing

RipEX_D should have a /24 link to subnet via its if_bridge interface and gateway (RipEX_A) and a default gateway (also for the whole radio segment.

All the routes are obtained via OSPF. There is no Babel configured.

RipEX_D – OSPF routing

Fig. 5.22: RipEX_D – OSPF routing

©  2024 RACOM s.r.o. All Rights Reserved.