Catalyst 9000 Series and Open IOS-XE: The New Era of Programmability on TechWiseTV

Catalyst 9000 Series and Open IOS-XE: The New Era of Programmability on TechWiseTV


♪ [music] ♪ – [Robb] So, I think you’re
perfect for this. You’ve been on all sides of the
equation. The customer side, you’ve been on the vendor side, as you are now. When it comes to network
engineers who spend so much time and energy on a career and then
they look at something like programmability, and you say, “Wow, now I
got to become a programmer?” Is that the question to be asking? – [Lauren] No, I don’t think so, and I
don’t think anyone needs to be worried about their jobs going away or anything
like that, but it’s more about taking these tedious tasks we
do every day, repetitive tasks, you know, the
box-by-box-by-box configuration, and getting rid of that.
Orchestrating that somehow or automating it somehow either through a tool that
already exists, you know, using the GUI, or
through programmability. – Well, and I think there’s more options
for that, right? We didn’t always have this, so it wasn’t something that we could
do before. There are so many open tools that we can now interact with. Cisco, as a
company, you know, we’ve built so much intellectual property around how we do our
operating systems and all this kind of stuff. And I don’t know, I probably
shouldn’t say this, but we’re probably a little bit late to open some of that stuff
up and pick up on that. Because we just have…there’s just so
much that relies on the network. You’ve gotta be really careful how you do
that. And as I’ve learned, there’s a lot of different ways to do it.
But how do you get started with something like that? I mean, how do you look at it and say,
“Oh, that’s what I should do first”? – Yeah, and I think that’s where most
network engineers have trouble. Which language do I even start with? You
know, luckily, at Cisco, we use a lot of Python and it’s great for beginners. So,
that’s one way to just get started, but there you go.
– Agreed. – Another is, you know, don’t
boil the ocean. Don’t start out making these complex scripts and you want to
automate your entire day. Just start out with one task, maybe figure
out how to make a REST call to the APIs, and that’s all you have to do. And then
you’ve automated, you know, part of your day. And
continue from there. – You know, and one resource I highly
recommend, because I go on there and I’m not a network engineer, I don’t have that
intelligence that you do, and the ability. I went on the DevNet site
and started going through the… I don’t remember what is was called…
– An open sandbox. – …but it was Basic Programming Network
101. But you get access to all of our gear and you can run those REST APIs using the
APKEYM [SP] and you have access to all that type of stuff. And you really begin to understand
and go, “Wow, all we’re really talking about is like gluing certain things
together to produce a certain result that happens like this,” versus a lot of
potentially mistake-prone, you know, finger issues that you’d have to go
through, right? – Yeah. And that’s another major issue,
the human error element. That’s great for automation, right? – Something we’ve got to set ourselves up
towards. But it’s not full automation, I think there’s still a lot of control it
feels like it leaves you with, so you’re not losing control and feeling
like you’re losing access, but I think you’re gaining
a lot of power with it. – Yeah, absolutely.
– It’s an opportunity, you think? – I think it’s absolutely an opportunity
and an opportunity to save time so that you can innovate elsewhere. – Yeah. Or work less, watch more Netflix,
whatever the case may be. – There you go. More videogames. – All right. Well, let’s get started on
that one. Guys, the Catalyst team continues to open things up on the
switches, this is happening all across Cisco. In fact, today we’re in the middle
of a series. Big announcements around SD-ACCESS. Fully automated network
deployment management. We’ve got several shows explaining that and peeking beneath
the covers. But with today’s topic, Programmability, I tend to think of that
as more of a semi-automatic. Huge leaps forward in making our network
interactions easier, less time-consuming, less error-prone. In fact, today we focus
on the programmability vision that is driving change across Cisco. The options
now available within Catalyst open things up through the entire
lifecycle. We give you a hands-on breakdown with four reasons why,
why you need to grok this stuff. Demonstrations that show just how easy
it can be to eliminate repetitive and tedious tasks, improve device
interaction, get these machines to do stuff for you, which is a great start
towards programmatic control. Plus, how you can stop bad configuration
from ruining everything through something called transactionality. Well, first, we
kick things off with Rohan Grover. ♪ [music] ♪ Rohan, welcome to TechWiseTV.
– [Rohan] Thank you. – Question for you. I think a lot of
network engineers look at some of what we’re doing in programmability, and
perhaps at first glance, if they’ve not really taken some steps into it, you go
through this thought process of, “Wait a second, is this a threat to my
career? Is this something I should embrace?” You know, where should they be
thinking about these type of things? – Well, Robb, the way I
look at it, you know, as enterprise are
going through this digital transformation, they’re being asked by
their CIOs to do more with less. They’re being asked to automate more
stuff. And they’re going through this phase of automation. And now, when you’re
going towards automation, it’s not enough just to build the best
automation software like we have using APKEYM and DNA Center, we also have to
essentially fundamentally change the way the networking devices interact with the
automation software. And the old ways of doing things using CLI or using SNMP are
no longer going to scale to a world where everything is going to be automated and
it’s going to be more machine-to-machine interaction versus human-to-machine
interaction, which was the norm before. So I think that’s the way that network
operators should think about this, and they should think about how this is
the new way of doing things and how Cisco is now evolving IOS, which has been out
there for the last 30 years. But this is not your
daddy’s IOS anymore. – No, it really isn’t. – We’re building Open IOS XE to
essentially make these fundamental changes. – And that’s specific. So, we are saying
Open IOS XE because we’ve introduced IOS XE a while back and it’s only recently
started to come out, I was going to say “recently,” over the last couple of years,
but where it comes out on platforms as they come out. Like 3850 I believe had it
from the get-go in 2013, and this type of thing. But we really embarked upon IOS XE
as being more modular so we could do things like programmability. We could
touch parts of it without it affecting the entire base of monolithic code in which
the previous IOS would be written, right? – Exactly. So, we’re really making IOS XE
to be open, extensible, and programmable. And we want to give the network operators
the entire lifecycle management tools that they need to essentially
operate the network. – So, it feels like to me, that
programmability really kind of includes, you know, a wide-ranging set of tools and
capabilities that people could take advantage of in where you’re thinking in
an automated manner but you’re not really fully automated because you’re still very
much involved but you’re certainly doing things perhaps, in a…well, in a more
programmatic manner. I just have trouble getting away from the word. When
we think of a device lifecycle, are we talking about the ability to add
value only in one particular part, or is this something that
affects multiple phases? – No, absolutely. We are looking at seeing
how we can take this through the entire lifecycle. Starting at day zero with device
bootstrapping. Open IOS XE supports protocols like iPXE, which are industry
standard. We also support plug-and-play, which is tied to our APKEYM software. So,
both open standard bootstrapping protocols like iPXE and ZDP, as well
as plug-and-play capabilities. – So, these really help with rollout and
that consistency with opening up new sites. – Exactly. So, whether you’re doing a
[inaudible] rollout that does not require like a sophisticated person to go out
there and just bring it up in a few minutes.
– Right, that’s expensive. – Yeah. And then when you move on to like
day one, which is bringing up and configuring your devices and making
changes to your devices, that’s where you’re fundamentally changing the CLI
model and going through this whole Netcon pyang [SP] interfaces. And I know if you’re
going to be talking a lot about Netcon pyang as we go forward in the show. And
also, operational data. Like, we really don’t
want to do this SNMP-based polling like
we’ve done in the past, that’s expensive. What we really want is a
streaming telemetry way of sending data out of the box so that you
get data when you want it. And… – So it’s more of a
real-time rather than I’ll ask for it on a
pre-determined schedule, it’s like, “Well, no, I need to know about it
when the event or whatever it is that I care about has happened.” – Exactly. So, you want to regard data
based on an event that has happened and it has to be without any penalty on the CPU.
So, streaming telemetry contextual in nature is really what we’re
looking at. – Which is interesting. I think we’ve
attacked these kind of things in the past through various management tools and
different kinds of things like this, but you guys have really been working hard
at kind of a inside-out when you look at the operating system and how it’s tied to
the hardware that we’re rolling out and such like this. Because we’ve had huge
announcements around this SD-ACCESS. How would you describe SD-ACCESS as it
relates to programmability? – Well, SD-ACCESS, as you know, is the new
paradigm of building and managing enterprise networks. It’s a policy-based,
automated way from edge-to-cloud, and we’re really looking at two different
ways in which you can configure and manage SD-ACCESS. So, one is the completely
turnkey, easy button solution that uses APKEYM and our DNA Center, but for the
more savvy, the more DevOps-type of customers, we’re also providing complete
programmatic access to configure and manage SD-ACCESS. So, this really gives a
choice to consumers on how they would really use SD-ACCESS. Using YANG, data
models, streaming telemetry, or using the easy button with APKEYM. – Oh, perfect. So, what I like about that
is that we’re finally moving to this age, it’s a huge deal going to this full
automation, easy button, if you will, because it truly is a lot of things
happening behind the scenes and a lot of people get afraid of things like that. And
so, people that are maybe coming off of CLI or really like how programmability
allows you to work it into other parts of the operation. It feels like we’re
exposing as much of the network and what’s happening as you’re accepting of, or as
much as you need to in your own operation. We’re not going to hide anything you don’t
want to have hidden, but we’re also not going to expose
anything that you shouldn’t have to deal with. It depends on each customer and
their specific applications. Fair enough? – Exactly. And the other thing I wanted to
point out, like with our new Catalyst 90A, which is part of this big announcement
that we’re doing. These are based on x86 processors. So, now you have the
capability to host third-party applications and secure Linux containers
right on those Catalyst boxes. – That’s very nice. – So applications such as perfSONAR, which
is very commonly used in universities for performance monitoring. You can now host
these directly on the switch and that’s a lot of value for the do-it-yourself sort
of customers that we just talked about. – That’s perfect. Well, Rohan, thank you
very much. I appreciate your time. – Thank you, Robb. – I’ll just have you take a walk right
over here. Guys, we’re not done with the show yet. What I want to get into is
reasons why programmability becomes very important. And to help me do that, I want
to bring on Jeff. I’ll have you come on up. How are you doing, sir?
– [Jeff] Hi, Robb, doing well. – Good to have you. Please, take a seat.
– Thank you. – So, and also, I want to say, we’re going
to go through some reasons of programmability, and we’re also going to
bring in Lauren and Fabrizio who are going to demonstrate some of these key points,
if that makes sense to you. – Works for me. – Because before we get into those four
points, what I wanted to understand from you, you’re a former customer,
you’ve seen both sides of this, and so, not only are you now with a vendor
and we’re putting this out there, I think you’ve got a good understanding of
this. Is, I think there’s a lot of people that look at this stuff and they go, “Man,
I am really good with CLI. I’ve got great muscle memory, I’ve been
doing this for years, I know what I’m doing.” And there might be a little bit of
a panic, as I’ve kind of mentioned with Rohan, but this notion of, do I still add
value in this world of programmability? So, I’m curious, from your perspective,
you know, do CLI skills have to go away? Is there…what’s really happening here?
What do we need to understand? – Well, I’m definitely a CLI guy, Robb.
I’ve been doing CLI… – You are one of those guys, yeah. – …for many years, absolutely. And no,
your skills don’t have to go away. You have to know what you’re actually
programming, or scripting. And so, you have to understand how
networks work and how network devices work. CLI is really a human-oriented
interface. And I’m a human, so, of course, I like CLI. But when you get into scripting
and programmability, you’re dealing with machine-to-machine
interfaces. So, we need a different kind of interface to really make
programmability work the way it should. – So, there’s a consistency level that we
don’t always see, because I think even without realizing you’re so comfortable
with that interface, you know as a network designer why it’s getting back certain
things, and you apply that into the decisions you make for the next thing you
input. It’s difficult for a machine to weigh those options if things come back in
a manner which is not something it expects, so to speak.
– That’s right. – Is that right? Okay.
– That’s right. – Well, what about SNMP? It felt like SNMP
was trying to come along for a while to really save us in network
management. What happened? – Well, I’ve been using SNMP since about
1998 and I think it goes back longer than that and it’s definitely a venerable
protocol, but it has a lot of limitations. It really is an old protocol and it’s not
suited to the types of things we’re talking about. If you’ve ever looked at an
SNMP model, like an SNMP MIB, they do have data models and structure.
But when you go access something in a MIB, it’s like 1.4.6.2.3.whatever, right?
– Right. – It’s not very usable. And also, most
people have used SNMP for operational data and they haven’t been using it for config
as much. So, we need a new method of doing this. – All right. Well, I’d like to…we’re
going to introduce these at the appropriate part, but I’d like to get into
these four reasons. I’d seen this in one of your internal presentations, and I like
the way you presented this because I thought it made it very clear to me about
the value of programmability. And so, I thought we’d go through this
step-by-step. As I mentioned, this first one, I wonder if you could
explain this, what do we mean by reason number one, this notion that we need to
eliminate tedious tasks? – Well, I think as CLI engineers we’ve all
done this, where we had to configure a number of devices. We configure one, put
the configuration into Notepad, tweak a couple of values, paste it into
the next device, tweak a couple of values, and paste it into the next device. So, if
we’re already doing that, if we’re using Notepad in that way, we’re
already thinking along the lines of automation, right?
– Yeah. – Because there are certain things that we
just don’t want to do with CLI. So, I always tell people, “Well, if you’re
nervous about programmability and automation, but you’re doing these things
with Notepad, it’s really just a bad automation tool. Why not use a better
automation tool that’ll take away those tedious tasks that you don’t
like to do as a part of your job?” – Well, and this is our first reason, but
it feels like, you know, there’s a value…a lot of
people have turned scripting, of course,
over time to make certain things easier, and I think once
you get comfortable with a little bit of scripting, you being realizing the power
behind that. And I don’t know, I think it’s a good reminder that when we
say programmability, we’re not talking about someone becoming a hardcore
programmer where you’re doing something from, say, you know, assembly code on
up or something. But really talking about extensions of things you already do to
make it simpler, and it feels like that’s what you’re leaning towards here is,
don’t ignore the simple ways in which, if there’s anything you’re doing that’s
tedious or repetitive, it might be a ripe candidate for
some type of programmability, correct? – Very true. And you might become a
hardcore programmer someday, but you can start as a scripter, you know. Start out
simple and develop your skills as you go along. – Well, perfect. So, Lauren, I’ll
see what you guys got. – All right. So, we’re talking about
removing repetitive tasks, right?
– Yep. – Real timesavers for network admins, and
not doing that box-by-box imperative-style configuration. So, what
do you have for us, Fabrizio? – [Fabrizio] So, we have here…we have an
example of a standard Python script running on a Linux server. – Okay. So, why choose
Python? I see it all the time. – Yeah. There are several reasons. The
main one, however, Python, it’s a slightly better and simpler than other scripting
languages. And so, it’s more human-friendly.
– Great for beginners. – Correct. Very easy to start with. And
also, the power comes from a lot of libraries that you can find
on the open-source. So, it’s very easy to
leverage those libraries to do whatever you are supposed to do in
your environment. – All right. Very cool. – These are the main reasons. So, the main
idea here, we have one device that it is used as a master, our Catalyst 9300, and
several devices that are used as a follower. So, the configuration from the
master will be synced to the follower. Right? In a very easy way. And what we are
leveraging here is a standard open APIs, NETCONF YANG models, that are
provided by IOS XE, the Open IOS XE. So let’s run a Della [SP] Python script,
and what the Python script is doing, it’s connecting through NETCONF again to all
the three devices. And are provided in a menu so that you can sync the
configuration between the master and the followers again. And we can, for instance,
see what’s that ability to sync the NTP server, right? So, if we check the
configuration before we run the Python script, we’ll see that the configuration
is different between the three devices, right? So, we select NTP, we let it run,
so what the Python script is doing is collecting the information from the master
and pushing the same configuration out to the followers. And you’ll see the NETCONF
configuration has been applied using an assist log. So, if we check again at the
configuration, now all three of them are synced. – And that’s important, right? And we want
the times to be across the board the same, so that’s a great use. – That’s the main point. And we have only
three devices here, but in most of our custom infrastructure we have hundreds,
maybe even thousands of devices. – Right. That could be a real pain to
configure box-by-box. – Exactly. And the beauty is that you can
even rollback if you are not happy with the configuration that has been applied,
very easily, still using Open IOS XE and the models you can rollback very easily in
few seconds and you’ll see that the configuration will be the
same in the Catalyst 3K. – So that rollback is all part of the same
Python script and use it as necessary? – Same concept using a NETCONF and using a
YANG model just rollback the configuration on the other devices. – And can anyone get this script? Do they
have to reinvent the wheel every time or will it be available? – They don’t. And that’s the power of
Python and the open-source. So, we are going to share and publish all
these scripts on Cisco DevNet and Cisco GitHub repository. – We like to hear that. All
right, thanks. Back to you, Robb. – All right. Thanks, Lauren. Okay, so it
seems like when we go there, we’re talking about, you know, a person is
triggering the…churning a certain set of things that’s going to happen. And so,
that makes a lot of sense. As we get into your point number two, this
notion of interaction between network devices and other systems, it feels like
we move into another level of depth here. How do you explain that? – Yeah, this is actually one
of my favorite use cases. So, a lot systems now, a lot of
applications have REST APIs opened up that enable you to use them or call them
through a script. So, for example, Cisco Spark, or ISE, or APIC-EIM, or
various third-party applications. And a lot of times, network engineers
don’t know what a REST API is, and it’s very simple. If you think of the
things you could do in a Spark room, for example, you could list the messages, or
post a message, or read a message. Those various things you would do by
clicking you can do from a script using an API call. So, what we can do now that
we’ve enabled YANG models and NETCONF on our switches and we’ve created structured
data, it’s very easy for us to, for example, read data off of a switch and
send it to one of those applications. And interact in ways that we just weren’t
able to do before, at least were very, very hard in the past. – I think some people may not fully
understand why we couldn’t have just easily read data off of a switch before.
Because it fundamentally sounds simple, but I think it gets into
this notion of data modeling. Maybe tell
me a little bit about how did NETCONF and YANG come about. These
are standards that’s not usually… I think Cicso drives a lot of these
things, but these are open, right? – That’s right. NETCONF and YANG are
standards. And so, to your point, yes, we could read data off of switches in the
past, of course, but usually what we would do is, if we read data
off, we’d have to do screen scraping and
regular expressions to extract anything meaningful and use it in
a script. And so, CLI data is really unstructured data. There is a structure,
but it’s very arbitrary and not really easily used by a script, for example.
– Not consistent enough, yeah. – Exactly. And so, what the YANG models
really do is, they define a consistent structure that both sides can agree on.
So, the script can access the YANG models, it knows what they are, it knows what the
structure of the data is, and the device that you’re talking to understands the
structure. And it’s important to point out that this applies to both configuration
data, which is the data commands you would type into a running config, as well as
operational data like a show command. – Okay. So, those things really
have to be consistent? – That’s right.
– If you will. – And so, NETCONF actually takes advantage
of these YANG data models. NETCONF is just the communications
protocol that opens up a channel between, say, your script and your device and
accesses those YANG models. – Are the things with NETCONF…I think I
remember you mentioning in terms of it maintaining some type of idea of state you
can rollback. Or, actually, we’re going to get to that in just a minute. I’m jumping
ahead, I’m getting too excited. Okay. Hold onto that, then. So, Lauren, I
wonder if you can show us what we might be able to do with that.
– We’re always ready here, Robb. – Excellent. – So, in this demo we’re actually going to
show how we can use the southbound APIs to the hardware and the northbound APIs to a
chat room, in this case, Spark, because we’re Cisco and we like
to use our own stuff. – Yeah, that’s all right. – And it’s a great product. All right. So,
yeah, run us through what we’re going to use this ChatOps scenario for, and tell us
a little bit about ChatOps, too. – So the ChatOps are a
new way to cooperate for operation teams
where you create rooms, chat rooms where people can
exchange information. But on this demo, we are bringing the ChatOps to a new level
where we are introducing API to have a live interaction with the devices. So, we
have this Cisco Spark, we created a room on Cisco Spark where the
user can type some text that will be sent into the Python script and the Python
script will translate the text into a NETCONF operation that
will be sent into the Catalyst 9K. Catalyst
9K will reply to the Python script, and the Python script will
publish in same Spark room the information retrieved from the Catalyst 9300. Okay.
And, as you said, all the information that’s changed by the Linux server to the
device will be NETCONF in the southbound and will be REST APIs from the Linux to
the Spark room. We can switch to the demo. What we have created is a new Spark room
Catalyst Operation. Very lonely. It’s only myself, Jeff, and the Catalyst
9300. And what you can see here, you can start interacting with the device,
starting with a ping just to make sure that everything is working fine.
– We always start with ping, right? – Yeah. That’s the way to go. And then we
can try to see, for instance, information about the routing table. And we do it in a natural
language in this time, it’s not the real C-line [SP]. – The Catalyst is one of your colleagues,
one of your friends that you’re chatting with.
– Yep. “Show me the routing table,” so the
Python script will translate the “show me the routing table” in a NETCONF
operation that will be sent into the Catalyst 9K. And the Catalyst 9K will
reply to the Python script and the Python script will publish the routing table on
the Spark room. – So it’s almost like a Get
Operation, but now I don’t have to, like, copy
all this information and email all my colleagues about it.
Everyone in the chatroom can see it in real-time, or if like a junior admin’s
doing something, I can see what they’re doing. – That’s a very good use case, yes. You
can do even some more using the Python libraries like a graph. You can even graph
the same information and then publishing the graph picture, a JPEG, on the Spark
room itself. So we say graph… …table. And what it’s doing now, it’s
using, again, another Python library, publishing the picture on box, and then
from box is publishing on the Spark room. So, in a few seconds you’ll
see a graphical representation of the same information. – And that’s helpful, too, right? No one
likes to go through and make all the graphs and the diagrams and all that, and
here we have it, again, all my colleagues can see it, perfect. – And easy. It didn’t take a lot of time
to it because we’re still leveraging existing Python libraries. – That’s awesome. I like this because I
usually, you know, I see ChatOps demos and they’re not really real world, it’s just
like, “Hey, cool, I can talk to my switch.” But this is a real-world business use
case, troubleshooting use cases, so that’s pretty cool.
– Yep. – All right.
Back to you, Robb. – You know, this makes me wonder, Jeff,
about YANG native models versus open and what’s the difference we need to
understand there? – Yeah, that’s a good question, Robb. YANG
is a standard. But the models themselves come in two forms. So, we have our own
models, our Cisco models, which we call native models. And those are models built
by Cisco specifically to work with our devices. There are also standards bodies
that define the models themselves. For example, OpenConfig. And we’re very
committed to supporting those as well. So, those are designed to work across
different platforms. Generally, there may be some specific features that
they don’t support in their standards that are either proprietary features,
like EIGRP or that sort of thing. So, in that case, you would use our native
model, but you can also use the open models as well. – Okay. So, as we move on to point three,
as contrast to point two, where we talk about kind of introducing
devices talking to other devices, I wonder if you could help me make this
distinction. So, in this third reason you bring up here is this notion that
programmatic control of network devices. Explain that one. – Yeah. I always like to define the word
“programmatic” because we hear it thrown around a lot. And yeah, if you think about
what a computer program actually does, it takes certain actions
based on data, right? – Yeah. – So, if this is true, do that. Or
while something is true, do something, when it’s no longer true, stop doing that
thing. And so basically, the idea is controlling network devices in
ways that we didn’t before using the data and the condition of the device. So, in
this example, you know, we have an example where if the input
errors get too high, we shut down an interface, because we all know, a degraded
interface is worse than a down interface. Right?
– Exactly. Yeah. – So maybe we want the routing protocol to
route around that. So, that’s an example of taking an action
based on a condition on the device. Now, we’ve had Embedded Event Manager for
many years that can allow us to take certain actions based on events on the
device. But one of the great things now is that we can augment that by calling, say,
a Python script from Embedded Event Manager when there’s a particular
condition on the device. – I like that. Because you’re also talking
about things that we may already be familiar with. The EEM’s been around a
long time, you know, certainly a lot of tickle scripts people get used to and this
kind of stuff. So, the stuff’s not being thrown out, we’re
augmenting and extending, which I think is a good
reminder for where a large part of the value comes from as we
say, “How do we stick things together,” it feels like. And now you’re talking about
reacting to some type of a catalyst, no pun intended, that is driving a
response that you’d like to see happen more automatically or
programmatically. Right? – That’s right. EEM was a very powerful
tool, but it’s not as powerful as Python. You couldn’t make a REST
call from EEM, for example. – But now that one talks to the other, you
can extend a whole lot of value there, correct?
– That’s right. – All right. Well, I’m anxious to see this
one, Lauren. What do you got for us? – All right. Well, we have another ChatOps
scenario here, but the previous demos you were running off-box, meaning from
your local laptop or from a separate server. These you’re actually going to run on the
hardware itself, on the switch from the guest shell, I’m assuming. – That’s correct. It’s a guest shell which
is a Linux container running on the device itself. And this is the power of Open IOS
XE [inaudible] Python running on a Linux container, tied all together with Embedded
Event Manager as just mentioned by Jeff, right?
– Okay. So, in this demo, what we have that
every time that the configuration is changed, the Embedded Event Manager will
detect the change and will trigger a Python script, again, running on the guest
shell, and the Python script, what it’s going to do is going to do a
diff between the current change, the current configuration and the previous
one, and it’ll send the diff to the Spark room. So, in the Spark room, you’ll see
that change in the configuration. So, we have another Spark room that we
call OnBox, Catalyst OnBox, same usual suspects here, myself and
Jeff and the Catalyst box. – Another lonely chatroom. – Yeah. Another lonely chatroom. And you
can see that every time the configuration is changed, the diff is published
on the Spark room. – So, we’re showing here that it used to
be Cat 9300 was the host name, and now it’s TechWise, which we love, right?
– YechWise. Yeah. – That is awesome, too, because
then I can get alerts real-time. My whole team can get the alerts real-time
using, you know, the power of the Event Manager along with Python. – And APIs, right?
– And the APIs, of course. – That’s something that
you couldn’t do before. – Thank you so much,
Fabrizio, that was great. – Thank you, Lauren.
– Round this out for us, guys. – All right, Lauren. Thank you. Thank you,
Fabrizio. Jeff, as we get to point number four here, and this was
something I started looking up, but it tied
back to the models, as I remember. But this notion of stopping
bad configuration. Are we talking about eliminating human error only here, or what
is it you’re leading into at this point? – Well, let’s look at an example. So, here
we have some CLI and there’s one line of bad CLI there. We have a .0 address on a
/24 mask. Now, that’s invalid configuration, it won’t work if you try to
put it into a router or a switch. But we have all this other configuration
related to BGP. Well, if you use CLI to paste that config into a
device, that one bad line would fail with an error, but all the rest of that config
would get committed. – Oh.
– Now, maybe you don’t want that. That’s actually
probably not a good thing, right?
– Right. – If one thing fails, you don’t want the
rest of it to go through. Well, specifically with the NETCONF
protocol, we have this rollback on error capability.
– That’s what I was remembering. Yeah. – That’s right. So, we can say that we
actually want to roll back the configuration if even one line of it or
one piece of it generates an error. We don’t want any of it to commit. – So, it’s an all-or-nothing type of thing
and it’s built into NETCONF so we get this notion of…and that’s what
you call transactionality? – Exactly. – That’s where that word comes from?
– Right. – I don’t think I’ve ever heard that used
before, but it makes a ton of sense. And it’s another one of those reasons why
NETCONF YANG was largely designed to start preventing some of these things that were
just, you know, stuff that would frustrate us about previous network management
tools. But things would fail because of simple things like that. We need all-or-
nothing or else we’re going to throw everything into some type of ambiguous
state across the network, yeah? – That’s right. And you could’ve done it
with CLI scripting in the past, but it would’ve been very hard. You would’ve had
to back up the config somehow and track the state, while this is just done
automatically. If it doesn’t commit, it’ll roll it back for you. – I’m excited about what you guys have
done because we’ll continue to open everything up. And so now we’ve got IOS XE
or Open IOS XE now available, you know, that code base is very well spread
and extremely, of course, represented directly on the new 9000
family. Specifically, I think it’s the first family of switches we’ve ever had a
consistent binary across every platform. I don’t think there’s been a time that
we’ve ever been able to do that. And what that opens up, both for us in
turning out new features and feature velocity and such, and what customers can
begin to take advantage of, with limiting their testing and regression,
and everything else they may have to go through. It’s an exciting time to be
taking more control of our devices and thinking more, I think, from a design
perspective versus that box-by-box perspective that a lot of us have just
gotten used to and almost accepted as that’s the way you do things.
– Sure. – Is there anything else we need
to understand about programmability? – Well, as you brought up at the beginning
of the show, I came from a customer environment, and in fact, Fabrizio did as
well. I’m not a software engineer, that’s not my background. And I always tell
people, to get started with this, start small. Again, you’re not going to have to
be an expert programmer. Start with some really simple scripting.
Go, like you mentioned, check out DevNet to get some examples and
ideas, and just get your feet wet. It’s very powerful and it’s one of those
things where, once you start playing with it, you’ll find a lot of uses that you
wouldn’t have even thought of before. – And I think that works the best. And
that’s almost the mentality of coders and such like this, and, frankly, quite a few
network engineers, which is just go play with something, it sounds like.
– That’s right. – Well, Jeff, thank you very much. Lauren
and Fabrizio, thank you. Rohan, thank you very much as well for
joining us. Guys, programmability is something not to be feared. We’re not
talking about becoming programmers. We’re network engineers. And that type of
expertise is not going away by any means. In fact, it may be more important than
ever because the more we automate, the more we do things like this, we still
need to understand how things work behind the scenes, or, otherwise, we are not
going to be able to troubleshoot. I think there’s certain
things like that, certain fundamentals that are
never going to go away. And frankly, we’ve been moving in
this direction for years, so it’s probably not a surprise to
anybody. But these are exciting times, lots of good stuff happening,
and this is just one part of it. Be sure
and check out the rest of our series as we continue to
explore SD-ACCESS and everything you need to know around this new world of hardware-
software integration automation that we’re moving towards. Getting policy back under
your control. It’s a lot of fun. And thank you for watching TechWiseTV.
That’s it for our programmability show, keep up with us online. All of our social
media information should be there. You can find all the shows at
techwisetv.com. On behalf of Lauren, my name is Robb, thank you for watching.
We’ll see you in the next one. ♪ [music] ♪

15 thoughts on “Catalyst 9000 Series and Open IOS-XE: The New Era of Programmability on TechWiseTV

  1. It's nice to see Cisco moving the software defined model to the access layer. I particularly like the ability to run containers on the catalyst 9000's.

  2. So, with Spark we would be able to "chat" with a Catalyst 9000 series switch and share running configs of these switches with other people in the spark chat room?

  3. Awesome video TechWiseTV as always. And undoubtedly YANG data modeling is and extraordinary resource and Python a must have tool that in nowadays everyone in business need to master.

  4. Great to see some api's coming into switches. But why for the love of god would you go for something like Yang/Netconf when there are already well known and established protocols like REST/soap? Im not trying to bash, I am genuinely interested why this decision has been made.

  5. I'm getting an error message as BOOT FAIL B in my Cisco 9300-48UXM-A switch

    I tried to go rommon mode but it's not working..how I need to troubleshoot it

Leave a Reply

Your email address will not be published. Required fields are marked *