One Customer - Multiple Sites (and Appliances)

[Kurt Schumacher]

How to integrate multiple sites and appliances under the same customer account?

Customer

- Site 1

- Site 2

..

TIA,

-Kurt.

[Marcos Hernandez]

The support for Multisite in Thunderbolt has been requested in the past. The feature ID I am using to track it is:

PF-34

Multisite support  for Thunderbolt

It is currently low priority on our list and NOT mandatory for First Service Availability (FSA). We will reprioritize based on feedback , of course.

Thanks a lot Kurt.

Marcos

[Kurt Schumacher]

Priority depends on the ability to cover multiple VLAN from the appliance. Trouble is,multiple VLAN are already deployed in the more advanced SMB networks. This requires a trunking port to connect the appliacne, a VLAN configured for the cloud traffic with gateway, and the ability to cover this and all other VLAN. Drawback: The appliance configuration becomes slightly more complex of course - there might be DHCP available on the different VLAN...

[Marcos Hernandez]

The feature I mentioned earlier refers more to geographically disperse sites being treated as a single entity in Thunderbolt.

Multiple VLAN support is mandatory for FSA. We have struggled with this implementation from the beginning, but we keep making progress. More recently, Engineering found some challenges in the relationship between the PHY in the PLG-1000 and the way  tagged traffic is passed to (or treated by) the OS (Linux). Our approach is exactly the one you mention: connect the appliance to a dot1q trunk and essentially let it ARP and get an IP on all broadcast domains known to the trunk port.

Things we will consider before formally supporting this feature:

1) Scalability. i.e . how many VLANs? how many devices/VLAN?

2) CPU impact on TBA

3) UI implications, i.e. will things look too cluttered? (maybe the way to go here is to just recommend that users rely on the dashboard view)

4) 3rd-party switch support policy, i.e. will TAC take a case to help a customer connect the TBA to a 3rd party switch?

Plan B in case we find that multiple VLANs, as stated above, are impossible to achieve, is to use a manual discovery mechanism that allows the Thunderbolt user to enter the IP address range he wants discovered, very much like your traditional SNMP probing application. I am not a big fan on this, but it could do the trick. We'll see.

Thanks a lot!

Marcos

[Kurt Schumacher]

Have not considered SheevaPlug Kirkwood (RGMII to 88F1116R) GbE driver VLAN limitations, it was simply not intended to become a network management appliance probably.

1) Scalability. i.e . how many VLANs? how many devices/VLAN?

device * VLAN = constant ... probably the most simple one is to limit the total number of suported nodes (devices). It's not nice to have low limits i.e. on the number of VLAN, even if I'm convinced there won't be hundreds in our customer focus fir Thunderbolt (but we never know), or of the number of devices on the same VLAN, as not all SMB/SME have perfectly segmented networks to start with TB.

2) CPU impact on TBA

VLAN handling (depends on how it can be implemented on the MAC level) should not create a big overhead, so 1) is likely the limitation.

Then, the binary compatible 88F6282 is reality, the 1.6 GHz SoC is available in small batches, with volume availability starting soon. Speed-up variants wit 1.8 and 2.0 GHz should be in-scope for the expected time schedule for the TBA volume production. So "more" is always possible.

I don't expect the CPU core is continuoulsy on 100%. Not convinced the SheevaPlug (sold in European and U.K. plug versions, tough) comes near to the European energy saving standards (for example energy efficiency level V or higher for external power supplies) -  both plugs run much to hot in my opinion - but that's a different story.

3) UI implications, i.e. will things look too cluttered? (maybe the way to go here is to just recommend that users rely on the dashboard view)

Allow a full (all VLAN), per VLAN groups, and per single topology views.

Can't resist now ->>>>> http://www.nagvis.org/ this simple Flash UI is ... limited.

4) 3rd-party switch support policy, i.e. will TAC take a case to help a customer connect the TBA to a 3rd party switch?

Up to the level fo what is required, and how to check if things are correct from the TBA side.

[Marcos Hernandez]

