dashboard manualy device discovery (2.1.1)


can any one explain how does the manual discovery work
and why it says when i insert drobo ip
status: not connected?

i have 2 drobos
1 is on local network
1 is on a different sub-net


I’ve asked DataRobotics support online the same question, the guy basically ignores my question and answered the other question he wanted to answer. Well, I’m guessing it’s for the Drobo with SAN support. iSCSI is probably considered as “direct connection”. SAN devices are different in that it’s more like a stand-alone “computer/server” of some sort.

Manual discovery is what it says on the tin - it allows you to connect directly to a networked Drobo by IP address, rather than relying on its not-always-reliable network auto discovery.

If you have a direct-attached Drobo (essentially anything other than an FS, Pro FS, or perhaps Elite), it will do nothing for you. If you have one of those, you can guarantee Drobo Dashboard will always connect to your Drobo (well, as long as the Drobo is working and you can route to it - but at least you don’t have to rely on flaky auto discovery). It even works across VPN connections and everything.

well i have a droboPro connected locally and i can access it w/o any problems

the other is a drobo FS, i have it on a different sub-net
and if i insert that ip in dashboard nothing happens…

does ne1 have any experience on use of this feature?

I believe (could be wrong) that the auto-discovery relies on broadcast packets and replies which can be filtered out in larger corporate networks.

Manual discovery should let it see a Drobo it may not be “hearing back from” but if the actual communication (broadcast or not) is not route-able across subnets, then it still won’t be able to communicate.

Yup. Bhiga nailed it.

If your router allows defining static routes, you should be able to define a static route from your PC’s subnet to the interface that’s connected to the subnet of the FS.

route table on router:
Key: C - connected, S - static, R - RIP, * - default, ~ - private

  • via xxx.xxx.xxx.xxx,   WAN2
  •   xxx.xxx.xxx.xxx/ via xxx.xxx.xxx.xxx,   WAN2

S xxx.xxx.xxx.xxx/ via xxx.xxx.xxx.xxx, WAN2
C is directly connected, LAN
S~ via, VPN
C~ is directly connected, VPN
C~ is directly connected, LAN is local network is remote network (with drobo fs on it)

i can talk to drobo fs w/o any problems


Tracing route to DROBO-FS []
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms
  2    40 ms    41 ms    39 ms
  3    41 ms    40 ms    43 ms  DROBO-FS []

Trace complete.

i could see drobo with dashboard 2.0.5 with sudppipe.exe (piped brodcast trafic on drobo fs ip)

what kind of new route should i make?

Looks like your route is OK.
Sounds more like the packet types Drobo Dashboard is using aren’t being routed.

Piping the broadcast traffic will work for the single Drobo and single external subnet. It can get confusing and/or flooded if you have many things broadcasting, or if you have more than one subnet you’re trying to mesh together.

Once upon a time I was trying to mesh three subnets together and needed multicast DNS to work seamlessly across…
I know avahi and other things exist, but eventually I gave up. :slight_smile:

Dashboard does use broadcasting to find Drobos on the network. If the routing between subnets is set up correctly, Dashboard should be able to connect to the FS on the other subnet using the manual discovery option. It will not be able to mount the shares; you will have to set up drive mappings to the shares.

well i can mount drobo manualy (netbios) couse i have set up net bios forwarding

i cant setup the dashboard to see the drobofs with proper ip in manual input
it just says not connected

for backup solution im using rsync on server (connected on drobopro) and drobofs and its working like a clock for 5 months already

the issue im having is just 2 monitor both drobos from 1 dashboard, and i cant make it work properly


This hasn’t worked since the first update after May 2013 (not with the FS or B800fs, anyway). If the Drobo isn’t on the same subnet as the PC, even if you enter its IP address and routing is set up properly, it won’t find it.

Are you aware of any plans to reintroduce this capability? It’s an inconvenience right now, since we have Drobos in multiple locations, each on a different subnet, and it would be very helpful to be able to administer them from one machine.