# default route - source and destination address are wildcard
ltm message-routing generic route default_route {
    peer-selection-mode sequential
    peers { default_peer, backup_peer }
}
  
ltm message-routing generic route forwarding_route {
    destination-address help
    peers { forwarding_peer }
}
  
ltm message-routing generic route bad_route {
    source-address annoying_user
    peer-selection-mode ratio
    peers { default_peer, blackhole_peer }
}

A standard LTM pool is used to list a set of devices that messages may be routed towards.

ltm pool my_default_pool members { 10.1.2.1:1234, 10.1.2.2:1234, 10.1.2.3:1234 }
ltm pool my_backup_pool members { 10.1.2.4:1234, 10.1.2.5:1234, 10.1.2.6:1234 }
ltm pool my_empty_pool members { }

If a transport-config is not defined, the outgoing connection will use the settings of the incoming connection for creating the outgoing connection.

ltm message-routing generic peer backup_peer {
   pool my_backup_pool
}

If a pool is not defined, the outgoing connection will use the destination (local address) of the incoming connection as the destination (remote address) of the outgoing connection. This is how to configure message forwarding.

ltm message-routing generic peer forwarding_peer {
   transport-config my_nosnat_tc
}

If a pool with no pool members is used, the message routed to that peer will fail routing. This can be used as a method to create a black hole route.

ltm message-routing generic peer blackhole_peer {
   ratio 3
   pool my_empty_pool
}

Each connection is assigned a peer name. This peer name must be set via the GENERICMESSAGE::peer name iRule command. Once the peer name has been sent, the connection is able to receive and forward messages.

The peer name is used to add a dynamic route to the route table. It is also used to set the source address of each message.

A BIG-IP^® system will make just one connection to a peer. This means that only one TMM is connected to each Peer. While this connection mode uses fewer connections it will introduce latency. This will happen when messages are disaggregated to the wrong TMM and must be forwarder. The following diagram provides additional detail.

Optimum scenario

1. Message arrives on a Virtual Server (VS)
2. Message is disaggregated to TMM-0
3. TMM-0 is connected to the correct server so the message is sent

Performance impacted scenario

1. Message arrives on a Virtual Server (VS)
2. Message is disaggregated to TMM-1
3. TMM-1 is not connected to Server 1 so message must be forwarded to the correct TMM. This will introduce latency.
4. TMM-0 is send message to Server 1

A BIG-IP^® system will make a connection from every TMM to the same peer. This means a machine with 8 cores will have 8 connections per peer. While this increases the number of active connections, it also improves performance because there is no need to forward messages between TMMs.

Every TMM is connected to every peer which decreases latency but increases the number of connections

1. Message arrives on a Virtual Server (VS)
2. Message is disaggregated to TMM-0
3. TMM-0 is connected to the correct server so the message is sent
4. Second message arrives
5. Message is disaggregated to TMM-1
6. TMM-1 is connected to the requested server so the message can be sent directly

A BIG-IP^® system creates one connection per blade to each peer. This provides a balanced performance approach between the per peer connection mode (only one connection) and a per tmm connection mode (a connection from each TMM). This mode only makes sense for a hardware chassis with multiple blades.

Each blade will make a single connection to each peer.

1. Message arrives on Blade 0
2. Blade 0 opens a connection to Server 1 and forwards the message
3. Second message arrives
4. Blade 1 opens a connection to server 1 and forwards the message

A BIG-IP^® system will create a new outgoing connection for each client. Note, clients do not share connections.

Connections will be created for each client.

1. Client 1 message arrives on a Virtual Server (VS)
2. Message is disaggregated to TMM-0
3. TMM-0 connects to Server 1 and sends the message
4. Second message arrives
5. Client 2 message is disaggregated to TMM-1
6. TMM-1 connects to Server 1 and send the message
7. Third message arrives
8. Client 3 message is disaggregated to TMM-0
9. TMM-0 creates a new connection for Server 1 for Client 3

Request messages are messages that expect a response to be returned from the destination. A request message contains payload data and a source and destination address. The source address will be auto populated by Generic Message with the peer name of the originating connection. The destination address will need to be populated by the script. The source and destination address will be used by the route table to find the best matching route to use for delivering the message.

Setting the destination address of a message will identify the message as a request message. The destination address is often generated by data contained in the message.

Response messages are messages returned by the destination to be delivered to the originator of the request. A message without a destination address is assumed to be a response message.

Generic message will assign a request-sequence-number to all request messages before raising GENERICMESSAGE_EGRESS event. The details of the originating flow (TMM and flow_id) of the request will be stored in a pending request table on the outgoing connection.

Each response message is initially assigned the oldest request-sequence-number in the pending request queue before raising GENERICMESSAGE_INGRESS event. Upon completion of the event the message will be forward to stored connection from the pending request table using the request-sequence-number.

If the pending request table is empty, the response message will be routed via the route table.

The default response routing implementation assumes that responses will arrive in the order that the requests were forwarded. If response message can arrive out of order, the script author will need to set the appropriate request-sequence-number during GENERICMESSAGE_INGRESS event.

Notification messages are messages that do not expect a response. Setting the no-response attribute of the message will instruct generic message that no response is expected for the message. If all messages will be notification message, the no-response attribute in the protocol profile should be set to 'yes'.

The source address is a string used to identify the originating connection of the message. This is auto-populated with the peer name of the connection.

The destination address is a string used to identify the destination for the message. This will be used by the route table along with the source address to determine the best route to forward the message towards.

The last hop contains an internal address for the originating connection for the message. For response routing, setting the next hop of the response message to the last hop of the request will instruct the router to bypass routing and forward the message directly to the specified connection.

The next hop specifies an internal address for a connection that should be used for forwarding the message.

Setting the route attribute of a message on ingress will bypass route table lookup and direct the router to forward the message directly to the route specified in the message.

After routing has completed, the route attribute of the message will be populated with the details of the route used.

Setting the attempted hosts attribute of a message on ingress will instruct the router to skip the provided hosts when performing a load balance pick.

After routing has completed, the attempted hosts attribute of the message will contain the list of transports (virtual or transport-config) and hosts (tuple) that the message has been routed towards.

The originator attribute will contain the transport (virtual or transport-config) and host (tuple) of the originating connection of the message.

After routing has completed, the route status attribute will contain the status (success or failure) of the routing operation.