Ainakin kerran raskaan verkkokokoonpanon tai vianmääritysistunnon aikana joku katsoja saa näyttävän ilmeen ja sanoo jotain "Gee, joka näyttää todella monimutkaiselta. Eikö ole helpompaa tapaa?"
Useimmiten tämä tapahtuu, kun olen polven syvällä kasassa ssh- tai telnet-istuntoja erilaisille reitittimille, kytkimille tai palomuureille ja pidän muutama kymmenen muuttujaa päässäni. "Ei", vastaan, "ei ole."
[Myös .com: lue Paul Venezian pikaklassikko "Yhdeksän veteraanin Unix-järjestelmänvalvojan ominaisuutta". | Sitten, jos uskallat, liity keskusteluun Unix-pohjaisten järjestelmien uudelleenkäynnistämisestä. ]
Saatat ajatella, että tällä hetkellä meillä olisi maagisia käyttöliittymärajapintoja ja ohjattuja ohjattuja konfigurointielementtejä, jotka antaisivat kenen tahansa satunnaisen henkilön konfiguroida OSPF-tunnelointi oikein GRE: n, EIGRP-uudelleenjaon ja BGP-peeringin kautta. Tarkoitan, että he ovat olleet olemassa jo ikuisesti - eikö heidän pitäisi olla paljon yksinkertaisempia hallita nyt? Vastaus on ilmeinen verkonvalvojille: Jos jokainen verkko olisi identtinen, niin kyllä, se olisi hieno. Todellisuus sanelee toisin.
Näiden protokollien ja työkalujen teho on niiden laajuudessa ja soveltamisalassa. Voit tehdä asioita Cisco IOS: lla, jota edes Ciscon ihmiset eivät koskaan pitäneet; kokoonpanotasolla IOS on ohjelmointikieli, ei pelkästään kytkentä- tai reititysalusta. Syy siihen, miksi Linux-ydin on kirjoitettu C: llä, ei VPL: llä (visuaalinen ohjelmointikieli), on sama syy siihen, että raskaille reititys- ja vaihtokokoonpanoille ei ole käytettävissä runko-peräkkäin käyttöliittymää. Toki on olemassa SNMP-pohjaisia työkaluja, jotka helpottavat kytkinportin VLAN-osoitteen vaihtamista tai käännösten ja sääntöjen lisäämistä palomuuriin, mutta ne voivat mennä vain niin pitkälle. Väistämättä he törmäävät seinään sitä vastaan, mitä heidät on rakennettu käsittelemään verrattuna siihen, mikä on tosiasiallisesti mahdollista taustalla olevan käyttöjärjestelmän kautta.
Ei vain tuoreet kokoonpanot ylittävät sen, mitä nämä työkalut pystyvät käsittelemään; virheenkorjaus ja vakiintuneiden verkkojen vianmääritys vaativat yleensä enemmän ymmärrystä ja taitoja. Clippyä ei ole olemassa raskaissa reititysongelmissa tai edes yksinkertaisissa ongelmissa, kuten väärin määritetty linkki LACP-nipussa. Lyhyesti sanottuna verkon kokoonpanoille ei ole turvaverkkoa. Ei ole kätevää IDE: tä, joka tietäisi jotenkin, että olet siirtänyt kaksi numeroa OSPF-verkkolausekkeeseen, mikä aiheuttaa reititysprotokollan epäonnistumisia etäsivustossa.
Mikään näistä ei ole uutinen verkonvalvojille, mutta se on järkyttävää tuntemattomille. Jostain syystä monet ihmiset ajattelevat, että 9-paikkaisen ydinkytkimen määrittäminen tai MPLS-verkon rakentaminen toimii samalla tavalla kuin heidän Netgear-kotireitittimen Wi-Fi-parametrien määrittäminen. Joissakin tapauksissa olen jopa kuullut jyrinä, että verkon ylläpitäjät "tekevät siitä vaikeamman kuin se on" työn turvallisuuden varmistamiseksi. Vaikka olen varma, että se tapahtuu ajoittain, voin vakuuttaa teille, että suurin osa verkonvalvojista työskentelee valtavien pakettijälkien läpi selvittääkseen, miksi WAN-linkin liikenne katoaa ajoittain tai miksi tiettyjä aliverkkoja ei reititetä oikein mesh-etäsivuston VPN-kokoonpano ei liioittele ongelmaa vain tilansa parantamiseksi.
Jopa konfigurointirajapinnan ja kokoonpanoelementtien, kuten., Monimutkaisuuden (mutta välttämättömyyden) ulkopuolella sama turvallisuus-liikennelupa käyttöliittymän sisällä on se, että näiden työkalujen käyttäminen vaatii perusteellisen ymmärryksen niiden toiminnasta, mikä johtuu elinikäisestä oppimisprosessista. Ja toisin kuin monet muut IT-tehtävät, ei ole kumoa-painiketta, kun vahingossa estät pääsyn etäsivustoon etkä pääse takaisin etälaitteeseen ongelman korjaamiseksi.
Kyllä, verkonhallinta on vaikeaa. Se on mahdollisesti haastavin osa nykyaikaisessa tietotekniikassa. Näin sen on oltava - ainakin siihen asti, kunnes joku kehittää verkkolaitteita, jotka pystyvät lukemaan mieltä.
Tämä tarina "Miksi verkonhallinta on niin kovaa bleping" julkaistiin alun perin osoitteessa .com. Lue lisää Paul Venezian The Deep End -blogista osoitteessa .com. Uusimmat yritysteknologiauutiset ovat seuraamalla .com Twitterissä.
