WEBVTT
00:00:00.280 --> 00:00:01.110
Can you guys hear me okay?
00:00:01.110 --> 00:00:02.100
>> Yes.
00:00:02.100 --> 00:00:03.230
>> Okay, so let's get started.
00:00:03.230 --> 00:00:07.140
We have a jam packed session so
I want to get over the agenda and
00:00:07.140 --> 00:00:09.460
also just get the show started.
00:00:09.460 --> 00:00:12.710
So I'm Yu-Shun Wang, I'm Program
Manager in Azure Networking.
00:00:12.710 --> 00:00:15.240
In today's session we're
going to discuss about
00:00:15.240 --> 00:00:17.460
virtual appliances in Azure.
00:00:17.460 --> 00:00:20.770
So these are third party virtual
appliances running on the Azure
00:00:20.770 --> 00:00:22.580
platform and
given I'm from the networking site.
00:00:22.580 --> 00:00:26.640
So the key focus today will be on
the networking virtual appliances
00:00:26.640 --> 00:00:30.300
rather than general appliances and
there will be a lot more out there
00:00:30.300 --> 00:00:32.820
but today we're gonna
focus on network.
00:00:32.820 --> 00:00:34.950
So this is the agenda today.
00:00:34.950 --> 00:00:37.740
So as you can see, I'm gonna go
over a little bit very quickly
00:00:37.740 --> 00:00:41.440
regarding what is virtual
appliances, what Azure is doing to
00:00:41.440 --> 00:00:45.840
help partners onboard their Virtual
Appliances onto Azure platforms, and
00:00:45.840 --> 00:00:48.680
from the customer perspective
why you would care, and
00:00:48.680 --> 00:00:50.650
go over a little bit of
the platform capability.
00:00:50.650 --> 00:00:55.060
But as you can see, the majority of
today's agenda is that we invited
00:00:55.060 --> 00:00:58.230
a set of our ecosystems
partners to be on stage,
00:00:58.230 --> 00:01:00.930
showcasing their virtual
appliances running on Azure.
00:01:02.290 --> 00:01:06.095
And, definitely one thing to say is
this is not an exhaustive list, but
00:01:06.095 --> 00:01:09.910
then we are working closely with
the partners on today's agenda and
00:01:09.910 --> 00:01:11.940
also several others that
couldn't make it today and
00:01:11.940 --> 00:01:14.180
we just couldn't include
everybody in the session.
00:01:14.180 --> 00:01:18.670
So, okay, so
what is Network Virtual Appliances?
00:01:18.670 --> 00:01:21.610
So, virtual appliances are really
just virtual machines performing
00:01:21.610 --> 00:01:22.840
certain functionality.
00:01:22.840 --> 00:01:25.990
And in this case, network
functionality, such as Firewall,
00:01:25.990 --> 00:01:31.210
IDS, IPS, WAN optimization or there
Maybe stop running as load balancer
00:01:31.210 --> 00:01:34.850
and definitely a lot of the security
focus appliances, right?
00:01:34.850 --> 00:01:38.230
One trend that we have been
seeing is that more and
00:01:38.230 --> 00:01:41.140
more a lot of the virtual
appliances actually one appliance
00:01:41.140 --> 00:01:42.630
performs several functionality.
00:01:43.820 --> 00:01:46.800
Half of this stuff listed here,
actually they can all do VPN,
00:01:46.800 --> 00:01:49.810
they can all do certain part
of firewall functionality but
00:01:49.810 --> 00:01:53.430
then, I mean most of the names
that you recognize, they kind of
00:01:53.430 --> 00:01:55.790
have a little bit of affinity
to one thing than the other.
00:01:55.790 --> 00:01:59.160
So we kind of did a little bit of
the categorization just kind of to
00:01:59.160 --> 00:02:01.940
segment and to focus on different
part of the functionality.
00:02:03.080 --> 00:02:05.630
So one thing to note is that
00:02:05.630 --> 00:02:09.030
most of this appliance platform
actually runs on Linux and FreeBSD.
00:02:09.030 --> 00:02:11.830
So I want to take this
opportunity to highlight that.
00:02:11.830 --> 00:02:15.966
From the Azure perspective, we are
actually open to all platforms and
00:02:15.966 --> 00:02:19.546
overall from the platform side of
things, we're trying to make Linux,
00:02:19.546 --> 00:02:24.270
FreeBSD, all the non-Windows
platform also as first class citizen
00:02:24.270 --> 00:02:25.630
on the Azure platform.
00:02:25.630 --> 00:02:27.690
So right now,
especially for FreeBSD,
00:02:27.690 --> 00:02:30.500
this is actually
kind of a new thing.
00:02:30.500 --> 00:02:34.310
From hypervisor perspective,
FreeBSD has already been supported.
00:02:34.310 --> 00:02:38.390
But I think, most of you may know,
FreeBSD is not
00:02:38.390 --> 00:02:41.000
highlighted as a supported platform,
and we are going to change that.
00:02:41.000 --> 00:02:43.010
Definitely from
the appliance perspective,
00:02:43.010 --> 00:02:45.640
we are going to onboard several
of the FreeBSD base appliances.
00:02:46.950 --> 00:02:50.260
Now why do you want virtual
appliances in Azure?
00:02:50.260 --> 00:02:53.730
So we've been talking about bringing
your own network into Azure.
00:02:54.800 --> 00:02:57.360
Definitely virtual appliances
is actually part of your
00:02:57.360 --> 00:02:58.300
premises network.
00:02:58.300 --> 00:03:03.040
They run as physical form vector
some may be in the virtual edition.
00:03:03.040 --> 00:03:05.620
On to Azure everything
from the customer
00:03:05.620 --> 00:03:07.700
has to be run as virtual machine.
00:03:07.700 --> 00:03:11.260
And most appliance vendor actually
already have virtual edition
00:03:11.260 --> 00:03:13.760
of their appliances running
either on HyperV or
00:03:13.760 --> 00:03:16.230
on some other hypervisor platform.
00:03:16.230 --> 00:03:19.450
The goal here is that we are
actually working with the appliance
00:03:19.450 --> 00:03:22.590
vendor, adapting to Azure
platform running on HyperV
00:03:22.590 --> 00:03:25.590
that the Microsoft Azure is
actually using and, of course,
00:03:25.590 --> 00:03:27.820
adapting to the networking
functionality so
00:03:27.820 --> 00:03:30.600
you have multilink maybe
forwarding and routing.
00:03:30.600 --> 00:03:32.250
All those kind of
things to run on Azure.
00:03:33.550 --> 00:03:37.750
And even though Microsoft will
provide some of the functionality,
00:03:37.750 --> 00:03:40.530
either in a form of
platform capability,
00:03:40.530 --> 00:03:44.390
platform features, or even
Windows Server as a virtual machine.
00:03:44.390 --> 00:03:49.170
But we do understand that from your
perspective whatever you run on
00:03:49.170 --> 00:03:52.100
premises actually if we can
enable you to run the same thing
00:03:52.100 --> 00:03:55.790
in the Cloud the consistency
of management and
00:03:55.790 --> 00:04:00.510
also you don't need to do another
training for your IT staff.
00:04:00.510 --> 00:04:02.240
That's actually where
we're coming from.
00:04:02.240 --> 00:04:04.480
Really bring your own network,
bring your own appliances,
00:04:04.480 --> 00:04:05.976
bring your own workload into Azure,
00:04:05.976 --> 00:04:09.399
either you run completely in
Azure or in a hybrid fashion.
00:04:10.670 --> 00:04:15.570
And finally, one thing I do want
to address, is that some of you
00:04:15.570 --> 00:04:19.490
may be thinking about yes, Microsoft
Azure is running Hyper Visor so
00:04:19.490 --> 00:04:21.300
I get a virtual appliance in batch.
00:04:21.300 --> 00:04:24.165
Can I just take the image and
run on Azure?
00:04:24.165 --> 00:04:26.615
Unfortunately there are some
constraints that just because you
00:04:26.615 --> 00:04:30.145
run on HyperV doesn't necessarily
mean it will run on Azure.
00:04:30.145 --> 00:04:33.035
So what we are working with
partner is that we are onboarding
00:04:33.035 --> 00:04:37.052
partner virtual appliance images
via the Azure certified program.
00:04:37.052 --> 00:04:39.232
So from the customer side,
you can go through the portal,
00:04:39.232 --> 00:04:41.412
you can search
the Azure Marketplace.
00:04:41.412 --> 00:04:44.802
That is the supportive way of
getting virtual appliances
00:04:44.802 --> 00:04:45.822
running in Azure.
00:04:45.822 --> 00:04:46.984
That is just one thing
to know about that.
00:04:52.579 --> 00:04:54.279
Oh, sorry.
00:04:55.450 --> 00:04:59.650
Transition is a little
bit slow here.
00:04:59.650 --> 00:05:02.700
Okay there, so
I'm not gonna go over this slide.
00:05:02.700 --> 00:05:06.140
So basically throughout
the week we have several
00:05:06.140 --> 00:05:09.120
Azure networking session talking
about the new networking
00:05:09.120 --> 00:05:11.940
functionality that actually we
are releasing in this ignite.
00:05:12.960 --> 00:05:16.140
One thing to highlight is we
finally have user-defined routes.
00:05:16.140 --> 00:05:20.810
This is a platform capability to
let you define routing table to
00:05:20.810 --> 00:05:24.820
direct your traffic, either in and
out of the Azure data center, or
00:05:24.820 --> 00:05:27.970
across subnet inside
of Azure data center.
00:05:27.970 --> 00:05:31.770
So that particular capability
enables a new range of virtual
00:05:31.770 --> 00:05:35.760
appliances such as firewall gateway,
VPN devices to run in Azure.
00:05:35.760 --> 00:05:37.690
So I do want to highlight that and
00:05:37.690 --> 00:05:40.030
we have a session tomorrow
morning at 9 o'clock.
00:05:40.030 --> 00:05:42.660
Actually we will chew you down
into some of its capability.
00:05:42.660 --> 00:05:45.570
So I think we have a 9 o'clock
talking about using a different
00:05:45.570 --> 00:05:48.890
route and virtual Network Security
and we have another session
00:05:48.890 --> 00:05:53.245
at 3 o'clock regarding the hybrid
part of the capability.
00:05:53.245 --> 00:05:57.850
Okay so the next resource I'm just
00:05:57.850 --> 00:06:01.970
going to flash through the key
scenario we're focusing on today,
00:06:01.970 --> 00:06:05.330
Application Delivery Controller,
or low balancer.
00:06:05.330 --> 00:06:07.790
So this is very straight forward.
00:06:07.790 --> 00:06:10.660
You have workload coming
either from the internet or
00:06:10.660 --> 00:06:15.470
from the private side either
from premises into Azure.
00:06:16.820 --> 00:06:19.260
And ADC, or Load Balancer,
00:06:19.260 --> 00:06:23.350
basically direct the traffic based
on the policy rule that you specify.
00:06:23.350 --> 00:06:25.030
Whether you're doing load balancing,
or
00:06:25.030 --> 00:06:27.260
you're directing traffic
based on the application, or
00:06:27.260 --> 00:06:30.880
based on Layer 7, based on content,
and all those kind of stuff.
00:06:30.880 --> 00:06:32.400
And we have a list of partner,
00:06:32.400 --> 00:06:35.780
that some already onboarded into
Azure Marketplace and several of
00:06:35.780 --> 00:06:39.790
them is actually going to showcase
their virtual appliances today.
00:06:40.950 --> 00:06:43.482
In the second scenario
we're highlighting is.
00:06:48.103 --> 00:06:50.715
The second scenario we're
highlighting is WAN optimization.
00:06:50.715 --> 00:06:52.695
We're going to stay closer
because the clicker is not
00:06:52.695 --> 00:06:53.965
working very well.
00:06:53.965 --> 00:06:57.415
The second scenario we're
highlighting is WAN optimization.
00:06:57.415 --> 00:07:00.245
So WAN optimization is
actually a very interesting
00:07:00.245 --> 00:07:01.660
category of appliances.
00:07:01.660 --> 00:07:04.200
Because it work in a truly
hybrid fashion, right?
00:07:04.200 --> 00:07:08.380
So they are optimizing your WAN
traffic storage application or
00:07:08.380 --> 00:07:11.170
other application HTTP
level kind of workload.
00:07:11.170 --> 00:07:14.158
Typically they will have one
appliance, either virtual or
00:07:14.158 --> 00:07:17.323
physical, on premises and
another happened in the cloud, and
00:07:17.323 --> 00:07:20.330
they worked together to compress or
optimize the traffic.
00:07:20.330 --> 00:07:24.864
And riverbed is with us today
to showcase riverbed still had
00:07:24.864 --> 00:07:29.671
running both on prem and Azure and
also SteelCentral to provide
00:07:29.671 --> 00:07:33.403
a good showcasing of
the telemetry or analytic.
00:07:33.403 --> 00:07:37.082
Now, the last scenario is actually
the new one that we really
00:07:37.082 --> 00:07:39.430
are highlighting in
this [INAUDIBLE].
00:07:39.430 --> 00:07:40.890
Security appliances such as,
00:07:40.890 --> 00:07:45.280
Firewall, IDS/IPS,
customers cannot do this before
00:07:45.280 --> 00:07:49.800
because we did not have the platform
forwarding routing functionality.
00:07:49.800 --> 00:07:51.850
Now with user defined routes,
00:07:51.850 --> 00:07:54.540
customers can actually
direct the traffic.
00:07:54.540 --> 00:07:57.730
You can say, I can set a default
route, any traffic that's not
00:07:57.730 --> 00:08:01.180
flowing between my virtual machine
actually goes through the inspection
00:08:01.180 --> 00:08:04.970
devices, such as firewall,
IDS/IPS, so you can do that now.
00:08:06.880 --> 00:08:12.420
Now, that's it so, for the next,
I guess, 50 some minutes, we'll
00:08:12.420 --> 00:08:16.330
invite partner to be on stage, show
casing their virtual appliances.
00:08:16.330 --> 00:08:18.760
So, I do want to set a little
bit of the ground rule,
00:08:18.760 --> 00:08:21.780
because we have many partners
that will be on stage.
00:08:23.630 --> 00:08:26.860
So I'm going to ask you guys to hold
off your questions until the end and
00:08:26.860 --> 00:08:29.900
we ask all the partners to stay
here so you can ask questions
00:08:29.900 --> 00:08:33.360
individually to the appliance
vendors of choice here.
00:08:33.360 --> 00:08:36.625
And the second thing is
some of the appliances here
00:08:36.625 --> 00:08:38.295
are already onboarded to Azure.
00:08:38.295 --> 00:08:41.795
And some are actually in
the process of getting onboarded.
00:08:41.795 --> 00:08:44.845
For example, we just released
the routing feature and
00:08:44.845 --> 00:08:47.715
most of the firewall vendor, they
have to build on top of the routing
00:08:47.715 --> 00:08:51.652
feature before and do the testing,
making sure everything runs well.
00:08:51.652 --> 00:08:55.062
So you should expect to see
basically in the next couple
00:08:55.062 --> 00:08:58.222
of months some of these vendors will
have their virtual prices popping up
00:08:58.222 --> 00:08:59.572
in Azure Marketplace.
00:08:59.572 --> 00:09:01.302
So just want to set it
right expectation here.
00:09:02.332 --> 00:09:05.402
So we're going to start out talking
about Application Delivery Control,
00:09:05.402 --> 00:09:06.302
and Load Balancers.
00:09:06.302 --> 00:09:07.932
And so for the first one,
00:09:07.932 --> 00:09:11.470
we're inviting Citrix to be on
stage to showcase their stuff.
00:09:11.470 --> 00:09:11.970
Karl.
00:09:16.975 --> 00:09:18.660
>> Thank you Yu Shan,
Good morning everyone.
00:09:20.440 --> 00:09:22.425
Okay, just wanted to make
sure you could hear me.
00:09:22.425 --> 00:09:25.360
V.J. come on up and
we'll get started here.
00:09:25.360 --> 00:09:29.560
As Ushan said, we are an application
delivery controller, NetScaler.
00:09:29.560 --> 00:09:31.870
Many of you probably know us.
00:09:31.870 --> 00:09:35.090
It's funny as I meet people Citrics
will go, oh go to meeting, which
00:09:35.090 --> 00:09:38.320
is obviously one of our offerings,
they see it on TV and what not.
00:09:38.320 --> 00:09:40.870
Or they think the virtualization
as it happens in desktop.
00:09:42.880 --> 00:09:44.490
We also have a large
networking division.
00:09:44.490 --> 00:09:46.868
We will also be working
on WAN optimization, but
00:09:46.868 --> 00:09:49.481
we're going to talk briefly
about NetScaler today.
00:09:49.481 --> 00:09:53.451
As Yu Shan mentioned, allot of
the features and functionality we'll
00:09:53.451 --> 00:09:57.283
show we do that one thing that we're
not going to show today that I did
00:09:57.283 --> 00:10:00.780
want to highlight is our NetScaler
gateway which sits in front
00:10:00.780 --> 00:10:04.211
of XenApp or XenDesktop to do
gateway functionality for that
00:10:04.211 --> 00:10:08.150
providing secure granular control
to deliver those applications.
00:10:08.150 --> 00:10:14.500
I was gonna go 25 minutes just to
make sweat, but I'll not do that.
00:10:14.500 --> 00:10:16.240
We're gonna bring VJ up.
00:10:16.240 --> 00:10:19.710
And he's going to show you a demo
not on the gateway functionality,
00:10:19.710 --> 00:10:22.550
but sort of the traditional
functionality that we're
00:10:22.550 --> 00:10:24.440
doing is in ADC and load balancing.
00:10:24.440 --> 00:10:26.760
He'll talk about his
topology here for a second.
00:10:26.760 --> 00:10:29.113
One thing I did want
to comment on that
00:10:29.113 --> 00:10:32.140
did mention is where we are as
far as a marketplace place.
00:10:32.140 --> 00:10:34.280
If you go today to
the marketplace we're not there.
00:10:34.280 --> 00:10:37.780
We're literally, I think a lot
of my vendor brethren here were
00:10:37.780 --> 00:10:40.260
sitting in some staging
servers waiting to publish.
00:10:40.260 --> 00:10:41.450
So we're right there.
00:10:41.450 --> 00:10:43.680
So we won't be months,
we should be days.
00:10:43.680 --> 00:10:46.360
So please keep a look out for
us in the marketplace.
00:10:46.360 --> 00:10:49.950
And with that I will turn it
over to Vijay and let him go.
00:10:49.950 --> 00:10:50.450
>> Thanks Carl.
00:10:54.316 --> 00:10:56.557
[INAUDIBLE] Slides first.
00:10:56.557 --> 00:10:57.358
>> Yeah, sorry.
00:10:57.358 --> 00:11:03.236
So we're able to deploy
NetsScaler VPX on Azure and
00:11:03.236 --> 00:11:08.280
here's a demo topology that we have.
00:11:08.280 --> 00:11:11.940
We have highly available
set of netscalers running
00:11:11.940 --> 00:11:13.750
within a Cloud service.
00:11:13.750 --> 00:11:16.710
So we have a bunch
of different pools
00:11:16.710 --> 00:11:18.800
of servers sitting on the back.
00:11:18.800 --> 00:11:22.980
So we're gonna do the load balancing
of the servers and also provide
00:11:22.980 --> 00:11:26.220
additional functionality of an
application delivering controller.
00:11:26.220 --> 00:11:29.800
So let me switch to my screen
00:11:34.480 --> 00:11:39.020
okay, there you go, so this is one
of the net scalers running in Azure.
00:11:39.020 --> 00:11:41.940
This is a management
portal from Azure.
00:11:41.940 --> 00:11:46.514
And you can see we have a two
net scalers running in highly
00:11:46.514 --> 00:11:48.045
available pair.
00:11:48.045 --> 00:11:50.400
And let me go to the dashboard for
NetScaler.
00:11:50.400 --> 00:11:53.500
This is the current
dashboard I'm just creating.
00:11:53.500 --> 00:11:54.870
To the Cloud service IP.
00:11:54.870 --> 00:11:56.620
Which is a directory
to primary net scaler.
00:12:04.130 --> 00:12:06.130
You have the basic configuration.
00:12:06.130 --> 00:12:08.196
It's pretty simple to use and
00:12:08.196 --> 00:12:10.710
there's a lot of
configuration options here.
00:12:10.710 --> 00:12:13.840
As you can see different categories
of configuration that you can do.
00:12:14.920 --> 00:12:18.690
Traffic management being one of the
most basic ones and then we get into
00:12:18.690 --> 00:12:23.342
advanced features such as access
gateway, application fire-walling,
00:12:23.342 --> 00:12:28.400
and security,lot of security and
feature set, so I'll just show you
00:12:28.400 --> 00:12:34.830
a quick scenario of user accessing
some resources on your environment.
00:12:34.830 --> 00:12:36.390
And I'll talk about the features.
00:12:38.770 --> 00:12:42.100
So assuming there is
an Enterprise customer,
00:12:42.100 --> 00:12:47.430
client trying to get some resources
from the Azure Cloud, and there's
00:12:47.430 --> 00:12:52.100
an application delivery controller
sitting in front, so the client
00:12:52.100 --> 00:12:55.970
actually connects to the application
delivery control on a virtual IP and
00:12:55.970 --> 00:13:00.340
what we do is, let's say he is
trying to access application D okay?
00:13:00.340 --> 00:13:04.250
So he has specified up in the URL
and then as soon as you enter.
00:13:05.760 --> 00:13:07.590
So the couple of
things happening here.
00:13:08.590 --> 00:13:11.560
First thing,
you can see that HTTPS page
00:13:11.560 --> 00:13:15.500
that means the scaler is
actually doing SSL offloading.
00:13:15.500 --> 00:13:19.270
You can manage all of
your certificates and
00:13:19.270 --> 00:13:22.160
instead of having it on the servers,
you can actually
00:13:22.160 --> 00:13:27.340
set everything on the net scaler
to offload your SSL offloading.
00:13:27.340 --> 00:13:30.100
What we have also done, is we have
always redirected the user to
00:13:30.100 --> 00:13:32.120
an authentication
page on net scaler.
00:13:32.120 --> 00:13:33.660
That is one more feature.
00:13:33.660 --> 00:13:38.140
So what net scaler can do is, we
provide authentication, auditing and
00:13:38.140 --> 00:13:43.147
authorization for
users access secure sources.
00:13:44.410 --> 00:13:46.505
With authentication,
what it can set up in net scaler,
00:13:46.505 --> 00:13:49.700
is you can actually set up
external authentication,
00:13:49.700 --> 00:13:51.180
with accurately using adapt.
00:13:51.180 --> 00:13:55.730
[INAUDIBLE] And radio servers,
we support a lot more of them.
00:13:55.730 --> 00:13:58.940
You have a centralized
management of security as well.
00:14:00.630 --> 00:14:05.550
Let me go ahead and
provide some credentials.
00:14:05.550 --> 00:14:09.500
Now you actually are exposed
to the web servers, right?
00:14:09.500 --> 00:14:13.780
Another thing happening here,
which I wanted to focus on I'm
00:14:13.780 --> 00:14:18.360
specifying application D, right, so
the URL, FQDN is remaining the same.
00:14:18.360 --> 00:14:19.510
So what's happening here is,
00:14:19.510 --> 00:14:21.940
we also do something
called content switching.
00:14:21.940 --> 00:14:26.280
So based on the request
that the client is sending,
00:14:26.280 --> 00:14:30.290
we can do real-time analysis
of the request, and
00:14:30.290 --> 00:14:34.090
redirect the user to a particular
resource pool or service set.
00:14:35.130 --> 00:14:37.920
So we can also do it
based on the URL request.
00:14:37.920 --> 00:14:42.360
The body content,
the RD cookies and much more.
00:14:42.360 --> 00:14:46.887
This is completed by
using our infrastructure.
00:14:46.887 --> 00:14:49.080
And also the policy infrastructure.
00:14:50.090 --> 00:14:53.800
The way the policy infrastructure
works is you provide some policies.
00:14:53.800 --> 00:14:58.390
If the policy is hit, then you take
an action based on the policy.
00:14:58.390 --> 00:15:01.210
So what we can do is we can
configure a lot of, if you have
00:15:01.210 --> 00:15:05.060
an extensive infrastructure to
create such policies and actions.
00:15:05.060 --> 00:15:09.300
And you can pretty much make it
very flexible to your needs.
00:15:09.300 --> 00:15:11.500
So you can go ahead
with that as well.
00:15:12.910 --> 00:15:16.840
And then of course, let's say
they are going to another server.
00:15:16.840 --> 00:15:19.730
Let's say we are going to
application on the same FDQ invite.
00:15:19.730 --> 00:15:23.070
So this is a basic load balancing
functionality that net scaler
00:15:23.070 --> 00:15:24.240
can provide as well.
00:15:24.240 --> 00:15:27.600
So we can go to different
pools of servers.
00:15:27.600 --> 00:15:29.630
We'll being sending it
to a different server.
00:15:31.510 --> 00:15:34.235
Okay, so
I think it's one-second delay,
00:15:34.235 --> 00:15:37.660
so here what's happening is with
the basic load balancing net scaler
00:15:37.660 --> 00:15:41.580
can also do advanced monitoring
of the back-end servers.
00:15:41.580 --> 00:15:45.090
So you can do a basic monitoring for
TCP probes, or
00:15:45.090 --> 00:15:49.540
you can do HTTP probes, or you can
also make your custom monitors to
00:15:49.540 --> 00:15:51.430
ensure that the servers are up and
running or
00:15:51.430 --> 00:15:54.690
the health of the servers are good,
are they part of the load
00:15:54.690 --> 00:15:58.510
balancing set, or should they be
removed or excluded from the set.
00:15:58.510 --> 00:16:00.770
So you have a lot of
functionality built around that.
00:16:03.610 --> 00:16:08.148
And then let me show you quickly
on the NetScaler front, so
00:16:08.148 --> 00:16:11.204
we do other functionality as well,
for
00:16:11.204 --> 00:16:15.110
example in the application
firewalling as well.
00:16:15.110 --> 00:16:19.100
Which can protect your servers
from escule injection or
00:16:19.100 --> 00:16:21.070
cross site scripting.
00:16:21.070 --> 00:16:22.710
And so
you can configure that as well.
00:16:22.710 --> 00:16:26.808
So it has very wide
security features as well.
00:16:26.808 --> 00:16:30.720
And as Carl was mentioning about
access gateway we can also provide
00:16:30.720 --> 00:16:34.620
connectivity to the users so
they can
00:16:34.620 --> 00:16:38.270
access their resources on the back
end without in a particular fashion.
00:16:39.840 --> 00:16:42.020
And this one is a highly
available pair,
00:16:42.020 --> 00:16:47.880
we can deploy NetScaler in an active
active or an active standby.
00:16:47.880 --> 00:16:51.680
And also you can take advantage
of the availability setup as your
00:16:51.680 --> 00:16:55.230
offer, so that they are deployed
across the different fall zones.
00:16:55.230 --> 00:16:58.510
So that way you get, make sure
that it's always up when they're
00:16:58.510 --> 00:17:04.160
upgrading their environment and so
on and so forth, and to add to that,
00:17:04.160 --> 00:17:08.700
we also have an extensive API
with Nitro for automation.
00:17:08.700 --> 00:17:11.920
So you can actually use
the automation API to manage,
00:17:11.920 --> 00:17:15.460
automate a lot of your configuration
of net scalar and dynamically change
00:17:15.460 --> 00:17:20.870
configuration and you can do SNMP
polling to get some analytics and
00:17:20.870 --> 00:17:23.620
we have a dashboard as well for
which you could use.
00:17:23.620 --> 00:17:28.110
And to add to that, you can also use
your Azure PowerShell to actually
00:17:28.110 --> 00:17:32.210
deploy the net scalers and manage
images and so on and so forth.
00:17:32.210 --> 00:17:35.590
So, it's a pretty comprehensive and
flexible appliance,
00:17:35.590 --> 00:17:39.880
and can adapt to any of
the needs that you guys have.
00:17:39.880 --> 00:17:41.190
So, I think I'll conclude there.
00:17:41.190 --> 00:17:42.642
Thanks Esha.
00:17:42.642 --> 00:17:43.489
>> Thank you Resay.
00:17:43.489 --> 00:17:49.851
>> [APPLAUSE]
>> So, for the next one.
00:17:49.851 --> 00:17:54.762
Oh, sorry.
[LAUGH] Yeah, Greg, I'm from F5.
00:17:54.762 --> 00:17:57.710
We'll be showcasing
F5 BIG-IP in Azure.
00:17:57.710 --> 00:17:59.243
Oops.
00:17:59.243 --> 00:18:01.542
Next slide.
00:18:01.542 --> 00:18:04.230
>> Can everybody hear me?
00:18:04.230 --> 00:18:05.840
Pretty good? Great.
00:18:05.840 --> 00:18:06.340
Thank you.
00:18:07.540 --> 00:18:11.910
So to start off with, basically,
everything you just saw.
00:18:11.910 --> 00:18:13.990
And, we'll continue on from there.
00:18:13.990 --> 00:18:15.700
I don't want to do too many slides.
00:18:15.700 --> 00:18:17.880
I'm actually gonna do just
one slide if I could.
00:18:17.880 --> 00:18:20.070
And give Andy the clicker here.
00:18:20.070 --> 00:18:20.570
Bear with me.
00:18:23.460 --> 00:18:24.295
Pass past that.
00:18:24.295 --> 00:18:27.535
Come on.
00:18:30.135 --> 00:18:31.560
Thank you.
00:18:31.560 --> 00:18:33.820
So, really,
here's the Star one marketing slide.
00:18:33.820 --> 00:18:36.280
All I really wanna point out
when we talk about this is,
00:18:36.280 --> 00:18:38.170
it's regardless of whether
you're using the BIG-IP and
00:18:38.170 --> 00:18:40.700
hopefully everybody's familiar
with F5 and the BIG-IP.
00:18:40.700 --> 00:18:43.370
But, whether you're
using the BIG-IP for.
00:18:43.370 --> 00:18:49.020
A virtual addition or you're using
our 8U VIPRION gigantic chassis.
00:18:49.020 --> 00:18:50.900
The look, the feel,
the functionality,
00:18:50.900 --> 00:18:52.390
the feature set, it's the same.
00:18:53.470 --> 00:18:55.790
So, we brought that as well,
we're bringing up into Azure.
00:18:55.790 --> 00:18:59.480
And as Lucian said,
it's not as easy as it would seem.
00:18:59.480 --> 00:19:02.060
It's not just bringing a VE and
loading it up there.
00:19:02.060 --> 00:19:03.340
But we're getting very close.
00:19:03.340 --> 00:19:04.760
We're actually in early
access testing now,
00:19:04.760 --> 00:19:07.068
we hopefully will be
going live very soon.
00:19:07.068 --> 00:19:11.000
So what I I wanted to do though
is basically go through the demo,
00:19:11.000 --> 00:19:13.930
talk about a few different scenarios
that we're gonna talk about or do,
00:19:13.930 --> 00:19:16.840
and talk about our functions
as we go through it,
00:19:16.840 --> 00:19:19.380
so let's look at the scenario.
00:19:21.210 --> 00:19:23.209
So here's our environment,
our demo environment.
00:19:24.370 --> 00:19:27.330
Currently right now,
we have our on premise data center.
00:19:27.330 --> 00:19:31.840
We have basically an application,
a web farm on premises.
00:19:31.840 --> 00:19:35.850
In addition to that,
we have in the east US Azure region,
00:19:35.850 --> 00:19:38.060
we have that application as well.
00:19:38.060 --> 00:19:39.320
We have a copy of that.
00:19:39.320 --> 00:19:43.710
You'll also notice we are using
the big IP to do an IPsec Tunnel.
00:19:43.710 --> 00:19:49.900
So we're on premise between
Big IP East and on-Premis.
00:19:49.900 --> 00:19:52.279
In addition to that, Western Europe,
00:19:52.279 --> 00:19:54.810
we have another copy
of the application.
00:19:54.810 --> 00:19:58.500
So what we're gonna do, on each of
these sites we have literally one
00:19:58.500 --> 00:20:02.341
big IP, virtual edition, managing
all of the different functions.
00:20:02.341 --> 00:20:04.701
Now, we always recommend
you deploy them in a pair.
00:20:04.701 --> 00:20:07.165
So you're doing an HA pair,
you do that up in Azure,
00:20:07.165 --> 00:20:08.341
you do that up on-prem.
00:20:08.341 --> 00:20:12.248
But what I wanted to point out is
the fact that you can actually do
00:20:12.248 --> 00:20:14.851
all this functionality
with one device.
00:20:14.851 --> 00:20:17.236
So what we're gonna do here
is we're gonna do GTM,
00:20:17.236 --> 00:20:19.797
that's our global load
balancing mechanism module.
00:20:19.797 --> 00:20:23.271
We have LTM which is our
traditional local traffic manager,
00:20:23.271 --> 00:20:24.301
load balancing.
00:20:24.301 --> 00:20:27.493
We have APM which is
pre-authentication,
00:20:27.493 --> 00:20:30.779
single sign-on federation
module as well.
00:20:30.779 --> 00:20:32.823
In addition to that we have ASM, and
00:20:32.823 --> 00:20:35.412
ASM is our
Application Security Module, and
00:20:35.412 --> 00:20:39.788
what that does is that's our layer
seven, that's our WAF, our Firewall.
00:20:39.788 --> 00:20:42.133
So right now, we have that
running in all the environments.
00:20:42.133 --> 00:20:44.763
So what I want to do is, basically,
00:20:44.763 --> 00:20:48.286
take you guys on a little
tour around the globe.
00:20:48.286 --> 00:20:50.910
Let's see how we do here.
00:20:50.910 --> 00:20:52.210
That's why I'm going to switch over.
00:20:55.740 --> 00:20:56.250
There we go.
00:21:00.012 --> 00:21:01.629
Log in to the BIG-IP.
00:21:06.092 --> 00:21:08.530
All right, to start with,
so here we are in Azure.
00:21:08.530 --> 00:21:10.090
So you notice once again,
00:21:10.090 --> 00:21:14.820
I have a total of three VMs for
each environment and the BIG-IP.
00:21:14.820 --> 00:21:17.596
These are all running in
basically just two Cloud Services.
00:21:17.596 --> 00:21:19.868
So our BIG-IP is doing all
the load balancing and
00:21:19.868 --> 00:21:22.982
all the traffic management for
the Cloud Services in each region.
00:21:25.675 --> 00:21:28.647
And what I am logged into right
now is actually the Cloud E.
00:21:28.647 --> 00:21:29.831
So this is Azure E.
00:21:29.831 --> 00:21:34.429
So this is the big IP run up in
Azure or one of the big IPs.
00:21:34.429 --> 00:21:39.119
And what I'm gonna do is,
to help guide us along.
00:21:39.119 --> 00:21:43.289
Cuz I'm gonna pull up our
pool of load balancers.
00:21:46.940 --> 00:21:50.250
So once again just like we do Local
Traffic Manager and we have pools of
00:21:50.250 --> 00:21:55.310
back end servers, this is our
pool of actual BIG-IP servers.
00:21:55.310 --> 00:21:58.974
So we're load balancing across the
globe all our BIG-IPs which are then
00:21:58.974 --> 00:22:02.231
load balancing all the applications
that are underneath them.
00:22:02.231 --> 00:22:05.760
So to give us a little tour,
I'm gonna start off, level set us.
00:22:12.261 --> 00:22:15.419
I'm gonna lock down
some of these guys.
00:22:15.419 --> 00:22:15.919
All right.
00:22:20.922 --> 00:22:23.601
And this is a live site, so anybody
in the audience that wants to play
00:22:23.601 --> 00:22:25.775
around with this, by all means
you can join in the fun.
00:22:25.775 --> 00:22:30.445
It's test.f5demo.net.
00:22:30.445 --> 00:22:33.817
And you'll notice if you do put in
HTTP, it will automatically redirect
00:22:33.817 --> 00:22:36.690
you to HTTPS, and
we are doing the SSL offload.
00:22:36.690 --> 00:22:38.310
So this is our login screen.
00:22:38.310 --> 00:22:38.889
So I'm gonna login.
00:22:38.889 --> 00:22:39.424
Let's take a look.
00:22:44.323 --> 00:22:44.960
And there we go.
00:22:44.960 --> 00:22:46.123
And as you will notice.
00:22:48.492 --> 00:22:52.240
We are communicating and direct
it to the On-premise environment.
00:22:52.240 --> 00:22:52.920
Pretty straight forward.
00:22:52.920 --> 00:22:55.624
This is typically what
we do historically.
00:22:55.624 --> 00:23:00.806
All right, so close out of there,
00:23:00.806 --> 00:23:03.495
to say the least.
00:23:03.495 --> 00:23:05.121
Let's go to Europe.
00:23:21.769 --> 00:23:23.680
All right, so
now we log back in again.
00:23:23.680 --> 00:23:27.000
Now, I'm actually connecting
to the Azure Cloud in Europe.
00:23:27.000 --> 00:23:29.210
This is Western Europe
in the Netherlands.
00:23:29.210 --> 00:23:32.165
The thing you'll notice now,
in seeing here excuse me,
00:23:32.165 --> 00:23:35.174
in our diagram, is we don't have
any authentication or any AD or
00:23:35.174 --> 00:23:38.330
anything going on up on Azure,
it's all being handled on-prem.
00:23:38.330 --> 00:23:39.980
So now, if you're in the East Coast,
00:23:39.980 --> 00:23:41.490
once again we have
the IP sect tunnels.
00:23:41.490 --> 00:23:42.960
So we can do a number of options.
00:23:42.960 --> 00:23:45.975
We can do things like
basically NTLM off, so
00:23:45.975 --> 00:23:49.240
pre-auth to AD directly across
the wire, through the tunnel.
00:23:50.520 --> 00:23:54.150
We can do authorizations,
things like that, multi-factor auth.
00:23:54.150 --> 00:23:56.080
But in Europe we don't
have that option.
00:23:56.080 --> 00:23:58.510
So what we're doing here in this
case is we're actually using
00:23:58.510 --> 00:23:59.137
SAML Federation.
00:23:59.137 --> 00:24:02.580
So, because we're
using SAML Federation,
00:24:02.580 --> 00:24:04.710
it gives us the ability to
do other things like that.
00:24:04.710 --> 00:24:07.410
So we can actually federate
to other environments.
00:24:07.410 --> 00:24:12.382
So now, the same user who is logged
into Cloud Europe is now pulling up
00:24:12.382 --> 00:24:17.122
and connecting directly to,
drum roll please, Office 365.
00:24:17.122 --> 00:24:19.351
So a single sign on to Office 365.
00:24:22.416 --> 00:24:23.020
One time.
00:24:23.020 --> 00:24:27.213
Now of course, this could be Office
365, this could be Sales Force,
00:24:27.213 --> 00:24:31.216
this could be somebody else, this
could be another Cloud provider.
00:24:31.216 --> 00:24:32.792
If we're up in the Clouds, and
00:24:32.792 --> 00:24:35.535
all our major providers
are getting up there, okay?
00:24:46.239 --> 00:24:47.984
Kill Europe,
something happened there,
00:24:47.984 --> 00:24:49.489
we're gonna come back to the world.
00:24:52.508 --> 00:24:56.084
All right, so now let's take a look
and we should go back to the East.
00:24:59.218 --> 00:25:02.550
The important thing to note
here is once again the goal is,
00:25:02.550 --> 00:25:06.562
when we're talking about Hybrid
deployments and things like this for
00:25:06.562 --> 00:25:08.134
HA, for just scaling out.
00:25:08.134 --> 00:25:10.062
The goal is to make sure
that our end users,
00:25:10.062 --> 00:25:13.225
the consumers coming in, they don't
have to do anything different,
00:25:13.225 --> 00:25:14.950
they don't see anything different.
00:25:14.950 --> 00:25:17.899
The whole point is this is a single,
seamless experience for them.
00:25:19.130 --> 00:25:22.310
So once again, log it in just
like you did before, same user.
00:25:23.480 --> 00:25:24.960
And if everything goes right now,
00:25:24.960 --> 00:25:27.910
you'll notice the little glowing
green guy over there in the corner.
00:25:27.910 --> 00:25:29.740
Now, we're back in Azure East.
00:25:29.740 --> 00:25:30.680
Same thing.
00:25:30.680 --> 00:25:31.524
And once again.
00:25:39.349 --> 00:25:40.673
Single sign-on.
00:25:40.673 --> 00:25:43.578
Back to Office 365.
00:25:43.578 --> 00:25:45.412
So that's easy, once again,
we are using LTM.
00:25:45.412 --> 00:25:47.688
We are using GTM,
which is our Global Traffic Manager.
00:25:47.688 --> 00:25:49.070
We're using APM, for
00:25:49.070 --> 00:25:52.353
pre-authentication single
sign-on federation.
00:25:52.353 --> 00:25:54.083
In addition, excuse me,
00:25:54.083 --> 00:25:56.910
we also have ASM installed
on all of these BIG-IPs.
00:25:56.910 --> 00:25:58.558
We actually have our
WAF running as well.
00:25:58.558 --> 00:26:02.662
So I'm gonna click on this test page
here, it's not gonna say too much in
00:26:02.662 --> 00:26:05.434
other than to basically
say I've been blocked.
00:26:05.434 --> 00:26:07.828
This is really just
to show you that,
00:26:07.828 --> 00:26:10.078
I'm not kidding you when I say it.
00:26:10.078 --> 00:26:11.123
Let's take a look and see.
00:26:16.974 --> 00:26:19.900
And you'll notice right off the bat
that I have been blocked out.
00:26:26.610 --> 00:26:29.859
And there is my WAP, basically
telling me, essentially what it's
00:26:29.859 --> 00:26:33.370
telling me when we get down to here
is that I have an illegal file type.
00:26:33.370 --> 00:26:35.290
Basically, I've restricted just for
00:26:35.290 --> 00:26:38.880
the sake of a demo that you
cannot access a text file.
00:26:38.880 --> 00:26:39.390
Real simple, but
00:26:39.390 --> 00:26:43.420
it kind of gives you the idea
of what ASM can do for you.
00:26:43.420 --> 00:26:47.000
So really,
that's pretty straightforward.
00:26:47.000 --> 00:26:48.780
Coming out,
we're in early access as I said.
00:26:48.780 --> 00:26:55.032
We're coming out hopefully soon,
I'll leave it at that.
00:26:55.032 --> 00:26:58.181
If you are interested by all
means certainly reach out to us,
00:26:58.181 --> 00:27:00.651
come down to the booth,
have a conversation and
00:27:00.651 --> 00:27:02.717
with that I'm gonna
leave it to there.
00:27:02.717 --> 00:27:03.507
>> Okay.
>> Thank you very much.
00:27:03.507 --> 00:27:09.400
>> [APPLAUSE]
>> Okay,
00:27:09.400 --> 00:27:13.120
so for the next one, we're gonna
talk about WAN optimization.
00:27:13.120 --> 00:27:15.787
And we have Judy, Brett, and
00:27:15.787 --> 00:27:21.238
Peco from Riverbed to showcase
their Riverbed appliances.
00:27:21.238 --> 00:27:22.167
>> Hi everybody.
00:27:22.167 --> 00:27:23.026
Can you hear me?
00:27:23.026 --> 00:27:23.932
Okay.
00:27:23.932 --> 00:27:25.929
Thank you so much.
00:27:25.929 --> 00:27:26.890
I'm Judy Mirkin.
00:27:26.890 --> 00:27:30.071
I wanna talk to you a little about
what we have to show you here today.
00:27:30.071 --> 00:27:34.204
This thing is, you weren't kidding,
it's being a little difficult.
00:27:34.204 --> 00:27:37.770
So I'm the Director of the Riverbed
and Microsoft Alliance.
00:27:37.770 --> 00:27:41.390
Microsoft and Riverbed have been
working together for over a decade.
00:27:41.390 --> 00:27:45.050
I don't know a special on Azure,
we've been tightly aligned.
00:27:45.050 --> 00:27:49.360
As many of you saw
back in WPC of 2014,
00:27:49.360 --> 00:27:53.040
we were one of the very first
adopters with four other companies
00:27:53.040 --> 00:27:56.280
to adopt Azure and
to become certified on Azure.
00:27:56.280 --> 00:27:59.952
Our solutions have been working
on Azure for a long time, and
00:27:59.952 --> 00:28:03.409
with our 26,000 joint
customers with Microsoft,
00:28:03.409 --> 00:28:07.311
we're bringing all of our Azure
solutions to market together.
00:28:07.311 --> 00:28:11.537
We are at the Recognized Leader in
WAN Optimization with over 50% of
00:28:11.537 --> 00:28:15.263
market share and the ability to
provide the best visibility,
00:28:15.263 --> 00:28:18.572
optimization and control for
the Hybrid Enterprise.
00:28:18.572 --> 00:28:21.490
We're bringing these
solutions to our customers.
00:28:21.490 --> 00:28:24.848
So we're very excited to show
you some of these items and
00:28:24.848 --> 00:28:28.993
show you some of the successes that
all these customers are working on
00:28:28.993 --> 00:28:29.934
with us today.
00:28:29.934 --> 00:28:31.794
With the strength of our company,
00:28:31.794 --> 00:28:35.515
we've brought together two of our
product families, SteelHead and
00:28:35.515 --> 00:28:38.738
SteelCentral to show you this
whole end to end experience.
00:28:38.738 --> 00:28:41.798
How to bring application
performance management,
00:28:41.798 --> 00:28:44.260
network performance management.
00:28:44.260 --> 00:28:47.990
And then all the visibility
optimization control that customers
00:28:47.990 --> 00:28:50.900
could want to get them themselves
the best user experience,
00:28:50.900 --> 00:28:53.740
best diagnostics,
best telemetry, and
00:28:53.740 --> 00:28:56.300
the fastest utilization
of their infrastructure.
00:28:56.300 --> 00:28:57.710
So let me bring up Brett and Peco.
00:29:00.110 --> 00:29:04.450
We're gonna be showcasing here,
two Azure Virtual Appliances.
00:29:04.450 --> 00:29:07.372
Our Riverbed SteelHead which
we've been talking about,
00:29:07.372 --> 00:29:10.111
many of you know, I know we
have got a lot of customers,
00:29:10.111 --> 00:29:13.411
I can see many of them here already
in our Riverbed SteelCentral.
00:29:13.411 --> 00:29:14.387
So these items,
00:29:14.387 --> 00:29:18.782
SteelCentral is right now finalizing
its last bits of certification, but
00:29:18.782 --> 00:29:22.142
you will find these in
the certified Azure Marketplace.
00:29:22.142 --> 00:29:24.645
And we're here at booth 261, and
00:29:24.645 --> 00:29:28.782
feel free to stop by where we
can help you with any questions.
00:29:28.782 --> 00:29:30.686
Peco.
00:29:30.686 --> 00:29:31.917
>> Thanks Judy.
00:29:31.917 --> 00:29:35.562
So where's the clicker?
00:29:35.562 --> 00:29:38.204
All right, sorry about that.
00:29:38.204 --> 00:29:42.540
So I'm going to talk
shortly about SteelCentral,
00:29:42.540 --> 00:29:47.350
which is the visibility platform
that is part of Riverbed, and
00:29:47.350 --> 00:29:48.000
I'll do a quick demo.
00:29:50.300 --> 00:29:54.010
So what is the Riverbed SteelCentral
platform about?
00:29:54.010 --> 00:29:58.600
It's about giving you complete
visibility from the end user device,
00:29:58.600 --> 00:30:02.725
through network inside the
application through the system all
00:30:02.725 --> 00:30:04.140
the way to your data.
00:30:04.140 --> 00:30:07.712
The advantage there again is to
give you integrated analytics so
00:30:07.712 --> 00:30:10.831
that you don't have silos of
data that you have to jump.
00:30:10.831 --> 00:30:14.907
Jump through to monitor and diagnose
problems with your applications,
00:30:14.907 --> 00:30:18.516
and enable to actually collaborate
with your colleagues across
00:30:18.516 --> 00:30:19.800
the IT organization.
00:30:22.830 --> 00:30:25.550
Not only can we give
you the visibility,
00:30:25.550 --> 00:30:29.880
we can actually give you access
to and enable you to control and
00:30:29.880 --> 00:30:33.210
optimize your applications
within Azure.
00:30:33.210 --> 00:30:37.777
So I'm gonna jump quickly into the
demo section here in a second, but
00:30:37.777 --> 00:30:40.951
I wanna to talk a little
bit about how we do that.
00:30:40.951 --> 00:30:46.216
How do we enable you to actually
bring all this data together
00:30:46.216 --> 00:30:51.075
into the integrated analytics
approach that we have?
00:30:51.075 --> 00:30:55.997
Looks like the demo has stopped.
00:30:55.997 --> 00:30:57.112
Sorry about that.
00:31:10.416 --> 00:31:12.050
There you go.
00:31:12.050 --> 00:31:13.100
Short pause.
00:31:13.100 --> 00:31:15.800
So how do we actually accomplish
00:31:15.800 --> 00:31:18.480
giving that integrated
analytics some visibility?
00:31:18.480 --> 00:31:22.637
A key concept here is giving you a
full transaction path through every
00:31:22.637 --> 00:31:25.084
single component of
your application.
00:31:25.084 --> 00:31:29.886
Again, user device, network,
application server components,
00:31:29.886 --> 00:31:33.686
all the way inside the application
code to your data.
00:31:33.686 --> 00:31:37.946
So, any point of this transaction
can actually become a bottleneck
00:31:37.946 --> 00:31:39.462
that can be optimized.
00:31:39.462 --> 00:31:41.620
Whether that you optimize
it with design or
00:31:41.620 --> 00:31:45.280
you optimize it with a SteelHead
Appliances on the network,
00:31:45.280 --> 00:31:47.430
that's a choice that you have and
control that you have.
00:31:47.430 --> 00:31:52.470
So, I'm gonna jump into a quick demo
here with SteelCentral AppInternals.
00:31:52.470 --> 00:31:53.520
It's our agent based
00:31:55.400 --> 00:31:57.830
solution that we're certifying
with Azure currently.
00:31:57.830 --> 00:31:58.790
It will be available soon.
00:31:58.790 --> 00:32:03.239
So what you're seeing here is
a quick view of your application.
00:32:03.239 --> 00:32:05.965
Again, data coming from
the end user devices,
00:32:05.965 --> 00:32:09.996
data coming from your systems,
all the way through the application.
00:32:09.996 --> 00:32:14.734
So quick scenario here is maybe
you wanna understand who are your
00:32:14.734 --> 00:32:19.043
top users visiting this
particular site or application.
00:32:19.043 --> 00:32:22.886
Maybe you wanna understand,
how is your infrastructure and
00:32:22.886 --> 00:32:23.950
systems doing.
00:32:24.950 --> 00:32:27.660
Do you have a bottleneck
inside your transaction paths?
00:32:28.680 --> 00:32:32.009
Again, applications are more
increasingly complex,
00:32:32.009 --> 00:32:35.829
not only how they're being consumed,
but also on the back end,
00:32:35.829 --> 00:32:40.350
so having that visibility between
the front and the back end is key.
00:32:40.350 --> 00:32:44.078
So the example here that I have in
the demo is, I drilled down into
00:32:44.078 --> 00:32:48.088
a particular transaction type to
understand how my users are doing,
00:32:48.088 --> 00:32:52.166
and immediately spot that my users
in India actually are experiencing
00:32:52.166 --> 00:32:55.460
more performance issues
than anybody else.
00:32:55.460 --> 00:33:00.990
So my next question is, well that's
interesting, what can I do about it?
00:33:00.990 --> 00:33:04.830
How do I diagnose what's
happening with my users in India?
00:33:04.830 --> 00:33:05.850
So I can drill down further.
00:33:07.430 --> 00:33:12.430
Again, a key principle of
the SteelCentral platform is
00:33:12.430 --> 00:33:13.910
big data analytics.
00:33:13.910 --> 00:33:17.248
Capturing every single transaction,
every single packet,
00:33:17.248 --> 00:33:20.203
understanding that performance
characteristics and
00:33:20.203 --> 00:33:24.720
using an integrated transaction
approach to give you that insight.
00:33:24.720 --> 00:33:28.286
So every single dot on this view is
actually an individual user action
00:33:28.286 --> 00:33:31.310
that was taken, and
we've recorded every single thing.
00:33:32.330 --> 00:33:36.980
Not only do we record every single
action and put it in the context of
00:33:36.980 --> 00:33:40.040
a transaction, but we actually
have a complete diagnostic record
00:33:41.440 --> 00:33:45.115
about that particular transaction.
00:33:45.115 --> 00:33:49.738
So the example I have here is,
if somebody reported that they have
00:33:49.738 --> 00:33:54.450
a problem, in this case we can
see that individual record.
00:33:54.450 --> 00:33:57.510
We can tell that the majority of
time was actually being spent in
00:33:57.510 --> 00:34:02.380
the redirect versus something
that's happening on the Azure side.
00:34:02.380 --> 00:34:05.130
Right, so at that point
don't blame the network,
00:34:05.130 --> 00:34:08.280
don't blame Azure, it's something
that the application is doing.
00:34:08.280 --> 00:34:10.920
It's creating that
additional redirect that
00:34:10.920 --> 00:34:13.754
has to go all the way to
the data center, back to India.
00:34:13.754 --> 00:34:16.715
And you can see
the transaction topology
00:34:16.715 --> 00:34:19.480
on the back end within Azure.
00:34:19.480 --> 00:34:22.020
Maybe you're calling
remote web services, maybe
00:34:23.500 --> 00:34:27.670
you're calling your data
center in a hybrid scenario,
00:34:27.670 --> 00:34:30.390
but we'll give you that
entire transaction path.
00:34:30.390 --> 00:34:34.340
Example I have further is, again,
we record every single action.
00:34:34.340 --> 00:34:36.168
You can step to the user session and
really,
00:34:36.168 --> 00:34:41.520
really understand kind of user
behavior and what you can optimize.
00:34:41.520 --> 00:34:45.510
Maybe your CEO is logging into
your site and he's having a really
00:34:45.510 --> 00:34:49.670
poor experience because he's
flying on a jet somewhere, right?
00:34:49.670 --> 00:34:53.422
You wanna understand that and
be able to do something about it.
00:34:53.422 --> 00:34:56.409
And the last thing I wanted
to highlight, again,
00:34:56.409 --> 00:34:58.693
is back to the application topology.
00:34:58.693 --> 00:35:01.773
Not only can we track every
transaction through every component
00:35:01.773 --> 00:35:05.195
of the application, we can actually
aggregate that data and give you,
00:35:05.195 --> 00:35:06.860
here's the application health.
00:35:08.070 --> 00:35:10.020
What are some of the hot spots?
00:35:10.020 --> 00:35:14.170
In this case, the application team
has decided to host the database
00:35:14.170 --> 00:35:17.270
on premise and they've hosted
the app servers in Azure,
00:35:17.270 --> 00:35:22.060
so that immediately has become
a bottleneck inside the application.
00:35:22.060 --> 00:35:25.990
So, it's interesting to be able to
measure things, diagnose them, but
00:35:25.990 --> 00:35:30.350
it's even more interesting
if we can do something about
00:35:30.350 --> 00:35:33.000
it as a network engineer or
as a system engineer.
00:35:33.000 --> 00:35:36.110
And I'm going to transition to
Brett to cover how we can actually
00:35:36.110 --> 00:35:37.400
optimize the user experience.
00:35:39.500 --> 00:35:40.013
>> Thanks.
00:35:42.649 --> 00:35:44.367
This stuff is amazing.
00:35:44.367 --> 00:35:45.806
Come down to our booth and
take a look at it.
00:35:45.806 --> 00:35:49.472
It gives you the visibility that you
can really only dream of when you
00:35:49.472 --> 00:35:51.925
deal with the entire
network from end to end.
00:35:51.925 --> 00:35:54.815
Let's see here.
00:35:54.815 --> 00:35:58.290
We're gonna talk about
optimizing Azure workloads.
00:35:58.290 --> 00:36:04.290
Let's get this running.
00:36:04.290 --> 00:36:06.800
Riverbed is famous for
reducing network traffic and
00:36:06.800 --> 00:36:09.470
improving performance
of Microsoft workloads.
00:36:09.470 --> 00:36:10.830
We've been doing if for a long time.
00:36:10.830 --> 00:36:12.460
You start with two SteelHeads and
00:36:12.460 --> 00:36:14.530
you put them on the ends
of your networks, and
00:36:14.530 --> 00:36:17.970
then whatever traffic you send
between the SteelHeads is optimized.
00:36:17.970 --> 00:36:20.907
And this can be databases,
mail, files,
00:36:20.907 --> 00:36:23.360
all different kinds of materials.
00:36:23.360 --> 00:36:25.980
You can take your Exchange,
your SharePoint, all files,
00:36:25.980 --> 00:36:29.860
send them across this network, and
turn terabytes into gigabytes.
00:36:29.860 --> 00:36:32.260
This is a SteelHead report
from an actual customer.
00:36:32.260 --> 00:36:35.100
Take a look at these kinds of
optimizations we're getting
00:36:35.100 --> 00:36:37.820
with CIFS, MAPI, HTTP.
00:36:37.820 --> 00:36:42.840
All of this for one day, 245
gigabytes worth of traffic reduced
00:36:42.840 --> 00:36:46.073
to 18.4 gigabytes of actual
traffic on the wire.
00:36:46.073 --> 00:36:50.372
That's a 97% reduction of traffic.
00:36:50.372 --> 00:36:51.550
97% reduction, and
00:36:51.550 --> 00:36:55.770
we do that every day for thousands
of customers all around the world.
00:36:55.770 --> 00:36:58.000
Now you can do the same
thing with Azure workloads,
00:36:58.000 --> 00:36:59.700
and this is where it
gets really interesting.
00:36:59.700 --> 00:37:02.030
You can take an on-premise
SteeHead and
00:37:02.030 --> 00:37:05.670
you can pair it with a virtual
machine running SteelHead in Azure.
00:37:05.670 --> 00:37:09.410
You can then optimize these Azure
workloads so that you can do HDTP
00:37:09.410 --> 00:37:13.558
workloads like IIS, SharePoint,
moving stuff into blob storage, and
00:37:13.558 --> 00:37:16.686
you're gonna dramatically
reduce your bandwidth and
00:37:16.686 --> 00:37:20.275
improve performance while
reducing your costs.
00:37:20.275 --> 00:37:22.376
When Microsoft heard about
this they said, hey,
00:37:22.376 --> 00:37:25.127
let's test this with something
really new and fun, so we went and
00:37:25.127 --> 00:37:26.846
did some work with
Azure Site Recovery.
00:37:26.846 --> 00:37:29.927
Here you can see some tests that
we did with Azure Site Recovery
00:37:29.927 --> 00:37:33.603
showing the optimization that we're
getting on moving virtual machines
00:37:33.603 --> 00:37:34.264
into Azure.
00:37:34.264 --> 00:37:37.287
We're talking 95, 85, 78, 90%,
00:37:37.287 --> 00:37:40.475
you get the idea,
this is a lot of optimization.
00:37:40.475 --> 00:37:44.013
In fact, they basically said,
the SteelHead Solution exceeded
00:37:44.013 --> 00:37:46.265
expectations in
a variety of scenarios,
00:37:46.265 --> 00:37:48.984
which is all the scenarios
that they've tested.
00:37:48.984 --> 00:37:52.955
You can download this paper still
from Microsoft.com downloads.
00:37:52.955 --> 00:37:54.778
Let's take a look at a completely
different situation here.
00:37:54.778 --> 00:38:00.250
We've got a two megabyte network on
60 milliseconds of latency added.
00:38:00.250 --> 00:38:02.780
This is a SharePoint
server in Azure.
00:38:02.780 --> 00:38:05.820
We're gonna download
a 13.5 megabyte PowerPoint
00:38:05.820 --> 00:38:07.390
deck on an unoptimized network.
00:38:07.390 --> 00:38:11.110
When we click save it
will start the timer and
00:38:11.110 --> 00:38:16.910
you'll see that basically this will
run about a minute and six seconds.
00:38:16.910 --> 00:38:20.120
A minute and six seconds to
download this 14 megabyte file.
00:38:20.120 --> 00:38:22.110
Now this is an optimized download.
00:38:22.110 --> 00:38:24.950
We previously uploaded this
through the Azure SteelHead.
00:38:24.950 --> 00:38:27.650
So the next user downloads this
file, how long does it take?
00:38:27.650 --> 00:38:29.070
We'll take a look.
00:38:29.070 --> 00:38:30.040
One second.
00:38:30.040 --> 00:38:33.600
One second for this 14 megabyte
file to come across the wire.
00:38:33.600 --> 00:38:36.330
Now what kind of optimization do
we get with the Azure SteelHead on
00:38:36.330 --> 00:38:37.910
this particular download?
00:38:37.910 --> 00:38:39.910
It looks like about 99%.
00:38:39.910 --> 00:38:45.310
So we took all of that off the wire,
times as many users as you have.
00:38:45.310 --> 00:38:47.770
This is a significant benefit.
00:38:47.770 --> 00:38:50.320
Now, generally when people see this
they think this must be some kind of
00:38:50.320 --> 00:38:51.050
a file cache.
00:38:51.050 --> 00:38:52.510
Well take a look at this.
00:38:52.510 --> 00:38:54.912
We're gonna open up
the same PowerPoint deck.
00:38:54.912 --> 00:38:58.540
We're gonna browse all the way
to the end of it, and when we do
00:38:58.540 --> 00:39:01.830
we're gonna insert a new slide and
we're gonna save this slide.
00:39:01.830 --> 00:39:03.580
And that makes the file bigger and
00:39:03.580 --> 00:39:06.010
it changes the digital
footprint of the deck.
00:39:06.010 --> 00:39:09.327
Next, we're going to rename the
slide so that this would completely
00:39:09.327 --> 00:39:12.314
defeat any kind of a file cache
system in a traditional sense.
00:39:12.314 --> 00:39:15.402
And we're gonna drag and drop it
back into the SharePoint library.
00:39:15.402 --> 00:39:18.075
It's gonna go back through
the Azure SteelHead and
00:39:18.075 --> 00:39:21.030
upload into the SharePoint
document library.
00:39:21.030 --> 00:39:23.870
In this case the upload takes
a little bit longer than it does on
00:39:23.870 --> 00:39:25.290
a download situation.
00:39:25.290 --> 00:39:29.052
About 35 seconds, which is
twice as fast as the download.
00:39:29.052 --> 00:39:30.851
Now how much optimization
did we get on this?
00:39:30.851 --> 00:39:31.820
Well let's take a look.
00:39:31.820 --> 00:39:36.370
We got about 92% on a modified,
renamed file.
00:39:36.370 --> 00:39:39.356
First time this SteelHead had
ever seen this particular file.
00:39:39.356 --> 00:39:43.668
Now that is significant, because it
shows that the SteelHeads optimize
00:39:43.668 --> 00:39:47.625
bits and protocols, not files,
and that means that we find many,
00:39:47.625 --> 00:39:51.174
many more cases for optimization
than a simple file cache.
00:39:51.174 --> 00:39:54.408
There's a bunch more to say and show
about this technology, so come down
00:39:54.408 --> 00:39:57.431
to our booth with Application
Performance Company, and you can see
00:39:57.431 --> 00:40:00.415
now that we're also the Azure
Application Performance Company.
00:40:00.415 --> 00:40:03.386
Thank you.
00:40:03.386 --> 00:40:07.794
>> [APPLAUSE]
>> Thank you Brett.
00:40:07.794 --> 00:40:12.405
And next we have Adam
from CheckPoint.
00:40:12.405 --> 00:40:13.285
>> Come on up and setup.
00:40:21.566 --> 00:40:22.192
Are we good?
00:40:22.192 --> 00:40:22.995
>> Go ahead.
>> All right, thanks.
00:40:22.995 --> 00:40:25.100
Good morning, everyone.
00:40:25.100 --> 00:40:27.330
So, I'm Adam Lasser
from Check Point.
00:40:27.330 --> 00:40:28.420
Email address is up there.
00:40:28.420 --> 00:40:30.290
So if you guys don't have
time to stick around after,
00:40:30.290 --> 00:40:32.600
feel free to send me a note.
00:40:32.600 --> 00:40:36.290
We've been developing security
solutions since the mid 90s.
00:40:36.290 --> 00:40:38.740
Some of you may know us
as The Firewall Company.
00:40:38.740 --> 00:40:42.350
The security industry obviously has
changed quite a bit over the years.
00:40:42.350 --> 00:40:45.640
So we provide plenty
of other capabilities
00:40:45.640 --> 00:40:47.432
along the lines of
intrusion prevention.
00:40:47.432 --> 00:40:50.390
Network-based Anti-malware.
00:40:50.390 --> 00:40:52.100
Data loss prevention.
00:40:52.100 --> 00:40:53.200
And user content filtering.
00:40:53.200 --> 00:40:55.410
So the product has
definitely evolved.
00:40:55.410 --> 00:40:59.920
And we've got security appliances
that cover various implementations.
00:40:59.920 --> 00:41:03.290
So no longer do we just sit
on a physical server or
00:41:03.290 --> 00:41:06.480
appliance within your
local data center.
00:41:07.660 --> 00:41:09.340
Because of the networking and
00:41:09.340 --> 00:41:11.980
virtualization changes
that we've seen.
00:41:11.980 --> 00:41:13.990
We support Microsoft Hyper-V.
00:41:13.990 --> 00:41:15.050
We support Azure.
00:41:15.050 --> 00:41:18.800
So we're gonna talk a little bit
about how we can secure your network
00:41:18.800 --> 00:41:20.290
based infrastructure.
00:41:20.290 --> 00:41:23.250
And some of the things that you
should've mentioned earlier,
00:41:23.250 --> 00:41:26.380
specifically regarding the user
defined route capabilities.
00:41:26.380 --> 00:41:30.090
So we've had a virtual appliance for
Azure for quite some time.
00:41:30.090 --> 00:41:32.990
Last fall they added the capability
to have multiple network interfaces
00:41:32.990 --> 00:41:36.490
on a single appliance that helped us
and gave us greater functionality.
00:41:36.490 --> 00:41:39.610
But now that you can actually define
your own routes, you can do so
00:41:39.610 --> 00:41:40.234
much more and
00:41:40.234 --> 00:41:43.555
really get the full capabilities
of a Checkpoint Security Gateway.
00:41:49.452 --> 00:41:50.160
>> There we go.
00:41:50.160 --> 00:41:53.630
Okay, so from a protection
perspective, now that you've got
00:41:53.630 --> 00:41:56.100
services both deployed on
premise and in the Cloud,
00:41:56.100 --> 00:41:59.030
you've got another attack factor
that you need to protect against.
00:41:59.030 --> 00:42:01.510
You don't want something to
infiltrate your internal network and
00:42:01.510 --> 00:42:04.170
then be able to infect something
that may be in your cloud services.
00:42:04.170 --> 00:42:06.870
So you've gotta protect
those communications.
00:42:06.870 --> 00:42:09.650
You still have to be worried
about what actually happens
00:42:09.650 --> 00:42:10.490
within the Cloud.
00:42:10.490 --> 00:42:14.900
And protect those services that
are actually in the Cloud directly.
00:42:14.900 --> 00:42:17.420
And if you didn't catch it,
pretty slick animation that
00:42:17.420 --> 00:42:19.990
my marketing team put
together there, huh?
00:42:19.990 --> 00:42:21.550
And then,
00:42:21.550 --> 00:42:25.980
it's not news to anybody that
data's the biggest thing, right?
00:42:27.000 --> 00:42:30.760
Not much time goes by between
news reports of 80 million
00:42:30.760 --> 00:42:34.000
healthcare records lost or
credit cards lost.
00:42:34.000 --> 00:42:36.630
I'd bet the majority of you have
probably had to replace a credit
00:42:36.630 --> 00:42:39.580
card at some point because
somebody in some foreign country
00:42:39.580 --> 00:42:41.260
charged something on it. Right?
00:42:41.260 --> 00:42:41.840
So
00:42:41.840 --> 00:42:45.550
protecting corporate data
obviously is a really big thing.
00:42:45.550 --> 00:42:48.100
So from a Check Point perspective,
how do we do that?
00:42:48.100 --> 00:42:50.750
So I mentioned multiple
functionalities across
00:42:50.750 --> 00:42:51.930
the security landscape.
00:42:53.600 --> 00:42:57.006
Supporting Azure as
a deployment environment and
00:42:57.006 --> 00:42:59.450
you as you can see here
a bunch of check boxes
00:42:59.450 --> 00:43:01.520
calling out different
security functionalities.
00:43:01.520 --> 00:43:04.870
You can stand up are virtual clients
with Azure and with a click of
00:43:04.870 --> 00:43:08.990
a button, check a box when to enable
new security functionalities.
00:43:08.990 --> 00:43:12.110
And then as these environments
get more and more complex, and
00:43:12.110 --> 00:43:14.580
you've got infrastructure
all over the place.
00:43:14.580 --> 00:43:16.645
You've got multiple
locations to manage that.
00:43:16.645 --> 00:43:20.290
[INAUDIBLE]
There we go.
00:43:20.290 --> 00:43:24.530
One of the things that Check Point
does is give you the capability to
00:43:24.530 --> 00:43:27.180
manage your infrastructure
whether it's On-Premise or
00:43:27.180 --> 00:43:29.520
in the Cloud from
the same pane of glass.
00:43:29.520 --> 00:43:35.260
So a single unified console to
configure, to manage, to view logs,
00:43:35.260 --> 00:43:38.550
to monitor what's going on within
your particular environment.
00:43:38.550 --> 00:43:41.970
So with that I'm going to
jump quickly to a demo here.
00:43:41.970 --> 00:43:43.630
I want to show you
00:43:45.600 --> 00:43:50.120
what it actually takes to
configure and deploy within Azure.
00:43:50.120 --> 00:43:51.357
So let me plug in here.
00:44:02.339 --> 00:44:03.525
All right.
00:44:03.525 --> 00:44:05.015
So one thing to call out real quick,
00:44:05.015 --> 00:44:08.735
our capabilities do exist today
within the Azure Marketplace.
00:44:08.735 --> 00:44:10.455
Two different
licensing arrangements.
00:44:10.455 --> 00:44:11.845
So you can bring your own license.
00:44:11.845 --> 00:44:15.006
So if you already have Check Point
Security Gateway Licenses those will
00:44:15.006 --> 00:44:17.375
function within a virtual on Azure.
00:44:17.375 --> 00:44:20.325
And we also have
the pay-as-you-go option, right.
00:44:20.325 --> 00:44:24.030
So all directly
integrated with Azure and
00:44:24.030 --> 00:44:26.410
certified as a partner there.
00:44:26.410 --> 00:44:29.990
So real quick, I wanna show you
what's here in the environment.
00:44:29.990 --> 00:44:31.830
So we've got a Virtual Network.
00:44:31.830 --> 00:44:36.380
Within this Virtual Network, we have
three different subnets to find.
00:44:36.380 --> 00:44:39.640
So you can go ahead and
configure each of these.
00:44:39.640 --> 00:44:44.030
We've used just three different
address spaces on 10-dot networks.
00:44:44.030 --> 00:44:45.190
So you can see those three there.
00:44:45.190 --> 00:44:49.210
I'm going to go back and
take a look at the dashboard here.
00:44:49.210 --> 00:44:52.720
You can see, we actually have
only three Virtual Machines
00:44:52.720 --> 00:44:54.100
today in this demo environment.
00:44:54.100 --> 00:44:56.320
So there's an Application Server
on the back end.
00:44:56.320 --> 00:44:57.640
There's a Web Server
on the back end.
00:44:57.640 --> 00:45:00.920
And then there's a Check Point
Gateway sitting on the front-end.
00:45:00.920 --> 00:45:05.029
And that Check Point Gateway, we use
00:45:05.029 --> 00:45:09.860
we've got certain
end points defined.
00:45:09.860 --> 00:45:13.270
That allow us to translate
the public IP that
00:45:13.270 --> 00:45:18.070
sits on that gateway to
private IP addresses.
00:45:18.070 --> 00:45:21.705
And then use address translation
within Azure to translate to those
00:45:21.705 --> 00:45:23.450
back-end servers that are sitting
on private IP addresses.
00:45:23.450 --> 00:45:25.520
So I go here and
I'll take a look at this.
00:45:28.180 --> 00:45:31.720
Right, so now I'm looking at the
actual Virtual Machine Configuration
00:45:31.720 --> 00:45:32.770
of our Security Gateway.
00:45:32.770 --> 00:45:35.660
And if I take a look at
these endpoints, so for
00:45:35.660 --> 00:45:39.935
purposes of just getting a really
simple demonstration up and running.
00:45:39.935 --> 00:45:41.845
Couple of different services.
00:45:41.845 --> 00:45:44.025
So HTTP we're allowing in.
00:45:44.025 --> 00:45:46.225
SSH so we can actually get
in from the command line and
00:45:46.225 --> 00:45:47.225
manage the appliance.
00:45:47.225 --> 00:45:49.895
And then you see a different
port there, that 18190.
00:45:49.895 --> 00:45:52.575
That's the Check Point Management
Protocol that's gonna actually allow
00:45:52.575 --> 00:45:54.545
us to get in and look at policy.
00:45:54.545 --> 00:45:59.435
And so now I'm gonna go ahead and
log into our management consul here.
00:45:59.435 --> 00:46:02.890
And this is actually connecting
by the public IP on this gateway.
00:46:02.890 --> 00:46:06.951
And via those end points getting
translated to the private IP sitting
00:46:06.951 --> 00:46:08.710
on that Check Point Gateway.
00:46:16.541 --> 00:46:19.148
Always fun to wait for
things to load here.
00:46:38.141 --> 00:46:40.289
As it would have it,
an hour passes by and
00:46:40.289 --> 00:46:42.135
the demonstration does not work.
00:46:48.898 --> 00:46:54.110
So in the interest of time,
I can show you the live demo later.
00:46:54.110 --> 00:46:56.690
I'm gonna run this in demo mode and
show you a couple
00:46:56.690 --> 00:47:01.050
of things that you end up doing
from a policy perspective.
00:47:01.050 --> 00:47:05.180
When you've got those endpoints
defined as we do here, that's going
00:47:05.180 --> 00:47:07.750
to translate the public IP address
to that particular machine.
00:47:07.750 --> 00:47:10.800
Now what we're doing actually in
this demonstration environment
00:47:10.800 --> 00:47:12.990
is we've got that HTTP call.
00:47:12.990 --> 00:47:19.210
That is actually going to translate
via in our Check Point Rulebase,
00:47:19.210 --> 00:47:23.270
so I show you here what network
address translation looks like.
00:47:23.270 --> 00:47:26.140
Basically, what we're doing is we're
creating an address translation
00:47:26.140 --> 00:47:29.560
rule within our policy that says
take anything that comes into
00:47:29.560 --> 00:47:32.550
the private IP address of our
Check Point Security Gateway.
00:47:32.550 --> 00:47:35.900
And if it's HTTP, we're actually
gonna translate that to
00:47:35.900 --> 00:47:39.470
the back end web server and
get HTTP there.
00:47:39.470 --> 00:47:43.154
If I browse here,
00:47:43.154 --> 00:47:47.329
I should get a copy of
00:47:47.329 --> 00:47:52.250
a Check Point Website.
00:47:52.250 --> 00:47:55.280
Basically we went ahead and
took a Check Point Website.
00:47:55.280 --> 00:47:56.140
Copy and pasted it.
00:47:56.140 --> 00:47:59.300
If I can't connect by the management
server then something's going
00:47:59.300 --> 00:48:00.510
on with virtual environment today.
00:48:00.510 --> 00:48:01.610
But effectively,
00:48:01.610 --> 00:48:05.640
what we're doing is, and
points allow you to translate
00:48:05.640 --> 00:48:09.580
the public IP address of a gateway
sitting out in front of your network
00:48:09.580 --> 00:48:12.740
infrastructure to the private IP
addresses that sit internally.
00:48:12.740 --> 00:48:17.790
And the fact that now we've got the
routing capabilites to route within
00:48:17.790 --> 00:48:21.320
internal subnets in Azure, you can
take your network segmentation
00:48:21.320 --> 00:48:24.340
strategy from the physical world
that your using in your data center.
00:48:24.340 --> 00:48:26.800
Separating your users from
Application Servers from
00:48:26.800 --> 00:48:29.390
the Database Servers and
you can provide the same kind
00:48:29.390 --> 00:48:31.690
of segmentation
capabilities up in Azure.
00:48:32.880 --> 00:48:35.170
With that,
I'll leave it to the next.
00:48:35.170 --> 00:48:35.752
>> Thank you, Adam.
00:48:35.752 --> 00:48:41.390
[APPLAUSE]
>> [INAUDIBLE]
00:48:41.390 --> 00:48:44.210
And next up, we have Cisco.
00:48:44.210 --> 00:48:46.295
Coming to showcase our CSR 1000V.
00:48:55.779 --> 00:48:57.590
>> [INAUDIBLE]
00:49:07.853 --> 00:49:08.630
>> Perfect.
00:49:08.630 --> 00:49:10.160
Can everybody hear me, okay?
00:49:10.160 --> 00:49:11.520
Sounds like it’s working.
00:49:11.520 --> 00:49:12.960
So my name is Jim Jolts.
00:49:12.960 --> 00:49:14.282
I am the product manager for
00:49:14.282 --> 00:49:17.765
a product that we call
the Cloud Services Router 1000V.
00:49:17.765 --> 00:49:20.020
And I was hoping I'd have
a demo ready today but
00:49:20.020 --> 00:49:22.860
as I mentioned at the beginning
of the presentation,
00:49:22.860 --> 00:49:26.300
the routing functionality just
became available on Azure.
00:49:26.300 --> 00:49:28.920
So we're working through some
testing there and we can get
00:49:28.920 --> 00:49:31.480
some demos set up with anyone
interested in seeing them shortly.
00:49:32.890 --> 00:49:35.611
So what is
the Cloud Service Router 1000V,
00:49:35.611 --> 00:49:37.900
otherwise called the CSR 1000V?
00:49:37.900 --> 00:49:40.540
Well, if you're kind of
hip to the Cisco lingo,
00:49:40.540 --> 00:49:42.870
you know we are a big
fan of acronyms.
00:49:42.870 --> 00:49:47.520
And it fits in with the ISR and
the ASR Series Routers.
00:49:47.520 --> 00:49:51.870
So the ISR 4400 Series Router and
the ASR 1000 Series Router.
00:49:51.870 --> 00:49:53.230
Both of those run iOS XE.
00:49:53.230 --> 00:49:54.650
That's kind of our latest and
00:49:54.650 --> 00:49:57.360
greatest Routing Operating System
on the routers.
00:49:57.360 --> 00:50:00.372
And the CSR now is that
exact same Software Platform
00:50:00.372 --> 00:50:02.411
turned into a Virtual Appliance.
00:50:02.411 --> 00:50:04.536
So we essentially took
what traditionally is on
00:50:04.536 --> 00:50:07.670
a Hardware Running Platform, turned
it into a Virtual Appliance that
00:50:07.670 --> 00:50:09.331
runs on all the normal hypervisors.
00:50:09.331 --> 00:50:13.013
And also runs on a number of
different Cloud Platforms including
00:50:13.013 --> 00:50:13.700
Azure now.
00:50:13.700 --> 00:50:16.474
So we're going through the final
testing phases of it on Azure and
00:50:16.474 --> 00:50:19.149
we're hoping we'll have it on
the marketplace within the next
00:50:19.149 --> 00:50:19.710
month or so.
00:50:20.770 --> 00:50:23.550
And it's not really just
a routing platform.
00:50:23.550 --> 00:50:27.010
It encompasses a whole bunch of
different network services that
00:50:27.010 --> 00:50:29.210
are all built into iOS XE.
00:50:29.210 --> 00:50:32.724
So routing obviously is number one.
00:50:32.724 --> 00:50:35.181
What we mainly see people
using the product for
00:50:35.181 --> 00:50:36.820
is VPN termination though.
00:50:36.820 --> 00:50:38.330
So I'll show you on the coming
slides what some of
00:50:38.330 --> 00:50:39.460
the architectures look like for VPN.
00:50:40.510 --> 00:50:44.838
But, typically we have enterprise
customers that are using ISRs and
00:50:44.838 --> 00:50:47.150
ASRs to build their
enterprise networks.
00:50:47.150 --> 00:50:49.720
Maybe they're a traditional
enterprise with lots of different
00:50:49.720 --> 00:50:50.540
corporate offices.
00:50:50.540 --> 00:50:54.200
Maybe it's a retail business with
lots of different retail locations.
00:50:54.200 --> 00:50:56.730
Hospitality, hotels,
those sorts of things.
00:50:56.730 --> 00:51:00.440
And you've gone through all sorts of
different engineering exercises and
00:51:00.440 --> 00:51:03.740
work to get this enterprise
network built and tuned and
00:51:03.740 --> 00:51:07.180
set up in a way that you can manage
it using technologies like DMVPN and
00:51:07.180 --> 00:51:10.200
all sorts of things that give
you NE to NE connectivity.
00:51:10.200 --> 00:51:13.010
Now if you want to extend some of
your applications into the cloud
00:51:13.010 --> 00:51:16.075
like Microsoft Azure You don't
wanna have to go through and
00:51:16.075 --> 00:51:17.290
re-architect all that stuff,
00:51:17.290 --> 00:51:19.730
touch all the different sites to
make them connect into the cloud.
00:51:19.730 --> 00:51:22.460
You just wanna be able to
simply extend your existing
00:51:22.460 --> 00:51:24.170
design into the cloud.
00:51:24.170 --> 00:51:26.120
And that's where the CSR
comes into the picture.
00:51:29.556 --> 00:51:31.180
Cool, clicker's working.
00:51:31.180 --> 00:51:34.380
So really, what we've tried to do as
goal here with the CSR is to take
00:51:34.380 --> 00:51:36.962
the functionality that we had
in iOS XE feature set that
00:51:36.962 --> 00:51:40.108
everybody is used to for building
their enterprise networks, and
00:51:40.108 --> 00:51:43.510
make it available anywhere
that you would want to use it.
00:51:43.510 --> 00:51:46.210
So almost everybody traditionally
starts on the left-hand side of
00:51:46.210 --> 00:51:46.750
this diagram.
00:51:46.750 --> 00:51:49.740
They have some physical
enterprise locations.
00:51:49.740 --> 00:51:51.810
As I mentioned, office buildings,
retail locations,
00:51:51.810 --> 00:51:52.770
those sorts of things.
00:51:52.770 --> 00:51:56.250
And they've built this network on
Cisco platforms like the ISRs and
00:51:56.250 --> 00:51:57.590
the ASRs.
00:51:57.590 --> 00:51:59.680
So we launched the CSR and
took that functionality,
00:51:59.680 --> 00:52:00.930
put into virtual environments.
00:52:00.930 --> 00:52:05.380
So if you build private data centers
on any of the common hypervisors.
00:52:05.380 --> 00:52:09.040
And you can then use the CSR to
bring connectivity from all those
00:52:09.040 --> 00:52:12.770
physical locations now into those
virtualized data centers as well.
00:52:12.770 --> 00:52:14.980
And then, finally,
on the right hand side,
00:52:14.980 --> 00:52:17.740
we've now taken that same platform
and moved it into some of
00:52:17.740 --> 00:52:21.220
the most popular cloud
platforms in the world today.
00:52:21.220 --> 00:52:23.930
And we're going to keep expanding
that list so that you can really
00:52:23.930 --> 00:52:26.493
take your existing Cisco
infrastructure and your design that
00:52:26.493 --> 00:52:29.401
you've built with connectivity to
all your locations and very easily
00:52:29.401 --> 00:52:32.376
connect into all these different
cloud platforms, including Azure.
00:52:36.092 --> 00:52:39.654
So really what it looks like is
if you're an existing enterprise,
00:52:39.654 --> 00:52:41.215
does the clicker work here.
00:52:41.215 --> 00:52:45.210
Closer?
00:52:45.210 --> 00:52:48.510
So you have your existing enterprise
locations and hooking together all
00:52:48.510 --> 00:52:54.040
those enterprise locations you have
an existing enterprise network.
00:52:54.040 --> 00:52:56.830
So this is the glue that you've
built, you've engineered to
00:52:56.830 --> 00:53:00.750
tie all of your locations together
and keep all of your users happy.
00:53:00.750 --> 00:53:02.290
And now if you're
gonna be expanding or
00:53:02.290 --> 00:53:05.950
moving some of your applications
into the cloud, come on.
00:53:05.950 --> 00:53:09.790
[LAUGH]
There we go.
00:53:09.790 --> 00:53:11.860
So now we got
Microsoft Azure turned up,
00:53:11.860 --> 00:53:14.680
you can then just basically
expand your existing enterprise
00:53:14.680 --> 00:53:17.400
network to connect into Microsoft
Azure without having to go and
00:53:17.400 --> 00:53:19.410
touch all of these individual sites.
00:53:19.410 --> 00:53:21.150
Turn up new VPN tunnels.
00:53:21.150 --> 00:53:24.640
You can do a couple lines of
config and reconfigure DMVPN and
00:53:24.640 --> 00:53:27.240
all of those sites will
automatically have access into
00:53:27.240 --> 00:53:29.500
the applications that you've
moved into Microsoft Azure.
00:53:29.500 --> 00:53:32.040
And as I mentioned we'll
keep expanding into
00:53:32.040 --> 00:53:34.720
additional clouds as well so
that we can give you unified
00:53:34.720 --> 00:53:37.170
connectivity using
your existing policies.
00:53:37.170 --> 00:53:39.110
Existing firewall policies for
tunnels.
00:53:39.110 --> 00:53:41.030
Existing firewall rules.
00:53:41.030 --> 00:53:43.730
All the different functionalities
that you have configured into iOS XE
00:53:43.730 --> 00:53:45.960
you can just expand into
whatever cloud provider
00:53:47.000 --> 00:53:48.030
you choose to expand into.
00:53:49.390 --> 00:53:51.085
So really in a nutshell,
00:53:51.085 --> 00:53:54.568
what the benefits are of
taking this approach are.
00:53:54.568 --> 00:53:56.055
You have an IT staff,
00:53:56.055 --> 00:54:00.280
they understand how to configure
Cisco products using iOS.
00:54:00.280 --> 00:54:02.794
They've gone through all
the engineering efforts to build
00:54:02.794 --> 00:54:05.560
topologies around different
routing architectures if they're
00:54:05.560 --> 00:54:07.080
using dynamic routing protocols.
00:54:07.080 --> 00:54:09.350
And you've got tons of
subnets all over the place.
00:54:09.350 --> 00:54:12.845
You wanna make sure you have
cohesive connectivity across all of
00:54:12.845 --> 00:54:14.830
your sites, across your clouds.
00:54:14.830 --> 00:54:16.530
You have existing VPN architectures.
00:54:16.530 --> 00:54:18.800
You have existing firewall rules.
00:54:18.800 --> 00:54:19.800
All the different features and
00:54:19.800 --> 00:54:22.140
services that we have
built into the CSR.
00:54:22.140 --> 00:54:25.780
And additionally, the CSR has
a container functionality built into
00:54:25.780 --> 00:54:29.160
it, meaning we have other groups at
Cisco that are building containers
00:54:29.160 --> 00:54:31.760
to put inside the CSR to
bring additional security and
00:54:31.760 --> 00:54:34.390
network services into
a single VM that you can
00:54:34.390 --> 00:54:36.230
then easily deploy into the cloud.
00:54:36.230 --> 00:54:38.210
So all of these different
technologies and
00:54:38.210 --> 00:54:39.650
features that you've
already gone through and
00:54:39.650 --> 00:54:43.572
trained and learned how to use
through the Cisco products.
00:54:43.572 --> 00:54:45.000
It's gonna be familiar, and
00:54:45.000 --> 00:54:51.220
when you expand into the cloud using
the iOS XE based platform in CSR,
00:54:51.220 --> 00:54:53.230
it's all going to look and
feel and work the same.
00:54:53.230 --> 00:54:55.300
It'll integrate with your
existing management tools.
00:54:56.620 --> 00:55:00.380
You can export flows using NetFlow
to do analysis on your traffic.
00:55:00.380 --> 00:55:02.130
All those standard tools that
you're used to are still
00:55:02.130 --> 00:55:04.070
going to continue to
work in Azure as well.
00:55:05.240 --> 00:55:08.750
So really that's the benefit
of CSR in a nutshell.
00:55:08.750 --> 00:55:11.390
And I'll stick around after
the presentation if anybody has any
00:55:11.390 --> 00:55:13.570
specific questions on the platform.
00:55:13.570 --> 00:55:16.900
And keep an eye on the marketplace,
just do a search for Cisco and
00:55:16.900 --> 00:55:18.800
we should pop up there
within the next few weeks.
00:55:18.800 --> 00:55:20.600
We're just going through
the last little bit testing
00:55:20.600 --> 00:55:21.210
that we need to do.
00:55:21.210 --> 00:55:22.454
And then we'll be a certified
00:55:22.454 --> 00:55:24.404
virtual appliance in
the Azure Marketplace.
00:55:26.725 --> 00:55:29.606
And with that I will turn it
over to the next presenter.
00:55:29.606 --> 00:55:32.969
>> Thank you for this.
00:55:32.969 --> 00:55:35.900
>> [APPLAUSE]
>> So this is the last one.
00:55:35.900 --> 00:55:38.540
Definitely the last one,
not the least, Fortinet.
00:55:38.540 --> 00:55:43.425
We have Chad and Jason from
Fortinet I'll hand it over to you.
00:55:43.425 --> 00:55:47.000
>> Is this on?
00:55:47.000 --> 00:55:50.500
Good morning folks, I know we're
just about out of time and so for
00:55:50.500 --> 00:55:53.200
that, it's a little
bit like speed dating.
00:55:53.200 --> 00:55:55.550
I'm going to run through the front
side of what Fortinet's about and
00:55:55.550 --> 00:55:58.430
then Jason's going to
walk through the demo.
00:55:58.430 --> 00:56:00.232
Go ahead and advance the chart here.
00:56:02.345 --> 00:56:05.240
Security's awfully
topical these days.
00:56:05.240 --> 00:56:07.120
We all see all the major
breaches that have taken place.
00:56:07.120 --> 00:56:10.440
Some of the more namely ones,
from Sony,
00:56:10.440 --> 00:56:14.900
Anthem just recently,
Home Depot, and others.
00:56:14.900 --> 00:56:16.239
It's not just credit
card information.
00:56:18.420 --> 00:56:19.970
It's healthcare records.
00:56:19.970 --> 00:56:21.330
It's employee records.
00:56:21.330 --> 00:56:22.700
This is very valuable.
00:56:22.700 --> 00:56:25.900
So we're seeing this continuing
to be an ongoing issue
00:56:25.900 --> 00:56:28.940
that you either have noticed
in the marketplace today, and
00:56:28.940 --> 00:56:31.950
has been publicized or
non-publicized.
00:56:31.950 --> 00:56:35.520
What you're seeing here is
a capture of our threat map.
00:56:35.520 --> 00:56:38.520
This is an integrated offering that
we have within FortiGuard Labs which
00:56:38.520 --> 00:56:42.600
is our in-house threat research
about what's taking place.
00:56:42.600 --> 00:56:44.215
This is showing you
were the bad guys are.
00:56:44.215 --> 00:56:45.933
You're seeing the frequency and
00:56:45.933 --> 00:56:49.220
you're seeing the severity
of the attacks.
00:56:49.220 --> 00:56:51.350
This is something that
actually takes place and
00:56:51.350 --> 00:56:54.700
is an offered service that we have
throughout all of our customers.
00:56:54.700 --> 00:57:00.580
As the other folks have talked about
earlier in the presentation today,
00:57:00.580 --> 00:57:02.360
cloud is a big piece of what
we're doing at Fortinet.
00:57:02.360 --> 00:57:07.774
We're already offered out on
AWUS and we'll actually be
00:57:07.774 --> 00:57:13.074
out on Marketplace and
published both in terms of BYOL,
00:57:13.074 --> 00:57:18.740
in June followed shortly after
with our commerce version.
00:57:18.740 --> 00:57:21.080
So just a quick thing on Fortinet.
00:57:21.080 --> 00:57:23.260
We have over 220,000 customers.
00:57:23.260 --> 00:57:24.940
We have two million endpoints.
00:57:24.940 --> 00:57:28.689
That gives us a great swath across
the market place of what's taking
00:57:28.689 --> 00:57:30.472
place and our threat research.
00:57:30.472 --> 00:57:33.590
We're headquartered in Sunnyvale,
California.
00:57:33.590 --> 00:57:37.290
More importantly, we have an
integrated security offering across
00:57:37.290 --> 00:57:40.290
our entire portfolio, so
you have a common posture.
00:57:40.290 --> 00:57:43.680
Whether you have your assets
dedicated in your own facilities or
00:57:43.680 --> 00:57:46.370
you move them to the cloud,
it's all the same OS.
00:57:46.370 --> 00:57:47.350
Same security posture.
00:57:49.680 --> 00:57:52.140
What you're seeing off to
the right is a bunch of
00:57:52.140 --> 00:57:54.470
different disparate
security solutions.
00:57:54.470 --> 00:57:56.360
What you get with an RVHD,
00:57:56.360 --> 00:58:01.530
that's available within Azure, is
a unified approach, all integrated.
00:58:01.530 --> 00:58:06.150
Whether it's application control,
whether it's antivirus, IPS, all of
00:58:06.150 --> 00:58:10.720
that is offered as a one solution to
cover all these different threats.
00:58:10.720 --> 00:58:12.768
So with that I'm gonna go ahead and
hand it off to Jason.
00:58:12.768 --> 00:58:16.139
He's gonna walk through what the
configuration is and a quick demo.
00:58:22.525 --> 00:58:25.045
>> Absolutely,
that thing is working now.
00:58:25.045 --> 00:58:28.870
[LAUGH] Thank you, my name once
again, Jason Bandouveras, product
00:58:28.870 --> 00:58:32.770
management for virtualization
solutions at Fortinet.
00:58:32.770 --> 00:58:37.460
Only wanna spend roughly 35
seconds on my two slides.
00:58:37.460 --> 00:58:41.180
We wanted to put this one up there
first, kind of use it as a visual
00:58:41.180 --> 00:58:44.750
representation of what your security
infrastructure could look like,
00:58:44.750 --> 00:58:48.090
within Azure, and it probably should
look very familiar to some of you,
00:58:48.090 --> 00:58:51.070
cause I'd like to think some of that
is also within your core environment
00:58:51.070 --> 00:58:52.800
at your data centers. Right?
00:58:52.800 --> 00:58:53.730
It could be.
00:58:53.730 --> 00:58:56.180
Obviously, the core
firewalling technology and
00:58:56.180 --> 00:58:57.880
advanced security pieces of that.
00:58:57.880 --> 00:59:02.110
But, you're also going to be
utilizing centralized management,
00:59:02.110 --> 00:59:04.122
central reporting analytics.
00:59:04.122 --> 00:59:09.007
We're putting strong authentication,
application delivery,
00:59:09.007 --> 00:59:12.146
as well as some point
security solutions,
00:59:12.146 --> 00:59:16.943
like WAFs, web application
firewalls, anti-spam gateways,
00:59:16.943 --> 00:59:22.544
advanced threat protection, doing
some sandboxing, along those lines.
00:59:22.544 --> 00:59:27.173
But we're specifically, what we're
launching here into the Azure
00:59:27.173 --> 00:59:31.721
environment, and what we're gonna
attempt to do a walkthrough and
00:59:31.721 --> 00:59:36.030
demo of, is specifically our
Fortinet flagship solution, and
00:59:36.030 --> 00:59:38.510
that ist he FortiGate VM.
00:59:38.510 --> 00:59:43.370
So let me try to bring this up.
00:59:43.370 --> 00:59:44.810
Outstanding.
00:59:44.810 --> 00:59:46.687
So, well actually let me log in,
00:59:46.687 --> 00:59:49.310
cuz it's much more
beautiful when you log in.
00:59:51.680 --> 00:59:56.000
Is anybody here familiar with
Fortinet before I get going or
00:59:56.000 --> 00:59:58.390
doing any day-to-day administration?
00:59:58.390 --> 01:00:01.750
Okay, so at least there was
a couple of arms up besides mine.
01:00:01.750 --> 01:00:04.910
This screen should look very
familiar to you, right?
01:00:04.910 --> 01:00:10.392
So, Fortinet owns the operating
system as well as the application,
01:00:10.392 --> 01:00:11.061
right?
01:00:11.061 --> 01:00:13.821
We're not just installing
on some base OS.
01:00:13.821 --> 01:00:16.321
We've actually built
our own 40 OS right.
01:00:16.321 --> 01:00:19.977
For the net operating system so
we are able to optimize the OS with
01:00:19.977 --> 01:00:23.890
the application and
be able to deploy this out there.
01:00:23.890 --> 01:00:27.680
You should also, if you're familiar
with 40 net, find this screen
01:00:27.680 --> 01:00:31.800
very familiar because it's
the exact same operating system and
01:00:31.800 --> 01:00:36.696
application that is running in your
FortiGate hardware appliances.
01:00:36.696 --> 01:00:40.570
That are running in your FortiGate
virtual appliances that we launched
01:00:40.570 --> 01:00:45.090
back in 2010, as well as
if you're running it within
01:00:45.090 --> 01:00:46.840
your Hyper V environment, right?
01:00:46.840 --> 01:00:51.270
All of those are the same exact
operating system and application
01:00:51.270 --> 01:00:55.860
that are going to be running within
the FortiGate VM in the Azure cloud.
01:00:55.860 --> 01:01:00.630
Alright so the dashboard
here is very customizable.
01:01:00.630 --> 01:01:03.770
It's kind of the state of affairs of
what your first looking at when you
01:01:03.770 --> 01:01:04.280
roll in.
01:01:04.280 --> 01:01:07.420
It's full of just basic information,
widgets,
01:01:07.420 --> 01:01:10.270
you can actually be
very customizable.
01:01:10.270 --> 01:01:13.620
I can sit here and
add widgets into the environment.
01:01:13.620 --> 01:01:17.910
I can move them around so they're
better fit for what I'm looking at.
01:01:17.910 --> 01:01:23.580
Right, so very straightforward very
easy, very customizable by you.
01:01:23.580 --> 01:01:28.401
Now what I'm gonna be going through
here is walking through just
01:01:28.401 --> 01:01:33.300
this interface that's logging
into FortiGate VM itself.
01:01:33.300 --> 01:01:36.370
But we also have the centralized
management, so one of our
01:01:38.030 --> 01:01:40.920
peers had already mentioned single
pane of glass management and
01:01:40.920 --> 01:01:43.020
that's also the case here.
01:01:43.020 --> 01:01:46.150
You can take that one
centralized manager and
01:01:46.150 --> 01:01:49.362
be able to manage your policy
whether it's in the cloud with
01:01:49.362 --> 01:01:53.610
a FortiGate VM for Azure, whether
it's in your main data center
01:01:53.610 --> 01:01:56.630
with your core FortiGate
hardware devices.
01:01:56.630 --> 01:02:00.440
Or out in your branch and remote
offices for other FortiGate hardware
01:02:00.440 --> 01:02:05.420
devices, remote office devices,
or virtual appliances.
01:02:05.420 --> 01:02:06.930
Now as I'm talking
about these widgets,
01:02:06.930 --> 01:02:10.470
I want to show you specifically
here, this one here, right.
01:02:10.470 --> 01:02:13.150
These are the features
of FortiGate VM.
01:02:13.150 --> 01:02:16.090
It's not just a firewall but it has
all the advanced features that you
01:02:16.090 --> 01:02:20.270
are gonna be looking for, right,
IPS, AV application control,
01:02:20.270 --> 01:02:23.930
DLP, as well as URL filtering.
01:02:23.930 --> 01:02:28.210
And I also wanna highlight how easy
it is just to enable these features.
01:02:28.210 --> 01:02:33.340
I don't have to go through
any advanced CLI commands.
01:02:33.340 --> 01:02:37.720
All I have to do if I wanna turn
on email filtering is click on and
01:02:37.720 --> 01:02:39.130
hit apply.
01:02:39.130 --> 01:02:42.450
Right, and now it's enabled
within that environment.
01:02:42.450 --> 01:02:45.160
Now taking a step further from that
01:02:45.160 --> 01:02:49.130
I can now setup very
grandular security policies.
01:02:49.130 --> 01:02:52.420
So you can see on the left
I've got AV, IPS, etc.
01:02:52.420 --> 01:02:55.620
And we have a lot of default
policies that come with this.
01:02:55.620 --> 01:02:58.460
Like if I was to look at intrusion
prevention here you can see I have
01:02:58.460 --> 01:03:01.200
a few default policies
already set up that come with
01:03:01.200 --> 01:03:03.000
the basic environment.
01:03:03.000 --> 01:03:05.720
But let's say I want to make my own.
01:03:05.720 --> 01:03:06.670
So I'm going to sit here and
01:03:06.670 --> 01:03:12.050
I'm going to set up a specific
AV policy called Azure Test.
01:03:12.050 --> 01:03:13.168
I want it to be,
01:03:13.168 --> 01:03:17.565
Azure Test 2, I guess I had
already set that up before.
01:03:17.565 --> 01:03:21.115
I wanna set it up as proxy,
as opposed to flow based.
01:03:21.115 --> 01:03:25.475
I wanna set it up just for
HTTP and just for FTP.
01:03:25.475 --> 01:03:28.105
And it's as simple as that, as
well as setting up the other ones.
01:03:28.105 --> 01:03:31.620
Now these security profiles,
once again can be
01:03:31.620 --> 01:03:35.690
as granular as you want them to be
or they can be default policies.
01:03:35.690 --> 01:03:39.280
You also have the capabilities
to use them in multiple security
01:03:39.280 --> 01:03:40.710
policies, right?
01:03:40.710 --> 01:03:43.680
So let me take the next step
over and take a look at
01:03:43.680 --> 01:03:46.470
our security policy that we
have within this environment.
01:03:48.280 --> 01:03:50.420
So we have a few
rules sets in there.
01:03:52.220 --> 01:03:53.830
Let's say I wanna
highlight this guy, and
01:03:53.830 --> 01:03:55.990
I wanna add my new AV policy.
01:03:55.990 --> 01:04:02.300
All I gotta do is right click,
select policy, Azure Test 2, done.
01:04:02.300 --> 01:04:07.270
I wanna add application control, so
01:04:07.270 --> 01:04:10.150
I can easily do that,
block point to point.
01:04:10.150 --> 01:04:13.300
But another thing I wanna mention
on these policies, once again,
01:04:13.300 --> 01:04:16.708
they can be general or
they can be very granular.
01:04:16.708 --> 01:04:18.800
From a granular stand point,
01:04:18.800 --> 01:04:22.250
it doesn't have to be
just an IP based policy.
01:04:22.250 --> 01:04:23.990
Or an object based policy.
01:04:23.990 --> 01:04:26.060
I can set them up on users.
01:04:26.060 --> 01:04:28.579
This being a Microsoft conference,
01:04:28.579 --> 01:04:32.888
I can literally integrate this
thing with active directory and
01:04:32.888 --> 01:04:37.720
then base my policies on active
directory users or user groups.
01:04:37.720 --> 01:04:40.880
So I can sit here and drill down and
say I wanna do this for
01:04:40.880 --> 01:04:45.280
my guest group, and you know what,
I only wanna set up this policy for
01:04:45.280 --> 01:04:46.640
mobile devices, right?
01:04:46.640 --> 01:04:49.530
So once again very flexible and
easy for
01:04:49.530 --> 01:04:52.310
you to set up these
extremely granular policies.
01:04:54.140 --> 01:04:54.840
Now, let me roll down.
01:04:54.840 --> 01:04:58.960
I'm gonna cancel out of that and
come back to our main policy page.
01:04:58.960 --> 01:05:03.020
I also wanna hit on, very briefly,
just I don't wanna hammer it
01:05:03.020 --> 01:05:06.030
in because the Cisco gentlemen
right before me talked about it,
01:05:06.030 --> 01:05:10.130
but, once again, and you Sean
had also brought it up, right.
01:05:10.130 --> 01:05:13.300
Azure portal,
you can set up site to site VPNs,
01:05:13.300 --> 01:05:18.290
but when deploying a FortiGate VM
within your Azure environment,
01:05:18.290 --> 01:05:19.650
now it can set up a full hub and
01:05:19.650 --> 01:05:24.680
spoke site to site VPN setup to my
remote offices, my branch offices,
01:05:24.680 --> 01:05:29.140
my DC, all going in and out of here
and having it terminate directly on
01:05:29.140 --> 01:05:35.590
the FortiGate VM itself as opposed
to the general Azure IP sect point.
01:05:35.590 --> 01:05:38.690
Now just, and I'm almost done,
one more thing.
01:05:38.690 --> 01:05:43.860
Just to kind of prove that I'm not
just going through the screens here.
01:05:43.860 --> 01:05:48.330
I had set up a RGP session,
which hopefully,
01:05:48.330 --> 01:05:51.510
you guys wouldn't do, to my backend.
01:05:51.510 --> 01:05:55.070
So, I actually have a Windows
12 server in the back.
01:05:55.070 --> 01:06:01.010
And I am going to attempt
to download a file
01:06:01.010 --> 01:06:06.098
that is infected, everybody should
be familiar with that carrier.
01:06:06.098 --> 01:06:07.370
Download.
01:06:10.795 --> 01:06:13.877
Now it should pop up and
give me my warning now that hey,
01:06:13.877 --> 01:06:17.240
you're trying to download
an infected file.
01:06:17.240 --> 01:06:18.600
Don't do that, right?
01:06:18.600 --> 01:06:20.330
And it doesn't automatically block.
01:06:20.330 --> 01:06:24.210
So the full devices,
as Chad was mentioning,
01:06:24.210 --> 01:06:27.350
we're constantly updating
our databases through
01:06:27.350 --> 01:06:31.000
our fully FortiGaurd deployment
network, as well as updating this.
01:06:31.000 --> 01:06:33.640
So we should probably be out
on the marketplace very soon.
01:06:34.820 --> 01:06:36.890
And I'm about done.
01:06:36.890 --> 01:06:38.000
Actually I am done.
01:06:38.000 --> 01:06:39.060
Absolutely I'm done.
01:06:39.060 --> 01:06:40.560
I do wanna mention
only one more thing.
01:06:40.560 --> 01:06:41.460
Yes, we're gonna be here.
01:06:41.460 --> 01:06:42.640
We're gonna take your questions.
01:06:42.640 --> 01:06:44.870
A small core of our group is here.
01:06:44.870 --> 01:06:48.080
You can also have any
questions at fortinet.com or
01:06:48.080 --> 01:06:50.820
send an email to Azure@fortinet.com.
01:06:50.820 --> 01:06:54.025
And we got a larger group of folks
there that we can hit up and
01:06:54.025 --> 01:06:56.848
set you up for emails,
whatever you'd like to do.
01:06:56.848 --> 01:06:57.418
Thank you.
01:06:57.418 --> 01:07:01.481
[APPLAUSE]
>> Thank you.
01:07:01.481 --> 01:07:05.881
Okay, so really want to thank
all of the partners for
01:07:05.881 --> 01:07:10.050
getting this ready in
such a short notice.
01:07:10.050 --> 01:07:13.350
Let me just go back
to my last slide.
01:07:16.320 --> 01:07:20.250
So basically, here's the message
we want to highlight.
01:07:20.250 --> 01:07:22.140
I can go through the summary.
01:07:22.140 --> 01:07:26.960
But it's that we are building
out an ecosystem.
01:07:26.960 --> 01:07:29.990
These are the lists of partners
that are either currently
01:07:29.990 --> 01:07:34.210
available on Azure Marketplace, or
for some of the partners that you
01:07:34.210 --> 01:07:37.300
are seeing today that we've
been working with very closely.
01:07:37.300 --> 01:07:41.450
So one thing is, if you actually
have appliance with the vendors that
01:07:41.450 --> 01:07:45.090
you are using on premises that you
don't see either in the marketplace
01:07:45.090 --> 01:07:48.640
or not on the slides that we're
working with, please contact us,
01:07:48.640 --> 01:07:49.700
let us know.
01:07:49.700 --> 01:07:52.850
It's not that they have to go
through us to be onboarded.
01:07:52.850 --> 01:07:54.930
So kind of from the product
side of things,
01:07:54.930 --> 01:07:58.420
we are more like consultants, like
helping partners to get onboarded.
01:07:58.420 --> 01:08:02.185
And because running in Azure is
slightly different than running
01:08:02.185 --> 01:08:02.749
on-premises.
01:08:02.749 --> 01:08:04.581
Some layer-two,
layer-three functionality,
01:08:04.581 --> 01:08:06.070
there will be some differences.
01:08:06.070 --> 01:08:08.973
But, by all means, if you see
a vendor that's not listed,
01:08:08.973 --> 01:08:12.398
you cannot find it, do let us know,
and we'll reach out to the vendors
01:08:12.398 --> 01:08:16.110
and we'll start working with them
to help them onboard to Azure.
01:08:16.110 --> 01:08:20.420
And one other thing, the message
coming from customers like you
01:08:20.420 --> 01:08:22.750
will be much,
much stronger than coming from me,
01:08:22.750 --> 01:08:25.920
from Microsoft to say, hey we
actually have customer requests.
01:08:25.920 --> 01:08:28.230
So, by all means,
please talk to your vendors and
01:08:28.230 --> 01:08:32.260
then talk to your Contact in the
partner ecosystem, and let them know
01:08:32.260 --> 01:08:36.060
you want their appliances on Azure,
and we can get that started.
01:08:36.060 --> 01:08:38.750
With that, I'm gonna open up
the floor up for questions.
01:08:38.750 --> 01:08:41.440
And all the partners will be here,
feel free to come up and
01:08:41.440 --> 01:08:43.250
ask them questions directly.
01:08:43.250 --> 01:08:44.270
With that, thank you very much.