Author Archives

by

Agentic AI for networking

As I’ve pointed out in several posts, and as you’ve certainly noticed, there is a teeny bit of hype surrounding AI these days. We’re told network engineers will be obsolete as our AI buddies take over our jobs. Want to roll out a network? No problem, your receptionist will do it for you while sipping a latte, pushing a button to call her AI agent. Some of us take a more realistic view. AI is a tool. An amazing one in many ways, but a tool nonetheless. And the big question is: how useful is it, really?

Most of the folks making the wild claims are marketers, “analysts”, and others who know little to nothing about networking. John Capobianco is certainly not one of these. John knows a lot about networking, and is a truly technical guy. (I’ve never met him in person, so he could be an AI agent, but I hope not.) John recently posted a detailed video about running an AI agent per device, and aggregating these up to a sort of agent-of-agents. His POC demonstrates that his AoA can go out and perform operations on multiple network devices. Cool.

That said, it brings me back to my early days in programmability, 2015 or so. One of the demos we used to run used Alexa. You could give voice commands to Alexa to go configure your routers, or collect data from them. Very cool! How many network engineers to date use Alexa to configure their networks? Approximately zero.

Of course, we weren’t really expecting to kick off a craze of Alexa-network-engineers. The demo was, as my peer Jason Frazier liked to say, about the “art of the possible.” Our model-driven interfaces made it that much easier to connect things in ways that weren’t previously possible.

As I mentioned in a recent post, programmability didn’t always click with network engineers. We would do a demo where we configured VLAN 100 using NETCONF. We just wrapped a giant block of XML in a giant block of Python, and–voilá–VLAN 100! The only problem was, every network engineer who saw the demo rolled his eyes and said, “I could do that with one line of CLI.”

Here’s the question for Capobianco: Is typing “Please configure an NTP server of 192.168.100.100 on all four devices” easier than, say, configuring an NTP server on all four devices? Or even using an Ansible script to do so? Is typing “What is the IP address of Ethernet 0/1 on R1 and R2” better than just going to R1 and R2 and looking at the “sh ip int brief” output?

We must also bear in mind that AI, still, has trouble with more complex tasks. In an earlier post I found it could not configure VRRP for IPv6 correctly. Even after providing it the operational output of the failed config, it still couldn’t provide the correct config. So, NTP servers are fine, but when we get into really complex stuff, will AI shine or fail?

I’ve been finding ChatGPT incredibly helpful working in my lab lately. I needed to do a few things on ProxMox, and it saved me a lot of searching through StackExchange. But if we want to go from useful tool to fully agentic network management, well, we have a long way to go. Right now the agentic demos feel a bit like the Alexa ones–the art of the possible, but not necessarily the probable.

2
by

Lab Notes: Proxmox

Note: I’m playing with themes right now. I don’t particularly like the one I’m on today, except code blocks look better and it reads nicer on phones. We’ll see if I can tweak the CSS to get it where I want it, or will need to switch themes again.

The nice thing about being an individual contributor again, and not being allowed to travel to Cisco Live in Amsterdam, is that I can spend more time in the lab. I acquired a UCS (actually DN appliance) server, for some new projects. It had a bunch of 2TB drives, and being a lab server I just threw them all in a RAID 0 for 12 TB. Simple. Next, getting a hypervisor up and running.

I’ve used ESXi for years, but it’s gotten a bit tiresome. The licensing is expensive and complex. For internal Cisco users, we need to go through a lot of hoops to get a license. So I decided to try ProxMox instead. It’s free, I don’t need to muck around with licenses, and so far, it seems to behave basically like ESXi. I had a little trouble finding a thing or two, but ChatGPT was quite helpful.

I’m setting up a GNS3 instance, on which I hope to install SONIC. The docs for doing SONIC on GNS3 say that you should install it on Windows, but I’m not convinced this is the case. I’m probably wrong and will find out. The SONIC image is 24 GB (!) so I had to make sure to account for that.

Anyways, the ProxMox install was a breeze. Just mounted the ISO via CIMC and away I went. My only complaint is that every time I log in to the browser, it asks me to buy a subscription. But this is not needed for day-to-day operation, just for updates.

So far, I’d recommend ProxMox enthusiastically. We’ll see if it holds up.

1
by

Legacy language

The spambots who regularly read my blog know that I have a fascination with language, and have a background in linguistics. So, I’m always fascinated by language and how we use it. This post is a bit pointless, but amusing (perhaps only to me).

In my last post I mentioned I might file a bug on VRRP. Apparently, I still have access to do this, although I cannot remember how to assign it.

Anyways, most Cisco customers know that a bug at Cisco is called a “DDTS”. We’ve called bugs DDTS’s as long as I’ve worked on Cisco products. But what does it actually stand for?

DDTS stands for Distributed Defect Tracking System. DDTS is actually the name of the bug-tracking software that Cisco used, a long time ago, to file and track bugs. DDTS was replaced long ago by CDETS, Cisco Defect and Enhancement Tracking System. Even when I was in TAC in 2005, we used CDETS, and not DDTS, to file and track bugs.

Not only is the term DDTS obsolete, it doesn’t even make sense if you expand the acronym. “There is a DDTS in that version of IOS XE” actually means “There is a distributed defect tracking system in that version of IOS XE”. Not likely!

Language evolves and words often lose meaning as they are used. I remember the Greek word “thumos” which meant something like “warrior spirit” in the days of Homer. A positive thing, something you’d want to have, a certain virility or militancy. By the time of New Testament Greek, 700 or so years later, it just means “anger”.

So, at Cisco my exec will have an “off-site”. This used to mean you’d go to Hawaii. Then, a Hilton in another city. Then, the local Hilton. Then, another building on the same campus. Now, at Cisco, we have “off-sites” on the same floor of the same building we work in every day. Nothing off-site about that!

Maybe we should have an off-site about DDTS’s…

1
by

Themes, again and again

