- In a previous video, which
I've linked here and below, I explained the concept of
a Software-Defined Network where we have a controller
that's managing network devices. The example that I used was
an OpenFlow based network. That was one of the original
or first Software Defined networks in recent times. There was a lot of hype
about OpenFlow in the past, but never really took off. People today are not really using OpenFlow except in very specific
niche environments. Another version of
software defined networking is what's called an overlay network, where we overlay a network on
top of an underlay network, and in this video, I'm gonna discuss that
in quite a bit of detail. (upbeat techno music) So overlay networks go back a long way in time. So in the old days, we had a
traditional telephone network. The intelligence was in
the telephone network. So the public switched
telephone network that AT&T, would have bought or British
Telecom would have bought here in the UK. The phones were dumb. They didn't even have dial tone without the network giving dial tone to the phone, so the phones were essentially stupid. But then that got revolutionized
with voice over IP. Then suddenly, we were using
the internet as a dumb core, and I shouldn't say it's totally dumb but from a telephone switching
point of view, it was dumb. We were basically setting
up calls across the internet and the devices in the core internet, didn't understand what
the calls were doing. They were just routing IP packets. So I phoned you using
Skype or WhatsApp today. I phone you the internet
doesn't understand what we're doing I mean,
WhatsApp calls are encrypted. So we're setting up a tunnel across the dumb central internet. So the intelligence is now
in the endpoints rather than in the core network. So notice the difference. In the old days intelligence
was in the network, end devices were dumb. That's switch round now, core network is just
high speed forwarding, that's what the internet should be doing, high speed switching routing of traffic, intelligence is in the
edge not in the core. So that was a whole industry
that got revolutionized. The PSTN public switched
telephone network was intelligent, endpoints were dumb. Intelligence was moved to the edge, to the endpoints core became dumb. All it was doing is high
speed forwarding of traffic from A to B. So if I made a call
from the UK to the U.S., the core internet routers
are just trying to move the traffic as quickly as
possible from the UK to the U.S. They don't understand
the call setup process, I mean, WhatsApp, again, is
setting up encrypted calls. The telephone system in WhatsApp or in Skype is out of the
control of the core internet. Okay, so that's great, but
in networking for many years, enterprise networking,
it didn't work that way. We would have, say, Cisco
IP phones on a network, and they would mark their
traffic as important. But then the network had
the intelligence of saying, okay, this traffic is more
important than that traffic. And then we try to implement
all kinds of clever stuff on the network, so the
applications were still done, but the network was intelligent. Notice where I'm going with this, network was intelligent, applications were dumb from the
point of view that a PC just sent traffic to it's default gateway, and then the network took care of things, intelligence in the network
endpoints were dumb. VMware, and others changed this entirely. So VMware purchased a
company called Nicira. Nicira almost got bought by Cisco. But in a data center, when we using ESXi as
an example from VMware, they said, okay, we don't need an intelligent network, we will put the intelligence
in the ESXi servers, in the servers because the
servers have visibility of the applications running on them. The server ESXi server
has visibility of the VMs, and the applications
running on the server. The network can't see the VMs, like the ESXi server can. So rather than having
an intelligent network, we make the network dumb,
just like the internet. It doesn't have visibility of
the applications and the VMs on the ESXi server. And what we do is we set up tunnels across the core network. So you could have and it doesn't matter, it could be Cisco routers,
could be HP switches, it doesn't matter. Your core network is simply
there to route as quickly as possible from one ESXi
server to another ESXi server. And we build what they call
here an overlay network. So we have our IP
network, traditional, say, IP version four, and then we build a whole
new network on top of that called an overlay network. This underlay network,
the physical network, doesn't understand what's going on because all it sees is tunnels. Think of WhatsApp, think of IPsec tunnels that you use across the internet. You can have the internet, and you build encrypted
tunnels across the internet that connect various
sites of your company. So your company may have
sites in the US and the UK, in Canada, in Japan, whatever. You set up these VPNs across the internet, you would be very upset
if the internet routers could actually see
inside your IPsec tunnel. The whole idea of encryption
is to hide the internal network information from the
core internet network. Same principle here. Now we're not using typically
encryption in a data center that use rather than IPsec
tunnels or GRE tunnels they use VXLAN tunnels. The whole idea of a VXLAN is, think of a restriction
in traditional switching, we have 802.1Q, it's restricted
to just over 4000 VLANs. You can only have 4000 VLANs in a network. Now, if you running big ESXi servers, and you have lots of customers, and then you have lots of
departments for lots of customers, and they wanna whole bunch of VLANs, you run out of 4000
VLANs very, very quickly. So VXLAN supports 16 million VLANs, and I say VLANs because that
concept no longer exists, 16 million subnets, rather than 4000 subnets in 802.1Q. So in a traditional switching network, we would create up to 4000 VLANs. That's how we would
implement security let's say by restricting who can
talk to who based on VLANs or subnets, but in a
traditional switched environment we kinda limited that doesn't
scale to a data center. So in a data center, they
wanna use this whole concept and let me go over it again just to make sure that it's clear. We have a core network, could be Cisco routers, Cisco switches. Now notice the politics here, because VMware and Nicira
basically changed the game. The core network now
doesn't have to be fancy, because it's gonna be like the internet. I just need the core routers to route traffic from one ESXi
server, so one VMware server to another VMware server. And just assume we've got a
whole bunch of VMware servers, these VMware servers will set up tunnels to each other automatically. They're not encrypted,
but it's the same concept, they will set up a tunnel
from one ESXi server to another ESXi server, and they will use a
totally different subnet, totally different network. Just like you, if you're setting up a
VPN across the internet, we'll use a different subnet, different IP addressing
to the core internet. You can route RFC 1918 addresses
across the internet agreed, if you use a tunnel. So the outside IP address
would be a public IP address when you're routing from
one router to another using an IPsec tunnel across the internet, but the inside IP addresses
could be RFC 1918 addresses. The core internet doesn't see that data because it's encrypted. So the whole idea in a data
center is the core network could be very simple, basic subnetting. We don't need VLANs we can
run routing everywhere. So, this solved another problem because let's say we wanna
have a VM on one ESXi server and another VM on another ESXi server but we want them in the same VLAN, same VLAN, same broadcast domain, they must be layer two
connection between these two Vms, that are in different servers. Now you might say why
would you wanna do that. Now think about the vMotion. The vMotion is something
that allows you to move a VM, automatically if you want
from one physical ESXi server to another ESXi server. So when the load on the
server gets too high, it can automatically migrate
the VM to another ESXi server to use resources on this ESXi server. But the problem is,
you've now moved the VM, from one server to another
server, but you wanna keep them in the same VLAN. So what happens if I move
it to that server over there using vMotion across a network? Now, traditionally, we
would have to run layer two across this because that VM, and this VM are on the same subnet, so we need to have a layer
two connection across. But with this overlay network
and this concept of doing away with a clever core, the core network can
run routing protocols. So we don't need spanning tree
we just run OSPF everywhere as an example. So it's a layer three network. But this VM running on this ESXi server and this VM running on
this ESXi server can be in the same subnet because they are
connected across a tunnel. So this PC could have an
IP address of 10.1.1.2, this PC could have an IP
address of 10.1.1.1/24 let's say when a broadcast is sent by
this PC, it goes into the tunnel sent across the tunnel to
that PC on the other side. Now it gets complicated with
broadcasts and multicast. But just think of the concept
that these two devices are on the same VLAN when
in actual fact they're not the same VLAN because this
infrastructure is routed. So we are basically
pulling a cable logically, from that VM on that
ESXi server to this VM on this ESXi server. So logically, you've got an
ethernet cable from one side to the other, but it's just
a tunnel created using VXLAN. I went into a lot of detail
here, let me just summarize. Overlay network is a
network that's built on top of an underlay network, underlay network are physical devices, which could be Cisco routers and switches. ESXi from VMware will build, and it's actually NSX, it's not ESXi, it's NSX is
the product that does this. NSX will build, a whole new network, an overlay network across
the underlay network. This underlay network doesn't
understand what's going on with this overlay network. As an analogy, again, think of
this underlay as the internet and the overlay network
as your VPN tunnels going across the internet. The core routers don't have visibility of the traffic that you are encrypting through your IPsec tunnels. The core, Cisco routers and
switches in a data center don't have visibility of the VM traffic going through a VXLAN tunnel, all they see is this
ESXi server wants to talk to this ESXi server, or, this
ESXi server wants to talk to that ESXi server, they don't understand that it's actually a VM running within this ESXi
server that's talking to VM within that ESXi server. So we basically tunneling traffic across. SDN has been very popular
in the data center, but there haven't been many
offerings for the enterprise. So SD-Access is a product
that revolutionizes the way that we configure and manage enterprise networks,
specifically campuses. So SD-Access is used in the campus. SD-WAN can be used in the WAN. Notice the term Software
Defined something. I wanna introduce these concepts now in the automation section, because notice we are automating
networks using a controller or using an application. Rather than manually configuring
network through the CLI, we are automating the networks through the use of a controller. Software-Defined Access,
now just Software Defined, could be Software Defined coffee. I mean, there's so many terms with this word of software
defined, networking got abused. We had software defined
networking, there was OpenFlow, then we had software defined networking that was using API's, we had
Software Defined Networking, there was overlays. So, we spoke about overlays
and underlays already, basically became Software
Defined whatever you like. But Software Defined Access
or SDA is Cisco's solution, of changing the way a
enterprise network works. So traditionally in an enterprise network, we would have spanning tree, that causes a whole bunch of issues because we have to match up
you know forwarding of ports to HSRP default gateways, causes a whole lot of issues, so we wanna do away with spanning tree and what we do is we just run
routing protocols everywhere. So the default gateway of your PCs will be the local access switch. So the switch on the edge, the
switch that they connect to rather than a core switch
or a distribution switch. We run OSPF everywhere or a
routing protocol everywhere so we do away with spanning tree, we do away with port
blocking that kind of stuff. Basically, the idea is the
network gets managed as a fabric. So we have all these routers and switches that are
controlled by a controller, and then similar to NSX from VMware, what we do is we building
tunnels automatically, VXLAN tunnels once again, where we build an overlay
across the underlay network. So the core underlay
network can be fairly basic. Rather than configuring a
whole bunch of access lists on the core devices, we can
do everything as a policy on the SDA server and then apply a policy on the network devices, and DNA center will basically
build stuff automatically, So it will build the VXLAN tunnels, it will apply the policies. So we have this concept once again of intent based networking, and intent is I wanna do something, but I don't wanna have to
explicitly write everything down to make that happen. So as an example, I wanna
stop PCA talking to PCB. In a traditional environment, you have to create access
lists that stop those devices from talking to each other, but within an intent based scenario, and in some of the other
controller based implementations, I would basically say, okay, this guy can't talk to
this guy, put a cross there. So that's all done through
a GUI as an example. And then that applies
a policy to the network that basically stops that. So you as a network engineer
don't have to go and configure access lists manually, your intent is stop this
guy talking to this guy, and the network just makes
that happen automagically, which is quite scary in some ways, because what happens if it goes wrong? So the whole idea of this
SDN stuff is fantastic, and I don't wanna blow it out
of the water straight away. But just be aware that you should kind of understand what's
going on under the hood because what happens if
something goes wrong? But the principle is, we have an underlay network, then we put VXLAN tunnels over
it, which allows us to apply policies on the overlay network rather than on the underlay network. So we can stop this guy talking
to this guy much more easily using these tunnels than to try and have a single access list on an interface of a
router that blocks people across the entire network, much better way of doing things. It's basically the way it's
going, so we have a controller that manages a whole bunch
of devices in the enterprise. Now, just stepping back a
second, sorry to jump around. Software Defined Networking
was more for the data center. So it was NSX was a fantastic
success in the data center. Cisco have ACI, also
a data center product, but what about enterprises? So SDA is an enterprise solution, where we take Software Defined principles and apply it to an enterprise. And we applying policies on that network rather than in a data center. So basically, simple things like okay, let's get rid of spanning tree, so we run OSPF or a routing
protocol everywhere. Everything's layer three,
rather than layer two. But, you know, how do we
get this device to talk to this device? We can apply a policy through a GUI, or a management station, or a controller, if you wanna use the right term, that applies the policy onto
the network without you having to manually configure
a whole bunch of stuff. The idea is use is this
term of abstraction. Abstraction is used everywhere. As an example, if I wanna
write a piece of Python code, I don't have to know how to make that do something on a hard drive. I'm an abstracted from
the low level programming, the operating system abstracts
me from the hardware, operating system abstracts
me from network cables, stuff like that. I'm programming in a high
level programming language, Python that goes all the
way down through the stack and actually make something
happen on the network. So I'm extracted from assembly
language as an example, I'm abstracted from low level stuff. I use my brain for doing high level stuff rather than low level stuff. So very real world example, pilots. A pilot today doesn't fly from
the UK to the U.S. manually the whole way. What do they use, they use auto pilot. So the idea is, auto pilot
allows the pilot to take care of high level tasks, while the low level stuff is
taken care of using autopilot. Now the airplane has all of these sensors that give information about
altitude stuff like that, and then the plane can guide the pilot, but autopilot can cause problems where the pilot tries to manage the network, or should I say the
plane through autopilot, by adjusting various high level parameters rather than just grabbing
the plane and flying it. And there was a really interesting video where they were talking about
this issue where automation has actually caused crashes because pilots no longer fly the plane like physically fly it, they try to adjust the planes
flying through autopilot so try and feed information to autopilot that then flies the plane
and adjusts the plane. But if you got a plane flying at you, you as a pilot you'd grab the aeroplane and fly it out of the way rather than trying to adjust autopilot. And I think that's the same thing that we as network engineers
need to be careful of, is don't rely on the autopilot or the cleverness of all
of these applications. When the network is
burning, or there's a fire, you need to jump in and fix the problems. So automation has its place. But it's still important to
understand how networks work, because automation will
allow you to break a network, very, very quickly if you don't understand what your automation is doing. I mean, if a programmer
just writes a script that sends a whole bunch
of BPDUs into a network running spanning tree, it could mess up your whole network. So you need to understand
what your program is doing or what these applications are doing. So there's huge advantages to abstraction, huge advantages to automation, but you still need to
understand networking. You still a network person, you still a network engineer,
you still need to understand protocols like spanning
tree OSPF, et cetera. But I think for me, the
programming side is very exciting because Cisco now have this DevNet track. So you have this world in front
of you which didn't exist. You've got this world now where you can go traditional networking, with a bit of programming, or you can go programming
with a bit of networking. So I think if you starting
in your career you have two wonderful choices and I mean, you just got to decide what you enjoy, do you enjoy programming
with a touch of networking, or do you enjoy networking
with a touch of programming? I think those are gonna actually become closer and closer in future. So five 10 years from today, the line between networking
and programming will just draw closer and closer. Networking is changing and I've been saying this for many years. I mean, now we going more to the cloud, so Cloud stuff is becoming more important. But don't think that if
you put it in the cloud, it's gonna solve your network problems. It's still a network,
you still have to manage the network cloud as in your network. I mean, if you put a VM
in the cloud, it's cool, it's just a VM, but
what happens if you have virtual machines in Asia,
and in America and in Europe? You suddenly you start
working with load balancers, you start working with firewalls, you start working with
access control lists, you start working with VLANs, not call that but you
start working with all the traditional networking stuff. So just because it's in the cloud doesn't mean that you
can ignore networking. Still gonna be a lot of
work for network engineers. It's just the roles may change rather than typing on the CLI, you might be working in a
controller, or in the cloud but you still need to understand
networking principles. Okay, so that was quite
a long ramble, I hope, that kind of discussion was
valuable to add to the course. I'm gonna show you some
more practical stuff now, in the rest of the course, but hopefully that gives you a
good idea of what's important for the exam and kind of
sets the 10,000 foot view, an overview of of programming
and network automation. You don't have to learn the
details of VMware implementation for the Encor exam, but I really think it helps
knowing a bit of history and seeing where this concept
of software defined networking can be applied in multiple domains. The point is, no longer today are we simply
gonna configure networks through the CLI, we're going to use a controller, to give us additional benefits and software defined networks. (upbeat techno music)
