Basic Babel and OSPF combination

https//www.racom.eu/eng/products/m/ripex/app/bab/ex5.html

Print version

6. Basic Babel and OSPF combination

Example 6 – Babel and OSPF diagram

Fig. 6.1: Example 6 – Babel and OSPF diagram


6.1. Description

The sixth 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 (0.0.0.0/0). 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 first example. See the required changes below. It is required to change RipEX_A and RipEX_D settings only.

6.2. RipEX_A Configuration

Add a 2nd IP/Mask to the “bridge” Ethernet interface. A new 192.168.100.1/24 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. 6.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. 6.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. 6.4: RipEX_A – OSPF activation


Create a new OSPF Area ID 0.0.0.0 (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. 6.5: RipEX_A – New OSPF backbone Area


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

Interface

if_bridge

Network IP/Mask

192.168.100.0/24

Network type

Broadcast

  • 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

2

  • 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. 6.6: RipEX_A – New OSPF interface


Go to the Static rules tab and add two rules.

  • 192.168.1.0/24

    • Metric type 2

    • Metric 1000

  • 0.0.0.0/0

    • 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. 6.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 192.168.1.1 so that packets generated in this RipEX2 unit use 192.168.1.1 as their Source IP.

RipEX_A – OSPF Import filter

Fig. 6.8: RipEX_A – OSPF Import filter


There is no change required in RipEX_B and RipEX_C units.

6.3. RipEX_D Configuration

Add a 2nd IP/Mask to the “bridge” Ethernet interface. A new 192.168.100.2/24 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. 6.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. 6.10: RipEX_D – Radio communication disabled


Disable Babel protocol.

RipEX_D – Babel protocol disabled

Fig. 6.11: RipEX_D – Babel protocol disabled


Enable OSPF with the same Router ID 4.4.4.4.

RipEX_D – OSPF protocol enabled

Fig. 6.12: RipEX_D – OSPF protocol enabled


Add one OSPF interface within a new backbone Area ID 0.0.0.0.

Interface

if_bridge

Network IP/Mask

192.168.100.0/24

Network type

Broadcast

Hello interval

2

RipEX_D – New OSPF Area and Interface

Fig. 6.13: RipEX_D – New OSPF Area and Interface


Details:

RipEX_D – OSPF interface details

Fig. 6.14: RipEX_D – OSPF interface details


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

RipEX_D – OSPF Static rules

Fig. 6.15: RipEX_D – OSPF Static rules


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

RipEX_D – OSPF Import filter

Fig. 6.16: RipEX_D – OSPF Import filter


6.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. 6.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. 6.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. 6.19: RipEX_A – OSPF output


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

RipEX_B – Babel routing

Fig. 6.20: RipEX_B – Babel routing


RipEX_B should have routes to its Radio neighbors (192.168.1.0/24 and 192.168.3.0/24) 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. 6.21: RipEX_D – System routing


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

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

RipEX_D – OSPF routing

Fig. 6.22: RipEX_D – OSPF routing


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