For my regular readers, as I like to say, all 2 of you, I’ve noticed that the theme I switched to a few months back does not display well on mobile. In particular, my last post had code blocks which get cut off when viewing on a mobile browser. Now that I’m not a manager-type anymore, I’d like to do more posts with code blocks, so this isn’t great. But even text-based articles don’t display well with this theme.

I’m working on finding a mobile-responsive theme, you may notice some changes to the look and feel over the next few weeks. I like dark themes, so hopefully I can find one that works.

3
by

VRRP, IPv6, and the “Why” Question

Ivan Pelpnjak has an interesting post (H/T to Ethan Banks) critiquing Cisco’s VRRP v3 CLI implementation for IPv6.  It got me thinking about a question I was told never to ask:  “Why?”

Never ask why?

Back when I really wanted to get into networking, I took a five-day bootcamp with Global Knowledge taught by a gentleman named Tony Marshall.  It was four-days of study, and then on day 5 you took the CCNA exam.  Tony was an awesome teacher, and I passed with flying colors.  However, if ever you asked Tony “Why?”, he would interrupt you before you finished your sentence and say, “never ask why!”  The way Cisco implemented it was the gospel truth handed down from above.  This is probably the correct approach for a four-day CCNA bootcamp, and producing automatons who never question Cisco’s decisions was also great for business.  In product management we call that “competitive advantage.”

Since I’ve been doing management stuff for eight years my CLI skills are a little rusty.  I’m going to walk through the VRRP problem in a lot more detail, largely for my own benefit, and then circle back to the “Why?” question in the broader sense.

VRRP and IPv6

Virtual Router Redundancy Protocol (VRRP) is a protocol used to provide default gateway redundancy, and is an IETF cousin of Cisco’s earlier Hot Standby Routing Protocol (HSRP).  VRRP allows two (or more) routers to share a single IP address, which one router actively responds to.  Should the router go down, the secondary router begins responding to that address.  If you’re reading this blog, you probably already know that.

VRRP is simple to configure.  I set up a VRRP group in my lab, using VRRP v3, which supports both IPv4 and IPv6 addresses:

s1(config-if)#vrrp 1 address-family ipv4
s1(config-if-vrrp)#address 10.1.1.100 primary
s1(config-if-vrrp)#priority 200

Here you can see I specify we’re using a v4 address, and I made 10.1.1.100 the primary address.  (You can have more.)  I also configured the priority value for this router (actually switch).  I did the same on the other router with a lower priority, and viola, we have a VIP responding to traffic.  From another router on this segment:

r1#p 10.1.1.100
.!!!!

 

How does ARP work in this case?  The MAC address used comes from a reserved block designated for VRRP.  The last octet is the VRRP group number.

r1#sh arp
Internet 10.1.1.100 0 0000.5e00.0101 ARPA Ethernet0/0

 

If this were VRRP group 2, then the MAC address would be 0000.5e00.0102.

So far so good, but how does it work for IPv6?

If I just attempt to configure a global IPv6 address with VRRP, a couple funky things happen.  First, I cannot add the “primary” keyword:

s1(config-if)#vrrp 1 address-family ipv6
s1(config-if-vrrp)#address 2001:db8:cafe:100::100/64
s1(config-if-vrrp)#address 2001:db8:cafe:100::100/64 pri?
% Unrecognized command

 

It will take the command without the “primary” keyword, but VRRP gets stuck in INIT:

Vlan111 - Group 1 - Address-Family IPv6
State is INIT (No Primary virtual IP address configured)

 

As Ivan points out, this is per the RFC.   The RFC requires that the source IPv6 address be a link-local address.  If you haven’t done a lot of v6, recall that each interface will have a globally routable IPv6 address as well as a link-local address, which, as the name implies, can only be used on the local link and is not routable beyond that.  Without getting into all the details, the link local address is assigned from the FE80::/10 block, and on Ethernet interfaces it is made unique by using the interface MAC address.

OK, the RFC says:

“…each router has its own link-local IPv6 address on the LAN interface and a link-local IPv6 address per VRID that is shared with the other routers that serve the same VRID.” (Emphasis added.)

So the router has its own address (assigned automatically when IPv6 comes up), but each virtual router ID requires a link-local address too.  Elsewhere, the RFC states the primary address must be the link-local address.  But why?

The RFC is explicit that this link-local address is the source-address for VRRP packets, so presumably this is to keep the VRRP packets local, and to prevent them from being routed outside the segment.

Fair enough.  Let’s add a link-local primary address:

s1(config-if)#vrrp 1 address-family ipv6
s1(config-if-vrrp)#address FE80::1 primary

And…it works!

Vlan111 - Group 1 - Address-Family IPv6
  State is MASTER

Easy, right?  One more step, perhaps, but it’s not too hard.  Except, as Ivan rightly points out, some vendors (like Arista) assign this link-local address automatically for you based on the group MAC address.  Aside from the fact that this makes it easier (no need to keep track of another VRRP address), it makes interoperability challenging.  If I want my IOS XE device to be in the same VRRP group as an Arista device, I need them both agreeing on the LLA.  (Although, to be honest, I’m not totally convinced on this use case.  Usually devices peering in VRRP groups will be identical hardware, even in mixed-vendor environments.  But I might be wrong.)

Let’s go with Ivan’s thought that this is poorly designed.  I have access to internal Cisco tools that Ivan doesn’t.  What are people saying?  Are we getting TAC cases on this?

It turns out, not many.  I found one case in Spanish, which I can read (even without ChatGPT).  The customer complained he configured VRRP “pero no hay ping”.  No “hay ping” because no hay link-local address.  The TAC engineer pointed the customer to a bug, so why isn’t it fixed?  Well, the bug (login may be required) is a documentation bug, requesting the link-local address be added to the VRRP docs.  They added this:

Device(config-if-vrrp)# address FE80::46B6:BEFF:FE50:DBB0 primary

 

