Spaning från Cisco Live 2025 – DevNet & AI

Ingen kan ha missat att det mesta inom teknik idag handlar om AI, och Cisco Live 2025 var så klart inget undantag. Nytt för i år var en ”AI Hub” i World of Solutions, men AI var på inget sätt begränsat dit.

Det är nog många som tycker det är för mycket fokus på AI generellt idag och att det inte är relevant för ens dagliga arbete. Till en stor del är det nog för att hypen inte realiserats, inom IT-infrastruktur har det varit begränsat med AI-system hittills, men nu känns det som att det är en hel del på gång inom snar framtid.

AI-området kan i stort sett delas upp i tre delar:

1. Produkter för AI-datacenter.
2. AI-produkter och -tjänster
3. Bygga system med AI

Vad menar vi med AI

Eftersom AI är ett så hett område idag används begreppet för att betyda allt möjligt: Vanliga algoritmer, maskinlärning, Large Language Models (LLMs) med mera. I den här bloggposten kommer det betyda i stort sett bara LLM.

AI är i slutändan bara en teknik och vi kan välja att använda det på det sätt vi vill. För de flesta inom nätverks/IT-infrastruktur-världen kommer det troligen inte innebära någon revolution inom överskådlig framtid, men troligen kommer det ha en påverkan framåt. Som alla andra nya tekniker är det bra att hänga med och utvärdera vad det kan vara användbart till, men kanske inte köpa den största hypen. Sessionen CISCOU-1044 gav en underhållande och enkel överblick av hur AI kan pass in och användas idag av nätverkstekniker.

Produkter för AI-datacenter

AI kräver väldigt kraftfull hårdvara, och här ligger Cisco ligger väldigt bra till i och med att man ligger i framkant i både nätverk och servrar. Självklart fanns det gott om hårdvara med benämningen ”AI Ready”.

Snabbare Nexus-switchar (porthastigheter börjar komma upp i 800G nu) och mer kraftfulla UCS-servrar med plats för GPUer helt enkelt. Det finns även färdiga ”AI-poddar” med en färdig stack av nätverk/servrar/lagring/mjukvara för att komma i gång så snabbt som möjligt.

AI-produkter och -tjänster

Här fanns det mycket att se, var och varannan produkt påstår att den har AI inbyggt på något sätt numera, problemet är bara att det är ett så brett begrepp att det kan betyda allt från simpla algoritmer till faktiskt självlärande system.

Några intressanta exempel:

• AI Defense. En säkerhetsprodukt som fokuserar på användningen av AI-system. Dels fungerar den som en access-kontroll för vilka AI-applikationer som får användas, och dels som en kontrollpunkt för kommunikation med AI-modeller, typ en proxy.
  Många organisationer har policys för hur AI får användas, men att faktiskt kunna implementera begränsningar för användandet kan nog vara riktigt användbart.
• Hypershield. Det är lätt att få fel bild av vad Hypershield är, det är ingen magisk lösning där AI automatiskt löser säkerheten, utan en paraply-produkt med målet att förena policys och visibilitet över alla säkerhetssystem i nätet.
  Här finns en stor möjlighet för AI att hjälpa till med att hitta signaler i en stor mängd data och så småningom hjälpa till med att föreslå policys och upptäcka system som är påverkade av sårbarheter.

Bygga system med AI

Det här är den mest intressanta delen för mig, hur man kan bygga in och på andra sätt utnyttja AI (som här betyder LLM) i sina egna applikationer och system.

Bland sessionerna i DevNet-delen verkade det nästan vara ett krav att baka in AI på något sätt, ibland till överdrift. LLMs ”kan” Cisco-CLI, men personligen ser jag hellre verktyg som Ansible och Terraform användas för att konfigurera enheter än att en LLM ska skicka in kommandon via något Python-bibliotek.

Agenter är vårens stora nyhet

Det största mode-ordet i år var ”Agentic” AI tillsammans med arbetsflöden (En striktare definition skiljer på att använda ”enklare” flödesbaserad AI och ”riktiga” agenter). I stort sett betyder det att skapa AI-instanser (agenter) som är:

• Begränsade och specialiserade på specifika handlingar, till exempel prata med ett visst system, tolka specifika loggfiler, eller summera ihop data från andra agenter.
• Har en hög grad frihet att tolka en fråga och komma fram till ett resultat (Utvecklaren ska fokusera på att definiera resultatet, inte processen för att komma fram till det).
• Har tillgång till ”verktyg” som ger modellen nya möjligheter, till exempel för att göra API-anrop eller hämta data från andra system.

Agenterna kombineras sedan i ett flöde som sätter en övergripande logik för hur de används och där olika beslut kan tas beroende på vad varje agent kommer fram till. Se till exempel AIHUB-2170.

