To be able to communicate to other Steelhead appliances, each active in-path interface needs to have an IP address, subnet mask and a default gateway defined. If the IP address is defined in a tagged VLAN, also a VLAN tag ID should be defined.
The most common issues with regards to the configuration are that the in-path interface IP address is the wrong IP subnet, that the VLAN tag ID is not properly defined or that the default gateway is set wrong.
The easiest way to determine if this is the case is to run tcpdump and check out the broadcast traffic like ARP requests, OSPF Hello packets and SMB traffic.
The ARP requests will be for IP addresses which are not in the expected IP subnet.
In this example the traffic from 192.168.1.0/24 while the in-path IP address is in 10.0.1.0/24:
Figure 4.8. ARP requests are coming from IP subnet 192.168.2.0/24
SH # tcpdump -ni lan0_0 'arp or (vlan and arp)' tcpdump: WARNING: lan0_0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lan0_0, link-type EN10MB (Ethernet), capture size 65535 bytes 21:19:59.256938 ARP, Request who-has 192.168.1.1 tell 192.168.1.3 length 28 21:20:07.618390 ARP, Request who-has 192.168.1.254 tell 192.168.1.8 length 46 21:20:08.127260 ARP, Request who-has 192.168.1.13 tell 192.168.1.12 length 46 3 packets captured 2123 packets received by filter 0 packets dropped by kernel
The SMB protocol uses IP broadcasts to announce services. These broadcasts should not leave the local IP subnet, so if you see them for IP addresses which are not on the expected IP subnet you know that there is something wrong.
Figure 4.9. SMB broadcast packets are coming from IP subnet 192.168.2.0/24
SH # tcpdump -ni wan0_0 ether broadcast tcpdump: WARNING: wan0_0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wan0_0, link-type EN10MB (Ethernet), capture size 300 bytes 21:35:19.514281 IP 192.168.2.55.42776 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQ \ UEST; BROADCAST 21:35:21.407979 IP 192.168.2.55.42776 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQ \ UEST; BROADCAST 21:35:21.678573 IP 192.168.2.55.42776 > 192.168.2.255.137: NBT UDP PACKET(137): QUERY; REQ \ UEST; BROADCAST
OSPF Hello packets are sent from the IP address of the router interface to a multicast address. If the IP address of the OSPF packet is not the IP address on the expected IP subnet you know that there is something wrong.
Figure 4.10. OSPF broadcast and unicast packets and coming from IP subnet 192.168.170.0/24
23:20:13.384849 IP 192.168.170.8 > 224.0.0.5: OSPFv2, Hello, length 48 23:20:14.386980 IP 192.168.170.2 > 224.0.0.5: OSPFv2, Hello, length 48 23:20:14.414477 IP 192.168.170.8 > 192.168.170.2: OSPFv2, Database Description, length 32 23:20:14.415890 IP 192.168.170.2 > 192.168.170.8: OSPFv2, Database Description, length 32 23:20:14.418003 IP 192.168.170.2 > 192.168.170.8: OSPFv2, LS-Request, length 36 23:20:14.418258 IP 192.168.170.8 > 192.168.170.2: OSPFv2, LS-Request, length 108 23:20:14.418357 IP 192.168.170.8 > 224.0.0.5: OSPFv2, LS-Update, length 64 23:20:14.420459 IP 192.168.170.2 > 224.0.0.6: OSPFv2, LS-Update, length 292
To solve this issue:
A visual confirmation of the ports of the devices connected to the LAN/WAN interfaces is required, with a follow-up in the configuration of these devices to check out which IP subnets are defined on them.
A remote investigation by shutting down interfaces so Ethernet links go down on the connected devices, giving indication of the connected ports on the neighbouring devices.
If the Ethernet frames generated by Steelhead appliance transmitted from the in-path interface are incorrectly tagged, the ARP requests coming out of it will never be answered or will be send out on the wrong VLAN.
First step: Ping the in-path interface IP address of the default gateway:
Figure 4.11. Ping the in-path interface IP address from the default gateway
RTR # ping Protocol [ip]: Target IP address: 10.0.1.6 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 10.0.1.9 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms RTR # ping ip 10.0.1.6 source 10.0.1.9 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms
If the in-path interface is using the wrong VLAN, this will fail completely.
The output of tcpdump will show only ARP requests:
Figure 4.12. Tcpdump running for a ping from the Steelhead appliance
SH # tcpdump -leni wan0_0 'host 10.0.1.9 and icmp or (vlan and host 10.0.1.9 and icmp))' tcpdump: WARNING: wan0_0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lan0_0, link-type EN10MB (Ethernet), capture size 96 bytes 18:53:46.123323 00:0d:b9:17:28:de > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 4 \ 6: vlan 3, p 0, ethertype ARP, Request who-has 10.0.1.6 tell 10.0.1.9, length 28 18:53:47.027193 00:0e:b6:42:f8:9c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 4 \ 6: vlan 12, p 0, ethertype ARP, Request who-has 10.0.1.9 tell 10.0.1.6, length 28
So the ARP requests from the Steelhead appliance are on VLAN 12, while the ARP requests from the router are on VLAN 3.
If an in-path interface has been disabled in the configuration, any IP address in the configuration will still be configured on the virtual in-path interface.
This means that if the same IP address has been configured on the inpath0_0 and inpath0_1 but inpath0_1 has been disabled, the two in-path interfaces will still get the same IP address configured. Despite that the in-path interfaces are independent, can be on the same IP subnet and have their own routing table, a duplicate IP address is not supported.
The solution would be to remove the IP address of the disabled in-path interfaces and a restart of the optimization service:
Figure 4.13. Remove the IP address of inpath0_1 via the CLI
SH (config) # no interface inpath0_1 ip address SH (config) # restart