…but nowhere do they tell you how they derived that address.  Meanwhile, on one of our internal mailers, an engineer asked about just using FE80::1 like I did.  The development engineer working on IPv6 VRRP replied:

Is the FE80::1 recommended?    <<< usage is fine AFAIK

 

Usage is fine, ok, but is this the best way to go about assigning link-local addresses for VRRP?

The “Why?” Question

Back to the larger question of why.  Cisco is not the only company to have built confusing CLI.  In Ivan’s very post, he even notes that Dell allows you to skip the link-local address altogether, in flagrant violation of the RFC.  And years ago I wrote pieces on utterly baffling Juniper CLI, such as the concept of and syntax for configuring RIB Groups.

Who designs the CLI?  A committee of experts who used to work at Apple, after thorough user experience research, you think?  More than likely, it was designed by the engineer charged with implementing the protocol.  This engineer is certainly not a network engineer and does not need to deal with operating a network.  Sure, he/she can configure routers a bit, but mainly for lab testing of his own features.  What makes sense to an engineer burning the oil at 3am in Bangalore might not make sense for the rest of us, but as long as the feature works, some way, some how, he can close his assignment and move on to the next thing.

But surely the executives at the vendor care, right?  Short answer:  they will care, and care a lot, if they meet with a giant customer and the giant customer screams at them that feature XYZ is impossible to configure.  Otherwise, it’s highly unlikely a senior vice president cares how VRRP is configured, and also unlikely he knows what it is.  Thus, the development of CLI can be a bit Lord of the Flies.  No adults in the room, so to speak.

What about filing an actual bug to get it fixed?  I could do so, for Ivan’s sake, but two problems.  First, the bug will be the lowest severity possible and engineering will be more focused on other things.  Second, if they do get to it, they won’t want to fix it for fear of breaking existing configs.  Years ago I brought up the problem with IOS XE’s model-driven management syntax.  To enable NETCONF you type “netconf-yang” at the global level. To enable RESTCONF you type “restconf”.  GNMI is “gnmi-yang”.  Couldn’t we have a code block called “model-based-management” (or something) and then you enable each of the features under that?  No, engineering told me, people are already using it the old way.  (Honestly, like, nobody was in 2016, but anwyays…)  Great idea, Jeff, but we can’t do it.

The TL;DR summary for you:  Tony Marshall was right.  Never ask: “Why?”

Postscript for those who think AI will replace network engineers:

I asked ChatGPT to provide me a configuration for VRRP v6, and provided it the global standby address.  ChatGPT gave me the configuration without a primary address.  Then, when I showed ChatGPT the “show vrrp” output which explicitly says “No primary virtual IP address configured”, it responded by telling me to:

  1. Make sure IPv6 is enabled globally. (!)
  2. Make sure the interface is up (!!)
  3. Reapply exactly the same config [without an LLA] (!!!)

So apparently we built CLI so confusing that even genius-level AI cannot figure it out.  Or, we got a ways to go before we get replaced by ChatGPT.  Just sayin’, “analysts.”

1
by

My years in management: Looking forward

 

As of December, my role at Cisco has transitioned from a leadership role back to an individual contributor.  Gone are the constant approval emails;  gone is the stack ranking of employees;  gone are the performance reviews and the one-on-ones.  It’s both relieving and eerily quiet.  As I make this transition back, after nearly eight years, I thought it would be a good time to reflect on leadership and what it means to me.

I never wanted to be a “people manager”.  When I first started in networking, way back in the early 2000’s, I was explicitly clear about this to my boss.  I loved hands-on work.  I wanted to be in the trenches.  If I were a cop, I wouldn’t want to be a detective–I’d want to be in the patrol car.  I also lacked the self-confidence to take on a team.  Routers I could handle; people not so much.

I worked in Cisco TAC, then at a partner, and then at Juniper Networks.  In all those years, the idea of managing people never once came up.  I didn’t ask for it, and nobody asked me to do it.  I was happy being the hands-on guy.  When I got married in 2012, I told my wife to never expect me to be in a leadership role.

That all changed when I came to Cisco for the second time in 2015.  I had landed my dream job as a technical marketing engineer.  I loved having a lab, doing Cisco Live presentations, writing blogs and books, and working with customers.  I was quite fine with this when my boss, Carl Solder, one day stunned me in our 1:1 by asking me to lead a small team.  I objected lightly–I want to do hands-on work, not manage people.  Don’t worry, he said, you still can.  To my surprise, as well as my wife’s, I said yes.

My first team had 12 people on it, covering Software-Defined Access, Assurance, and Programmability.  A bit of a hodge-podge.  The day the team was announced I was pulled one-by-one by my new team members into a room, to listen to each of their demands.  What had I gotten myself into?  My boss later told me that two experienced managers who were sitting outside the small conference room rolled their eyes and simultaneously said:  “welcome to management!”

The management philosophy I brought to my team didn’t come from books or coursework.  It came from my own observations.  Simply put, there are two management styles:  negative and positive.  Negative leaders are the most common.  They lack empathy and are thus unable to work with people.  They manage by assigning tasks and tracking metrics.  They pile on their people.  They are hard on their teams, task masters, and are mainly interested in their own self-promotion.  They see their team as a tool to achieve their own personal goals.  I’d had many such leaders, and worked poorly under them.  I struggled to remain motivated, and would usually do just enough work to get by.

Positive leadership looks at employees as individuals.  Positive leaders try to understand their employees’ needs and help them grow in their careers.  They look for potential in employees and try to develop that potential.  They try to align assignments to employee’s skills rather than forcing work upon people.  They look for strengths and play to those strengths.  Positive leaders are “servant leaders”, as much as I hate the cliche.  They care more about their people than themselves.  They promote their people rather than themselves.  Under this style of leadership, employees work hard because they feel their leadership cares about them.  They usually want to make their boss look good, and feel personally disappointed when they let their boss down.

