Drobo

Dual Drobo-FS Network Problem

I think I have discovered an annoying bug in the Drobo-FS network settings. When I plug both my Drobo-FSs directly into my computer at the same time they fight over the IP address.

Here is my setup:

[i]Turn on Drobo1, plug into computer.
Dashboard finds it.
I confirm it is using the default address of 169.254.213.234
I go into Advanced Controls -> Tools -> Settings -> Network

I change the name to Drobo-FS1. I change the settings from DHCP to Manual.
IP Address: 169.254.1.1
Subnet Mask: 255.255.0.0
Default Gateway: 0.0.0.0
DNS Server 1: 0.0.0.0
DNS Server 2: 0.0.0.0
(Drobo reboots)

Plug in my second Drobo directly into my second NIC.
Dashboard finds it.
I confirm it is using the default address of 169.254.213.234
I go into Advanced Controls -> Tools -> Settings -> Network

I change the name to Drobo-FS2. I change the settings from DHCP to Manual.
IP Address: 169.254.1.2
Subnet Mask: 255.255.0.0
Default Gateway: 0.0.0.0
DNS Server 1: 0.0.0.0
DNS Server 2: 0.0.0.0
(Drobo reboots)
[/i]
All good so far.
Now some tests:
[font=Courier]
C:>ping 169.254.1.1

Pinging 169.254.1.1 with 32 bytes of data:
Reply from 169.254.1.1: bytes=32 time<1ms TTL=64
Reply from 169.254.1.1: bytes=32 time<1ms TTL=64
Reply from 169.254.1.1: bytes=32 time<1ms TTL=64
Reply from 169.254.1.1: bytes=32 time=4ms TTL=64

Ping statistics for 169.254.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 4ms, Average = 1ms

C:>ping 169.254.1.2