Ett simpelt flöde kan till exempel vara två agenter, en med uppgift att läsa en fil och sammanställa en viss typ av data från den i en tabell, och en annan med uppgift att kontrollera att svaret från den första agenten är korrekt. Resultatet blir då förhoppningsvis bättre än om bara en LLM hade använts med en fråga, eftersom den andra agenten kan ställa nya frågor till den första agenten tills resultatet uppfyller kraven. I stort sett diskuterar de sig fram till en lösning.

Agenter i praktiken

En intressant session med ett mer komplext exempel var AIHUB-2006 där AI-agenter användas för att lösa ett problem med flera möjliga felkällor:

• Scenario: En applikation som kör i Kubernetes har problem, men orsaken är oklar. Det kan vara applikationen i sig, kubernetesklustret, databasen, servern eller nätet. Loggar och status finns från alla system, men det är för mycket information att hantera på en gång, och dessutom behöver inte alla fel vara relevanta för just den här applikationen.
• Felsökningen delas upp i ett flöde av agenter: En agent kan vara ansvarig för att samla in data och bestämma vilka system som är involverade, medan specialiserade agenter är ansvariga för att undersöka och tolka status i varje system. Resultatet av felsökningen kan sedan tolkas och summeras av en annan agent.
• Varje agent kan nu tränas till att vara ”expert” på sitt område vilket leder till bättre resultat. Tillsammans skapar de en kedja där en analys till slut endast behöver ta hänsyn till de system som rapporterat potentiella fel, dessa kan då viktas och en slutgiltig utvärdering görs om den mest troliga felkällan.

För mig känns det här som en väldigt rimlig utveckling, det är samma princip som vi använt inom IT i väldigt lång tid: Om man har ett stort problem som är svårt att lösa bryter man ner det i mindre delar och löser varje del individuellt. Det har visat sig att LLM-modellerna beter sig liknande människor: Desto större en fråga är i form av information, begränsningar, instruktioner o.s.v., desto större är också risken att den ”tappar bort sig” och ger ett ofullständigt svar.

Funktioner och identiteter

LLMer är förtränade på en mängd data och det finns sätt att finjustera dem i efterhand, dels med ny unik data och dels med signaler om rätt och fel svar, men det kräver en viss omträning av modellen. För riktig realtidsdata behövs funktioner, vilket är det som ger agenter deras stora värde i att vara systemspecialiserade. Funktioner är i stort sett ett skal runt ett API-anrop där begränsningar, säkerhet och annat kan implementeras. Agenten ges tillgång till funktionen med en beskrivning och kan välja att använda den för att svara på en fråga.

Exempel: En Meraki-agent kan ha en funktion get_clients som pekar på Merakis API-ändpunkt för att hämta antalet klienter per nät. Agenten kan då svara på frågan ”Hur många klienter finns på huvudkontoret just nu?” genom att använda funktionen och välja antalet klienter för nätet som heter ”HQ”.

Funktioner är inget nytt, men flera sessioner hade intressanta problemställningar gällande funktioner ihop med identiteter: Mer avancerade AI-system måste implementera samma säkerhet vi har idag i form av rättigheter och access-kontroller. Identiteter måste kunna propagera till funktioner, dels i form av vilka som finns tillgängliga, dels i form av vilken faktiskt data som är tillgänglig från ett annat system.

En presentation handlade om ett internt Cisco-projekt för en AI runt deras HR-system. Där går det inte bara att lära en LLM all data om all personal, vilken data som är tillgänglig är helt beroende av vem som frågar.

En annan session som beskrev detta i detalj och steg för steg var BRKETI-2411, dessutom med ett imponerande demo. Troligen den bästa sessionen jag såg för att få sig en bild av var AI är på väg.

Exempel från verkligheten

En session som visade ett bra exempel var AIHUB-2008 som handlade om hur Cisco TAC använder AI för att underlätta och snabba på felsökning.

I stort sett använder de AI-system för att analysera inkommande ärenden, klassificera och berika dem med data så supportpersonen som sedan tar ärendet har en bra startpunkt. Systemet föreslår sedan svar med uppföljning, potentiella lösningar etc. för supportpersonen att använda. Syftet är så klart att en AI ska kunna hitta mönster i en stor mängd data snabbare och enklare än en människa och exempelvis kunna läsa loggar och hitta rader som indikerar en känd bugg direkt.

Sessionen handlade en hel del om feedback och mätvärden för att se så systemet faktiskt fungerar som det ska och ger värde för personalen som använder det. En poäng de tryckte på var att människan alltid hade kontrollen i slutändan, AI-systemet kom bara med rekommendationer.

För mig är det här ett väldigt bra exempel på hur AI (specifikt LLM) används på bästa sätt: Ett verktyg som hjälper människor hitta signaler i en stor mängd data och från det föreslå en trolig plan framåt, det är lättare för människor att använda sin kunskap till att utvärdera ett resultat än att leta sig fram till svaret på egen hand. Dessutom tror jag det här kommer bli det vanligaste användningsområdet för AI: Effektivisering av befintliga system och processer, mer verktyg än egen produkt.