I learned a simple rule from my first boss, Henry Sandigo, who practiced this style of leadership.  When your team fails, you take the blame as the leader.  When your team succeeds, you give them the credit.  Negative leaders do the opposite.  When their team succeeds they take the credit, and when their team fails, they blame their team.

One time, my team held up a software release due to critical bugs.  This upset engineering, who pushed back.  One of the product management leaders was furious with me.   He came to me, stood an inch from my face, and with bloodshot eyes yelled at me:  “I want the name of everyone who was in that room making the decision.”  I said to him he could have one name, mine, because it was my team and I was responsible.  It turns out we were right, but I had to endure the fury of that leader for a long time.

If negative leadership is so ineffective, why is it so common?  The answer is simple.  Negative leaders tend to be ladder-climbers and self-promoters, whereas positive leaders are humble by nature.  Negative leaders are always out for themselves, and in the corporate world, that tends to advance you to higher positions.  Additionally, if negative leaders are in power, they have no respect for positive leaders.  They tend to promote people with their own leadership style, and view positivity as soft and weak.

As a leader, you become involved in people’s lives, often quite intimately.  I had two employees go through bitter divorces while on my team.  My philosophy was to give them the room they needed to recover and get back to work.  I had interpersonal conflicts that went to HR.  I had one employee drop from a cardiac arrest and who has been in a coma for two and a half years.  I’ve been in the room with him and his crying family, and dealt with his long-term leave of absence.  Configuring routers is easy in comparison to the harsh realities of life.

I’ve also had to lay people off more times than I can count.  One of the main reasons I didn’t become a manager for so long was that I never wanted to lay someone off.  It’s an unfortunate reality in the corporate world today.  When I’ve made that call, some have been angry, some have cried, most were just quiet.  I can only say I hated having to do it, and that I fought hard to not do it.  In fact, I’ve been criticized for fighting too hard to save jobs.  I cannot really complain as it’s much harder to receive the call than to make it.  But I tried to see my employees as humans and to help them as much as I could.  The unfortunate reality of the corporate world is that people are just seen as OpEx, as numbers on a spreadsheet, and not as human beings whose lives are horribly affected by losing their jobs.  I don’t know if I will ever return to leadership, but I’d be happy if I never had to make those calls again.  (For what it’s worth, I once was on the receiving end of the call.)

I also got to make several happy calls.  Promoting people is one of the great joys of management.  I helped several people get director and principal promotions, which are very hard to get at Cisco.  Although they did the work, I did the back-end negotiation, and I’m proud of each one of them. 

I tried to go the extra mile for my employees.  During the COVID lockdowns, I drove around to each of my direct’s houses and surprised them with a Christmas gift.  They were grateful to see a co-worker after so much time in lockdown.  When one employee, a gin lover, had a really bad day with a difficult VP, I sent him a nice bottle of gin, at my own expense.  I found little touches like this go a long way in building loyalty and positivity in a team.

We all learn from the great leaders we worked for.  I mentioned Carl and Henry.  Bask Iyer was another one. Bask came in as CIO of Juniper at a time when working in IT was like working in a morgue.  We were all depressed, beat up by the business, and unmotivated.  Bask would defend us in company meetings when we got attacked.  He went to bat for us.  He was a great technologist, but what really impressed me was his ability to stand up for us.  Gary Clark, who reported to Bask, exuded the same positivity.  When you met with Gary for the first time, he had a series of lego blocks with different personality traits.  He would arrange them in order while he was talking to you, building a model of your personality.  In other words, Gary wanted to know who you were, how you thought, and meet you where you were.  I always appreciated that.  

At my peak, I had 50 people reporting to me and multiple layers of management.  Then, through attrition, it dwindled to 30, 20, then 8, and now none.  A team of 50 seems like a distant memory to me now.  It’s hard to believe I did that.

Many technical people come to the same fork in the road that I did.  Do you stay technical, or do you take a management job to advance your career?  Notice I put these in opposition.  I can affirm that when you go into the management track, your technical skills atrophy.  As much as I tried to maintain and work in a lab, it became nearly impossible.

There was one day when I was invited, as a senior director, to a meeting on software-defined access architecture with a bunch of distinguished engineers.   They were discussing an idea around multicast.  As I listened, I decided to interject:  “If you do it that way, you’ll break PIM registration.”  One of the DEs rolled his eyes, but then another said “wait, Jeff’s right!”  It was nice to know I still had it.

Those moments, however, become rare.  I know that all of my employees respected that I had a technical background.  It’s important that leaders in technology companies know technology.  But if you go the management route, you will definitely find the technical side of things recedes as people become your main concern.

The hardest thing about being a team leader at a company like Cisco is pleasing all the factions that will ultimately provide feedback on you.  The second you step into leadership, there is a target on your back.  The corporate world is Machiavellian.  Nice guys finish last.  If you try to partner with and please one leader, another leader will get upset.  Pivot to him, and the first guy gets mad.  This was especially true for TME, which is seen as a service organization.

It’s important to remember that the corporate world is vicissitudinous.  Over the course of the years, you will see roles come and go.   I’ve seen executives who were flying high one day shown the door the next, and a whole new regime comes in.

As I said at the beginning, in some ways it’s a relief.  On the other hand, one of our product management VPs saw me with my team and said I was like a “proud papa.”  While it’s nice to do things myself again, I can say I was proud of the teams I lead, and I miss taking pride in my team instead of myself.

Will I ever lead a team again?  Who knows.  If I’m asked I will gladly do it.  If not, I’ll do my job as an individual contributor.  I don’t think there’s much room in the corporate world for leaders with my style, anyways.

The upside is, I can now spend time in the lab.  My routers won’t ask for raises.

22
0
by

Are network engineers obsolete?

Continuing on the theme of AI:

I can tell you what the MBAs are saying.  Remember, the MBAs know more about network engineering than you, despite your training and experience, because, well, they’re MBAs!  The went to Stanford!  Or Kellogg!  Or San Jose State!

