RFC 1925 – 12 sieciowych praw

Kiedy pierwszy raz czytałem RFC 1925, którego autorem jest Ross Callon, uznałem je za świetny żart z okazji prima aprillis.

Kiedy pierwszy raz czytałem  RFC 1925, którego autorem jest  Ross Callon, uznałem je za świetny żart z okazji prima aprillis. Jednak przygotowując ten wpis, odkryłem, że jest on cholernie prawdziwy.  Co najlepsze ten dokument ma ćwierć wieku, (wydany został 1 kwietnia 1996!) i nadal jest aktualny.

Jestem absolutnie pewny, że z większością – jeśli nie wszystkimi – miałeś, już do czynienia.

Zapraszam do zapoznania się z 12 sieciowymi prawa.

1) It Has To Work.

Jakie to proste prawda? Kto nigdy nie znalazł się w sytuacji, w której nie było ważne, jak rozwiążesz problem, niech pierwszy rzuci kamieniem. Sieć ma po prostu działać, a jak dobrze wiemy, najtrwalsze na świecie są tymczasowe rozwiązania.

2) No matter how hard you push and no matter what the priority, you can’t increase the speed of light.

Pewnych rzeczy nie da się przyspieszyć. Zwłaszcza takich, które wydają się wiecznością. Czas restartu routera, którego nie powinno się restartować. Czas oczekiwania na reakcję firewalla, na którym dodałeś ACL-kę i przestał odpowiadać. 

2a) (corollary). No matter how hard you try, you can’t make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won’t make it happen any quicker.

Ten punkt jest szczególnie polecany wszystkim osobom dopytując co 5 minut o update w tickecie, ETA i ETR. Choć jak tak się dobrze zastanowić, to nie jeden menadżer projektu ma też swoje za uszami.

3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.

Kiedy podstawą do podejmowania decyzji zaczynają być kolumny w excelu zamiast racjonalnych danych, nawet świnie mogą latać. Wystarczy odpowiednie ciśnienie z góry i gotowe. Zazwyczaj nie jest to ani dobre dla organizacji, ani tak tanie jak wyglądało na papierze, ale zwykle to już problem nowego menadżera lub konsultanta.

4) Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.

Nawet sieci zbudowane na podstawie prostych wzorców potrafią zaskoczyć swoją złożonością. Oprócz doskonałej znajomości działania protokołów równie ważne jest zrozumienie, ich wzajemnej zależności. Nie ma również jednej prawidłowej konfiguracji i każda sieć jest inna i wymaga poznania. Pamiętaj, że jeśli coś jest głupie i działa, to nie jest głupie.

5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.

Razem raźniej, nawet dzieci w przedszkolu o tym wiedzą. Jednakże problemy najlepiej sprowadzać do najmniejszych, odseparowanych od siebie elementów. Nigdy odwrotnie. Pamiętaj, że im prostsze rozwiązania, tym łatwiejsze późniejsze utrzymanie.

6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.
6a) (corollary). It is always possible to add another level of indirection.

Kto pracował na ticketach, ten wie, że „No issue found in xxx, please check with zzz” potrafi zapewnić nawet kilka godzin spokoju. Co w sytuacji, gdy wróci? Zawsze jest jakaś linia wyżej. W swojej karierze w NOC’u widywałem tickety przekazane do innych zespołów w czasie poniżej 6s! Ręcznie. Szanuję gościa.

7)It is always something
7a) (corollary). Good, Fast, Cheap: Pick any two (you can’t have all three).

Ta zasada ma zastosowanie w każdym aspekcie IT. Warto brać ją pod uwagę podczas projektowania oraz troubleshootowania. W końcu każdy problem można rozwiązać na jeden z trzech sposobów:

  • Dobrze i szybko, ale nie będzie tanio
  • Dobrze i tanio, ale nie będzie szybko
  • Szybko i tanio, ale nie najlepszy

8) It is more complicated than you think.

Proste rzeczy działają wyłącznie w labie i to też nie zawsze. Środowiska produkcyjne to nie tylko proste i te bardziej skomplikowane rozwiązania. To również cały bagaż wcześniejszych decyzji na temat architektury, umów z klientami, wewnętrznych polityk firmy. Jeśli ktoś przychodzi do Ciebie z prostym problemem, który zajmie Ci tylko 5 minut, nie wierz mu. Cytując klasyk „It’s a trap!”

9) For all resources, whatever it is, you need more.
9a) (corollary) Every networking problem always takes longer to solve than it seems like it should.

