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