The MBAs are sure you’re going to be replaced by AI.  I’ve personally seen comments from “analysts” saying that’s the case.  We’re not going to need network engineers anymore!  So all that stuff you’re learning about BGP or OSPF or whatever.  Don’t learn it!  AI will do it for you.  Poof!  Away with network engineers!  After all, they speak in a weird language we didn’t learn in MBA school!  (But it’s ok to speak in our own weird language.)

I happen to live in a world called “reality”, a mythical fairy-tale land to B-school professors.  In “reality”, life is a bit more complicated than B-school types believe it to be.  And those of us who actually have a bit of experience building networks and making them work see AI for what it is:  a tool.  Could it replace some network engineers?  Yes.  All of them?  Count me a skeptic.  But then again, I don’t have an MBA.

I use a note-taking app called Obsidian.  This is becoming more important to me the older I get, as my memory seems to be functioning less optimally.  I was thinking I needed to see a doctor until I talked to other folks my age who have the same problem.  Despite billionaires’ attempts to live forever, the human body has a shelf life and the clock starts ticking the moment you’re born.

Obsidian is great because it stores notes in text files, you write your notes in markdown, and you can generate tags.  I’m terrible at filing things, so I hate programs like OneNote which place the burden on the user.  You have to create notebooks and tabs, and so forth.  With Obsidian, I just add tags where I need them and I can find anything later on.

Anyways, I had taken extensive notes on Hypershield after talking for quite a while with a TME who is working on it.  In Obsidian, I work off of a “daily note” which is like a scratch pad for the day, and if something is important enough, I can select it and extract it to a new note.  In this case, I already had a note on Hypershield and I wanted to extract the text to this exiting note.  I couldn’t find a way to do it.

Enter ChatGPT.  Obsidian is highly extensible, and ChatGPT wrote me a Javascript to extract and append to an existing note.  Fantastic!  I put it into a plug-in, selected the text, gave it the name of the note, and bam!  My text vanished, nowhere to be found.  Not on the daily note, not on the scratchpad, not anywhere in the directory with the text files.  Since the deletion happened from a script, and not a keyboard/menu command, I couldn’t undo.  The text was lost.

ChatGPT was quite apologetic about the mixup and offered several ways to recover the text, none of which worked.

Hallucinations and errors from GenAI are nothing new.  We’re all aware of the problem, and I pointed it out in another context early on in the GenAI days.  But this is a huge problem for the predicted future of networks being totally automated by AI.  Despite the name, AI is not intelligent.  It is a system which generates language, human or machine, by ingesting a lot of content and trying to predict what the correct output should be.  And it can be wildly wrong.

Sure, we can implement checks and balances.  It would have been wise to copy my text to the clipboard before running the script.  Still, whenever we automate, we risk runway automation, and in environments where the network is absolutely critical, trusting AI is going to be difficult.

I’ve heard “analysts” say that their customers are complaining they cannot find qualified network engineers.  In their incredible logic, then they reason, let’s replace them with AI!  Brilliant.  How about asking why it’s so hard to find network engineers?  Is it a great career choice when you are young and reading that network engineers will be replaced by AI?

I’ve written about the “war on expertise” which has been going on in society in general, and in our field in particular.  I got into networking (a) because it fascinated me and (b) because it was a very promising career field.  When you have an interest and a passion for something, acquiring knowledge in that area becomes an end in and of itself.  I remember reading an article about NBA basketball referees, and how, when they travel, they love to challenge each other on obscure rules.  It was like this with network engineers.  We were always trying to one-up each other, learn a new protocol or knob, figure out the mysteries of multicast, or new ways to design networks.  When I go to Cisco Live (and for the second year in a row I will not be going to CL Europe), these are the sort of people who show up.  They are hungry to learn, expand their skills, and up their game.

Now you go to a trade show and all you hear about is how you will be replaced by AI.  Why the hell am I going to devote time to mastering a field if I’ll be obsolete in a couple years?

I’m worried for the future because we’re headed down a concerning path.  Nobody will be entering network engineering anymore, and AI won’t be able to replace the humans who operate networks.  Then what?

It would be nice to see networking vendors (and I mean all of them) encouraging people to learn networking, showing people this is a viable and lucrative career path, and that AI is a tool that they might use to learn networking and augment their capabilities.  And it would be nice to see MBAs stick to finance.  Or can we at least outsource the job of the MBAs to AI?  Yeah, that’d be nice.

8
by

The Next Big Thing, TLDR version

At the last Cisco Live in June, I was asked by marketing to do a “center stage” presentation.  My days of getting normal sessions at Cisco Live seem to be over.  Perhaps I’m too far into the management track (although that’s changing) to impress the Cisco Live Session Group Managers.  Eager to speak again, I accepted the proposal.

The abstract was provided for me.  I don’t remember the title, but it was something about AI and the campus.  So, I did my best to craft a set of slides that would be interesting.  When I ran them by marketing, I was told I couldn’t use my own slides.  I had to use theirs.  One of my secrets to success at Cisco Live is that I always build my own slides.  Rarely do I use a single slide from someone else.

Still, I did my best to build a story that would work.  Then I was told I’d be co-presenting with another PM, and we’d also have a customer on stage with us for an Oprah-style panel interview.  Even with these constraints, I spent a lot of time in my hotel room in Vegas practicing to be sure I nailed it.

The center stage is on the show floor (World of Solutions), and presenters there are broadcast onto a series of TVs scattered around the Mandalay Bay convention center.  They walk around the stage like they’re performing King Lear, but nobody watches the TVs or can even hear them.  It’s very performative, but a part of trade shows.

We had a rehearsal with marketing people, stage managers, cameramen, audio technicians, and and army of other people.  On the day of, there were marketing people, stage managers, cameramen, audio technicians, and and army of other people.  There was also a lady there who did intros for all the speakers, to get the audience pumped up.  I’m sure she showed up in Las Vegas decades ago to be a showgirl or something, but now in her 40’s she was doing corporate gigs at Mandalay.  As I got mic’d up and ready to go, I looked out at my audience.  Of the 50 or so chairs, 5 were occupied.  Four of them were friends of the customer presenting.  I looked at the intro lady and said: “I hope you can handle the stage fright.”  She laughed.