Zawsze potrzebujemy więcej sprzętu, ludzi i kawy. Zwłaszcza kawy.

10) One size never fits all.

Cokolwiek by nam nie wmawiały sklepy odzieżowe, jeden rozmiar nie będzie pasował wszystkim. Tak samo wygląda sprawa z sieciami oraz całym IT. Nie powstał jeszcze design, który pasowałbym do każdej sytuacji, dlatego rozwodzenie się nad wyższością „spine and leaf” nad „three-tier” nie ma sensu. To po prostu różne rozwiązania, świetne w innych zastosowaniach.

11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
(11a) (corollary). See rule 6a.

Ciężko się z tym nie zgodzić. Spójrzmy dla przykładu na firewalle nowej generacji zwane NGFW. Z miksu tradycyjnej zapory i odrobiny inspekcji ruchu, powstał marketingowy chwyt, który nie jedną firmę skłonił do wymiany dobrych urządzeń. Kolejny przykład SD-WAN? Miks tuneli IPsec z odrobiną logiki kontrolerów i mamy kolejny produkt, który dobrze się sprzedaje, choć nie zawsze jest potrzebny.

12) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.

Jestem wielkim fanem podejścia KISS – „Keep it simple, stupid!”.  Każdy protokół powinien rozwiązywać wyłącznie jeden problem. Koniec kropka.

Podsumowanie

Przebrnęliśmy przez 12 sieciowych praw. Jestem ogromnie ciekawy, co Ty sądzisz o nich sądzisz. Koniecznie dać znać w komentarzu!

Jeśli chcesz poznać inne RFC, wydane z okazji 1 kwietnia zajrzyj do wpisu Zabawne RFC.

RFC 1925 w całości możesz przeczytać na: https://tools.ietf.org/html/rfc1925

19 aplikacji, które musi znać każdy sieciowiec

Blog wspiera partner diamentowy

Borg5 - Diamentowy partner bloga

Narzędziownik sieciowca

19 aplikacji newsletter

Grupa na Facebooku

Pierwsze kroki w sieciach

Najnowsze artykuły

Model referencyjny ISO/OSI

Model referencyjny ISO/OSI

Maszyny, podobnie jak ludzie, do skutecznej komunikacji potrzebują pewnych zasad. My przestrzegamy zasad gramatyki oraz używamy słownictwa zrozumiałego dla odbiorcy, urządzenia natomiast wykorzystują standardy i protokoły. Na tym nie kończą się podobieństwa. Zwróć...

Automatyzacja sieci z Netmiko

Automatyzacja sieci z Netmiko

Netmiko to biblioteka napisana w Pythonie przez Kirka Byersa. Jest jedną z najłatwiejszych opcji wejścia w świat automatyzacji sieci. Dlaczego? Ponieważ Netmiko wykorzystuje Pythonową bibliotekę Paramiko do łączenia się poprzez SSH do CLI. Wszystkie przekazywane przez...

13 sposobów na zabezpieczenie sieci

13 sposobów na zabezpieczenie sieci

Zabezpieczanie infrastruktury to niekończący się proces, który polega na ciągłym testowaniu i ulepszaniu. Warto podchodzić do tego skrupulatnie i metodycznie – idealnie sprawdzi się tutaj proponowana poniżej 13-punktowa checklista bezpieczeństwa dla sieciowca.1....

Protokoły FHRP – HSRP, VRRP i GLBP

Protokoły FHRP – HSRP, VRRP i GLBP

Jest takie angielskie powiedzenie "Two is one, one is none". Mówi ono o konieczności stosowania redundacji, czyli zapewnienia nadmiarowości. Kiedy mamy dwa urządzenia, awaria jednego zwykle nie jest problemem i daje nam czas na naprawę. Posiadanie w momencie awarii...

Hot Standby Router Protocol

Hot Standby Router Protocol

HSRP, czyli Hot Standby Router Protocol to protokół  z grupy FHRP (first-hop redundancy protocol) opatentowany przez Cisco w 1994r. Jego zadaniem jest zapewnienie redundancji bramy domyślnej w przypadku awarii, bez potrzeby zmiany w konfiguracji urządzeń końcowych. W...

Jesteśmy parterem miedialnym konferencji 

PLNOG

O autorze

Rafał Rudewicz

Specjalizuję się w rozwiązaniach Enterprise oraz Service Provider. Projektuję, wdrażam oraz naprawiam sieci dla największych firm na świecie.

Komentarze

0 komentarzy

Wyślij komentarz

Twój adres e-mail nie zostanie opublikowany.

Powiązane posty

Zapisz się na newsletter