Join us as we gather around the hedge,
where we dig into technology,
business, and culture with the finest minds in
computer networking.
Hello, Tom. Did you turn that plan around?
Nope.
I'm gonna in the same spot. I'm gonna
have to drive all the way out to
Austin.
Yeah. Fix that plant. You should. That might
be the only way it might be the
only way it gets done.
I don't know. Or maybe I call the,
the local plant patrol,
the wonder pets. I'll call them, you know,
the phone the phone is ringing, and they
can come over to your house and turn
the plant around.
Nice.
If you see a raccoon wandering around your
house, you know what happened.
So today we are joined by Danny Wade.
So, Danny, where are you physically?
What what?
Yeah. Russ, thanks for having me on. So
I'm located in Maryland in The United States.
Okay.
Cool. So East Coast,
nearest the bay and the ocean and all
that stuff.
It's a cool little spot up there in
Maryland.
They all do tend to get the occasional
hurricane
that comes up the coast and the nor'easters,
which are brilliantly horrible.
When I lived in New Jersey, we hated
nor'easters.
Like, oh, please stop it with the nor'easters.
Yeah. Because they they come over the mountains
cold and pick up all the water from
all the lakes and the ocean, and then
they run up the coast and, like, just
dump snow everywhere. It's terrible.
So
let's see. So today, we are talking about
Pytest and network automation and test driven
or, yeah, automated driven testing,
I think, is the topic.
So I guess we should start with,
now, PyATS
is a Cisco only thing. Is that correct?
Or are there
non open source implementations as well? Or is
this like
Yeah. So it was developed by Cisco.
So there's kind of two parts to it.
So there's PyTS, the testing framework.
And then there's PyTS,
what they call the PyTS library,
or formerly known as Genie. And so Genie,
you may have heard of because
it has the
parsers and APIs
and kind of the tools
for
the toolset.
So the Genie portion, a lot of the
parsers and everything are open source.
It is a vendor agnostic tool, so it
does work outside of Cisco.
The testing framework, the PyTS piece,
the testing framework
is closed source. So
it's still internally developed by Cisco.
And the purpose around that and the actually,
the framework itself is it was used internally
at Cisco until it was publicly released,
and I guess it still is used to
test
all their different flavors of software for their
network operating systems.
Okay.
So,
so the so there are parts of it
that are internal to Cisco only. There are
parts of it that are not.
Yeah. That's a good way to summarize it.
Yeah. Okay. And so the open source parts,
are these something that the average network engineer
could go download and,
you know,
use? Or do you need the internal parts
as well-to-do this?
So the
so it really does come kind of in
a bundled package with the testing framework.
But from a contribution standpoint, you can anyone
can go to GitHub today and look at
the Genie parser library
and contribute
to new parsers,
new APIs.
There is actually a package
of PyTS. I
think it's called PyTS dot contrib,
c o n t r I b.
And you're able to create,
I don't want to say plugins, but you're
able to create ways to integrate with other
tooling. So for example, a popular one that
I like to use
is, they have the concept of what they
call a test bed, but essentially, it's an
inventory file for the PyITS tool.
You can
actually part of that contrib
package
is a way to integrate with NetBox.
So it's a CLI tool where you can
connect to NetBox and generate basically a dynamic
inventory file versus statically
handwriting all your
network inventory into a YAML file.
Okay. And so does this work with non
Cisco devices? I'm assuming that the Genie part
does.
Yes. Yeah. So,
both do.
Okay. Yeah. The testing framework really is
if you're familiar with Python testing frameworks, there's
one called unit test that's baked in
to the standard library.
It's very reflective of that.
So
the testing the PyTS side, the testing framework
is agnostic. It's really just like any other
software testing framework.
The Genie side or the PyTS library side
is the part that's open source and vendor
agnostic that you can contribute to. So So
it kind of feeds into that testing library
or the framework.
Awesome. Okay. Have you seen other vendors contribute
to
make their products usable with PyTS?
So I've personally contributed to
the Genie parser sign and, it it was
a Cisco command. I've seen most I haven't
looked through all the contributors, but most of
them are individual contributors that have a problem
and they fix it by creating a parser
for,
whether it be BIG IP
or Junos.
You can look through their
parser library. But
I see a lot of times it is
like individual contributors.
Okay.
So this would so from what you're saying,
this came out of, Cisco's own internal product
testing.
So what is the what is the motivation
to,
offer this to users? Do you find network
operators doing it for network testing then instead
of just product testing? Or what's the what
was the motivation for releasing this?
So I I I've never worked at Cisco,
so I don't I don't know. I can't
talk on behalf of Cisco. But,
my assumption is it it's a it's an
all around framework in
for not just testing, but
you build out an inventory file.
And essentially,
it creates an abstraction. Once you have an
inventory file, each
of those devices in your inventory file becomes
basically a Python object.
And
through that, you have methods associated with it.
So you can use like a there's a
configure method and you could pass in a
string.
If you were to just go to conf
t with Cisco,
you could do it straight using Python instead
of CLI scraping or anything like that.
So my thought and the way I think
a lot of people are thinking about it
is
just to be able to have a batteries
included framework to not just test the test
the, network, but also configure it and then
retest.
So it's really meant to,
hey, I'm not just looking for all this,
you know,
operational data using show commands. What I'm trying
to do is I want to configure a
feature
in a lab or closed off environment,
see do run their show commands, see what
changes, whether it be routing, layer two, whatever.
And then I want to remove that configuration
and see if everything resets that baseline.
So when I say testing it, I see
it as a larger
testing of feature once being configured versus just
running a bunch of show commands.
So Sure. Sure. Yeah. Hopefully, answers your question.
Cool. So so almost halfway to intent based,
it almost sounds like, or the original generation
of intent based. Like, let me go try
this, see what happens, and if it doesn't
work, pull it out, or at least verify
that it's doing what I think it should
be doing
based on, like, looking at show output and
stuff like that.
Yeah. Yeah. And and within the testing framework,
there's even ways to abstract, you know, parameters.
So you could have a
a non developer fill out a YAML file,
call it, something very basic human readable
of test parameters like I'm expecting
this AS number for this BGP process. I'm
expecting these number of routes.
And you fill out a parameter file, and
then you give it to the developer to
run all the tests or configure those tests
and then run them.
So, yeah, you could definitely make it intent
based.
I don't know. I don't want to say
it's the first generation, but it definitely is
you could you know, deployed as an intent
based framework.
Right. Yeah. Yeah. Because I'm just thinking I
was thinking, like, early generation only because that's
where,
like, a lot of the intent based products
started out was doing that type of work.
Now they've expanded
to other things since then, and I assume
that using this framework,
you could actually stick your own LLM behind
it and do things that are more dynamic
if you ever really wanted to. But this
would give you just the base library to
do that kind of thing.
It seems like you would be able to
interact with it in that way if you
wanted to.
Yeah. And I haven't been catching up with
him recently, but, John Capobianca,
the guy I co coauthored the book with,
the PyTS book, it,
he's doing something along those lines where he's
backing
this framework with an LLM
and doing some AI.
I'm not too deep into the AI stuff
right now. So but,
from things I've seen he post online, he's
definitely trying to take it to that extent.
Well, that's really cool. Yeah. So this this
acts as almost a middleware between
the LLM and the devices.
So let's so let's walk through, like, a,
like, a fictional example. Say that I have,
a reasonably sized OSPF network. I've got, I
don't know, two or 300 routers.
Pretty standard. Maybe it's a single area. Tom,
you just dream so small, but go ahead.
I know. Well, you gotta keep it real.
Right? How many people run thousand router
network? So,
anyway, you got this network reasonably sized, and,
it's deployed and things are working, but you
want to see,
what effect a certain change will have on
your network.
What how does how do you hook Py
PyATS into it, and how do you how
do you use what are the what's the
concrete steps for making you get an answer
from, oh, here's this thing on GitHub until
now I know what's gonna happen. Like, what
are the what's the workflow?
Right. So I guess the first thing would
be and this is a luxury, but having
some sort of test or dev network,
whether it be virtualized or physical.
So under that assumption,
you would to install PyATS, it's just a
Python package. So using pip, you pip install
pyts in the library.
And then from there, what you do is
I mentioned unit tests earlier as part of
the standard library within Python.
You basically use Python classes to create
test cases, individual test cases. And in each
test case, you would have an individual test.
You actually could have a setup, a test,
and a cleanup within one test case. So
if you wanted to do something like OSPF,
you would have an initial, what they call,
common setup,
which would connect to all the devices,
right? So just SSH connections out.
And then you would jump into your test
case of maybe running a show command as
a setup.
So you're collecting maybe some data beforehand.
And then you would go into the testing
of configuring the device.
And you could break that out into a
test, or you can include that in the
setup, however you want to do it.
But the setup piece is really to add
your configuration, add all your changes, and then
run your test
with the changes implemented.
So you'd run the test, and then you
would use
the cleanup
step to go through and wipe out your
config and do, I guess, call it your
baseline,
making sure everything's
where it's supposed to be. So that's kind
of how you would run through it is
creating that
test case, and then you would run the
test script across your inventory. And it would
go out and take care of the connections,
all the parsing of the show commands, and
then the configuration as well.
So what does the southbound, northbound interface look
like on this thing? Are you working primarily
with screen scraping? Are you primarily working with
Yang models? Or is it are there multiple
ways of communicating to the devices? Or how
does how does that bit work?
Yeah, that's a good question. Yeah, so they
have
most popular still is SSH, your common denominator.
But there are options to connect via REST.
Netconf is also so you're able to extract
those Jing data models and and create or,
you know, perform transactions using something like NetConf
and then also Rest Comp as well. So
there are alternative ways besides just screen scraping.
Okay. Alright. That's good because that always is
an issue, you know, with these with these
types of things is
and how do you handle yang models between
different
are there translation modules in there that you
can say, okay. I'm working on a Juniper
device. I'm working on a Cisco device. I'm
working on, well, Bird doesn't have Yang. I'm
working on FR routing.
Do you have translation models? How do you
deal with the different
implementations
of Yang or different
different ways of dealing with Yang?
So I mean, I think
so built into the library? No.
There's really not. You would have to either
create those translations or use Python logic
to I'm keeping the example simple. But you
could say, hey, if device. Os equals
iOS, then maybe look at these end capabilities.
Or if it equals fr, do these capabilities.
So you could
using the device attributes assigned to the device
objects, you could clearly delineate some of those
different capabilities.
That might be one way to do it.
Okay. Interesting.
So there's no way to consume a Yang
model
per se.
Right? I'm I'm assuming there's no way to
consume a Yang model from outside that would
be rather sophisticated
machinery in the software
and, like, use it. You would just have
to introduce possibly another Python library that can,
take a look. Like I said, it would
be outside the scope
of the Pyts, but you could implement it,
right? Because we're talking just Python at this
point. Okay. All right.
And
any like, because it's in Python I mean,
why Python? I'm always curious about this because
different people do do different things in different
languages.
Like, is there a reason for Python instead
of, like, Go or Rust or anything else?
Is it just because it's such a common
or is it because the open source stuff
was already there, Genie was already there in
that format, or was there a specific reason?
Not so once once again, I don't I
was on the development team, but my guess
is just based on
what I've seen, the amount of network automation
focused libraries, Python seems to be pretty dominant.
Ghost is catching up pretty significantly.
But yeah, Python, I think, just
and when it comes down to it, we're
just
what we're looking at is data parsing and
data manipulation.
And Python is still king, I think, in
the data science world and just kind of
be able to organize data. So that would
be my guess. Okay.
Yeah.
Cool. That's good.
Yeah. I mean, guesses are fine. I'm just
trying to figure it out. Right? Like, is
there anything else that's that's that's there?
Yeah. Okay.
So is there Danny, have there been any,
have you come across any real world use
cases where this approach
saves somebody time, saves errors and trip configurations,
saves something, anything in that area?
Yeah. So,
yes. I I work for,
and I basically, a consulting service, and we
we've implemented
this framework at a couple of our clients.
And
one that I've actually was hands on with
is being able to
validate
the team that I was working with was
responsible for doing hardware refreshes
at multiple sites,
sometimes
multiple within the same night or couple of
days. So
they're pretty fast churn here.
So what you know, part of the refresh
was obviously the configuration
piece, which I think that's the number one
use case is configuration management, generating configs, moving
configs.
But after the fact, once every once they
swapped out all the hardware, they had to
do all their validation with routing, layer two,
even environmental factors like your CPU memory,
power. Right? So making sure that even the
power supplies were in a healthy state.
And we were able to use the PyETS
framework to validate all of that.
So basically, the tool would run. It would
have
multiple artifacts. So it'd have pass fail results
along with connection logs. So you could see
the raw show output and everything that it
did on the device.
And it ran within
one to two minutes versus
running show commands that could take up to
twenty, twenty five minutes.
So, yeah, we we've definitely found we have
found that the network validation and testing piece,
not many people think of because, you know,
it's not really that fun. Like, it's not
it's not a top use case for many.
It doesn't really create any change. It doesn't
have any sort of progress in some network
engineers' minds because it's not making those changes
in solving their use cases.
But it has so much valuable data that
you might not know about your network.
Right? So,
it helps like I like to say, it
validates the design that was implemented,
or invalidates it.
So your network architects create a really nice
design, say, all right, engineers go implement this
or ops go implement.
And everyone just assumes it's working as expected
until there's a problem. But what if you
could just constantly
run tests against your network to validate that
design is implemented and running as expected?
Yeah. This is something that I think is
is
really, really underrepresented
in the industry today. Lots of people wanna
talk about, oh, I took my my intent
was translated into configurations, and I was able
to make the little soldiers march, and they
all did the things that I told them
to do. And, you know, we wanna talk
about, you know, monitoring bits per second on
an interface.
But it seems like there's almost no voices
out there talking about, well, is the network
actually working?
And that seem it seems to me that
this is is a strange gap.
Like, why why aren't more people talking about
is the network in the state that you
wanted it to be in? Are all those
routing tables correct like they should be? Are
all the interface states the right I think
people think of this as a monitoring problem,
but it's not. Validation is a is a
different area. Yeah. And and yeah. In fact,
I would say that was one of my
first things when I encountered intent based networking
was that people tend to think, I'm gonna
go check the configuration
Right. Every five minutes and make sure the
configuration hasn't changed. And I think,
yeah, but the configuration, like, unless somebody's going
in on the box and doing it, configuration
isn't gonna change. What changes is,
do I have all the BGP peers I
expect? Do I have the, all the USPF
neighbors do I expect?
Am I recursing into the correct place? Is
this route following that particular,
you know, going off the right interface? Is
that what I expect? Or is there something
different going on in the network?
And I need to go figure out why
it is this particular route is following that
thing over there instead of this thing over
here.
Yeah. Configuration management, like, if we focus on
that to the exclusion of other things, it's
it's like you you're seeing, like, 2% of
the entire problem space.
In in in my world where I do
a lot of product testing, configuration is a
mere suggestion.
Like Yeah. That is not a command. It
is not a a priority or authority of
anything. It is a, here's a good idea
that you might wanna do a system, but,
you know, you're it's the system's gonna do
its something. And Yeah. Yeah. Well, and and
that's and that's a thing too, right, that
we tend to think of configuration,
and this is
an argument throughout the entire world. In fact,
I use this as a I use this
as an interview question. Are recipes
suggestions?
Are they patterns to follow, or are they
chemical formulas?
And quite often, we think of a recipe
or a configuration
as a formula. You go do this.
When in reality,
you're trying to solve a problem,
right, which is to make a really good
cake or a really good biscuit or a
really whatever it is. And so
you may not have all the same ingredients
or whatever, and you might need to go
change things, or you may just like it
a little bit different, or you might have
a, you know, whatever it is.
And I think that we tend to, particularly
in the world of network validation and configuration,
we think of things as being very fixed.
There's one right way to do it or
whatever it is.
The reality is there's not one right way
to do it.
There's a thousand right ways to do it.
And what's important is that you come out
in the end
getting done what needed to get done.
That's really what's important.
And so it sounds to me that's kind
of what you're
you're addressing in this space is
not so much,
just like what the configuration looks like, but
like what the result is, what what what
is coming out of this.
So
so so, Danny, why,
why would I I think I know the
answer, but I would like to hear your
perspective.
Why would someone use PyTS
instead of just getting,
get setting up Pytest with test infra for
SSH into the devices and,
you know, because you can you can pretty
quickly make Pytest do most of this.
What's the what's the use case? Why why
is Cisco specific product?
Yeah. That's a that's a good point. So,
and and I've had other projects where I've
used,
pytest as well. Right? So,
I definitely understand, like, this this is a
problem that not pytest can only solve.
Why, you know, between the two, I'd like
to compare it to, like, if you're familiar
with Python web frameworks, Django and Flask.
So I've started my journey with Flask. And
for those that aren't unfamiliar, Flask is very,
very
rudimentary. It has just the basics
to just do requests and response to
web requests and responses.
And
then you have to kind of use extensions
to Hey, I want to talk to a
database. Alright. I'll install
Flask database.
Hey, I want to talk to this.
Okay. I got to learn about SQLAlchemy. I
want to do this. So you kind of
branch out very slowly as you need features,
whereas Django,
it's a batteries included framework where it has
a database, it has an ORM, which, you
know, you're able to communicate with that database.
And so that's kind of where PyTS is.
PyTS, I would say, is the Django of
network testing.
You have you have to define a test
bed, but everything else is taken care of
for you. If you want to configure the
device, you're one method away from that. If
you want to parse something,
you call the dot parse method, right? So
everything is just kind of built in.
Obviously, there's more there's more to learn about
it and there's a lot of documentation
and now a book out there for you
to understand the framework. But
it really is just it's batteries included. You
don't have to figure out all the different
pieces, especially if you're green.
But if you're
experienced and you have some familiarity with pytest
and some of the constructs there and you're
familiar with other Python libraries like NetMico or
Norni or Scrapply,
where you could do the device connection and
device
being able to get data off the devices,
then go for it. But yeah, I think
the batteries included piece of IETF, I think,
is what can draw
a lot of people into it.
Yeah. That's
that's that's great. I
the and I like I like that you
use Django because,
so I've I've no expert, but I've used
Django a couple of times. There's a fair
learning curve just learning how Django sees the
world, and it's Django. It's not Python. It's
Django. How does Django see the world? But
then once you understand Django's perspective, things are
so fast. You can do you can do
enormously complex things, in very little time. It's
just that you have to learn how Django
sees the world, and, I can see how
that would apply. And and with Pytest, you're
you're totally right. Like, you have to invent
all of the pieces yourself, and it's not
terrible. I mean, if you can write Python,
you can do all this stuff. But,
that that's great. I think that's a great
comparison.
Are there any restrictions or trade offs for
choosing
something that gives you more of the bits
and pieces prebuilt?
That's always a question, right? Yeah. That that
is. Yeah.
Yeah. So, I mean, with with PyATS,
I think it's especially if you're you're already
one that's hesitant with Python,
py ATS can get you up and running
pretty quickly without having you
without you having to understand the internals,
right? So there's a lot of, I would
say, abstraction,
and there's some features actually within the framework.
There's a feature actually called
PyATS Blitz,
that you don't have to write any Python,
it's all YAML. It's a lot like Ansible
in that way,
where you can you still have the constructs
of PyTS, but everything is defined in a
YAML file instead of, you know, Python classes
and functions.
So there's I would say there's more abstraction
on top of everything kind of being within
the framework, the inventory system,
the testing, the reporting,
the data parsing, the data models,
because there's a function within PyTS called,
or the PyTS library
called learn, where essentially
you can learn about a network feature like
OSPF
and you can run the learn command against
your entire testbed
regardless of the operating system, whether it be
iOS, Junos,
anything supported by the framework. It will come
back with a vendor agnostic, a data model,
essentially, that you can query
all those facts about that specific feature.
And the scheme is documented and so forth
in the Pytest documentation.
So all of that is out of the
box
there for you.
If you looked at an alternative route like
iTest,
you could build some of that,
being able to get all the command all
the show commands and being able to normalize
that data set and then using a you
know, data validation tool like a Pydantic.
So you could do all of that manually,
and it does provide more flexibility in that
way. But like I said, if if you're
coming from just traditional network engineering,
you know, you don't I don't think many
network engineers wanna get into data model and
data validation,
you know, day one. So I think there's
there's a lot to be had with having
that full framework
at your fingertips.
Okay. How does how does how does Pyet
yes. So have you noticed in terms of
performance, are there are things like concurrency
built in if you have a large inventory
that's all handled?
Yeah. So,
yeah. So there's a feature
called,
p it's called p call, but it's short
for parallel calls. So, essentially, they do parallelism
under the hood.
So it's not necessarily
your true concurrency, but it's parallelism. So you're
doing multiprocessing
to to hit all a bunch of different
devices. So you could basically
under the hood, you create, you know, multiple
processes to connect to each device.
And normally,
if you don't introduce p call, you're just
doing basically serial,
hitting each device and going through the pecking
order.
So here's here's one one example where,
if you don't want to deal with concurrency
and threads and stuff, you know, this is
where I yes. It would it would be
like, large inventory. Great. Problem solved. One of
the problems I've had to solve is concurrency.
And so what do you do? Well, we
turn to the Python threads library or whatever
else, you know, whatever library. And, you know,
you're smiling a little bit there, Danny. That
comes with a certain amount of suffering. Right?
Yeah. Yeah. The executor,
the pulling. Yeah.
Yeah. Yeah.
And so so this probably also intersects with
concurrency in a different way. Right? Sometimes you
need to configure things in a certain order
to make them work correctly, and you gotta
make sure
that step a was done before you do
step b, where, otherwise, things don't come out
correctly. And I assume there's a way of
handling all of that
type of stuff in PyATS.
Yeah. Yeah. So and and that's,
you're able to do that. A lot of
a lot of that kind of logic that
that logic handling is with the, the testing
framework. So you can choose,
hey, if this TestCase fails, which incorporates this
logic,
then we're skipping to the end and closing
out the testing. Everything else fails, right? Or
jump to this point. There's actually an interesting
way I believe it's an argument.
Whenever you
do pass fail,
because everything's in a class, you call on
self. So it's like self. Pass, self. Fail,
self. Whatever.
In that argument,
you could provide a string value as a
reason for the result, why it passed, why
it failed. But there's actually an argument called
go to.
And just
like programming back in the day where you
could jump around to different functions and use
the go to
functionality within, I think it was C.
Yeah, C, C plus plus tells us Go
to. I don't have too much experience with
it, so that's why I was saying that.
Yeah, that's fine. Yeah.
But yeah, so you can actually use that
and say Go to, and then you provide
the name of the test case.
So let's say you have five test cases,
and if this device fails on test case
two, skip three. You can either skip three
or you could say go to test four,
and then it will kind of keep going.
So it's kind of interesting that there are
some ways
to handle that during the testing,
phase.
Yeah. Cool.
So I'm assuming that if people wanna play
with this, they could do it with something
like container lab. Right? Like, doesn't require physical
hardware.
You can actually bring up
virtual boxes
using, I don't know, whatever whatever your poison
is for virtual labbing
and,
play with this. Right? Like, this is not
something that requires
physical hardware.
No, not at all,
because there's nothing that's super data nothing intensive
on the actual
network
devices themselves. We're just at it's either SSH
or NETCONFRESCONFR
connecting the device,
and extracting data. I will say with it
being
a coming from Cisco, obviously, there's a lot
of support for Cisco devices.
And as you guys probably know if you've
ever tried doing virtual labs, Cisco is it's
interesting compared to the rest of the network
vendors with containerization.
Now you can use ways to convert the
VMs to containers and so forth, and that's
kind of what I do. But they get
they can get kind of
resource intensive if you spin up too many.
So
that's just just a warning if you do
use something like a container lab. I do
a lot of my testing just within CML.
So once again, it is it's another Cisco
product, but it works out really well.
And they have a cool integration
where,
I'm sorry, it's really just a feature where
if you build out a,
a CML lab and
do all your testing and so forth, you
actually can there's a I think it's a
I don't know if there's a UI feature,
but there's an API endpoint
to export the whole lab as a PyTS
test bed.
So you can kind of add that as,
you know, if you're thinking
down the line of, like, doing a CICD
pipeline, you can call on CML,
get a certain lab by its ID, and
then call on that endpoint to generate
a dynamic
PyTS testbed.
And then that way, you don't have to
worry about Jinja templates
or dynamically figuring out your own logic to
create that testbed file. You can just use
a CML topology
to create that testbed.
Interesting.
Okay.
Awesome. I don't. Do you have anything else,
Tom, before we wrap up?
No, it's been really great. Thank you. Anything
for you, Danny? Is there some part of
this that you wanted to cover that you
didn't?
No. Not really. I mean, I definitely it's
a it's a big frame it's a big
library.
There's multiple features. I mentioned PyTS Blitz.
There's some other interesting
features within the
within the library. So definitely take a look
at the documentation.
And I would just say, like, it's kind
of a final word, like,
explore network testing and validation, whether it's with
PyTS or whether it's with Pytest or whether
it's outside of Python and it's using Go
or another testing framework. If you're able
to
get the data from the network, the testing
part
is pretty easy. So
being able to just you have to just
remember the network at the end of the
day is just data. So whether it's configuration
or,
you know, the operational state data,
getting that data out of your network. And
once you have that data, there's a lot
of really cool things you can do because
the software development world has been doing it
for years. So
Yeah. Yeah. I would just say take take
a look at network testing and validation as
your next step with with automation.
Yeah. That's really cool. Well, thanks for coming
on. And the book is PyATS.
Right?
Correct. Yeah. Cisco Py ATS, network tests and
automation solution.
Awesome. Great. I'll try to put a link
to it in the show notes if I
remember.
I never remember these things, so who knows?
I always say my memory is like a
steel sleeve. Only the big chunks stick.
So
that's the way it is. Alright. So, Danny,
where can people follow you? Are you Twitter
or X or LinkedIn or I don't know
wherever. Where do you blog someplace? Yeah. So
I have my own
blog, DevNet Dan.
That's also my Twitter
account as well. It's also DevNet Dan,
and I'm also on LinkedIn,
not under DevNet Dan. You can find me,
Daniel c Wade. It's just my full name,
on LinkedIn.
But, yeah, I'm most active probably on LinkedIn
and Twitter these days. I gotta catch up
on on the blog at some point.
Yeah. Well, that's okay. I'm I'm the next
person I ask is gonna be Tom, and
go ahead, Tom.
Tom's pitiful compared to you, Danny.
Link LinkedIn. That's it. Just search for me
on LinkedIn.
Oh, I don't know. Alright.
Okay. Well, I'm Russ White. You can find
me here at the hedge @rule11.techat
rule eleven academy
on LinkedIn
and
on Twitter. I don't know. I check I
check x a couple of times a day
or whatever now. So
feel free to DM me on any of
those, come over to the academy or whatever.
And
we know that you live we live in
an attention driven world and that,
your intention is probably the most valuable thing
in the world right now. In fact, if
you could sell it, you'd probably be wealthy,
but you can't, say you aren't.
So, anyway,
thanks for listening all the way to the
end of this episode of The Hedge, and
we will catch you next time.