I did my shtick, and it all went well enough.  At the very end, the one attendee who was not with the customer, who seemed to have shown up because it was a good spot for a nap, arose like Lazarus, raised his hand and asked:  “Could you guys please stop talking about AI at Cisco Live?”

If you’ve watched the Art of Network Engineering podcast, you probably are familiar with Lexie Cooper, one of the hosts.  I was on the podcast a while back and had a nice talk with her and Andy Lepteff.  The other day, Lexie showed up in my LinkedIn feed in clownish makeup and a bodysuit.  With the audio off, I looked at it and thought, “wow she’s really desperate for attention.”  Then I unmuted it.  I nearly died.

“Have you ever considered…using AI?”  she begins.

“Manage your network devices…with AI!”

“Manage your IOT stuff…with AI!”

“Design a PCB…with AI!”

“Automate your vegetable garden…with AI!”

“Ethernet cables?  Nope…AI!”

“Every vendor in the World of Solutions…with AI!”

…and so forth.

In a minute and thirteen seconds, Lexie captured the Zeitgeist of the current networking world perfectly and hilariously.  It seems that all of the protocols and technologies that make up the “Art of Network Engineering” have been single-handedly wiped away by AI.  Nobody talks about networking anymore, it’s all just AI.

Of course, those protocols and technologies are necessary for AI, for the Internet, and for the modern world to function.  Why do all vendors suddenly have a single-minded focus on AI, and seem to have stopped investing in actual networking technology?

It comes down to the culture of Silicon Valley, the corporate world dominated by Wall Street, and the quest for the “Next Big Thing”.  As network engineers we love acronyms, so I’ll coin a new one:  the NBT.  (With all due respect to NetBIOS over TCP.)

Technology executives are terrified of missing the NBT, and they spend their careers chasing the NBT.  It’s not entirely their fault.  If a technology company is not investing in the NBT, then the industry “analysts” will write somber reports criticizing the company and hurting the stock value.  Because the industry “analysts” have MBAs in topics like marketing and finance, they are experts at technology, and “analyzing” what networking companies should sell to network engineers.  In fact, because they are MBAs, they are experts in anything, really, and far more so than people who actually study and learn their specific fields.

There have indeed been some real NBTs.  Wireless is a good example.  When I started in networking, pretty much everything was hard wired.  Wireless was a major transformation in networking, and a new and different technology domain.  (I’m still not great at understanding it, admittedly.)  Mobile devices and smartphones radically changed the world, and nobody can argue that.

Cloud computing is an interesting one.  First of all, it was (and is) a marketing term.  It refers to several things, but in a broad definition we could say it refers to using someone else’s computing resources instead of your own.  In the case of SaaS, someone else is hosting the application and giving you access to it, whereas in the case of IaaS, they merely host the computing power and you manage the app.  Either way, it was not a new idea.  The idea of shared computing resources has been around since the advent of computing.  In the early days, all computing was done on shared systems.  At the dawn of the Internet, I got my email and other services through an ISP.  I telnetted into their system to check my email.  And in the mid-90’s, I worked at a company that offered a SaaS-based timecard service, before anyone even used the term “SaaS”.

Cloud computing in 1999

Still, we could say Cloud was an NBT.  I used to go to auctions during the dot-bomb of the early 2000’s, and even a small dotcom company had to purchase servers and network gear and host them in rented rack space in a colo.  AWS drastically changed that.

Of course, there have been many potential NBTs that turned out not to be.  The “Metaverse” was one of these.  After 2 years in COVID lockdown, nobody was interested in slapping on a VR headset and meeting their friends using a unicorn avatar floating around a fake version of Mars.

Watch out when an exec begins a presentation with this apocryphal Henry Ford quote:  “If I had asked people what they wanted, they’d have said faster horses.”

Aside from the fact Ford never said it, this quote is recited ad nauseam to inspire people to disruptive innovation.  Nobody ever seems to notice the obvious, however.  The automobile was popularized by Henry Ford over 110 years ago.  It hasn’t changed much since.  Sure, your Subaru is a lot different from a Model T, but the basic idea and design are the same.  The changes to automobiles–fuel injection systems, automatic transmissions–have been major, but nonetheless incremental improvements on the base design.  Once the NBT happened and spawned an industry, things reached a steady state.

From a corporate/investor perspective, this is problematic.  Stock prices are an indicator of future value, and investors demand “growth”.  (Hypothetical question:  is there an end-state to “growth?”  I.e., is a company ever done growing, and if so, when?  Related:  is there anything in nature which can grow indefinitely?)  Steady-state is not good for Wall Street.  So, execs need to go hunting for the NBT.

“Now wait,” many MBAs will correct me.  “The EV is a major disruptor in the automotive industry.”

Leaving aside the fact that EVs have existed in the past, and their questionable future, it just proves my point.  It took 100 years for the Tesla to exist.  But let’s circle back to that in a minute.

Recently I saw a LinkedIn post from a woman, Debbie Gomez, who is making a career change to become a network engineer.  She was joking about the contents of a woman’s purse, comparing it to the books she has in her car.  One of those books was Internet Routing Architectures by Sam Halabi.

When I was studying for my CCIE R/S in 2004, I used Halabi’s book.  It’s clearly visible in a picture of the stack of books I used to study for the infamous exam.  Debbie is studying the same content I was 20 years ago.

This is because, like the automobile, once networking was invented, change became incremental.  BGP hasn’t changed much because it can’t change much.  It’s run across multiple providers and multiple vendors, and it’s not easy to make changes.  Sure, it’s been extended since Halabi’s day, but it’s close enough to the original that his book is still totally relevant.

