Jumping in a bit late, but we do have a solution for optimal local routing. It is called SmartZones and is available with free and paid subscriptions. To set it up, look under the network tile in the app.pertino.com console. The short of it is that it allows you to identify a subnet and when devices enter that subnet, they choose the local route over Pertino. Here's the blog from when it was introduced.

Now the longer answer.

In a standard deployment, Pertino uses local name resolution and traffic can be routed locally instead of across the Pertino interface. The reason I say "can be" is because it is really tied to race conditions in the protocol (ie LLMNR in Windows). When you add AD Connect to enable your internal DNS to propagate across Pertino, all traffic ends up being forced across the Pertino interface. Smartzones solves this.

Hope that helps!

Post-mortem: http://status.pertino.com/incidents/nk4btw5cdbnb

Just a quick update. I'm sure anyone impacted has been following the status page, but we've been all clear for a few hours now and are closely monitoring all services.

@hubtechagain said:

hey @Josh i'm not sure if your 100% correct about devices that were connected. on one of my networks i've got 14 of 47 devices connected, 15 or so of my offline devices are devices that were connected earlier in the day and haven't been rebooted. i've noticed pertino has been acting a little funky since this weekend. Can we get a little more info as to what's happening?

That's what I've got from engineering and seems consistent from other customers, but more details will follow and I'd expect a post-mortem.

I'd expect all devices to auto-reconnect upon resolution, but I'll post here as soon as we're in the clear.

Adam - welcome to the community and overlay networking!

Not trying to hijack the thread as this appears to be a ZT feature request topic, but since Pertino has come up a number of times, here are the answers:

DNS: PITA. We solved it by using customer internal DNS in AD environments. This is a solution for many customers, but not the end all. Without some type of local integration, overlay networks can never really be used for an internal company network because protocols will not translate.

Free plans: all trials revert to a free network for up to 3 devices; existing free plans with more devices are still live - thanks beta testers! Take the class-action suit to LMI

Chef/Puppet: you can automate Pertino installs with your orchestration tools. We even have a Docker compatible client for cloud-bursting, cross-DC networking

LDAP integration/custom UI: We've got some APIs already available, some in the works. Plan is to make it so if you don't want to, you never have to enter the Pertino console.

Best,
Josh

Hey guys,

I was on a demo but here's the scoop. It looks like any connected devices should be fine, but we're experiencing latency for devices that were previously disconnected and coming online. We've got it up on the http://status.pertino.com/ page.

@JaredBusch Correct. This has been the one downside for AD Connect if you have users that frequent the office. Traffic is forced across the Pertino interface. 430 will allow you to designate "zones" where devices use local routes instead.

@thanksajdotcom In regards to 370, we didn't push auto updates to all clients for subsequent releases. 420 is the first that everyone is getting.

@thanksajdotcom Client updates are automatic, however they do not necessarily get pushed at the same time as releases. The Windows update should go out very soon. In the past, we required manual updates.

@Carnival-Boy Here if you have questions about similarities/differences. Just ping me or email. [email protected]

@thanksaj Try manually upgrading via the ptray on the Windows box.

@thanksaj Do either of the end points have a Pertino version 370 or less? We made enhancements to connectivity for Linux devices post-370.

@thanksaj How long ago did you experience that?

@Ambarishrh Can you email me the email address you used to set up the network? I'll look at the vswitch. [email protected]

@Ambarishrh Have you tried Windows to Windows? We've seen some serious challenges with SMB shares from Windows to Mac. If performance is the same then it could be latency as you're probably connecting to a vSwitch in Amsterdam, but we've even heard good things from users in South Africa, so I'm guessing it has to do with protocol.

@IRJ Sorry, I've been disconnected with a new addition to the family. Have you emailed [email protected]? I've also never gone through the install with a Linux GUI...

@Hubtech No prioritization yet. The only detection is on the receiving side if you're using AD Connect (ie local device without Pertino tries to access local file server - the filter guarantees it receives local address rather than Pertino 50.203.224.x). Nothing to do with routing, more with controlling IPs that are handed out.

I do know of customers that have set prioritization for interface that is used. Supposedly this helps.

@scottalanmiller Your set up is perfect for Pertino since most of your AD servers are offsite, so the system doesn't have to decide how to route...Pertino is the only option.

@JaredBusch

That is the one issue in today's version of AD Connect. There can be suboptimal routing when your Pertino-enabled devices are local to the resources they are accessing (unless you disconnect Pertino on those laptops when they hit the LAN).

A near-term release has additional filtering that detects connectivity based on SSID/network and determines routing.