Steelhead Deployment

Things to go wrong and how to find and fix them

Things to go wrong
Wrong cable types (Cross vs. Straight) L2 settings & negotiation (half / full & speed) Bad Location (relative to MPLS, IPsec-VPN, NAT, L7-FW) Limited IP connectivity (VLANS / transfer segments / Firewalls) LAN / WAN ports swapped (no opt. in one direction) Packet Rikochet (WAN link more data than LAN) Forwarding Asymmetry (VRRP vs. WAN / forgotten links) NAT between the Steelheads (no opt. / broken sessions)

2006-2010 Riverbed Technology. Duplication Prohibited.

Wrong cable types (Cross vs. Straight)

All Riverbed Ports are CLIENT Ports (like your and my laptop) Cable types should be chosen as if the Steelhead was a Server Watch out for switching modules in spoke routers Auto-MDI-X might fix a wrong cable type while Steelhead is powered up Once the relay goes shut there is no MDI-X anymore on the SH Your site might go offline due to missing MDI-X when relay goes shut -> Insert Steelhead while power down Setting speed and duplex to fixed values might disable MDI-X

straight

cross

cross (mostly)

2006-2010 Riverbed Technology. Duplication Prohibited.

L2 settings & negotiation (half / full & speed)

If you do Auto / Auto, you should check the negotiation results switch port should match LAN-port / WAN-port should match Router port If you use fixes settings, dont choke yourself 10/half is o.k. for a 2MBit/s line, but insufficient on Steelhead LAN side Use same settings all the way through (unless you do fail-to-block) Use flodd-ping to check for excessive packet loss
ping -f -I <loc-in-path-ip> -s 1400 <remote-ip>

Full 100M Auto

Full 100M Auto

Full 100M Auto

Full 100M Auto

2006-2010 Riverbed Technology. Duplication Prohibited.

Bad Location (relative to MPLS, IPsec-VPN, NAT, L7-FW)

We need to see cleartext on the LAN -> no tunnel technologies allowed We can do L4 transp. on the WAN, but there is no HTTP in port 80 then -> L7 inspection on the WAN side might get confused We can traverse NAT now, but its no fun We belong (seen from the WAN) after VPN and before NAT & L7
WAN Cloud WAN Router L4 Firewall / ACLs VPN Terminator Riverbed Steelhead NAT L4-L7 Firewall IDS / IDP Server LAN
2006-2010 Riverbed Technology. Duplication Prohibited.

<- we belong here (if U want an easy life)

Limited IP connectivity (VLANS / transfer segments / Firewalls) InPathIP addresses must be able to communicate with each other This could be limited due to A) VLAN Trunk -> set the right VLAN number on the InPathInterface B) InPath is sitting on a non-routed transfer network -> use FT (or FT/reset) in all InPath-Rules AND use OOB-Transparency C) Firewall blocks TCP sessions between the Steelheads -> Open TCP Port 7800 in- and outgoing to and from all InPathIPs In a combined situation (where more than one of the above applies), FT/reset in all InPathRules and <in-path peering oobtransparency mode "full> is your best shot check InPath- with Connectivity <ping I inpath0_0 10.17.0.23> to adjacent routers as well as to remote InPathIPs

2006-2010 Riverbed Technology. Duplication Prohibited.

LAN / WAN ports swapped (no opt. in one direction)

Ever had A->B gets optimized, B->A does not ? In most cases LAN and WAN are swapped @ location B Two ways to validate this Flow details of passthru flow go to reports -> current connections and switch to passthru look for an ununtentional passthru flow and look int he details SYN from WAN in the Flow Details on Client Steelhead points to LAN/WAN swap on that box InPathIP has two different MACs for LAN and WAN ... Ping InPathIP from L2-adjacent IP look into the ARP cache compare the MACs with the MACs of the SH InPath-MACs are listed here: reports -> networking -> interface counters You can generate probes by
tproxytrace -i inpath0_0 <ip>:<port>
2006-2010 Riverbed Technology. Duplication Prohibited.

Packet Rikochet (WAN link more data than LAN)

Slow performance but no packet loss involved Check whether the WAN interface has more data than the LAN interface If so, then either Use Simplified Routing (SR) learns routes from passing traffic safest setting is Destination only never point the InPath-DefGW to a Firewall when using SR Add static routes to the InPathInterfaces for the networks where DefGW points into the wrong direction If SR is used, Static Routes are less powerful than a route learned by SR
R
R

2006-2010 Riverbed Technology. Duplication Prohibited.

10

Forwarding Asymmetry (VRRP vs. WAN / forgotten links)

Steelheads are Layer-7-Devices Traffic must flow through the same pair of SHs forth and back Often in the Datacenter customers swear my router pair is active/passive because we do VRRP or there is no other link VRRP argument only true for outgoing traffic / there IS another link Use Steelhead Model with multiple interfaces or use connection forwarding Only bad RST and bad SYN/ACK are verified asymmetries, SYN rexmit and probe filtered are NOT, theyre just SUSPECTS

2006-2010 Riverbed Technology. Duplication Prohibited.

11

NAT between the Steelheads (no opt. / broken sessions)

NAT between Steelheads used to create problems Solved with 6.0 when using FullTransparency and OOB-Transparency If you have NAT the steelheads, do FT7reset & OOB-Full-Transparency

2006-2010 Riverbed Technology. Duplication Prohibited.

Thank You !
Questions ?