I’ve written in the past about how non-technical executives view the complexity of networking as a creation of engineers who “revel in complexity”.  In their view, the NBT in networking is to just have “simplicity”, where you don’t need all the fancy BGP, OSPF, EIGRP, ISIS, EVPN, VXLAN, STP stuff.  Just like the Tesla is so much simpler than a traditional car.

I recently started working on cars, because I always like to do things with my hands.  My 2011 BMW 328i is probably the wrong car to start working on.  It’s complex, and designed so that simple tasks require disassembling large parts of the engine.  I recently replaced the valve cover, successfully, but man was it a nightmare of carefully removing various parts.  To even get the thing out took about 30 minutes of me standing on the engine and my brother-in-law working it from the side.  If I learned one thing, it’s how complex a modern car is.

I have a Tesla as well.  There’s no question it’s simple.  There’s hardly an engine to speak of.  There is no gear shifting when you drive it.  You don’t even turn it on.  There is no maintenance required except for tires and brakes. The only fluid required is for the windshield washer.

Many technology executives feel this transformation needs to happen for networking as well.  The problem–they don’t seem to realize–is that the underlying complexity of networking, the protocols, cannot go away.  They exist for a reason.  Can they be improved?  Sure.  Can they be eliminated?  No.

That’s not to say much of the mess of networking cannot be improved.  Vendors have created a lot of that mess, and all are guilty to some degree.  We can distinguish unnecessary complexity from necessary complexity.  A lot of it is unnecessary, but even if you remove that, you’re left with the necessary complexity.

The only option for simplicity when you cannot really simplify, is to abstract.  That is, you hide the complexity.  It’s still there, but it’s easier to deal with.  Take a modern airplane.  It’s just as complex a machine, perhaps more so, than a plane built in the 1970s.  But the cockpit is throughly automated, and the systems throughly instrumented.  It’s much easier to manage than a 1970’s plane.  And yet, someone still needs to know how it all works.

This brings us back to our starting point, AI.

Why is AI driving Lexie to the point of putting own garish makeup and screaming into the camera?  Of course, everyone thinks it’s the NBT.  But is it?

We can easily understate the importance of GenAI and the significance of the technological advancement.  It’s nothing short of astounding.  ChatGPT makes a great search engine, but apart from that, it’s ability to interpret and generate language and code in creative ways is incredible.

Even though I worked on programmability, my knowledge of Python is pretty poor.  If there’s one programming language I feel absolutely comfortable in, it’s Applesoft BASIC from the 1980s.  I’ve found I can have ChatGPT explain some of the more challenging Python concepts by translating them to BASIC.  It’s crazy.  Computers haven’t been able to do anything like that before.

I’ve asked it to generate NETCONF code blocks for configuring IOS XE, with less success.  It gave me an operational data model to configure an IP address on an interface.  These errors can and will be corrected, however.

And yet, even if AI reaches the point of being able to configure and operate network devices, it will still be an abstraction layer.  I cannot fathom AI somehow doing away with networking.  At most, it would be like the automation systems on the plane, not like a Tesla.

I asked ChatGPT to design a networking system that does not use protocols.  It responded:  “Designing a data networking system that does not use protocols is a challenging idea because protocols are fundamental to networking—they define the rules for data exchange.”  It then dutifully attempted to frame out a protocol-free system, but the result was unimpressive, and the AI admitted that it would have a lot of problems.

I am among those working on AI projects at Cisco, both out of interest and out of necessity.  Working at a vendor, I’m caught up in the NBT just like we all are.  While I cannot talk about the specifics of any of the projects, I do see potential for its use beyond the current applications of AI.  (Mainly analyzing operational data.)

Is it really the NBT?  Is it really a “disruptor” on the level of wireless or smartphones?  Or are we tilting at windmills as with the Metaverse?

Time will tell.  But I’m sure Lexie will have plenty of content for more videos.

Meanwhile, keep reading Halabi.  We still need him.

4
by

Blog Updates

Updates for my regular readership of two people plus 5000 spambots:

  • I stayed away from the blog for a long time because I made the mistake of sharing my last post, on HPE/Juniper, on LinkedIn.  Imagine the panic when people actually read it, including SVPs at Cisco.  I’m fairly open with my thoughts on this blog, and I don’t want to limit my career prospects.  In retrospect, I think I should embrace frankness and keep sharing blogs on LinkedIn.
  • I changed the WordPress theme for this blog.  I think this new theme is a bit more readable.  Hopefully you all feel the same.  The previous theme had a weird issue.  When I shared the post on LinkedIn, instead of the title in the auto-generated preview, it said “posts navigation”.  That looks cheesy.  Rather than try to hack the HTML and figure out why, I switched themes.  The new one doesn’t have that problem.
  • However, before I did this I attempted to share the latest blog on tech field day.  LinkedIn seems to have cached it with “posts navigation” as the title, so I’ll probably republish it with a different permalink, leaving the old one in place for anyone who might have been directed to it.  So if you see the article again, I’m not going crazy.
  • I hope to get back to doing some technical blogging.  I love the perspectives and reflections, but something can’t keep me out of the lab.  Look for a few blogs soon.  (And I have a great history of promising to do something for this blog and not delivering on it, hope that doesn’t happen.)
5
by

Feeling like a Puppet

Starting a new job is always a challenge.  It’s one thing to do an internal transfer within a company, like I did when moving from Technical Marketing Engineer to Product Management.  I even stayed in the same team.  But moving to a new company and new role is overwhelming and risky.

I experienced this when I went to Juniper.  I’d defined my entire existence in terms of Cisco.  When I worked at a Gold partner, I refused to touch anything–servers, desktops, etc.–that was not Cisco-branded.  I’d barely even touched a Juniper device.  Now I was expected to coherently articulate a network architecture when I didn’t even understand the products that were involved.  (One could argue network architecture should not be product-specific, but we all know better.)

Ironically enough, after six years at Juniper, going back to Cisco proved challenging.  I didn’t touch a single Cisco device in six years.  At the time I went to Juniper, Nexus products didn’t even exist.  Now I was expected to be doing technical marketing–at the principal level–for products I hadn’t even heard of.

