The Next Hop function is used for switching to an alternative route if there is a failure of any of the CUs on the transfer route. The node in Next Hop mode works with the main set of routing tables. It also a set of back-up tables available for use if the connection to the nearest adjacent node according to the main set is lost.
An example of a back-up connection between nodes 01 and 04:
02 . . . . . . ---- 01 04 ---- Tl1: 04>02 . . Tl1: 01>02 main table Tl2: 04>03 . . Tl2: 01>03 back-up table . . 03
Settings in menu Ne:
Nid|address |M | u s | L N |l w n g H|sTO Err Cent vTO hTO (0) 0049C067 - S00| - R00|0 0 0 0 -| 15 SERV OFF 304 30 (1) 690F0001 S00 S00| - R01|1 0 0 0 -| 15 SERV OFF 304 30 (2) 00000000 S01 S00| - R02|0 0 0 0 -| 15 SERV OFF 304 30 ....
Definition of back-up tables in menu DNe:
Node Extensions: retab Nid |l w n g| Mode (0) |0 0 0 0| 0 (1) |2 0 0 0| 1 ...back-up set of tables for node 1 (2) |0 0 0 0| 0 .... >>1 Node Extensions: (l)o:2 (w)i:0 (n)e:0 (g)l:0 (H)rt:0 (K)eep lines:ON ...activation of transmission of keep packets
Switching on Next Hop mode in menu DGe:
Dynamic routing: Globals m(o)de:NEXT HOP ...Next Hop mode validity (t)imeout:120sec ...interval of transmission of keep packets (N)id:1 ...applies to node number 1 Parameters: ....
The node in Next Hop mode sends keep packets to the nearest nodes based on the main and back-up routing tables.
12:39:26.032|690F0002 690F0001|690F0002 690F0001|7AB RFTX 0 90 0dat 0 12:39:26.073|690F0001 690F0002| |7AB*31~ 70 0*06 ack 12:39:33.038|690F0003 690F0001|690F0003 690F0001|7AC RFTX 0 90 0dat 0 12:39:33.078|690F0001 690F0003| |7AC*31~ 70 0*06 ack
Based on ACK the dynamic table is updated. This is available for diagnostics purposes through command mrt:
>>mrt >>Tt: 2 120 Tt:nid:1 toa:690F0002 ttl:12.000000 m:2.000000 Tt:nid:1 toa:690F0003 ttl:29.000000 m:2.000000
Items in the table:
Tt:nid:1 number of node in Next Hop mode toa:690F0002 address of tested adjacent node ttl:12.000000 remaining validity time(12sec) m:2.000000 line status: 2 line OK 1 one packet wasn't ACK acknowledged on the routing channel 0 two or more packets didn't receive ACK, switch to back-up set of tables -1 unknown line status
The table can be generated automatically every second and sent to the monitoring system channel number 1 (menu ise1). Generation is switched on using command DGeuSn. Be careful not to overload the RFC during transmission of monitoring via the radio.
The line status is evaluated according to ACK on the routing channel. If this channel is Ethernet with ACK switched off and thus no ACK arrives use mode NEXT HOP+KEEPS. In menu DGe select:
Dynamic routing: Globals m(o)de:NEXT HOP+KEEPS ...mode Next Hop+Keeps validity (t)imeout:120sec (N)id:1
Now the keep packets looks as follows:
13:28:38.034|690F0002 690F0001|690F0002 690F0001|0EE RFTX 2 94 5dat 0 0001 13:28:38.074|690F0001 690F0002| |0EE*30~ 71 0*06 ack 13:28:38.113|690F0001 690F0002|690F0001 690F0002|1A7*29* 71 2*94 5dat 0 8001 13:28:38.113|690F0002 690F0001| |1A7 RFTX 0 06 ack
A response (with data 8001) is sent to each keep packet (with data 0001) from the opposite node. Based on this response the line status is determined, even in the case where no ACK arrives.
Nodes in Next Hop mode can be chained further. In the following example data is transferred between nodes 01 and 06. If any of the nodes 02,03,04,05 fail they are automatically replaced by the back-up line.
Tl1: 06>04 Tl1: 01>02 main table Tl2: 06>05 Tl2: 01>03 back-up table 02 . . . . . . 04 Tl1: 04>02 . . . . Tl1: 01>04 05>02 . . . . 02>04 06>02 . . . . 03>04 ------ 01 . 06 ------ Tl2: 04>03 . . . . Tl1: 01>05 05>03 . . . . 02>05 06>03 . . . . 03>05 03 . . . . . . 05 Tl1: 06>04 Tl1: 01>02 main table Tl2: 06>05 Tl2: 01>03 back-up table
Rules for network creation in the example:
02 . . . . ---- 01 04 ---- . . . . 03
node 01 chooses between the main (02) and back-up (03) route.
test of connection and selection only concerns the next step (next hop).
selection of main/back-up route takes place according to ACK response to prior keep or data packet.
the route in the other direction must be assessed and switched by another node, which has the chance to select between two routes. Here it is node 04, and nodes 04,05,06 in the previous more complicated example.
a fault on the route must be detected from both sides so that both directions are switched to the back-up route. Here, upon switching off CU 02 a failure is registered by nodes 01 and 04 and both switch to the back-up direction via 03.
it is not a good idea to combine different media, for example, during a connection between CU 01 and CU 02 over a wire link a fault on CU 02 will be correctly identified only when switching off the whole of station 02. If only one of the channels is interrupted (SCC or RFC), then the fault from the other side will not be ascertained and the back-up line will only be switched in one direction. In the other direction the connection will remain interrupted.
similarly it is not a good idea to line several CUs behind each other without branching:
02 . . 04 . . . . ---- 01 06 ---- . . . . 03 . . 05
If there is a failure of any of the stations 02,03,04,05 the route is switched by only one of the end stations 01 or 06 and two-way transmission is lost.
on switching to a back-up set of routing tables the whole set g,n,w,l is switched. It is necessary to fill in all tables, even in the back-up set, if they are used in routing.
switching to a back-up route occurs after assessing the loss of two packets. These are not delivered to the end station.