Testing

Print version

7. Testing

The simplest way is to verify the connectivity via ICMP ping, e.g. a ping from RipEX4-Remote to the server connected to the RipEX radio in the centre – 192.168.131.16.

Go to the Diagnostic/Ping menu in the RipEX4-Remote unit. Choose the ICMP type and fill in the Destination IP (192.168.131.16). Other parameters might stay in default values.

Ping from RipEX4-Remote to the server connected to the radio in the centre

Fig. 7.1: Ping from RipEX4-Remote to the server connected to the radio in the centre

The ICMP ping proved the remote server accessibility. But how can we make sure the packets are encapsulated to GRE? Login to the RipEX1-Base unit and choose the Diagnostic/Monitoring menu. Set the parameters as depicted on Fig. 7.2 below and click on the “Start” button. Afterwards, execute the ping requests from RipEX4-Remote unit.

Monitoring parameters and monitoring output

Fig. 7.2: Monitoring parameters and monitoring output

The packet length might be set to be 0 Bytes, because the payload is not important now. To display only GREv0 packets, define the advanced parameter as ‘ip proto 47’ (GRE protocol port).

NOTE:
The GRE interface might be monitored directly using the ‘-i gretun0’ advanced parameter.

The ICMP packets are displayed in the output as GREv0 packets. There is no encryption and thus the packets are readable.

You can try to test accessibility of other units. The principle is the same.

Accessibility issues might be caused by:

  • Missing routing rules (or default gateway, …) on one of the computers

  • Enabled firewall blocking the incoming ICMP requests

  • Misconfigured routing rules or GRE tunnels in RipEX units

  • Etc…