Remote Locations for Customers

[danny]

Hello Marcos,

I have a customer that has multiple locations, do I have to create a new customer for every location or will there be a way to create remote locations for a customer?

[Marcos Hernandez]

Hi Danny,

You have to create one customer record for each location. We will allow a more logical representation of a multisite network in the future, but the notion of one appliance per site will remain. Things like accurate discovery, remote cross-launch, local access to device, etc., could be compromised over a VPN.

Thanks,

Marcos

[Brian Bergin]

I thought the original discussions focused on allowing discovery across VPNs?  Has that been removed?  I don't know about anyone else, but I'd sure love the ability to put one TBA in a customer with multiple locations and have it show me devices from all their locations.  Even if there were a token fee for each new location, it'd be better than having to manage 5 different TBAs for 5 different locations.  We, for example, have a customer, #1163, who as several remote locations, none with more than 4 or 5 devices (PCs & printers for point of sale) so the cost of a TBA would be prohibitive at the remote locations but they'd be much more likely to go for it if I could use one to manage all.

[Marcos Hernandez]

Hi Brian,

With our current architecture, this is going to be nearly impossible to deliver. Here are the reasons:

1) Many of the discovery protocols that we support wouldn't work over a routed VPN tunnel or  DMVPN environment (some of them don't even work across VLANs!)

2) A cross launch to a remote location would have to go through the main location

3) You wouldn't be able to take advantage of the "free" DDNS-like service you get with each TBA site:

proxy.X.YYYY.ciscovar.com

should resolve to the WAN IP of the customer site.

"X" is a site number (currently always set to "1") and "YYYY" is your customer id.

Finally, for very small networks you can, today, add the devices manually. All the Thunderbolt features should work fine as long as you have IP connectivity to the target host.

Thanks,

Marcos

[Kurt Schumacher]

1) Many of the discovery protocols that we support wouldn't work over a routed VPN tunnel or  DMVPN environment (some of them don't even work across VLANs!)

VLAN a must - and is logically at least rather easy to achieve using a trunk port, or a port configured to the appropriate VLAN with tagging. Unless I'm wrong, we discussed that before. Key is to make all VLAN available on the port where the TBA is connected - and the TBA is able to scan all 409x valid VLAN IDs. We understood your RD enhanced and fixed the Marvell SoC related issues and limitations on VLAN support.

No VLAN support is a show stopper for Thunderbolt.

The discovery over VPN (i.e. for small remote sites) is almost a must in the targeted market, semi-automatic is ok, and the Cisco Discovery is certainly able to handle a higher granularity at the remote site whee available. The network management systems we had deployed 25 years ago were able to discover almost every device already.

The "free" DDNS feature including the dedicated remote access is not required - and might be not deisred due to security considerations, too.

-Kurt.

[Marcos Hernandez]

Yes, the multiple VLAN feature is one that is taking us some time to deliver. And you are right, as previously discussed, it will use a trunk connection to a Cisco switch (the one we will "officially" support).

The "DDNS-like" feature is one that people seem to like. It allows a fixed name mapping for situations where the public IP of the site changes (majority of consumer-grade broadband access).IS you security concern that someone might find out which IP you are using?

[Brian Bergin]

"Free" DDNS is moot.  It's not a security risk.  Anyone sending an e-mail discloses the IP of their LAN so this isn't an issue (though we won't use it, it's too complicated to remember).

[Kurt Schumacher]

The "DDNS-like" feature is one that people seem to like. It allows a fixed name mapping for situations where the public IP of the site changes (majority of consumer-grade broadband access).IS you security concern that someone might find out which IP you are using?

Misunderstanding. You mentioned DDNS as a reason to deploy additional TBA to other (small) sites of the same customer. The security implication is not the public IP itself - but the security design in place with many installations, allowing incoming connections from the wild Internet to one or very few central sites only. As well, many installations restrict the outgoing traffic, i.e. to streamline Web proxy infrastructure, too.

-Kurt.

[Marcos Hernandez]

I understand now Kurt. The multisite design in that situation is not controlled by Thunderbolt, but by whatever VPN topology you pick (full mesh, DMVPN, etc.)