Paul Arends
Hallo allemaal, ik ben terug om te verkennen hoe agentic AI zou kunnen passen in de workflow van een netwerkingenieur en een waardevol gereedschap zou kunnen worden in onze gereedschapskist.
In mijn blogpost, Het creëren van een NetAI-speeltuin voor Agentic AI-experimenten, begon ik deze reis door te verkennen hoe we Model Context Protocol (MCP) servers en het concept van “tools” kunnen gebruiken om onze AI-agenten in staat te stellen te communiceren met netwerkapparaten door show-opdrachten te sturen. Als je die post nog niet hebt gelezen, moet je dat zeker doen, want het is echt fantastische proza. Oh, en er zit ook wat coole NetAI-spul in. 😉
Hoewel het fascinerend was om te zien hoe goed AI een netwerkengineeringtaak kon begrijpen die in natuurlijke taal werd gepresenteerd, een plan kon maken en dat plan kon uitvoeren op dezelfde manier als ik zou doen, was er een beperking in dat eerste voorbeeld. Het enige “gereedschap” dat de agent had, was het vermogen om show-opdrachten naar het netwerkapparaat te sturen. Ik moest expliciet de details verstrekken over het netwerkapparaat – details die direct beschikbaar zijn in mijn “bron van waarheid”.
Om de kracht van agentic AI te realiseren, moet NetAI toegang hebben tot dezelfde informatie als menselijke netwerkingenieurs. Voor de post van vandaag wilde ik verkennen hoe ik source-of-truth-gegevens aan mijn NetAI-agent kon verstrekken. Dus laten we aan de slag gaan!
NetBox biedt een MCP-server
NetBox is al lange tijd een favoriet gereedschap van mij. Het is een open-source netwerkbron van waarheid, geschreven in Python, en beschikbaar in verschillende implementatieopties. NetBox heeft me door veel van mijn netwerkautomatiseringsverkenningen begeleid; het leek passend om te zien hoe het zou passen in deze nieuwe wereld van AI.
In eerste instantie verwachtte ik een eenvoudige MCP-server in elkaar te zetten om toegang te krijgen tot NetBox-gegevens. Ik leerde al snel dat het team van NetBox Labs al een open-source basis-MCP-server op GitHub had uitgebracht. Het biedt alleen “leestoegang” tot gegevens, maar zoals we zagen in mijn eerste NetAI-post, begin ik toch langzaam met alleen-lezen werk. Het hebben van een startpunt om wat bron van waarheid in mijn speeltuin te introduceren, zou mijn verkenning aanzienlijk versnellen. Helemaal geweldig.
Het toevoegen van NetBox aan de NetAI-speeltuin
Ben je ooit aan het werk geweest aan een project en afgeleid geraakt door een ander “cool idee”? Nee? Ik denk dat het gewoon aan mij ligt… 🙂
Net zoals bij de meeste van mijn netwerklabs en verkenningen, gebruik ik Cisco Modeling Labs (CML) om de netwerkspeeltuin voor AI uit te voeren. Dit was niet de eerste keer dat ik NetBox als onderdeel van een CML-topologie wilde hebben. En terwijl ik me voorbereidde om te spelen met de NetBox MCP-server, had ik de gedachte…
Hank, zou het niet geweldig zijn als er een CML NetBox-node was die gemakkelijk aan een topologie kon worden toegevoegd, en die automatisch NetBox zou vullen met de topologie-informatie van CML?
Natuurlijk heb ik mezelf geantwoord…
Natuurlijk wel, Hank, dat is een geweldig idee!
Mijn gedachten begonnen meteen de details uit te werken van hoe ik het in elkaar kon zetten. Ik wist dat het super makkelijk en snel zou zijn om het af te maken. En ik dacht dat andere mensen het ook handig zouden vinden. Dus nam ik een “korte omweg”.
Ik weet zeker dat velen van jullie hun wenkbrauwen fronsten toen ik zei “super makkelijk” en “snel”. Jullie hadden gelijk om sceptisch te zijn, natuurlijk. Het was niet helemaal zo makkelijk of eenvoudig als ik had verwacht. Desalniettemin lukte het me om het werkend te krijgen, en het is echt gaaf en handig voor iedereen die niet alleen een NetBox-server aan een CML-netwerk wil toevoegen, maar ook wil dat het vooraf wordt gevuld met de apparaten, verbindingen en IP-details van de CML-topologie.
Ik moet nog de documentatie compileren voor de nieuwe knoopdefinitie voordat ik het naar de CML-Community op GitHub kan posten voor anderen om te gebruiken. Beschouw deze blogpost echter als mijn openbare verantwoordelijkheidspost, die aangeeft dat deze binnenkort zal verschijnen. Je kunt me eraan houden.
Maar genoeg van de zijweg in deze blogpost, laten we terugkeren naar de AI-zaken!
Het toevoegen van de NetBox MCP-server aan LM Studio
Zoals ik al zei in de laatste blogpost, gebruik ik LM Studio om het Large Language Model (LLM) voor mijn AI-agent lokaal op mijn laptop te draaien. De belangrijkste reden is om te voorkomen dat ik enige netwerkinformatie naar een cloud AI-service stuur. Hoewel ik een “lab-netwerk” gebruik voor mijn verkenning, zijn er details in de labopstelling die ik NIET openbaar wil hebben of die ik riskeer in toekomstige trainingsgegevens voor een LLM te belanden.
Als deze verkenning succesvol is, zou het volgende stap zijn om de aanpak met productiedata te gebruiken; echter, dat is zeker niet iets dat overeenkomt met een verantwoorde AI-benadering.
Het clonen van de netbox-mcp-server code van GitHub was gemakkelijk genoeg.
De README bevatte een voorbeeldconfiguratie van een MCP-server die alles bood wat ik nodig had om mijn mcp.json-bestand in LM Studio bij te werken en deze toe te voegen aan mijn reeds geconfigureerde pyATS MCP-server.
Zodra ik het bestand had opgeslagen, ontdekte LM Studio de beschikbare tools.
Er worden drie tools aangeboden door de NetBox MCP-server:
– netbox_get_objects: Generieke tool die objecten in bulk ophaalt uit NetBox. Het ondersteunt “filters” om de teruggegeven objecten te beperken.
– netbox_get_object_by_id: Tool om een enkel object van elk type uit NetBox op te halen op basis van een ID.
– netbox_get_changelogs: Tool om audit- en wijzigingsevenementen op te zoeken.
Ik laadde vervolgens het nieuw uitgebrachte open model van OpenAI, gpt-oss, en stuurde de eerste query.
Mijn eerste gedachte… Succes. En toen krabbelde ik even op mijn hoofd. 10 apparaten? Scroll terug naar de CML-topologieafbeelding en tel hoeveel apparaten er in de topologie zijn. Ga gerust je gang, ik wacht wel…
Ja. Ik telde ook zeven apparaten. En als ik NetBox zelf controleer, toont het ook zeven apparaten.
Dus wat gebeurde er? LM Studio toont het exacte antwoord van de tooloproep, dus ik ging controleren. Inderdaad, er werd slechts informatie van zeven apparaten teruggegeven. Toen herinnerde ik me dat een van de beruchte meme-waardige tekortkomingen van veel AI-tools het vermogen is om te tellen. Blauwe bessen iemand?
Dus dit werd een mooi leermoment over AI… AI is fantastisch, maar het kan fout zijn. En het zal slecht zijn met sommige van de vreemdste dingen. Blijf waakzaam, vrienden. 😉
Na het oplossen van het probleem met de 10 apparaten, besteedde ik een aanzienlijke hoeveelheid tijd aan het stellen van meer vragen en het observeren van de AI die de tools gebruikte om gegevens uit NetBox op te halen. Over het algemeen was ik behoorlijk onder de indruk, en toegang hebben tot gegevens van de bron van de waarheid zal essentieel zijn voor elk Agentic NetAI-werk dat we ondernemen. Wanneer je dit zelf probeert, speel dan zeker rond en zie wat je kunt doen met de LLM en je NetBox-gegevens. Ik wilde echter verkennen wat mogelijk was in het samenbrengen van tools.
Ik wilde beginnen met iets dat zowel nuttig als vrij eenvoudig aanvoelde. Dus stuurde ik deze prompt.
Ik moest de LLM nog steeds vertellen wat de referenties zijn voor de apparaten. Dat komt omdat hoewel NetBox een fantastische bron van waarheid is, het GEEN geheimen/wachtwoorden opslaat. Ik ben van plan te onderzoeken welke toolopties er zijn voor het ophalen van gegevens uit geheime opslag later.
Als je je afvraagt waarom ik een lijst met stappen heb gegeven om dit probleem aan te pakken in plaats van de LLM het “zelf te laten uitzoeken”, is het antwoord dat hoewel GenAI LLMs “briljant” kunnen lijken, ze GEEN netwerktechnici zijn. Of, meer specifiek, ze zijn niet getraind en afgestemd om netwerktechnici TE ZIJN. Waarschijnlijk zal de toekomst afgestemde LLMs bieden voor specifieke functierollen in plaats van de algemene LLMs van vandaag. Tot die tijd is de beste praktijk voor “prompt engineering” om de LLM gedetailleerde instructies te geven over wat je wilt dat het doet. Dat verhoogt dramatisch de kans op succes en de snelheid waarmee de LLM het probleem kan aanpakken.
Laten we eens kijken hoe de LLM de eerste stap in het verzoek heeft afgehandeld, namelijk het controleren van de apparaatverbindingen.
Op het eerste gezicht ziet dit er redelijk goed uit. Het “wist” dat het de kabels van NetBox moest controleren. Er zijn echter wat problemen hier. De LLM heeft wat lijkt op een geldig filter gemaakt voor de zoekopdracht: “device_a_name”: “router01.” Echter, dat is eigenlijk GEEN geldig filter. Het is een
Een volledige blogpost zou kunnen worden geschreven over de reden waarom deze hallucinatie plaatsvond, maar de TL;DR is dat de NetBox MCP-server GEEN expliciete details verstrekt over hoe filters moeten worden gemaakt. Het vertrouwt erop dat de LLM in staat is om een filter te bouwen op basis van de trainingsgegevens. En hoewel elke LLM heeft geprofiteerd van de overvloedige hoeveelheid NetBox-documentatie die beschikbaar is op internet, heb ik in al mijn tests nog geen enkele LLM succesvol het juiste filter zien maken voor iets anders dan de meest basische zoekopdrachten voor NetBox.
Dit heeft mij ertoe gebracht om mijn eigen “mening” te beginnen vormen over hoe MCP-servers zouden moeten worden gebouwd, en het houdt in dat er minder “gegok” nodig is van de LLM’s om ze te gebruiken. Ik zal zeker meer terugkomen op dit onderwerp in latere berichten en presentaties. Maar genoeg daarover voor nu.
De LLM weet niet dat het filter fout was; het neemt aan dat de teruggegeven kabels allemaal verbonden zijn met router01. Dit leidt tot andere fouten in de rapportage, zoals het “Gedachte” proces onthult. Het ziet zowel Kabel 1 als Kabel 4 als verbonden met Ethernet 0/0. De waarheid is dat Kabel 4 verbonden is met switch01 Ethernet0/0. We zullen zien hoe dit later een rol speelt in de samenvatting van de gegevens.
Zodra het de kabelinformatie heeft, gaat de LLM verder en voltooit de rest van het gebruik van de tool om gegevens te verzamelen.
Het vinden van het Out of Band IP en SSH-poort was eenvoudig. Maar de eerste poging om “show cdp neighbors” uit te voeren mislukte omdat de LLM in eerste instantie de SSH-poort niet gebruikte als onderdeel van de tool-oproep. Maar dit is een uitstekend voorbeeld van hoe Agentic AI fouten van MCP-servers kan begrijpen en “oplossen”. Het realiseerde zich de behoefte aan SSH en probeerde het opnieuw.
Ik heb verschillende gevallen gezien waarin AI-agenten fouten met tool-oproepen oplossen door middel van trial-and-error en iteratie. Sterker nog, sommige MCP-servers lijken specifiek te zijn ontworpen met dit als verwacht gedrag. Goede foutmeldingen kunnen de LLM de context geven die nodig is om het probleem op te lossen. Net zoals wij als mensen zouden reageren en aanpassen wanneer we een foutmelding krijgen van een opdracht of API-oproep die we verzenden. Dit is een uitstekende kracht van LLM’s; echter, ik denk dat MCP-servers kunnen en moeten worden ontworpen om de hoeveelheid trial-and-error die nodig is te beperken. Ik heb ook LLM’s “opgegeven” zien na te veel fouten.
Laten we eens kijken naar de uiteindelijke reactie van de AI-agent nadat het het verzamelen en verwerken van de resultaten heeft voltooid.
Dus hoe heeft het gepresteerd?
Eerst de goede dingen. Het heeft correct herkend dat de link naar switch01 vanuit NetBox overeenkwam met een CDP-vermelding. Uitstekend. Het heeft ook de ontbrekende CDP-buur voor de “mgmt”-switch aangegeven. Deze ontbreekt omdat “mgmt” een onbeheerde switch is en geen CDP draait.
Het zou echt “cool” zijn geweest als de LLM had opgemerkt dat het apparaattype van “mgmt” “Onbeheerde Switch” was en had opgemerkt dat dit de reden was dat CDP-informatie ontbrak. Zoals eerder vermeld, is de LLM NIET afgestemd op netwerkingenieursgevallen, dus ik geef het daarvoor een vrijstelling.
En nu de fouten… Het probleem met het filter voor de kabel resulteerde in twee fouten in de bevindingen. Er zijn niet twee kabels op Ethernet0/0, en de “Andere ongebruikte kabels” zijn niet verbonden met router01.
Hank’s leerpunten uit de test
Ik was zeker een beetje teleurgesteld dat mijn initiële tests niet 100% succesvol waren; dat zou een geweldig verhaal hebben opgeleverd voor deze blogpost. Maar eerlijk gezegd was het tegenkomen van een paar problemen nog beter voor de post.
AI kan ronduit verbazingwekkend en adembenemend zijn met wat het kan doen. Maar het is niet perfect. We staan nog aan het begin van Agentic AI en AIOps, en er is nog veel werk te verzetten, van het ontwikkelen en aanbieden van afgestemde LLM’s met domeinspecifieke kennis tot het vinden van de beste praktijken voor het bouwen van de best functionerende tools voor AI-gebruiksgevallen.
Wat ik heb gezien in dit experiment, en al mijn experimenten en leren, is het ware potentieel voor NetAI om netwerkingenieurs een krachtig gereedschap te bieden voor het ontwerpen en beheren van hun netwerken. Ik zal mijn verkenning voortzetten en kijk uit naar het zien van dat potentieel dat werkelijkheid wordt.
Ik heb nog veel meer geleerd van dit project, maar de blogpost wordt behoorlijk lang, dus het zal moeten wachten op een volgende aflevering. Terwijl ik daaraan werk, laat me weten wat je van AI vindt en wat het potentieel is om je dagelijkse werk als netwerkbeheerder te verbeteren.
Hoe heeft AI je recent geholpen? Wat is de beste ontdekking die je tot nu toe hebt gedaan?
Laat het me weten in de reacties!
Lees verder:
Het creëren van een NetAI Playground voor experimenten met agentic AI
Beheer van de wildernis van MCP-servers
Meld je aan voor Cisco U. | Sluit je vandaag nog gratis aan bij het Cisco Learning Network.
Leer met Cisco
X | Threads | Facebook | LinkedIn | Instagram | YouTube
Gebruik #CiscoU en #CiscoCert om deel te nemen aan het gesprek.
Deel:
