In the simplest deployment scenario, an in-path deployment with the same IP subnet behind the Steelhead appliance LAN interface as on the in-path interface, the routing of packets coming from an in-path interface is simple: All delivery is either on the local IP subnet or to be sent to the default gateway of the IP subnet.
When there are multiple IP subnets defined on the LAN behind the Steelhead appliance or when the IP subnet on in-path interface is different from the IP subnets of the LANs, this approach of a single default gateway doesn't work anymore because traffic to the IP subnets which is not on the in-path interface will be sent to the default gateway on the WAN side of the Steelhead appliance instead of to the router on the LAN side of the Steelhead appliance. This causes that traffic to travel one extra hop, to be inspected by a firewall which might not like the traffic, to be applied to QoS rules defined on the WAN interface of the Steelhead appliance and so on.
Figure 5.94. Steelhead appliance with multiple LANs behind it
192.168.0.0/24 .------------. ,----. .------------. | WAN Router |----| SH |----| LAN Router |--- IP Subnet 1 / 192.168.1.0/24 '------------'.9 W'----'L .8| | | |--- IP Subnet 2 / 192.168.2.0/24 | | | |--- IP Subnet 3 / 192.168.3.0/24 '------------' WAN router MAC address: 00:0d:b9:17:28:dd LAN router MAC address: 00:21:70:3e:6b:7f Default gateway for Steelhead in-path interface: WAN router
With the in-path interface being on the same IP subnet as the rest of the hosts on the LAN side, in the auto-discovery phase there will be two or three packets seen on the WAN interface: one incoming SYN+ and one or two outgoing SYN/ACK+s, depending on if Enhanced Auto Discovery is enabled or not.
Figure 5.95. Tcpdump of traffic if the in-path IP address is on the same IP subnet as the hosts on the LAN
11:44:12.311915 00:0d:b9:17:28:dd > 00:21:70:3e:6b:7f, ethertype IPv4 (0x0800), length 94: \ 10.0.1.1.49850 > 192.168.1.1.50: Flags [S], seq 3346759466, win 65535, options [mss 1 \ 460,nop,wscale 1,nop,nop,TS val 2834406441 ecr 0,sackOK,nop,nop,rvbd-probe AD CSH:10.0 \ .1.6 01010a0001060005,rvbd-probe EAD 0c01,nop,eol], length 0 11:44:12.312010 00:0e:b6:8c:7a:ed > 00:0d:b9:17:28:dd, ethertype IPv4 (0x0800), length 86: \ 192.168.1.1.50 > 10.0.1.1.49850: Flags [S.], seq 20020520, ack 3346759467, win 65535, \ options [mss 1460,nop,wscale 1,nop,nop,TS val 2834406441 ecr 0,sackOK,nop,nop,rvbd-pr \ obe EAD 0c01,nop,nop,nop,eol], length 0 11:44:12.312484 00:0e:b6:8c:7a:ed > 00:0d:b9:17:28:dd, ethertype IPv4 (0x0800), length 94: \ 192.168.1.1.50 > 10.0.1.1.49850: Flags [S.], seq 20020520, ack 3346759467, win 65535, \ options [mss 1460,nop,wscale 1,TS val 2834406441 ecr 0,sackOK,rvbd-probe AD CSH:10.0. \ 1.6 SSH:192.168.1.6:7800 11110a000106c0a801061e78,rvbd-probe EAD 0e3d,nop,eol], length \ 0
With the in-path interface being on a different IP subnet than the rest of the hosts on the LAN side and the default gateway set to the WAN router, there will be seven packets seen on the WAN interface: One incoming SYN+, one outgoing SYN/ACK+, one forwarded SYN+ to the server seen twice, one final ACK to the server seen twice and one SYN/ACK+ back to the client-side Steelhead appliance.
Figure 5.96. Tcpdump of traffic on a different IP subnet behind the Steelhead appliance
11:44:25.629579 00:0d:b9:17:28:dd > 00:21:70:3e:6b:7f, ethertype IPv4 (0x0800), length 94: \ 10.0.1.1.49853 > 192.168.2.1.50: Flags [S], seq 3631007307, win 65535, options [mss 1 \ 460,nop,wscale 1,nop,nop,TS val 2834419715 ecr 0,sackOK,nop,nop,rvbd-probe AD CSH:10.0 \ .1.6 01010a0001060005,rvbd-probe EAD 0c01,nop,eol], length 0 11:44:25.629695 00:0e:b6:8c:7a:ed > 00:0d:b9:17:28:dd, ethertype IPv4 (0x0800), length 86: \ 192.168.2.1.50 > 10.0.1.1.49853: Flags [S.], seq 20020520, ack 3631007308, win 65535, \ options [mss 1460,nop,wscale 1,nop,nop,TS val 2834419715 ecr 0,sackOK,nop,nop,rvbd-pr \ obe EAD 0c01,nop,nop,nop,eol], length 0 11:44:25.629966 00:0e:b6:8c:7a:ed > 00:0d:b9:17:28:dd, ethertype IPv4 (0x0800), length 90: \ 10.0.1.1.49853 > 192.168.2.1.50: Flags [S], seq 3498683517, win 5840, options [mss 14 \ 60,sackOK,TS val 11038597 ecr 0,nop,wscale 2,rvbd-probe AD CSH:10.0.1.6 01010a00010600 \ 05,rvbd-probe EAD 0c05,nop,eol], length 0 11:44:25.696347 00:0d:b9:17:28:dd > 00:21:70:3e:6b:7f, ethertype IPv4 (0x0800), length 90: \ 10.0.1.1.49853 > 192.168.2.1.50: Flags [S], seq 3498683517, win 5840, options [mss 14 \ 60,sackOK,TS val 11038597 ecr 0,nop,wscale 2,rvbd-probe AD CSH:10.0.1.6 01010a00010600 \ 05,rvbd-probe EAD 0c05,nop,eol], length 0 11:44:25.696686 00:0e:b6:8c:7a:ed > 00:0d:b9:17:28:dd, ethertype IPv4 (0x0800), length 66: \ 10.0.1.1.49853 > 192.168.2.1.50: Flags [.], seq 4162643507, ack 1520852933, win 1460, \ options [nop,nop,TS val 11038663 ecr 2163923817], length 0 11:44:25.696790 00:0e:b6:8c:7a:ed > 00:0d:b9:17:28:dd, ethertype IPv4 (0x0800), length 94: \ 192.168.2.1.50 > 10.0.1.1.49853: Flags [S.], seq 20020520, ack 3631007308, win 65535, \ options [mss 1460,nop,wscale 1,TS val 2834419715 ecr 0,sackOK,rvbd-probe AD CSH:10.0. \ 1.6 SSH:192.168.0.6:7800 11110a000106c0a800061e78,rvbd-probe EAD 0e3d,nop,eol], length \ 0 11:44:25.763141 00:0d:b9:17:28:dd > 00:21:70:3e:6b:7f, ethertype IPv4 (0x0800), length 66: \ 10.0.1.1.49853 > 192.168.2.1.50: Flags [.], seq 4162643507, ack 1520852933, win 1460, \ options [nop,nop,TS val 11038663 ecr 2163923817], length 0
Checking the source and destination MAC addresses of the packets, you can see that the additional packets are the ones normally expected on the LAN side of the Steelhead appliance. However, because the default gateway is set to the WAN side router, currently they are first send back to the WAN router which then forwards them to the LAN router.
The first solution would be to configure the gateways to these IP subnets behind the Steelhead appliance in the routing table of the Steelhead in-path interface:
Figure 5.97. In-path interface gateways
SH (config) # ip in-path route inpath0_0 192.168.1.0 /24 192.168.0.8 SH (config) # ip in-path route inpath0_0 192.168.2.0 /24 192.168.0.8 SH (config) # ip in-path route inpath0_0 192.168.3.0 /24 192.168.0.8 SH # show ip in-path route inpath0_0 static Destination Mask Gateway default 0.0.0.0 192.168.0.8 192.168.1.0 255.255.255.0 192.168.0.8 192.168.2.0 255.255.255.0 192.168.0.8 192.168.3.0 255.255.255.0 192.168.0.8
This is an administrative overhead which needs to be synchronized every time a new IP subnet is defined behind the Steelhead appliance, but it will make sure that the in-path interface does know the path to the configured IP subnets.
Instead of having to configure all the IP subnets behind the LAN interfaces of the Steelhead appliances, the Steelhead appliance can learn the source and destination IP addresses of the packets received by associating it with the source and destination MAC addresses of the Ethernet frame.
This way it will build a list of destination IP addresses and the MAC address on the Ethernet segment they are reachable via. IP addresses not in the Simplified Routing table will be sent out via the normal IP routing table.
The Simplified Routing method can populate the IP address and MAC address combinations in the Simplified Routing table by looking at different kinds of data:
Destination-only: The destination IP addresses and destination MAC addresses of optimized TCP sessions. This will populate the Simplified Routing table with the destination IP addresses based on the routing information to the destination IP addresses. This is the default since RiOS versions 6.0.
Source and destination: Both the source and destination IP addresses of optimized TCP sessions.
All: The source and destination IP addresses of all IP traffic, not only the optimized TCP sessions.
Figure 5.98. Overview of the simplified routing table, pre RiOS 8.0
SH (config) # in-path simplified routing dest-only SH # show in-path macmap-tables relay ip_addr mac_addr vlan ref_count inpath0_0 10.0.1.1 00:0d:b9:17:28:dd 0 1 inpath0_0 192.168.2.1 00:21:70:3e:6b:7f 0 1
Figure 5.99. Overview of the simplified routing table, RiOS 8.0 and later
SH # show in-path macmap-tables relay ip_addr mac_addr vlan ref_count valid inpath0_0 10.0.1.1 00:0d:b9:17:28:dd 0 0 Yes inpath0_0 192.168.2.1 00:21:70:3e:6b:7f 0 0 Yes
So it knows that on inpath0_0 the host with IP address 10.0.1.1 is behind the gateway with MAC address d4:9a:20:c2:52:0e. But it still doesn't tell you if it is on the LAN or on the WAN side of the in-path interface, you need the system dump for that.
The file
macmap_tables
contains the table as above. The files
mactab_entries
in RiOS 5.5
and
pkttab_entries
in RiOS 6.0 and higher in the subdirectories of the
er/
directory contains the link between the MAC addresses of the gateways
and the LAN or WAN side and the VLAN the gateway is in:
Figure 5.100. Matching the MAC addresses of the gateways with the LAN and WAN interfaces
[~/sysdumps-SH] edwin@t43>cat macmap_tables inpath0_0 10.0.1.1 00:0d:b9:17:28:dd 0 1 inpath0_0 192.168.2.1 00:21:70:3e:6b:7f 0 1 [~/sysdumps-SH] edwin@t43>ls -al er/*/pkttab_entries -rw-r--r-- 1 edwin edwin 681 Jun 6 2012 er/0/pkttab_entries -rw-r--r-- 1 edwin edwin 664 Jun 6 2012 er/1/pkttab_entries -rw-r--r-- 1 edwin edwin 5343 Jun 6 2012 er/2/pkttab_entries [~/sysdump-SH] edwin@t43>cat er/0/pkttab_entries ent/tot ht[chain] p addr vlan dev type hits flaps p \ vlan_chg p race 1/ 2 317[ 0] 0 00:21:70:3e:6b:7f 0 lan0_0 EAL_DEV_LAN 0 0 0 \ 0 0 0 2/ 2 569[ 0] 0 00:0d:b9:17:28:dd 0 wan0_0 EAL_DEV_WAN 509394 0 \ 0 0 0 0
So the host with IP address 10.0.1.1 is on inpath0_0 behind the gateway with MAC address 00:0d:b9:17:28:dd which is on the WAN side of the inpath0_0 interface.
While in theory this should be fool proof since it learns from the network there are a couple of scenarios to keep alert about.
Pre RiOS 7.0.4 and 8.0, the Simplified Routing table could only be cleared by rebooting the appliance. Once learned the entry could not be unlearned, only overwritten with new information.
With RiOS 7.0.4 and 8.0, the command
in-path simplified routing-entries flush <interface>
will mark all the macmap table entries for a specific in-path
interface as invalid, causing them to be ignored until learned
again:
Figure 5.101. Unlearning entries from the macmap tables
SH # in-path simplified routing-entries flush all SH # show in-path macmap-tables relay ip_addr mac_addr vlan ref_count valide_data jiffies_update_l \ ru inpath0_0 10.0.1.1 00:0d:b9:17:28:dd 0 0 No 159168 59901600 \ 68 inpath0_0 192.168.2.1 00:21:70:3e:6b:7f 0 0 No 451650 59904525 \ 50
Interface bonding consists of two interfaces on a server which listen to the same IP address. It has been the experience that they can be sending out packets with the MAC address of the non-master interface but not accepting packets send to it. Switching to the Destination-Only Simplified Routing setting will overcome this problem.
In a Connection Forwarding deployment, always use the Destination-Only Simplified Routing setting.
Other in-path devices behind or in front of the Steelhead appliance can transparently generate the traffic, but will end up with the source MAC address of the in-path device, causing the Steelhead appliance to learn them. Use the Destination-Only Simplified Routing setting in this situation.