NagVis is a very interesting product, I had not heard about it. Little secret: we run Nagios for most monitoring and probing functions ;-)

I will take a look in more detail. Thanks,

Marcos

[Brian Bergin]

Marcos,

Several of our customers run VPNs between locaions, some to as many as 5 or 6.  IMHO, this really needs to be higher than "low" priority.  Is it "critica", probably not, but I'm betting a decent % of potential sites will require something like this.

BTW, if you'll fix the scrolling, what you have now is terrible comapred to what we had on Drop 1.  If you're going to use Flash then having to use scroll bars stinks.  At the very least let us CTRL-click to drag the screen around, but personally, I'd rather have to CTRL-Click to drag wile selecting multiple devices than to assume we'd rather just click and drag to do it.  After all, how often will we really need to modify multiple devices vs. how often will we need to scroll around in the GUI?  I'm betting it's very low on the multiple select and very high on the day-to-day moving around.

Finally, if you're worried about clutter, why not list it like this in the Global Dashboard:

• Customer 1 (click to expnd site locations)
  • Customer 1 site 1
  • Customer 1 site 2
  • Customer 1 site 3
  • etc..
• Customer 2
• Customer 3
• etc...

Then in each specific customer Topology have "shortcuts" to move between sites as well a button to show the entire topology even if it contains a large # of devices.

[Kurt Schumacher]

Can't agree more regarding to Flash (with Flex or whatever is behind) badly sucks, and is out - Web 2.0 is in. Flash does badly adopt to the user standards that can differ widely, depending on the platform used to run the browser. Any scrolling in Flash will always look and feel different, and the usability is not very consistent.

Yes, the structure you show is what I had suggested in the original posting. This can still lead to a cluttered views - and of course this problem is solved in about a dozen open source NNM system for a long time already.

[Marcos Hernandez]

Thanks Brian and Kurt. I have bumped the priority of this feature based on your feedback.

Marcos

[Kurt Schumacher]

My dear friend Marcos,

I'm glad to help. This link to NagVis was selected intentional - thus my "can't resist* comment! Nagios was not really a secret to me, no - it's very obvious from the way the network device discovery works - respective does not work the way we need it. What might be feasible for a NNM must not be good enough for what we want to achieve here...

Regards,

-Kurt.

[Michael Holloway]

Just a quick clarification, TBA runs nagios as a basic engine to invoke monitoring sensors and issue events, but isn't used in discovery.  We do use some stock nagios plugin sensors, as well as plugins we've developed in-house.

-mike

[Kurt Schumacher]

Even better - so the discovery (that works very similar to Nagios anyway) can be adopted better to the SMB requirements.

[beowulfs]

sorry to resurrect an old thread, but me too me too. multisite vpn support.

[Brook Powers]

I agree with all of the above.

First, 20-25% of my clients have multiple locations (between 2-4 sites) connected by VPN.

Second, the flash/flex interface is just awful, slow, awkward and not intuative or efficient.

[Marcos Hernandez]

As Michael mentioned in that other thread, the Thunderbolt UI is currently undergoing a major usability redefinition. I am not sure we will be able to get rid of Flex though, but the consistency and ease of use will be there.

With regards to VPN support, we are looking at this from a visual/presentation standpoint. A functional discovery mechanism across VPNs would require, in most cases, a routable discovery protocol (like SNMP). Things like CDP, Bonjour, LLDP and DHCP, just to name a few, would not readily work across sites. It is safer to have 1 appliance per site, and then provide a way to logically connect such sites in the Portal.

All that said, you can sort of represent a multisite network today. All we need in Thunderbolt to monitor an asset is IP connectivity to it, regardless of location. So if you manually add devices to your Topology, you can enable pretty much any monitor, with the exception of the DHCP one, unless you use a helper address to change the DHCP-related broadcasts into unicast requests that traverse the WAN. This you do on your routers though.

Notice that if you truly have a L2 VPN, then one appliance should theoretically do the trick. L2 VPN's are very uncommon in the SMB though. L3 VPN's are easier, faster better.

Thanks,

Marcos