In today's video, we're going to be taking
a look at connecting the new Catalyst 8000v virtual router to a Cisco SD-WAN network. Now
if you're unfamiliar with the Catalyst 8000v, you may have known earlier that Cisco
had two other products - both the ISRv and the CSR 1000v - both of which
were virtual IOS-XE routing devices. And the Catalyst 8000v aligns with the new
Catalyst 8000 routing platform and kind of consolidates both that ISR and CSRv platform into
one new virtual image. So while starting with the latest versions of the virtual IOS-XE platform,
it is all going to be branded as Catalyst 8000v, most of the things that you'll see in this
video today can apply to the CSR 1000v as well. So to kick this off - let's take a look at
the topology that we're dealing with today. If you've seen any of my previous videos,
you may recognize this SD-WAN topology. It's pretty simple, has the entire control plane
- vManage, vBond, vSmarts - a couple of remote locations that are being represented by vEdge
Cloud VMs and a Linux server standing behind them. And then the new thing that I've added here
today, is a new site site id number 400 that has the same setup with a Linux
server that can be used for testing - but this time we have a Catalyst 8000v
running as the branch edge device. One last thing before I get started, there are
a lot of different ways to bring a 8000v online including some day0 auto-provisioning and you
know, all that type of magic - but because this is a lab environment, I will only be showing the
manual process for bringing up a Catalyst 8000v. With that, let's go ahead and get started. So
I'll go ahead and bring up the console of our Catalyst 8000v. And this will probably look
similar to any other IOS-XE command line interface that we've seen before. One thing to note, is that
in the earlier days of IOS-XE based SD-WAN, there used to be two completely separate firmware images
for an ISR. There would be the traditional IOS-XE image that ran standard routing and what we're
used to historically - and there would be a new image that would be specifically for the SD-WAN
enabled feature set. With the latest versions of IOS-XE code, including what runs on the catalyst
8000v, we're now running a single consolidated or unified image. So when this image boots up -
we'll either be in one of two different modes: we'll be in autonomous mode which represents the
traditional IOS-XE standalone routing device or we'll be in controller mode which enables us
to use new platforms like the Cisco SD-WAN. And it's easy enough to switch back and
forth between them whenever we need to. So to find out which mode we're running
on right now, we'll do a 'show version'. And if we scroll to the bottom of this, sure
enough, we can see that our router operating mode right now is listed as "autonomous". And so
to begin using the SD-WAN software, we will have to change this to controller mode - and we'll do
that with the command 'controller-mode enable'. Now the device will warn us, that when
we go ahead and confirm this change, it's going to go ahead and reboot, wipe everything
that we have stored on the device - including the current configuration. So if this is a
device that was already in production, and you might have some configuration that's worth
saving, we'll want to back that up prior to making this change. But since this is a lab device
and it's brand new - no config at all - we'll just go ahead and hit continue. And because I'm
not going to bother with the day0 config, we'll also hit 'no' here. This reboot might take
a couple of minutes so we'll be right back. Okay now that our device has rebooted, you might
be surprised to see that we're presented with a username and password prompt. We're going to log
in with the default credentials, which are going to be "admin" and "admin" for both the username
and password. And we will be forced to change this immediately upon logging in. Okay and then
we'll be kicked out real quick - and we'll have to re-log in with the new username and password which
is going to be "admin" and whatever we just set. We can check again to make sure that we are
in controller mode, by doing a 'show version' once more. And scrolling down we can now see that
our router operating mode is controller managed. Okay now to get the configuration going,
we will have to do some manual config on the Catalyst 8000v side before we head over to
vManage. So first, let's start off with some of the SD-WAN specific config settings - and if you
haven't used an IOS-XE based SD-WAN device before, we won't be able to use the typical 'config t'
that we're used to on a standard IOS-XE device. Instead we'll have to use a command called
'config-transaction'. This is because all of the configuration done on an SD-WAN device is
transactional. So when we enter new commands they don't take effect on the device until we
manually commit those to memory. Once we run that commit command, anything that we've changed
on the device will take effect immediately. So first thing we'll do we'll go ahead
and set the hostname to "cat8k-site400". Next we'll set some of the system configuration
settings - so we'll drop into 'system', we'll set our organization name, then we'll set
our site id to 400, we'll set our system IP, and also because this is a lab I will manually
set the vBond IP to the IP that we have of the vBond in our lab. Okay once we're
done with that, we'll go ahead and commit these changes for now before moving on. So we'll
just type 'commit' - give that just a second. Next we're going to do the configuration
for our VPN 0 interfaces, and the tunnel configuration associated to that. So we'll go
ahead and go into 'interface GigabitEthernet1', which is my internet-facing interface. And
we'll set a static IP address of 192.168.99.237, and do a 'no shut'. Then we'll go and create
a tunnel interface. For this tunnel interface, we'll do a 'no shut' again, then we'll do
a 'ip unnumbered' for GigabitEthernet1. We'll also do a 'tunnel
source' of GigabitEthernet1. And we'll set our 'tunnel mode' to 'sdwan' -
and we'll exit out of that. Then we'll drop into the SD-WAN config subtree, and again we'll set
interface GigabitEthernet1 as a tunnel interface - and we'll set the encapsulation to ipsec. And
for now we'll go ahead and set the color as biz-internet. And last but not least, we'll go
ahead and set a default route for now to our gateway. And with all that done we'll
commit these configuration changes. Now depending on your configuration,
you might be able to move on to the vManage configuration next. But in my
lab I'm actually using a local certificate authority that has self-signed certificates. And
I'm using that CA to sign everything in my lab, so that I don't have to go out to the internet and
get any of the publicly signed Cisco certificates. So in order to facilitate this, I will have to
load the enterprise root CA certificate on my Catalyst 8000v - so that it will recognize my
vManage when they go to negotiate. So I'll have to make a couple of additional configuration
changes here to allow that to happen. So if you can see back in my lab diagram,
we do have a dedicated management interface out GigabitEthernet3 - so let's go ahead and set
that up for management access to be able to reach my TFTP server. So back in our config, we'll go
ahead and define VRF 512 for address-family ipv4. And then we'll go ahead into
interface GigabitEthernet3, and we'll do 'vrf forwarding 512' - and this one
will get our IP address via DHCP - and we'll exit out of this. And last but not least, we'll set our
TFTP source interface to GigabitEthernet3 as well. And then we'll go ahead and
commit these changes as well. All right now let's go ahead and
do a 'show ip interface brief', make sure we have a DHCP address on our Gigabit
3 interface - and looks like we do. So we'll go ahead and do a 'copy tftp' for our cacert.pem
file, and we'll copy that to 'bootflash'. And it looks like that copied successfully. We can
go ahead and double check that it is in bootflash, by doing a 'dir bootflash:' - and I'll go ahead
and filter that to just the file we're looking for. And we do have that. So next we'll go ahead
and install that using the command 'request platform software sdwan root-certificate-chain
install' and then the file location which is 'bootflash:cacert.pem'. Okay it looks like it's
installed and again we can validate this by using the 'show sdwan certificate root-ca-cert'. And
sure enough, does look like we have the correct certificate loaded. We won't go ahead and go
through all of this so we'll hit 'q' to exit. Okay now for the most part we're done on
the Catalyst 8000v for now. We're going to have to go generate our one-time password
and keys from vManage to be able to activate this device. So let's go ahead and hop over to
vManage now. Now that we're in the dashboard, we can see that everything is up and
healthy. We'll go over to the left side and under configuration, we'll select devices.
We'll find one of the unused Catalyst 8000v routers - hit the ellipses on the right side,
and click 'generate bootstrap configuration'. We'll go ahead and leave this as is, and hit
ok. And we'll go ahead and copy just the top part of this file out to a notepad file.
We'll only need the 'uuid' and the 'otp' values in order to activate our Catalyst 8000v
router. So let's go ahead and bring that back up. And in order to activate this, we're
going to use the command 'request platform software sdwan vedge_cloud activate' and then
we'll provide the chassis number and the token id. And once we hit enter, that should start
trying to reach out to our vBond in order to begin the onboarding process. So in order
to validate, we can start using the command 'show sdwan control connections'. And we can see
that it's beginning that communication out to vBond and vManage. If we go back to vManage real
quick and refresh the page - we can see that our certificates signing request has been
generated by the Catalyst 8000v. And that should be automatically signed shortly
and then distributed to our 8000v router. We can also see that vManage does already show
the hostname as 'cat8k-site400' and the system IP. And after just a short period of time, we can
see that our certificate has been generated and installed on our Catalyst 8000v. So if
we hop back over to that once again, do another 'show sdwan control connections'...
sometimes it takes a couple of minutes as the connections are built and torn down
between different onboarding steps. Okay and as you can see on the
8000v now, we're starting to see logs as OMP is coming online. So let's
go ahead and do a 'show sdwan control connections' one more time - and so sure
enough, we have our final connection state, which should be the connections up
to both vSmart as well as vManage. Now if we hop back over to vManage, go back
over to the main dashboard, we should see that we have three WAN edge devices online. Sure
enough, we do. That includes the two vEdges that I have already, as well as the new Catalyst 8000.
and last but not least we can go over to monitor and down to network. And we can see
that everything is up and running there. Not all the bfd connections have come up
online just yet but I'm sure they will shortly. And now if we wanted to, we could go ahead
and carry out with our template and policy configuration and provisioning within vManage
- and go ahead and push that out to our Catalyst 8000 device, to bring it fully
in line with our SD-WAN network. However, to demonstrate something
very quickly I'm going to go ahead and just configure VPN 10 for our
LAN-side service VPN very quickly. Now that I've manually configured the service
side VPN of VPN 10 for our LAN/client devices, I wanted to touch on something very quickly that
I've gotten asked about a couple of times. So if you're familiar with a lot of the commands on the
vEdge platform, you'll notice that a lot of those don't translate one-to-one on the IOS-XE based
platforms. So for example, when you make that transition from typical vVdge and Viptela code to
IOS-XE - you'll notice that a lot of the Viptela commands that you might be used to, are now
prefixed with the 'sdwan' keyword. So for example, on a typical vEdge device, we might do a 'show
bfd sessions'. However, on our Catalyst 8000v, we'll have to do a 'show sdwan bfd sessions' -
and we can see that output here. Now one thing I've run into a couple of times, is what do you
want to do when you look at the routing table. On a normal Viptela device, you might do 'show
ip route' or 'show ip route vpn 10' for example. And so on our Catalyst device, we might think
that we'd have to use the 'show sdwan ip route' command - which in fact doesn't work. And if we
try this real quick, we'll see that the device responds back with "Error: This command is not
supported". Now the reason for that, is that we're not creating any different routing tables on our
IOS-XE device when we're running the SD-WAN code. In fact it's just using the normal, built-in
mechanisms within an IOS-XE device to handle the routing table. So for example, if we just do a
'show ip route' - what we'll see in this output is actually what we would expect to see in the VPN 0
configuration on a normal Viptela or vEdge device. So all of those routes and configuration is
now getting dumped into the normal or global routing table on an IOS-XE device. And so what
that means, is if we wanted to see the routing table specifically for our VPN 10 - that is
actually just configured as a separate VRF within the IOS-XE code. So for example, based on
my configuration earlier - we can do a 'show vrf' - and we can see that we both have the
VPN 512 that we configured for our management interface, as well as 10 for our LAN-side network.
And so now we can do a 'show ip route vrf 10'. And we should see some of the OMP-propagated
routes from our other two locations. Which for right now we are seeing it from at least
site 200 - I did note earlier that it looked like we were having some connection issues between one
of the other two vEdge locations... so it looks like that's probably site 300. I can go ahead
and fix that on the back end - but I just wanted to demonstrate one of the littler differences
between running IOS-XE based SD-WAN code versus the Viptela vEdge code, that some people might be
used to if they've been running this for a while. Okay and with that - that's all I have for this video. I hope that this was helpful
and thank you so much for watching!!
