Steelhead Deployment

Things to go wrong and how to find and fix them

© 2006-2010 Riverbed Technology. Duplication Prohibited.

3

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.

4

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.

5

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, don‘t 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>

Full100M

Full100M

Full100M

Full100M

AutoAutoAutoAuto

© 2006-2010 Riverbed Technology. Duplication Prohibited.

6

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 it‘s 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 <- we belong here (if U want an easy life)

NAT

L4-L7 Firewall

IDS / IDP

Server LAN

© 2006-2010 Riverbed Technology. Duplication Prohibited.

7

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.

8

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.

9

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

RRRR

© 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, they‘re 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

Thank You !

Questions ?