[upbeat music]
>>THWACKcamp.
[dots beep]
[air whooshes] >>Leon,
we should talk about labs.
You okay with that?
>>I'm always okay talking about labs.
What do you mean?
>>Okay, okay.
So one of the questions or concerns I heard quite frequently
is having lab,
and even if you have a lab as a SolarWinds customer,
you don't have access to gear.
>>What do you mean?
People don't have a spare Nexus switch
or 7200 or something just lying around?
>>No, it's like hat rabbits, no Nexus, right?
[Leon laughs]
Let's go a few steps back.
So basically there's two reasons, I think, for having a lab,
and one would be like a temporary lab.
You wanna try something,
and before you go production, you should test.
You should test before you go into production.
So that would be a temporary lab.
Maybe, I don't know,
apply a change to a device or to the platform.
And the other more involving is probably
you have your production system,
which might be a huge Orion deployment
in a smaller, but temporary lab
where you can really test things all the time.
That is probably interesting
if your organization has to be compliant
to whatever standard.
So you can test stuff small before you go live.
>>Or if you wanna test out automation or alerts
or things like that.
Now, what's interesting about this is
is that this is where GNS3 comes in really handy.
Now, GNS3 is a free tool
that's actually under the SolarWinds umbrella,
and it lets you create virtual networks.
So that problem that you said
about not having spare gear lying around,
you can create a virtual network and then monitor it
with your Orion installation.
Now, I wrote about this like five years ago
when the software was a lot less sophisticated
than it is today where you would put everything
on your laptop.
It would all be right there.
But with cloud, private cloud or public cloud,
I think it's time to update it.
So I did that.
I updated the eBook.
It's available now.
It's gonna give the step-by-step instructions
on how to do everything that we're showing,
and it actually is the basis for this session.
So I think that's a really good way to solve the problem
that, Sascha, you're talking about.
But I think we need to talk about cost for a quick second,
because if we're talking about cloud,
then even if you have budgets set aside for it,
there is gonna be a cost.
So I wanna take a look at
what I set up for this session here.
So here is the actual Azure cloud costs
for my Orion installation and also for the GNS3 environment.
And you can see that it's really not a lot.
I'm spending a little bit over $6 on storage,
$2 on virtual machines, almost nothing on the network.
The real cost was the SQL database
that goes along with Orion,
and it's still not much.
So it can be a really economical way to run a lab.
And you get the flexibility of being able
to put lots of things in and take things out.
It's certainly cheaper than buying real gear.
And the other thing that's really useful about this
is that the installation,
which is another thing that I hear about from people
when they're complaining about the lab,
is that the effort to install Orion or to create the lab
or whatever it is is expensive in terms of time.
Whereas, if you go ahead and install Orion
from Amazon Marketplace or from the Azure store,
it's just click, click, click, and there it is.
It's all pre-configured for you.
>>That is particularly important for the guys
with the temporary labs.
You just need to test something right now.
It's click, click.
Okay, it's a bit more,
but not that many clicks.
And it runs.
That's it.
>>And one of the other things is to keep costs low,
you can just shut everything down
when you're done.
>>Yeah, but there was one thing.
If you shut the instance down
as you monitor stuff in Orion,
you need to unmanage the devices.
I mean, if you enjoy receiving lots of emails,
because device down, interface down, whatever down, fine,
but shut it down.
There's a few things you should consider.
So for example, you can automatically shut down, or sorry,
unmanage the devices in the Orion Platform.
That's like a scheduling feature,
so you can automate it.
You could use PowerShell.
So you can use our API and PowerShell to unmanage a device.
And I'm pretty sure you can use PowerShell even to
start and shut down the GNS instance in the cloud.
>>Yep, exactly.
So there are a lot of PowerShell scripts out there
for automating startup and shut down in AWS or Azure.
And, like you said, the Orion SDK is incredibly flexible
to start or stop services,
or monitoring specific nodes as well.
So you can make that one single thing.
And you can even do it on a time schedule.
>>Okay, so let's have a look at what exactly's available,
the clouds.
So, basically, you just go, as in our example,
to the Azure marketplace,
and you can just start a new search at SolarWinds
and you will see,
and it's pretty much all Orion models available.
So, we have it on the screen right now,
and we can scroll down a tiny bit
and you see all the models, including DPA is there.
Everything is available,
and you can build your own system basically.
We're not showing all of the models today.
That's just a few.
>>No, no, no.
I kept it relatively small,
because we don't have six hours to go over all this.
So we're just gonna do NPM, NCM, and NetFlow,
and we're gonna show those today.
I also wanna point out that the Orion Installer
that you're used to on the earth,
not in the cloud, is the same one that's here.
So if you install just, let's say SAM or NPM,
that doesn't mean you stop there.
You can rerun the installer and add more modules after
if you wanna test additional things out.
So don't feel like you have to pick the perfect right choice
right here, and you're locked in.
You can always extend it in your cloud-based installation
of Orion as much as you could otherwise.
But yeah, we're only showing those three modules
for right now.
So let's dig into how you build this kind of lab.
First of all, I wanna point out that GNS3 is free.
As I mentioned before, you can download it from GNS3.com.
It's really useful if you need to pass,
say, Cisco certifications.
And there's two components to it.
There's a graphical interface,
and there's also the server.
And you can put them all on the same machine,
or you can put them separately here.
What you're looking at is that I have it separately.
I have a Windows machine running the graphical interface.
And then in the PuTTY window,
I have an instance of Ubuntu running the GNS3 server piece.
So that's what I have these two pieces going on.
Then, in another machine, I have Orion running.
And, again, Windows server.
You can see I've got the services running,
and then the database, if you want to have it.
If this is a very short-term thing,
you can put the database local.
But, of course, Sascha,
we don't really like to do that, right?
>>No, I was just about interrupting you.
So, if it's super tiny short test, it's fine.
Same box, SQL Express, but no, no, no.
[Leon laughs]
Put it separated, the database elsewhere.
It's much better.
>>Exactly, okay.
And here, like I said, is the GNS3 environment.
Now the other thing is that to make this work in the cloud,
you're gonna need to open up some ports on the Unix,
the Linux box itself.
So you're gonna have to get into IP tables,
and you're gonna have to put in some--
>>Enough of the penguins.
Just go ahead.
>>Okay, that might be a little bit more technical.
>>Too many penguins.
Okay, fine.
There are some technical details, but it is in the eBook,
so please, don't worry.
There's some extra steps that you need to do,
but we've outlined them perfectly in the book.
You can follow them step by step.
Okay, so let's take a look at what it looks like
when it all goes together.
So here you can see my Orion installation,
and I'm monitoring those same three routers R1, R2, and R3,
very creatively named,
that are running in the GNS3 environment.
And it's all being monitored in Orion
as if it was real gear.
>>So we can now have fun and destroy things?
>>Yes, absolutely.
That's exactly what I wanted to show.
So, here we've got these devices and they're up,
but what happens if I shut them down?
Now this is something you can't do on the online demo.
>>And you shouldn't do in production.
>>Exactly.
And that's the beauty of GNS3,
because these devices don't actually exist,
and they're not actually doing something.
So if I wanna shut down router one,
I can go into GNS3, and just say, "Stop,"
and it's down.
What's interesting is that
the other two are showing warning,
because the serial interfaces,
the ones that connect to that R1 router,
are no longer available,
and so, it perceives a problem there.
But, of course, I can go back to GNS3 again,
and I can bring that router back up.
And there we go.
Everything's back up and running again.
>>So where do we start?
I mean, we probably don't start out of mapping in the cloud.
We start locally, right?
>>Right, okay.
And that's one of the things that I get asked about
when I talk about this
is that cloud compute is expensive,
even if it's not horrifically expensive.
But you can do this locally.
You can install a copy of GNS3 locally on your laptop,
and then you can build your project,
your environment locally,
and then just copy that GNS3 file
up to your cloud-based instance of GNS3.
And as long as you have all of the router images,
you have all the images of the IOS there,
which I only am using one for this.
As long as that's up there too,
it's all gonna run exactly the same way
that you have it built down on earth.
So that's another way to keep your costs low.
I do wanna point out that the more devices
and the larger your environment,
the more memory the GNS3 server is gonna need.
So that's gonna have an impact on your costs as well.
But the really cool part about cloud
is that that's kind of fluid.
It's a little bit elastic, so then if you need more--
>>There's resources, right?
If you would run GNS locally,
it's probably a bit cheaper,
because we don't have the cloud cost,
but it's eating resources and lots of resources.
>>Yeah, I've heard from more than one person
who was studying for an exam, or whatever,
who realized that they needed to buy a new laptop,
just because GNS3 was chewing up so many resources
on their machine that they couldn't keep doing it,
or they needed a separate server, whatever.
There's your trade-off.
So let's take a look at a few other use cases.
I think the first one I wanna do, it's a weird one,
but it shows how flexible this GNS3 environment is
is that you can actually use universal device pollers on it.
For example, the supply state.
I'm just gonna do a quick test here
on all the machines and hit test,
and it's gonna collect the OID.
Now I do have to say that not every object ID is supported.
There's not gonna be any fans.
So the fans aren't gonna work,
even though, theoretically, in a real box, they would,
but you still can use this
to test out universal device pollers before you apply them.
And another use case is that you can do config changes.
You can see here that we've been collecting the configs,
okay fine, just for a day, because it's a demo.
And, again, we wanna keep our cost down,
but you can use it to test backing up configurations.
You can use it to test making configuration changes,
pushing out configuration changes,
all of that stuff.
Also, that's another use case.
Sascha, what do you got?
What kinds of ideas do you have?
>>Well, I would probably use such a lab
to go for the really crazy stuff,
which you would never do in production,
like compliance with auto remediation.
What about that, right?
So what we see here is a rule,
which I defined earlier,
and we will just go to manage policy reports.
Leon, can you just click?
You got the mouse there.
Perfect.
And manage rules.
>>Manage rules.
>>And search for Telnet.
I love it when I just say something,
and Leon makes it happen.
That's perfect. [Leon laughs]
So, there's the rule, Telnet.
Oh no, let's have a quick look at it.
Select edit.
There we go.
What we see here is, basically, a very simplified rule,
because we're in a lab,
so, basically, transport input Telnet SSH.
If this is found, we are not happy.
We can use it the way it is.
If we would like it to be a little bit more complicated,
we can use Regex, but Regex and me are kind of at war,
so I leave it out here.
And if you look at the bottom, [Leon laughs]
there's now an auto remediation,
and that's where things get tricky.
So, if we find the condition,
the first condition with Telnet,
we will automatically remove Telnet again.
So we just go to the VPI line
and issue the SSH only command.
And, basically, if we know we'd go to the router,
we're not doing this right now,
but if you would change the configuration,
the next time we pick it up,
it would be automatically fixed.
And you can be very, very creative
with your remediation words.
>>Right, and, again, just to emphasize the idea here is that
one of the reasons why I hear a lot of IT folks
and network engineers not try out automation,
automated remediation, is because they're afraid
of something going wrong.
They're afraid of what might happen in production.
Here's a chance to work in your GNS3 environment,
which is fake and doesn't actually exist,
and try remediation rules, see what the impact is
across the entire environment
Poke at it.
Shove it.
See if it falls over,
and once you're really comfortable with it,
that's when you can move it into production.
>>All right, what else could we do?
>>There's also NetFlow.
>>NetFlow is a good example.
We can just try and generate some flows.
Obviously, if we look at the GNS3 instance,
we need something that's actually generating flows,
not just the router sitting there.
We would just set it up and router using the console.
And we will use Cisco as an example.
It has like five lines of configuration or so.
And we should see it here on the screen.
And we should also see it's showing up as a flow source
somewhere else.
So what else?
What else could we do?
>>I think at this point,
it's pretty clear that GNS3 is giving you
a real network environment to play around with.
So, for example,
if you wanna test out firmware upgrades,
you can do your firmware upgrades
and push them to your GNS3 environment.
Make sure that you haven't messed anything up,
and see how that works.
We talked about testing configuration scripts.
You can do what's called leaf and branch
where you're pushing out the configuration
to your furthest devices and then the next string
and the next string so that you don't cut yourself off
from that farthest branch by accident.
You can also install server-based monitoring
like SAM, for example,
and GNS3 will let you create virtual PCs
inside the GNS3 environment
that's generating traffic, running an application,
and you can practice monitoring it
in that environment, again, with the safety net
of not actually breaking anything that's in production.
So those are some additional use cases
that you may want to explore.
>>I have an idea.
So, we could actually run it.
It is possible to run an Orion server in the GNS instance.
The performance is not so great,
but it is possible. >>Yes. [laughs]
>>That opens like a can of worms.
Okay, so you could start playing with HA, for example.
So within, within Orion HA, from totally inside the box.
Great idea.
>>Right.
And that's the kind of thing where that 30-day
unlimited license for a demo probably comes in handy,
'cause you can keep on installing it.
You can keep on trying it until you get it right.
But also 30 days of really intense work
is usually what you need to shake any of the bugs out
before you try it at your next level of implementation.
>>We have seen GNS.
We have seen Orion,
but what I'm missing is the piece that gets it all together.
Let's have a look at Azure.
>>Right, so on on the back end on the Azure portal,
it's pretty straightforward.
I've got the Orion VM.
The GNS3 virtual machine, the server,
and GUI are separate devices or separate instances.
And then there's a bunch of associated items
like storage and the network card.
In cloud, everything gets broken out as a separate element,
I guess, is the best way to put it.
But it's all right there.
And as we showed earlier, installing it is just a matter
of going into the marketplace
and saying click, yes, one of those, one of those,
one of those, and there you have it.
>>We could make it hybrid too, right?
>>Yeah, you could absolutely have some parts of this
in the cloud, and then monitor some stuff
that's on-prem, or in another instance.
You'd have to build VPN tunnels and things like that,
but it's definitely doable.
Well, hopefully that's enough to get everyone excited
about trying this out.
>>If not, it's too bad that we are running out of time.
>>Right.
And if you're interested,
but you really aren't sure where to start,
I wanna remind you that there's an eBook
that walks you step-by-step through creating this.
And of course, I'll be blogging about this as well.
>>And we are looking forward to your questions,
well, at least, Leon does.
[Leon laughs] Anyway, thanks for joining us.
Yeah, thank you very much.