Hello everybody, thank you for being here, my name is Anfonso, please call me Poncho,
and I'm also a developer advocate at Cisco Debt.
I'm very happy to be here with you, sharing this session, and in this session we're going
to discover together a very, very practical approach towards leveraging your network automation
operations of every day, using an open ecosystem based on AI agents, and also low-cove
tooling.
So by the end of the session, I hope that you're more aware of all these tooling, all these
things that you can do with this ecosystem, and be of all sorts of interesting use cases
in your own networks, right?
Let's go, let's go, let's go, let's go, let's go, let's go, let's go, let's go, let's work
on.
All right, well, this is my name, I'm based on Lisbon Portugal, and here I lay my LinkedIn
and GitHub in case you'll want to carry on with the conversation later on, and I always
love to share this picture, it's our offices in Tokyo Japan.
We have one mascot for technology, and I think that's pretty, pretty cute.
So let's get started with our agenda, and we're going to have a look, very brief overview
of what agentic ops means in the world of network automation, what's the current status
and which are the tools that we have available.
Then we're going to have a look at proposal of text that stack for these open ecosystem
for our network, and then we're going to have a deep dive into very technical demos.
I have two use cases prepared for you, and then we're going to wrap it up with some references
and good practices.
So having said that, what do we need to take this steps back and talk about our modern
LLMs?
Like the LLMs that we can use right now, either it's a BNAPI or things that we can download
via Olama, whatever that may be.
As of now, LLMs are surprisingly good when it comes to speaking the language of networking.
I'm talking about CLI commands.
Most of when it comes to the most popular Bendor's out there, and the thing is that all
these LLMs have been exposed to a lot of real network use cases.
So they can speak the networking language, while they don't have the context of the network.
That means they don't know what's going on in the network, but they can be fluent by generating
CLI commands.
Out of the box, we know trading, we know nothing.
They are very good at that as of now.
And also something that they're very good at is generating a series of steps when it comes
to the interpretation of a high level intent.
So for example, if I take a model that I just downloaded and ask hey, for this very popular
Bendor, can you tell me what's the health of the interfaces of this network device?
More than often, these LLMs will be able to generate as soon as the good lists of commands
that they will issue and that they will then cross-check to give me the information that I need.
And on top of that, we have low coding tools available so that we can create all these
genetic architectures with little to no code.
There's of course some coding plug, yes, mostly glue code or like the data formatting, whatever.
But it's pretty seamless to create these architectures and more important to app guard
rails.
That means we want to have a human in the loop, for example, we need to have a person
there who presses the red button.
So having said that, I have this proposal of an open ecosystem of text stack, so to say.
We start off with our LLMs.
I'm pretty certain that most of you are aware of Olaman.
We can deploy it in our own computer, we can deploy it also like on more powerful environments
and we can download all sorts of models that we can also train and while these models
are tailored for some specific applications.
Next, N8N.
It's right now one of the most popular workflow platforms out there.
And the thing about it is that you can easily self-host it.
It allows you to do all it, it allows you to monitor all the different executions of your workflows.
And if you ask me, it's pretty fun to use.
I have a lot of fun using it.
It has a collector of integrations.
We're going to find out in the demo how we can leverage it for our network automation operations.
And the last but not least, MCPs, yes.
At the end of the day, we need to talk to our real networks.
Our infrastructure is the living creature out there and we need to be able to talk to it.
So I want to ask you something, if has any of you here heard about PIATS?
Please trace your hand.
Okay, well, I'm going to be honest, that's more than what I expected.
I'm pretty happy about it.
For those who don't know, PIATS is a project donated by Cisco.
It was initially created as a test automation framework, but it has evolved into much more than that.
It allows us to seamlessly communicate with our network devices when we provide an inventory in a very simple YMO file.
And that's the way that we can interact with those devices.
So speaking of this, let me jump into my repository.
Just in one second.
Okay, it's not showing up.
Hold on.
Sorry about that, let me just put it here.
Yeah, that's better.
Now you're going to see me all crooked to the monitor.
So we have a PIATS entity server.
This is completely open to code.
You can check it out, contribute, whatever you need.
And we have some exposed tools that are completely based on these PIATS library.
We also have a here instructions to use and always on sandbox.
You can actually test it with a real network.
It's available in our definite site.
I also cared some other instructions for setting it up and you're writing it with a
leave it a chat for examples.
You can test it right away.
So going back into our presentation, I want to integrate all these different tools in
this open ecosystem and show you one very first demo.
This demo, we're going to have an agent check-ups workload for network automation operations.
Think about this.
It's entirely based on any done.
We're going to have our unsaturated employee connected to our always on sandbox lab.
This is a real network rail infrastructure.
We're going to have a lack of authentication in the NGRACTONO hooked to our Slack channel.
We're going to use NGRACT because although NGTA has some tunneling available by default,
let me tell you something, it's not reliable.
So for now, you better rely on something more stable like NGRACT.
Think about this.
We're going to be able to interact with our LLM, with our NCP.
To do two types of queries, reef queries from our infrastructure, but also right operations.
I should be able to commit network configurations.
Think about this.
We're going to be implementing guardrails and human in the loop.
So at the end of the day, as I mentioned, we have a person, a human being, pressing that
red button.
And then jump into our demo here.
I'm going to go, just second to worse my mouse.
There we go.
OK.
First of all, in this time, let me turn it back.
Can you see the graph that we have here, the diagram?
Not really.
All right.
Well, before that, let's jump into something.
I think this one is a little bit more clear.
I have a Slack channel.
In this Slack channel, I created this small bot.
It's called BACC.
And packet is going to be integrated into this channel here.
Let me just make some in a little bit more.
I think that's better, right?
For the people in the back.
Awesome.
OK.
So I added my packet app.
I'm going to say, hey, hey, buddy, can you please tell me which order devices in my inventory?
It's going to go to my N8N workflow.
It's going to use all the tooling that I have available during which we will hop to in
a second.
And it's going to give me a reply.
This is the list of devices in your inventory.
This is how we're once again.
I were always on the N8N sandbox.
You can also use it yourselves.
Now, I can say, hey, packet.
OK, that's nice.
Can you please list all the b-lens on my switch one?
I want you to show me the information that you can find.
Create the nice table with it.
Cool.
It's going to go there.
It's going to fetch the information.
It's going to format it for me, and it's going to display it here.
Perfect.
OK.
That's a read operation.
Now I want you to do something else for me.
Please create a new b-lens on this switch.
Use this part of meters just send it in.
Something happened here.
I'm going to show you later.
I have here the human in the loop later that I will show you in a moment.
I said, yes, in this time, and this configuration went into my device.
And here, it's showing me the confirmation of what just happened.
Now, that human in the loop situation.
I'm going to do it again here for the same switch,
brand new b-lens here.
It's going to show me a part.
This is my human in the loop thing.
It's going to show me a part.
And it is me, the human being, who presses the red button.
It's a yes, or it's a no.
And all of this is possible due to these N-A-10 workflows that we have here.
I'm going to show you here the executions very, very quickly.
We have these several agents here.
We have an intent agent, which is going to determine
if the web kind of operation I'm doing here.
Is it the read operation?
Is it the right operation?
What am I doing here from the message that came from Slack?
And you can see here that I'm using an Olama.
This is completely deployed on my computer.
I am using this quen model running right here right now
in my computer.
Then moving on, it's going to say, hey, this is a read intent.
So I'm going to be using this reading agent,
which is blocked to my MCP server.
Then it goes to a formatting agent, which makes it all
pretty, basically that's its own purpose.
And then it goes back to my Slack.
Now, what happens if it is right operation?
What I'm going to have here, no, this one here, perfect.
You can see that it goes in some other way here.
It's going to go to my planning agent.
This planning agent relies on how fluid it is on speaking CLI
for this specific device model in platform.
And it will propose a series of CLI commands
that translates my intent, my high little intent,
into actual CLI configurations.
And it's going to put it there on my Slack.
In that nice card that you saw that accept or deny.
And then if I say, yes, I want to configure that.
I want to push that.
I'm going to trigger this web hook,
and that's going to go into my commit agent.
This commit agent has a series of guardrails.
It should only write the specific commands
that come from the other part.
And those commands only should not hallucinate.
It should not come up with anything else.
It's just pushing it there through the MCP.
That's it.
We do nothing else.
There's also guardrails implementing on the MCP itself,
so I invite you to take a look at the tools at the code,
because, for example, some operations,
like shutting down the device, or whatnot,
are completely rejected at an MCP level.
So having said that, let me go back into our presentation,
because there's another interesting use case
that I want to share with you.
OK, I'm just going to hop here into our other demo.
We are going to be leveraging a very similar work now,
but this time it's going to be for reporting
and automated ticketing.
A sorts of get-ups reporting and ticketing suicide.
I'm going to have the finish on my repository
of the reports that I want to have, the agents that I need,
like all the agents' prompts are going to be there,
and I'm going to be storing their reports
and creating get-up issues if my agents
determine that there's something that needs my attention.
So having said that, let me go back to my browser
and I'm going to go here and here I have my status workflow.
Looks a little bit intimidating, doesn't bite.
I promise, but it's basically two agents.
Let me zoom in here.
We have a reports AI agent, which is going to take,
whoops, sorry.
It is going to take from my get-up here,
a definition of an agent.
You are a network automation assistant.
You're going to be creating this beautiful mark
than reports.
It's also going to take from this repository, let me show you,
as soon as it reports.
For example, this one here.
I want you to report on the operational state
of my interfaces of device R1 only.
So we're going to take these files in our NATEN workflow.
We're going to send them to our reports,
whenever it's, we have a scheduler or also manual triggering,
and you can see here what we have.
This is my agent.
This is my file prefix, my query, my intent, my notes,
and that's it.
We're going to do all the processing,
and then we send that, sorry for the mess up here.
We send that to our tickets IA agent.
This one takes the report.
It takes also the agent prompt that I have
thing in get-up as well.
And it will create tickets based on what's
happened in that reporting.
So at the end of the day, I end up with something like this.
In my repository, I have this automated issues.
You can see that with that last trigger,
I have here this ticket here, from the interfaces
that just report.
Hey, it's low, but you maybe want to have a look at it.
You want to improve the interface documentation.
Monitoring here we have with some context here.
Have some key recommendations.
Mark them list of tasks that we can accomplish here.
Current status and here we have a reference of the report,
which was also automatically generated and stored
in my repository.
You have here an executive summary, assumptions,
environment, overview, all the stuff is here.
And I want to go back to an agent and actually show you
what happened behind the curtains.
If we go back to our first agent, the one
for the reporting, and we expanded here,
you can see that my agent made several calls
to my NCP client.
You can see that first it took a list of devices,
just verify that the device that I requested
isn't in bed tree, that I'm not coming up with anything
random.
Then it issued a series of CLI commands that it knows very well,
because it's a wear of the device type and platform.
So it knows that these commands are going to work.
And it knows which tools to use with this PIA TSNCP
server.
So it used, for example, a show in your faces,
then it's sent a show in your face summary,
then it sends a show IP interface brief.
And that's it.
It did all the cross-referencing of all these outputs,
generated that report, marked them format.
Put it there, and get half, then pass it on
to the ticketing agent.
So that's basically how it works.
This low-code agentic workflow.
Let me go back to our presentation.
Yes.
And I'm going to skip all the way to a nice wrap-up.
It's our some personal suggestions
that I give to you if you're interested
in leveraging this in your own projects.
You know, baby steps build very single, very, very focused
agents that do very specific things.
We've all the different stages in your architecture
for network automation.
Also, Twitter LLMs, like a junior network engineers, right?
Just give them some patience, give them a lot of guidance,
give them a lot of guardrails, so that they don't
need to use potentially, talk, see, or potentially
conflicting configurations in your network.
Nobody wants a Friday night outage, right?
And the last but not least, use real networking tools.
There's lots of things available out there.
As my collection mentioned, there's a plethora of MCP
servers out there for any tool controller that you may need.
Now, this is an example with PI8TS, but everything
is at your fingertips.
And also, in definite, we have a lot of information
about this.
We have a lot of real devices, laughs available for you.
It's all for free, just need to create your Cisco accounts
not much else.
And just to wrap it up, I'm going to leave you here
with some references.
We're going to know more about NATEN, PI8TS, links are here.
And also, this is the QR code for the repository
of all these NATEN workloads that you just saw.
If you just, some seconds to take a look at the QR code,
all right, they'll real good.
So I want to show you the repository before we jump into QA.
Awesome.
It's just going to go back to our browser.
Here it is.
PI8TS, loves a gigantic ops.
Please have a look at it.
It was made with a lot of love and care and coffee.
And here you have the two low code workflows
that we just saw.
So everything's here.
And happy coding.
And let me know how it goes.
Thank you.
OK.
So we have time for maybe just a couple of questions.
Yep.
I was just curious.
When you, at least, let's say, for my experience,
I just want to hear what your thoughts are.
That when you are dealing with MCP tools, is it a good idea
to start with a destructive train of thought?
That is to say, if I complete my workflow,
as you have done here, the only way to really
be confident of it is if I say, hey, I put all these guard
rails in place, but what if the worst case?
Is that a good approach, you think?
Or is it just to optimize at the optimize?
No, I think it's actually the best thing to do from early on.
Think about networking.
We'll know here.
It's a different kind of Pokemon, right?
We really need to be pre-entive when it comes
to destructive configurations straight off the bat.
So my recommendation is, yeah, implement guard rails anywhere
you can.
Here, it's at an MCP level, but also at a workflow level.
We have guard rails and humanity loop.
And just try it out with the sandbox network.
So you don't break anything for real.
All right, well, great.
Well, thank you very much.
Thank you.