4.6. IP Subnet configuration related issues

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.

4.6.1. Wrong IP subnet for the in-path interface

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.

4.6.2. In-path interface IP address is in the wrong VLAN

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.

4.6.3. Duplicate IP addresses on in-path interfaces

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

4.6.4. Duplicate IP addresses on the IP subnet

If an in-path interface detects that it has been configured with an IP address already in use on the IP subnet, it will complain about it in the logs:

Figure 4.14. Duplicate IP addresses on the in-path interfaces

kernel: [IP.ERR] inpath0_0: IP address 192.168.1.5 conflicts with 00:1c:c4:ee:3f:90

4.6.5. Default gateway unreachable

In the end, when everything is configured correctly, it just could be that the default gateway is unreachable. Ping any other IP addresses on the IP subnet and see if they work would be the next steps.