Policy-based routing enables the TCP/IP stack to make routing decisions that take into account criteria other than just the destination IP address. The additional criteria can include job name, source port, destination port, protocol type (TCP or UDP), source IP address, NetAccess security zone, and multilevel secure environment security label. Policy-based routing might be useful in the following sample scenarios:
- You might want to favor high-bandwidth links for batch traffic, but for interactive traffic you prefer low-latency links. If so, you could define policies such that Telnet traffic is routed over the low-latency links, and FTP traffic is routed over the high-bandwidth links.
- You could define a policy to ensure that traffic that is tagged with a security label and zone is routed to a secured network over an appropriate outbound interface.
- You might want to control the links that are used by Enterprise Extender traffic to keep that traffic from being impacted by other IP traffic loads.
Restrictions:
Policy-based routing applies only to TCP and UDP
traffic that originates at the TCP/IP stack. The following types of
traffic are routed always by using the main route table, even when
policy-based routing is in use:- Traffic that uses protocols other than TCP and UDP
- Traffic that the TCP/IP stack uses
- Traffic for the Ping and Traceroute commands
- If Common INET (CINET) is used to run multiple z/OS® Communications Server TCP/IP stacks concurrently,
CINET has no knowledge of the policy-based route tables that are used
by those TCP/IP stacks. CINET has knowledge only of the routes in
the main route table of each TCP/IP stack. Avoid use of policy-based
routing in a CINET environment, unless at least one of the following
conditions is true:
- All applications establish affinity with a particular TCP/IP stack.
- The route destinations in each TCP/IP stack route table are mutually exclusive with the route destinations on the other TCP/IP stacks, including the default route.