About in-path interface settings
In-path settings are under Networking > Networking: In-Path Settings.
In-path interface settings
Enable Link State Propagation shortens the recovery time of a link failure in physical in-path deployments. Link state propagation (LSP) communicates link status among connected appliances. When enabled, the appliance monitors the link state of all connected peer appliances. When a status check fails, the appliance disconnects the corresponding interface, blocking the link. This allows a link failure to quickly propagate through a chain of appliances. If the link recovers, the appliance restores the connection on the corresponding interface.
Cloud Accelerator and SteelHead (Virtual Edition) running on ESXi 4.x or Microsoft Hyper-V don’t support LSP. SteelHead (Virtual Edition) running on ESXi 5.0 and later with a Riverbed NIC support LSP.
Other in-path interface settings are very similar to the base interface settings, with these differences:
• If there’s a routed network on the LAN-side of the in-path appliance, the router that is the default gateway for the appliance must not have the ACL configured to drop packets from the remote hosts as its source. The in-path appliance uses IP masquerading to appear as the remote server.
• In the case of UDP encapsulation with NAT, different SteelHeads could use the same public-facing destination addresses. To uniquely identify such SteelHeads, specify a NAT IPv4 address paired with a specific port opened on the NAT in the NAT IPs and ports field. Specify multiple NAT IPs and ports on separate lines.
• For IPv6, specify a global or site-local IPv6 address. You can’t use a DHCP server to assign an IPv6 address automatically.
• For IPv4, if you have a router (or a Layer-3 switch) on the LAN side of your network, specify this device as the in-path gateway. For IPv6, you can use a link local address.
VLAN tag ID specifies a numerical ID from 0 to 4094 that identifies a specific VLAN. Enter “all” to match all VLANs, or “untagged” to match untagged connections. Passed-through traffic maintains existing VLAN tags. Default is 0.
Enable Appliance Management on This Interface enables reachability through the physical LAN and WAN interfaces to connect a third-party management device.
In-path routing table
You can configure interface-specific static routing tables for in-path interfaces. Specify the destination IP address and the IP address for the gateway. The gateway must be in the same network as the in-path interface.
In-path interfaces for appliance management
You can also use in-path interfaces to connect the appliance to non-Riverbed network management devices. This secondary management interface (MIP) enables you to manage appliances from a private network while maintaining a logical separation of network traffic, eliminating the need to deploy a switch or borrow a switch port.
Some deployments don’t allow access to the MIP when plugged into a private subnet with a separate IP address space. In this type of deployment, you can’t use the in-path interfaces for appliance management.
MIP for third-party management device
A MIP interface is accessible from LAN and WAN sides, and you can reach it even when the primary interface is unavailable, the optimization service isn’t running, or the logical in-path interface fails. A MIP interface isn’t accessible if the physical LAN and WAN interfaces fail.
MIP interfaces use the main routing table. They support IPv6 addresses and 802.1Q VLAN. Any connections destined to a MIP aren’t optimized and don’t appear in the Current Connections report.
A MIP must be in its own subnet. It can’t reside in the same subnet as the primary or auxiliary interfaces and it can’t share the same subnet with any other interfaces on the appliance.
With LSP or fail-to-block enabled, a MIP becomes unreachable if its corresponding in-path interface fails.
You can remove MIPs from the base interfaces main routing table.