Configuration Mode Commands : SteelHead Configuration Commands : Peering Commands : in-path peering rule
  
in-path peering rule
Configures in-path peering rules.
Syntax
[no] in-path peering rule {auto | pass | accept} [peer <peer-ip-address>] [ssl-capability {cap | in-cap | no-check}] [src {<ip-address> | all-ip |all-ipv4 | all-ipv6>}] [dest {<ip-address> | all-ip |all-ipv4 | all-ipv6>} [dest-port <port>] [rulenum <rule-number>] [description <description>]
Parameters
auto
Automatically determines the response for peering requests (performs the best peering possible).
pass
Allows pass-through peering requests that match the source and destination port pattern.
accept
Accepts peering requests that match the source-destination-port pattern.
peer <peer-ip-address>
Specifies the in-path IP address of the probing SteelHead. If more than one in-path interface is present on the probing SteelHead, apply multiple peering rules, one for each in-path interface.
The peer client-side SteelHead appliance IP address is IPv4 only.
ssl-capability
Specifies one of the following options to determine how to process attempts to create secure SSL connections:
•  cap (capable) - The peering rule checks whether the server-side SteelHead is present for the particular destination IP address and port combination. If the destination IP address and port are of an SSL server that is properly configured and enabled on the server-side SteelHead, and if there is no temporary or short-lived error condition, the SSL-capable check is a success. The SteelHead accepts the condition and, assuming all other proper configurations and that the peering rule is the best match for the incoming connection, optimizes SSL. The default peering rule with the SSL capable flag matches those connections to the destination IP/port combination for which there is an SSL server configuration added. The SteelHead considers the SSL server a match even if it is defined on a port number that is not the standard port 443. For all connections that match, the SteelHead performs both auto-discovery and SSL optimization.
•  in-cap (incapable) - If the destination IP address and port are not an SSL server that is properly configured and enabled on the server-side SteelHead, or if there is a temporary or short-lived error condition, the SSL-capable check fails. The SteelHead passes the connection through unoptimized without affecting connection counts. The default peering rule with the SSL incap flag matches any SSL connection to port 443 for which there is no SSL server configuration on the SteelHead.
•  no-check - The peering rule does not determine whether the server SteelHead is present for the particular destination IP address and port combination. This default rule catches any connection that did not match the first two default rules. The SteelHead performs auto-discovery and does not optimize SSL. This rule always appears last in the list and you cannot remove it.
src <ip-address>
Specifies the source subnet IP address and netmask for this rule. Use the format XXX.XXX.XXX.XXX/XX for IPv4 and X:X:X::X/XXX for IPv6.
src all-ip
Specifies all IPv4 and all IPv6 addresses. This is the default.
src all-ipv4
Specifies all IPv4 addresses.
src all-ipv6
Specifies all IPv6 addresses.
dest <ip-address>
Specifies the destination subnet IP address and netmask. Use the format XXX.XXX.XXX.XXX/XX for IPv4 and X:X:X::X/XXX for IPv6.
dest all-ip
Specifies all IPv4 and all IPv6 addresses. This is the default.
dest all-ipv4
Specifies all IPv4 addresses.
dest all-ipv6
Specifies all IPv6 addresses.
dest-port <port>
Specifies the destination port for this rule. You can specify a port label or all for all ports.
rulenum <rule-number>
Specifies the rule number. The system evaluates the rules in numerical order starting with rule 1. If the conditions set in the rule match, then the rule is applied. If the conditions set in the rule do not match, then the rule is not applied and the system moves on to the next rule. For example, if the conditions of rule 1 do not match, rule 2 is consulted. If rule 2 matches the conditions, it is applied, and no further rules are consulted.
The type of a matching rule determines which action the SteelHead takes on the connection.
description <description>
Specifies a description to facilitate communication about network administration.
Usage
You can provide increased optimization by deploying two or more SteelHeads back-to-back in an in-path configuration to create a serial cluster.
Appliances in a serial cluster process the peering rules you specify in a spill-over fashion. When the maximum number of TCP connections for a SteelHead is reached, that appliance stops intercepting new connections. This allows the next SteelHead in the cluster the opportunity to intercept the new connection, if it has not reached its maximum number of connections. The in-path peering rules and in-path rules tell the SteelHead in a cluster not to intercept connections between themselves.
You configure peering rules that define what to do when a SteelHead receives an auto-discovery probe from another SteelHead.
You can deploy serial clusters on the client or server-side of the network.
Important: For environments that want to optimize MAPI or FTP traffic that require all connections from a client to be optimized by one SteelHead, Riverbed strongly recommends using the master and backup redundancy configuration instead of a serial cluster. For larger environments that require multi-appliance scalability and high availability, Riverbed recommends using the SteelHead Interceptor to build multi-appliance clusters. For details, see the SteelHead Interceptor Deployment Guide and the SteelHead Interceptor User’s Guide.
Notes:
•  When you combine two SteelHeads that have a bandwidth limit of 20 Mbps each, the serial cluster still has a limit of 20 Mbps.
•  If the active SteelHead in the cluster enters a degraded state because the CPU load is too high, it continues to accept new connections.
Preventing an Unknown (or Unwanted) SteelHead from Peering
To prevent an unknown SteelHead from peering you must add a pass-through peering rule that passes through traffic from the unknown SteelHead in the remote location. For details, see the Management Console online help and the SteelHead Deployment Guide.
Example
This example shows how to configure a cluster with these three in-path appliances in a data center:
WAN----SH1----SH2----SH3----LAN
SH1 ip address is 10.0.1.1 on a /16
SH2 ip address is 10.0.1.2 on a /16
SH3 ip address is 10.0.1.3 on a /16
In this example, you configure each SteelHead with in-path peering rules to prevent peering with another SteelHead in the cluster, and with in-path rules to not optimize connections originating from other SteelHeads in the same cluster.
SH1 configuration:
SH1 > enable
SH1 # configure terminal
SH1 (config) # in-path peering rule pass peer 10.0.1.2 rulenum 1
SH1 (config) # in-path peering rule pass peer 10.0.1.3 rulenum 1
SH1 (config) # in-path rule pass-through srcaddr 10.0.1.2/32 rulenum 1
SH1 (config) # in-path rule pass-through srcaddr 10.0.1.3/32 rulenum 1
SH1 (config) # write memory
SH1 (config) # show in-path peering rules
Rule Type Source Network Dest Network Port Peer Addr
----- ------ ------------------ ------------------ ----- ---------------
1 pass * * * 10.0.1.3
2 pass * * * 10.0.1.2
def auto * * * *
SH1 (config) # show in-path rules
Rule Type Source Addr Dest Addr Port Target Addr Port
----- ---- ------------------ ------------------ ----- --------------- -----
1 pass 10.0.1.3/32 * * -- --
2 pass 10.0.1.2/32 * * -- --
def auto * * * -- --
 
SH2 configuration
SH2 > enable
SH2 # configure terminal
SH2 (config) # in-path peering rule pass peer 10.0.1.1 rulenum 1
SH2 (config) # in-path peering rule pass peer 10.0.1.3 rulenum 1
SH2 (config) # in-path rule pass-through srcaddr 10.0.1.1/32 rulenum 1
SH2 (config) # in-path rule pass-through srcaddr 10.0.1.3/32 rulenum 1
SH2 (config) # write memory
SH2 (config) # show in-path peering rules
Rule Type Source Network Dest Network Port Peer Addr
----- ------ ------------------ ------------------ ----- ---------------
1 pass * * * 10.0.1.3
2 pass * * * 10.0.1.1
def auto * * * *
SH1 (config) # show in-path rules
Rule Type Source Addr Dest Addr Port Target Addr Port
----- ---- ------------------ ------------------ ----- --------------- -----
1 pass 10.0.1.3/32 * * -- --
2 pass 10.0.1.1/32 * * -- --
def auto *
* * -- --
SH3 configuration
SH3 > enable
SH3 # configure terminal
SH3 (config) # in-path peering rule pass peer 10.0.1.1 rulenum 1
SH3 (config) # in-path peering rule pass peer 10.0.1.2 rulenum 1
SH3 (config) # in-path rule pass-through srcaddr 10.0.1.1/32 rulenum 1
SH3 (config) # in-path rule pass-through srcaddr 10.0.1.2/32 rulenum 1
SH3 (config) # write memory
SH3 (config) # show in-path peering rules
Rule Type Source Network Dest Network Port Peer Addr
----- ------ ------------------ ------------------ ----- ---------------
SH1 (config) # show in-path rules
Rule Type Source Addr Dest Addr Port Target Addr Port
----- ---- ------------------ ------------------ ----- --------------- -----
1 pass 10.0.1.2/32 * * -- --
2 pass 10.0.1.1/32 * * -- --
def auto * * * -- --
Product
SteelHead CX, SteelHead EX, SteelHead-v, SteelHead-c
Related Commands
show in-path peering rules