bardzo zły design

Czy istnieje na tyle zły projekt lub wdrożenie sieci, że nie ma on żadnych zalet?  W rozmyślaniach nad fundamentami projektowania zagoniłem się w ciemny zaułek, gdzie takie pytania stają się niebezpiecznie nurtujące. W pierwszym odruchu była odpowiedź, że “naturalnie tak, mogą być same wady”. Są wszak projekty i wdrożenia, które się nie sprawdziły i trzeba je bezwzględnie zmienić. Zaczyna się dyskusja.

Moje “naturalnie tak” mówi: “Weźmy na przykład uruchomienie spanning-tree w płaskiej sieci L2 miksując przy tym różne protokoły STP, MST, czy PVRSTP”. Moje “aby na pewno?” odpowiada: “Coż z tego, skoro można doprowadzić do współpracy wymienione protokoły, a uwzględniając strategię “dual vendor” stworzyć wyspy, w których określony protokół jest uruchomiony na urządzeniach konkretnego dostawcy.”  Będzie działać? Jakoś będzie, więc i zalety się znajdą. Z drugiej strony strategię “dual vendor” można efektywniej zrealizować za pomocą jednego protokołu zamiast kilku. Czy w takim przypadku zalety rozwiązania w odniesieniu do bardziej optymalnych projektów nadal są zaletami?

Spróbujmy jednak nie odpuszczać. Nadal trzymajmy się argumentu “dual vendor” do obrony złego projektu. Może sieć zrealizować tak, aby maksymalnie uniezależnić od siebie warstwy kontrolne? Użyjmy metody “ships in the night”. Polega ona na równoległym aktywowaniu dwóch lub więcej protokołów, które  rozgłaszają wspólną przestrzeń adresową. Choć niekoniecznie są to identyczne prefiksy. W routingu jest to do zastosowania. Czy w spanning-tree dałoby się uzyskać “ships in the night”? Okazuje się, że na chwilę obecną nie. Ramki nie mają świadomości, do którego drzewa spanning-tree należą. Zaraz, zaraz. W routingu też nie ma takiej świadomości, a mimo to daje się to zastosować. Dlaczego więc nie można w spanning-tree? Otóż każdy protokół spanning-tree buduje swoje własne drzewo blokując nadmiarowe łącza. Dwa równolegle działające protokoły spanning-tree mogłyby spowodować pętlę. Chyba że, ramki miałyby świadomość, według którego drzewa miałyby się poruszać. Przykładowo, ramki posiadają świadomość topologii w Fabric Path/TRILL, gdzie są znaczniki FTAG. Zrównoleglenie spanning-tree wymagałoby więc modyfikacji nagłówka lub dodania 4 bajtowego znacznika, niczym 802.1Q. Nazwijmy go znacznikiem PS (od Parallel Spanning-tree). Mógłby on wyglądać następująco:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = Parallel STP  |   FTag           |   Hop Limit  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Przy okazji posiadałby ograniczenie pętli w płaszczyźnie danych w postaci Hop Limit. Każdy protokół xSTP nadawałby własny numer FTAG wynikający z konfiguracji. Ruch w VLAN-ie tagowanym miałby zewnętrzny tag PS oraz wewnętrzny dot1Q, taki PSinQ (wymowa: psinkju). Oczywiście nie byłoby problemu z QinQ oraz dot1ad. Zostawię to do realizacji na jakiś draft IETF lub standard IEEE 802.1PS. ;)

Wracając do naszego pierwotnego rozważania widzimy, że taki design przy obecnym stanie rzeczy nie jest realny. Zaleta “dual vendor” przy wielu protokołach xSTP traci rację bytu. Czy “naturalnie tak” wygra? W tym momencie projektowi przychodzi w sukurs argument podziału organizacyjnego. Niech będzie tak, że jeden departament odpowiada za protokół A, a drugi za protokół B. Klarowne? Na upartego, tak! Co prawda jest to przypadek praktycznie nie występujący w przyrodzie dla warstwy 2, ale dla innych projektów może to być argument prawidłowy. Zawsze też znajdą się dodatkowi sprzymierzeńcy, wprost nietechniczni: “jak działa, to po co ruszać?” oraz “job security is my priority”. Można więc założyć, że dla zadanego otoczenia filozoficzno-egzystencjalnego rozciągniętego wokół dowolnego projektu i wdrożenia istnieje niezerowa ostatnia deska ratunku. Nawet, gdyby sieć miała ubijać pakiety, rozłączać usługi, banować administratorów, to zawsze znajdzie się jakaś zaleta. Choćby i zaleta polityczna. W takim przypadku słomiany miś powinien być wręcz jak największy.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
This entry was posted in Uncategorized. Bookmark the permalink.