Vége a CiscoLive! 2019-nek. Aki belenézett az előadásokba (írtam róla itt), annak feltűnhetett hogy a fő témák az automatizáció és a SDx megoldások voltak. SD-WAN, SD-Access, DNA, ACI, DevNet…
Megbújt viszont egy remek kis session, aminek a címe: “The CCIE in a Software Defined World (BRKCRT-3075)”. A fóliákért kattints ide.
Ez egy új előadás volt, és én kötelezővé tenném mindenkinek aki hálózatokkal foglalkozik. Nem feltétlenül a CCIE-ról szól, és remekül árnyalja a képet.
Több remek példával szemléteti a “szükség lesz -e még a hálózati tudásra és kompetenciákra az SDN világában?” kérdéskört.
Nézzünk néhány fóliát az én kommentjeimmel.
Van aki szerint már nincs is értelme a CCIE-nak. Már 2014 év végén sem volt az illető szerint 🙂
Picit ellent mond a nagy SDN hype-nak hogy 71% azért még a jó öreg CLI-t használja. API 3%, NMS 10%, Network automation tool: 6%…
API vs. CLI… Másra való a két felület.
Mire való az API? Erre.
A gépeknek sokkal “logikusabb” az API (mivel struktúrált a felépítése), az embernek a CLI (utóbbival azért tudnék vitatkozni néhány esetben).
Az alábbi példán láthatjuk ugyanazt a konfigurációt YANG, XML és CLI nézetben.
Itt már fel kell hogy merüljön mindenki fejében a kérdés: “ha nem tudod mi az a VRF és mi az az RD, tudod -e automatizálni a konfigurációt?”
Nézd meg közelebbről! Majdnem ugyanaz.
Mi történne ha most azonnal megszűnne a CLI? Minden hálózatos tudásod a kukába mehet? Ugyan…
Oké, de akkor mit kéne csinálni? Tanuld meg a hálózati technológiákat (CCxx), tanuld meg a scriptelés alapjait és élvezd az automatizáció nyújtotta előnyöket.
Jön a mellbevágó igazság: régóta “software defined networking” van. Pl. BGP.
Az underlay és az overlay hálózatok régóta külön válnak. Nyilvánvaló példa erre a Wireless (WLC), kevésbé nyilvánvaló a GRE tunnel. Ki kell építeni mindkettőhöz az underlay-t: csak az overlay miatt.
Fel kell épüljön a CAPWAP Tunnel a WLC és az AP között, ehhez szükséges az underlay network. Általában az underlay nem fontos számunkra mert minden a CAPWAP-ben megy. Miért ne építhetné fel az underlay-t egy kontroller, és koncentrálhatnánk az overlay-re? Viszont ha gond van az underlay-ben, hogy tudnánk hibát keresni ha nem értünk az “underlay” technológiákhoz (STP, routing, QoS)?
De nézhetjük az MPLS VPN-t is: azért kell MPLS core-t építenünk hogy a L3VPN ki tudjon felette épülni. Ha úgy nézzük már tettünk egy lépést az “automatizáció” felé az ospf ldp autoconfig paranccsal. Ha minden klappol és áll a BGP session az MPLS felett akkor el is feledkezünk az underlay hálózatról, mert csak arra kell hogy a MP-BGP össze tudjon fütyülni. Ha viszont nem működik valamiért akkor kell MPLS ismeret, tudni kell hogy működik a labeling, stb. Kell hálózatos tudás? Na ugye.
Az SDx hálózatok is bonyolultak, csak másképp.
Mi várható a CCIE-nál? Alapvetően még mindig a protokollokról fog szólni, de elképzelhető a laboron később olyan rész ahol ALAP scripteket kell írni.
Szóval akkor most mi van?
Az SDN jó dolog, de nem csodaszer. Nem érdemes struccpolitikát folytatni: ezek a megoldások már itt vannak, foglalkozni kell velük. Viszont ugyanúgy szükség lesz hálózatos tudásra, mint most. A protokollokat ismerni kell. Az SDN és a programozás csupán könnyebbé teszi az életünket. Olyan dolgokra fókuszálhatunk amelyek fontosabbak. Eltolódhat a munka akár pl. a több design irányába, de ha gond van akkor szükség lesz a trobleshooting skillekre. Az ismétlődő feladatokat scriptek elvégzik.
Néhány gondolat még zárásként:
- Ezt a példát mindenki ismeri. Hálózatoktól függetlenül.
Azt jelenti -e az Excel-ben a SUM függvény hogy innentől kezdve nem kell tudni összeadni 3 számot fejben/papíron/akárhogy?
Ha nem tudod mit akarsz csinálni az A1-A3 cellákkal (összeadni, átlagolni stb.) akkor hogy fogsz rá függvényt írni?
- Tudsz -e úgy kenyeret sütni hogy nem ismered a receptet?
- Másként terjed -e 5 GHz-en a rádiójel attól hogy az AP az standalone vagy LWAPP?
- Változik -e a WPA2 protokoll attól hogy az AP standalone vagy LWAPP?
- Van -e különbség Layer 8-ban (user) az SDN és nem SDN között? 🙂
Ezeket az eszközöket a gyártók azért adják a kezünkbe hogy hatékonyabbá tegyék a munkánkat. Ezek jó dolgok. Segítenek.
Eltolódik majd a határ mert lehet hogy a Service Desk is meg tud alap dolgokat csinálni a segítségükkel (pl. forgalom engedélyezése/tiltása), és nem lesz annyi junior hálózatos feladat. De ez jó: rá lehet koncentrálni a komolyabb dolgokra. Levesszük a terhet a junior rétegről akik így komolyabb dolgokkal tudnak foglalkozni.
De ne feledjük: “shit happens”. És olyankor bizony szükség lesz a “régi” tudásra is.
Szerintem tanulja meg tehát továbbra is mindenki hogy néz ki az IPv4/IPv6/TCP/UDP stb. header, mi kell ahhoz hogy az OSPF neighborship összeálljon stb. mert még szüksége lesz rá a jövőben is 🙂