Pinging 169.254.1.2 with 32 bytes of data:
[color=#FF0000]Reply from 169.254.121.224: Destination host unreachable.[/color]
Reply from 169.254.1.2: bytes=32 time<1ms TTL=64
Reply from 169.254.1.2: bytes=32 time=1ms TTL=64
Reply from 169.254.1.2: bytes=32 time=2ms TTL=64

Ping statistics for 169.254.1.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 2ms, Average = 1ms
[/font]

Here is the first bit of wierdness
[color=#FF0000][font=Courier]Reply from 169.254.121.224: Destination host unreachable.[/font][/color]
Not quite sure what is happening here.

Another test:

[font=Courier]C:>ping drobo-fs1

Pinging drobo-fs1 [169.254.213.234] with 32 bytes of data:
Reply from 169.254.213.234: bytes=32 time=1ms TTL=64
Reply from 169.254.213.234: bytes=32 time<1ms TTL=64
Reply from 169.254.213.234: bytes=32 time<1ms TTL=64
Reply from 169.254.213.234: bytes=32 time<1ms TTL=64

Ping statistics for 169.254.213.234:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

C:>ping drobo-fs2

Pinging drobo-fs2 [169.254.213.234] with 32 bytes of data:
Reply from 169.254.213.234: bytes=32 time<1ms TTL=64
Reply from 169.254.213.234: bytes=32 time<1ms TTL=64
Reply from 169.254.213.234: bytes=32 time=1ms TTL=64
Reply from 169.254.213.234: bytes=32 time<1ms TTL=64

Ping statistics for 169.254.213.234:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
[/font]
What The??? Now both my drobos are coming back as [color=#FF0000][font=Courier]169.254.213.234[/font][/color]!!

Another test:
In Windows Explorer I go to
[font=Courier]\Drobo-FS1[/font]
No Problem, I can see the correct shares.

Next I go to
[font=Courier]\Drobo-FS2[/font]
Now I can only see the shares on Drobo-FS1 :frowning:

Next I go to
[font=Courier]\169.254.1.[color=#FF0000]1[/color][/font]
No Problem, I can see the correct shares on Drobo-FS1

Next I go to
[font=Courier]\169.254.1.[color=#FF0000]2[/color][/font]
No Problem, I can see the correct shares on Drobo-FS2

Next I go to
[font=Courier]\169.254.213.234[/font]
Once again I see the files that are on Drobo-FS1

Can anyone else confirm the same problem?

It sounds like your computer is retaining both the old and new ip address of each DroboFS. I would recommend that you clear your cache or better yet, reboot your computer and then try your tests again.

I’m not sure why you are doing this, but I don’t think there’s anything really wrong with what’s happening.

If you just plug the FS’s straight into your LAN along with your computer then they will get unique 192.168.x.x or 10.x.x.x addresses, dependent on config.

If you plug in the FS’s direct, what’s wrong with letting them both use the auto-configured IP addresses, which are supposed to be different, and letting Dashboard find them that way? You are naming them, so you will know which one is which. I think what is happening is this:

The first FS generates an auto-configured address. Dashboard will find it, and you can name it. If you then plug in the second one, it ought to generate a different auto-configured address, at least that’s what the standard says. It is supposed to check to see if the address it chooses is already in use, and if it is, pick another one.

I think that is what is happening to you. The first one chooses an address according to it’s algorithm, and it’s not in use so it sticks. You then change the address. When you plug in the second one, it uses the same algorithm to pick an address, which happens to be the same one that the first one originally picked (you could consider this a weakness in their implementation, they should probably use an algorithm that will generate different addresses on different FS’s, but as long as it does the checks and tries again if the address is in use it doesn’t really matter and is not really a “bug”). Because you have changed the address on the first one, when the second one does its checks it finds that the address it chose is not in use so it keeps it. You then change it on the second one.

Now you have had FS 1 at the auto-address plus your chosen one, and Drobo 2 at the same auto address plus your chosen one. Your computer might be getting confused about the names as both Drobos have had the same IP address at one point in time, and it is probably caching name/IP address pairs as it sees them.

I’d just let them both autoconfigure separately and not worry about the static IPs.

Can you explain what you are trying to do and why?

Thanks for the advice, but maybe I should have mentioned I am quite skilled with computers, so I have already investigated this very thoroughly :stuck_out_tongue_winking_eye:

I have verified the problem exists for more than a week across multiple reboots on both Windows 7 and XP. I configured them in my Windows 7 then went into XP, where there would be no previous caching, with the same result.

I have also manually run an [font=Courier]ipconfig /flushdns[/font], and tried [font=Courier]ipconfig /release[/font] / [font=Courier]ipconfig /renew[/font]

Any other ideas?

Actually, if you do not have a DHCP server running the Drobo defaults to 169.254.213.234. This means to plug in 2 at once you need to set static IPs

Sorry, should have mentioned in my OP I am not running a DHCP server on my PC.

hmmm, the manual says 169.254.213.234. Does not mention anything about the Drobo itself auto configuring an address (without DHCP).

The one time I did have them both on Auto configure I could only access one at a time and would have to turn one off to get to the other one.

I do have a network switch that has DHCP enabled, but my PC is on WiFi. If I plug them into my switch the speed will be terrible.

By “auto-configured” I meant a link-local address, as defined here: http://en.wikipedia.org/wiki/Link-local_address

This is used in the absence of a DHCP server, as in your case. Your PC and the two Drobos should end up on three unique IP addresses in the 169.254 range. Try it and see, this is a standard that Linux, Mac OS, Windows, etc. all follow, and as Drobo FS is Linux underneath I would expect it to “just work”.

I’m running on lack of sleep, so I might be totally off here but…

Sounds like you’re doing a direct-connect between the NIC and the FS units (NIC1-FS1, NIC2-FS2).
Which results in both Drobos on the same subnet (169.254.0.0/255.255.0.0) but using different NICs.

Without some server-class NIC drivers or added intelligence, Windows doesn’t know how to route traffic for the same subnet to different NICs.

To compound that, autoconfig addresses can’t do collision-detection because they’re on separate NICs. Hence you’re getting two of the same address.

Then to make life especially difficult… Windows does NetBIOS over TCP/IP to do the name->IP resolution. But both names are registered to the same IP (even though they’re on different NICs), so the traffic goes to the preferred NIC bound to File and Printer Sharing for Microsoft Networks in Network Connections>Advanced>Advanced Settings (in most cases).

Solution #1:
Put the two FS+NIC pairs on different subnets.
Assign a fixed IP address to each unit and NIC, making sure the unit and the NIC it is attached to are in the same subnet, but the subnets between the two pairs are different.
For example, NIC1 might be 192.168.10.1/255.255.255.0 and FS1 might be 192.168.10.2/255.255.255.0 while
NIC2 would be 192.168.11.1/255.255.255.0 and FS2 would be 192.168.11.2/255.255.255.0

Solution #2
Connect both FS units to the same NIC using a switch.

Solution #1 is preferred as you’ll have full bandwidth of the NIC dedicated to the FS unit it’s attached to.
Solution #2 could work with full bandwidth if you had a server-class NIC and an L2 or better switch that supported Link Aggregation. #1 is infinitely cheaper, not to mention a lot less headache and complexity. :slight_smile:

[EDIT] Changed the private IPs (192.168.x.x) so they’d be less likely to collide with your wireless connection’s NAT and DHCP.

Didn’t spot the second NIC thing…

What you are suggesting makes sense, either #1 or #2.

I don’t think an FS can saturate GigE so I would think #2 would be the easiest, just get a regular GigE switch and go.

Spiney’s right. If you’re not planning to use the connection for anything other than FS use, the two combined still wouldn’t saturate the connection, so a good switch would be fine.

No L2 switch, server NIC or Link Aggregation required. :slight_smile:

havoc, did you get things resolved?

Sorry for the delay… my second Drobo was off-site for a few days so I couldn’t test anything.

yep.

hmmm, but NIC1 gets auto configed with 169.254.121.224 and NIC2 gets auto configed with 169.254.93.178. And my Drobos are 169.254.1.1 and 169.254.1.2. Everything has it’s own working address, it shouldn’t matter if windows can’t figure out which NIC has which Drobo as long as the address is correct in the packet??

My drobos are not auto configed… I have hard coded them to 169.254.1.1 and 169.254.1.2

Actually the problem is that the Drobos are still talking on the 169.254.213.234 address… ( more on this later :slight_smile: )

When I tried using any subnet other than 169.254.0.0 255.255.0.0 (with no DHCP and direct connection to the NICs) the Drobos can’t be found. I believe I worked out why this is… further down…

I know this is always a solution, but as previously stated, if I plug them into my switch the only way my PC can access them is via slow 802.11g since I don’t want to run a cable over my floor from the other room.

[color=#000080]OK… so now on to the new stuff…[/color]
Firstly I tried bridging my to NICs so now windows only talks to the bridge, and the Drobos can see each other… still no good, nothing has changed.

Next I SSHed into my Drobos and found some interesting stuff:

[font=Courier]# /sbin/ifconfig
eth0
Link encap:Ethernet HWaddr 00:1A:62:02:CF:3F
inet addr:169.254.1.1 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:394 errors:0 dropped:0 overruns:0 frame:0
TX packets:288 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:46459 (45.3 KiB) TX bytes:41693 (40.7 KiB)
Interrupt:44

[color=#FF0000]eth0:0[/color]
Link encap:Ethernet HWaddr 00:1A:62:02:CF:3F
inet addr:[color=#FF0000]169.254.213.234[/color] Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:44

lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:56 errors:0 dropped:0 overruns:0 frame:0
TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4048 (3.9 KiB) TX bytes:4048 (3.9 KiB)
[/font]
So it seems each drobo itself is running a networking alias and grabbing 169.254.213.234 in addition to the static IPs.

So I look in some config files:

[font=Courier]# cat /mnt/DroboFS/System/DNAS/configs/network.conf

<?xml version="1.0" encoding="UTF-8"?> 17 Drobo-FS1 STUPID PRODUCTS 1 169.254.1.1 255.255.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0 1500 [/font] and

[font=Courier]# cat /var/network/static.conf
169.254.1.1
255.255.0.0
0.0.0.0
0.0.0.0
0.0.0.0
[/font]
…no mention of the alias config?

Since an alias must be on the same subnet as the main IP address, this probably explains why I can’t connect to the Drobos when I try to put each one on its own subnet. Because the drobo ALWAYS seems to assign itself 169.254.213.234 when directly plugged in to a NIC, this prevents setting a static IP in another subnet…

Armed with this new information I am almost ready to open a support ticket… any other ideas for me first?

Hmm…

When you changed the subnet masks from 255.255.0.0 to 255.255.255.0 did you do this on both NICs and both FS units? If so, that should have worked. If you let the NICs autoconfigure, they’ll still use 255.255.0.0 subnet masks and the two NICs will be on the same subnet (169.254.x.x),

The issue is that even with with the correct subnet information, the routing table determines where traffic destined for a subnet is directed, including on which interface this traffic is directed to. Since both NICs are on the same 169.254.x.x subnet, Windows only routes traffic to one.

That’s why bridging the interfaces let you see both - bridging the interfaces is like a Y-splitter/combiner and Windows treats both ports as the same NIC.

Looks like your 169.254.1.1 static IP is being used by the FS, as there’s traffic reported for it.
Set your NICs to static IPs with 255.255.255.0 subnet mask, un-bridge them, and give it another go.

Last time I tried I set one of my NICs to 192.168.1.7 255.255.255.0, and I set my Drobo to 192.168.1.77 255.255.255.0

The only was I was able to talk to the drobo after this was to plug the Drobo into my switch, and change the config on both my switch and my PC to the new subnet too.

Are you sure? Did you read the bit about the network alias? I would say that the problem is that both Drobos are configured to always use a network alias set to 169.254.213.234 in addition to whatever other static IP you manually set.

Plus I also checked my routing table before the last post and both NICs had the same entries in the routing tables. The way I read it was that a packet for either Drobo should have been sent out on both NICs, but I believe it was going out with the 169.254.213.234 address instead of the Static IP.

I’ve always been able to see both, as long as I use IP addresses in Windows.
The problem is I can’t use the hostname as both [color=#0000CD]\drobo-fs1[/color] and [color=#0000CD]\drobo-fs2[/color] point to [color=#0000CD]169.254.213.234[/color] instead of the IPs I have entered.
( EDIT: I might be able to fix the issue by editing the HOSTS file, but before that I want to confirm this is a bug. )

Yeah there is traffic for my Static IPs because I have been using IPs to connect to the Drobo in windows.

I will give it another crack tonight to change the subnet. I never had SSH on my Drobos the first time, so I am interested to see what the config gets set to when I go to the new subnet…

I’m not entirely sure how interface aliases work in Linux, so… I honestly don’t know.

I think the core “issue” you’re having here is just by design, though I could be wrong.
I believe when using an autoconfig address, FS grabs the first available address.
Problem is, each NIC has the same “pool” of addresses. Hence, when you connect FS1 to NIC1, it gets first available address of 169.254.213.234.
NIC1 registers that 169.254.213.234 is taken, but there’s no way for NIC1 to tell NIC2 “Hey, this address is taken” because the NICs don’t know about each other.
Thus, when you connect FS2 to NIC2, in the world of NIC2, 169.254.213.234 is still the first available address.

At least that’s what I think is going on…

Windows does send some IP-based traffic through some round-robin like mechanism, but when you get to different layers like SMB, it gets funky. Besides, if the goal is to maximize bandwidth, then having Windows send traffic to both interfaces is like using a network hub instead of a network switch.

BTW: Are there any other NICs on this machine? I ask because if you have another NIC that’s using the 192.168.1.x subnet… :frowning: That’s why I edited my post to use 192.168.100.x instead, just to avoid potential overlapss with existing NAT from a router, etc.

Your hostname thing is a bit more complex (NetBIOS over TCP/IP, etc).

Let’s go back to the static IPs and see if you can ping first. Then we’ll tackle the name resolution.

The Drobo manual says the Drobo will use 169.254.213.234 when directly plugged into a PC (at least for the DroboShare) :

[color=#0000CD]Help -> Troubleshooting -> Connectivity ->
“If it cannot obtain an IP address, it will be assigned the default IP address: 169.254.213.234”
[/color]
Which is why I am suspicious that this is by design.

Why would the Drobo grab the first available IP address when I have told it to use a Static IP? If this is true, wouldn’t it still be a bug, even if it is within the Link-local address range?

Nope… should be using Static IP I gave it, otherwise what is the point of allowing me to set it?
Also now that the NICs are bridged they can talk to each other, and both Drobos still register themselves as 169.254.213.234 despite the conflict.

Only 2 NICs, in a bridge, in the 169.254.0.0 255.255.0.0 range. My WiFi is on 10.1.16.0 255.255.255.0 range.

Will still try changing subnet tonight tho, am interested to inspect the ifconfig results from that…

In the “first available” scenario I meant in a non-static configuration. :slight_smile:

Difficult to say with manuals… It could mean that it’s hard-coded to 169.254.213.234, or it could mean that that’s the first available autoconfig address.

Unfortunately bridging gets… weird, and I have no clue how bridging affects Autoconfig addresses.

So, the true litmus test would be:

  1. Configure FS1 to DHCP mode.
  2. Power down FS1
  3. Configure FS2 to DHCP mode.
  4. Power down FS2
  5. Un-bridge your two NICs.
  6. Disable the second NIC (eliminating variables and confusing)
  7. Configure NIC1 to DHCP mode.
  8. Connect NIC1 to empty ethernet switch.
  9. Connect FS1 to same ethernet switch.
  10. Wait for negotiation…
  11. Check FS1’s IP address. Sounds like it should be 169.254.213.234
  12. Connect FS2 to same ethernet switch.
  13. Wait for negotiation…
  14. Check FS2’s IP address.

If the FS units are truly hard-coded to 169.254.213.234, then you should not be able to access FS2 at all via neither shares nor ping.

I’d test it for you, but don’t have two (or even one) FS… :slight_smile:

If it’s hardcoded then it’s not following the RFC. What they probably really mean is “the algorithm we use will choose 169.254.213.234 in the absence of other Drobo FS devices, which is what we expect as we don’t think anyone will try to use auto-configure with more than one FS at the same time.”

I’m with @bhiga here, I think the easiest way to solve this is a separate GbE switch that you hook one NIC and the two FSs to, and just let the autoconfigure work, or set static IPs all round in the say 192.168.100.x/24 space.

For the sake of confirming/denying the hardcoding/persistence, any switch would do.

True…