My boss, the legend Carl Solder, assigned me to programmability.  I knew nothing about it.  During my interviews with Carl, I had mostly talked about controller-based architectures.  While I was at Juniper, Jeremy Pruitt, an automation expert, had managed to get Puppet working for managing Juniper devices.  He pitched it to me and I had no interest at all.  This was a server technology, not a networking technology.  I was a protocols guy.

Now I was assigned to YANG, NETCONF, Python scripting, Ansible, and (ha, ha) Puppet.  I was fortunate to end up on a team of low-ego engineers who helped me to learn this stuff and who were willing to share opportunities with me.  They are still friends to this day.

One of the opportunities they shared was a chance to present at Tech Field Day/Networking Field Day.  In fact, TFD is a high-stress presentation, and nobody really wanted to do it.  Thus, three months into my new job, knowing nothing about Puppet or Nexus, I was called upon to present Puppet management of Nexus to one of the most challenging audiences we have.  I think TFD delegates can be a bit nicer these days, but back then a few of them loved to eviscerate vendors, especially Cisco.  Oh, and Jason Edelman and Matt Oswalt, two automation experts, would be in the audience.  Also Terry Slattery, who is the first person ever to pass the CCIE lab.  And my boss Carl, one of the best public speakers at Cisco.  And it would be livestreamed and everyone (it seemed) in Cisco would be watching it.  Great.

A tough room to stand in front of

The only way out was through.  My team was very helpful in preparing me, and I was able to spend a lot of time with engineering.  Truth be told, it was just technology, and I’m a technology guy.  It was learnable.  Cisco’s marketing team was also very helpful, explaining possible pitfalls and traps in presenting to the TFD audience.  For example, if you put “Cisco Confidential” on your slides, they’ll make fun of you.  (It’s a default on our PowerPoint templates.)  They told us not to cite Gartner.  I made a fake slide with ridiculously large “Cisco Confidential” and “DO NOT SHARE”  and a magic quadrant and presented it at rehearsal.  The look of horror from the marketing team told me they didn’t get the obvious joke.

It’s a joke, really!

Puppet was particularly challenging because, unlike Ansible, it was agent-based.  (I’m not sure if this is the case anymore, I rarely hear about Puppet in networking contexts.)  This meant you had to bring up a guestshell and install the agent on any device that it managed.  To be honest, this is less than ideal.  It means that before you could use Puppet to manage the device, there was a fair amount of setup required.  This could be done through PoAP (Power-on Auto-Provisioning, Cisco’s version of ZTP for Nexus), but it required a lot more work than simply enabling a few CLIs, all that was needed for Ansible.

There was a non-technical challenge that faced me as well:  I had been working on overcoming a terrible fear of public speaking.  I had melted down in one presentation in my early years at Juniper, and had spent the last several years doing training, Toastmasters, and anything I could to get over this problem.  I had successfully delivered some major presentations at Juniper before I left, but this was the highest pressure I had ever been under.  Would I panic?  Would I crack?  Would I be shown the door only a few months into the new job?  Public speaking is risky, because when you fail, you fail in front of a lot of people.

I’m still here, of course, and aside from a couple minor stumbles, it went off quite well.  Watching the video eight years later, I do cringe a bit at some of my slides.  I’m not a genius when it comes to PowerPoint, but I’ve done a lot of work to improve the quality of my decks.  Given the time constraints, I had to borrow some slides and hack together others.  I do hear some of my “signature” lines taking shape.  In nearly all my presentations on automation, I joke about Notepad being the most common automation tool used by network engineers, and this must be the first place I used that line.  And while Jason and Terry did ask questions, they didn’t break me and I was able to answer them quite assuredly.

My demo was a bit simplistic.  I provisioned a few VLANs and interfaces, and pushed a patch to a Nexus 9k.  As I started to take over lead on programmability, I changed my approach to it.  For example, when I showed network engineers how to provision a VLAN with NETCONF, their eyes would glaze over upon seeing the massive block of Python and XML needed to make it work.  Why not just type one line of CLI?  I became convinced we needed to show the value of programmability by showing how we can use it beyond just simple tasks.  Configure a VLAN?  Meh.  Use Webex Teams (or Slack) to interact with a router, better.  We did some silly demos like using Alexa to configure switches, but the point was actually to show that programmability opens up possibilities that were not there before.  Nonetheless, when I did this TFD, it was still early days.

My TFD session also ended up generating a popular meme, although it wasn’t on my account.  Jason Edelman and Matt Oswalt were sitting next to each other.  Jason was dressed in a sportcoat, clean cut, with Windows PC, and no stickers on it.  Matt was sitting next to him with unkempt hair, using a Mac covered with stickers.  Someone screenshotted it and posted it to Reddit with the caption, “the two types of network engineers”.  It’s funny because Matt and Jason wrote a book on network automation together.  (In the photo, my boss Carl looks on in the background on the right.  Dead center in red is Lauren Friedman, with whom I worked many times as our TFD coordinator in marketing.  Stephen Foskett, one of the TFD organizers, is between Matt and Jason.)

The two types of network engineers

 

In our careers as network engineers, we’re often thrown into things we know nothing about and are expected to quickly turn around and become experts. It happened every week in TAC. Working in product marketing, we’re often on the cutting edge and constantly fighting to stay above water. I had only a few weeks to learn Puppet, get a demo up and running, and present it to a challenging audience. The most important thing is to not get cocky, to understand what you don’t know, and to spend the hands-on time to plug those gaps in your knowledge.

Every public speaker knows the feeling of relief when you finally finish and the stress unloads. As I closed my talk and walked to the back of the room, Carl, my new boss, looked at me and gave me a thumbs-up. At that point if you told me I’d win Hall of Fame at Cisco Live for talking about programmability, I’d have thought you were crazy.

As for Puppet, I never touched it again.

4