> Configuring Routes and Zones
> You can create routes using the administration tool (see Chapter 6), or the administration APIs (see com.tibco.tibjms.admin.RouteInfo in the online documentation).
> Syntax
> To create a route using the administration tool, first connect to one of the servers, then use the create route command with the following syntax:
> create route name url=URL zone_name=zone_name zone_type=1hop|mhop properties

> ● | name is the name of the server at the other end of the route; it also becomes the name of the route.

> ● | URL specifies the other server by its URL—including protocol and port.

> If your environment is configured for fault tolerance, the URL can be a comma-separated list of URLs denoting fault-tolerant servers. For more information about fault tolerance, see Chapter 19, Fault Tolerance.

> ● | zone_name specifies that the route belongs to the routing zone with this name. When absent, the default value is default_mhop_zone (this default yields backward compatibility with configurations from releases earlier than 4.0).

> ● | The zone type is either 1hop or mhop. When omitted, the default value is mhop.

> ● | properties is a space-separated list of properties for the route. Each property has the syntax:

> prop_name=value
> For gating properties that control the flow of topics along the route, see Selectors for Routing Topic Messages.
> For properties that configure the Secure Sockets Layer (SSL) protocol for the route, see Routing and SSL.
> Example
> For example, these commands on server A would create routes to servers B and C. The route to B belongs to the one-hop zone Z1. The route to C belongs to the multi-hop zone ZM.
> create route B url=tcp://B:7454 zone_name=Z1 zone_type=1hop
> create route C url=tcp://C:7455 zone_name=ZM zone_type=mhop
> Show Routes
> You can display these routes using the show routes command in the administration tool:
> show routes
> Route T ConnID URL Zone T
> B A 3 tcp://B:7454 Z1 1
> C A - tcp://C:7455 ZM m

> ● | The Route column lists the name of the passive server.

> ● | The T column indicates whether the route is active (A) or passive (P), from the perspective of server A.

> ● | The ConnID column contains either an integer connection ID (if the route is currently connected, or a dash (-) if the route is not connected.

> Routes to Fault-Tolerant Servers
> You can configure servers for fault tolerance. Client applications can specify the primary and backup servers; if the client’s connection to the primary server fails, the client can connect to the backup server and resume operation. Similarly, a route specification can specify primary and secondary passive servers, so that if the route to the primary server fails, the active server can connect to the backup server and resume routing.
> Failover behavior for route connections is similar to that for client connections; see Configuring Clients for Fault-Tolerant Connections.
> Example
> create route B url=tcp://B:7454,tcp://BBackup:7454 zone_name=Z1 zone_type=1hop
> Routing and SSL
> When configuring a route, you can specify SSL parameters for the connection. Although both participants in an SSL connection must specify a similar set of parameters, each server specifies this information in a different place:

> ● | The passive server must specify SSL parameters in its main configuration file, tibemsd.conf.

> ● | When a server initiates an SSL connection, it sends the route’s SSL parameters to identify and authenticate itself to the passive server. You can specify these parameters when creating the route, or you can specify them in the route configuration file, routes.conf.

> Table 71 lists the parameters that you can specify in the routes.conf configuration file, or on the command line when creating a route. The parameters for configuring SSL between routed servers are similar to the parameters used to configure SSL between server and clients; see Chapter 18, Using the SSL Protocol.

> Table 71 SSL Parameters for Routes
> Parameter | Description
> ssl_identity | The server’s digital certificate in PEM, DER, or PKCS#12 format. You can copy the digital certificate into the specification for this parameter, or you can specify the path to a file that contains the certificate in one of the supported formats. For more information, see File Names for Certificates and Keys.
> ssl_issuer | Certificate chain member for the server. Supply the entire chain, including the CA root certificate. The server reads the certificates in the chain in the order they are presented in this parameter. The certificates must be in PEM, DER, PKCS#7 or PKCS#12 format. Example ssl_issuer = certs\CA_root.pem ssl_issuer = certs\CA_child1.pem ssl_issuer = certs\CA_child2.pem For more information, see File Names for Certificates and Keys.
> ssl_private_key | The local server’s private key. If the digital certificate in ssl_identity already includes this information, then you may omit this parameter. This parameter accepts private keys in PEM, DER and PKCS#12 formats. You can specify the actual key in this parameter, or you can specify a path to a file that contains the key. For more information, see File Names for Certificates and Keys.
> ssl_password | Private key or password for private keys. You can set passwords using the tibemsadmin tool. When passwords are set with this tool, the password is obfuscated in the configuration file. For more information, see Chapter 6, Using the EMS Administration Tool.
> ssl_trusted | List of certificates that identify trusted certificate authorities. The certificates must be in PEM, DER or PKCS#7 format. You can either provide the actual certificates, or you can specify a path to a file containing the certificate chain. For more information, see File Names for Certificates and Keys.
> ssl_verify_host | Specifies whether the server must verify the other server’s certificate. The values for this parameter are enabled and disabled. When omitted, the default is enabled, signifying the server must verify the other server’s certificate. When this parameter is disabled, the server establishes secure communication with the other server, but does not verify the server’s identity.
> ssl_verify_hostname | Specifies whether the server must verify the name in the CN field of the other server’s certificate. The values for this parameter are enabled and disabled. When omitted, the default is enabled, signifying the server must verify the name of the connected host or the name specified in the ssl_expected_hostname parameter against the value in the server’s certificate. If the names do not match, the connection is rejected. When this parameter is disabled, the server establishes secure communication with the other server, but does not verify the server’s name.
> ssl_expected_hostname | Specifies the name expected in the CN field of the other server’s certificate. If this parameter is not set, the default is the hostname of the other server. This parameter is relevant only when the ssl_verify_hostname parameter is enabled.
> ssl_ciphers | Specifies a list of cipher suites, separated by colons (:). This parameter accepts both the OpenSSL name for cipher suites, or the longer descriptive names. For information about available cipher suites and their names, see Specifying Cipher Suites.
> ssl_rand_egd | The path for the installed entropy gathering daemon (EGD), if one is installed. This daemon generates random numbers.

Copyright © TIBCO Software Inc. All Rights Reserved.