Narzut protokołów na łączu ADSL

Technologia ATM wydaje się dziś nieco skostniała, ale tu i ówdzie trzyma się nieźle. :) Dlatego warto czasem wiedzieć co jest na rzeczy, np. gdy klient  nie może wysycić swojego wypasionego łącza ADSL-owego ruchem IP.

Narzut wprowadzany przez łącze ADSL jest dwojaki i wynika z:

• enkapsulacji np. PPPoE
• warstwy adaptacji np. AAL5, która wprowadza szczególnie wielki narzut dla małych pakietów (np. TCP ACK)

To, z czym wiele osób ma problem to fakt, że łącze ADSL z "ATM pod spodem" choć ma stałą przepustowość (ustaloną w komórkach na sekundę, a komórka ma zawsze 53B), to w warstwie IP nie jest ona stała. Zależy od wielkości przesyłanych pakietów IP, ze względu na zmienność narzutu. Często przyjmuje się pewną uśrednioną wielkość narzutu dla średniego rozmiaru pakietów IP w obserwowanym ruchu i dodaje gratis użytkownikowi - w pewnych sytuacjach użytkownik może więc zaobserwować, że łącze transmituje dane szybciej, niż by to wynikało z oferty, którą zakupił. ;)

Jak wielki jest to narzut, ładnie uświadamia fachowiec we wpisie: ADSL Overhead. Pod wpisem wywiązała się także interesująca dyskusja nt. doboru optymalnego MTU dla łączy ADSL z enkapsulacją PPPoE i PPPoA.

Popularność i żywotność tego jakże pokręconego rozwiązania daje się łatwo wyjaśnić: dostarcza łatwość zarządzania tak podłączoną bazą klientów nawet przy bardzo dużych rozmiarach sieci. Istnieją sieci czysto Ethernetowe, które - choć nie musiałyby - wdrażają PPPoE tylko po to, żeby sobie to zarządzanie ułatwić.

Jak hartowało się IPv6

Uwaga nadchodzi IPv6 - krzyczy okładka magazynu NetWorld. Z którego roku? 2010? 2009? Nie, przestałem prenumerować to pismo chyba jeszcze w ubiegłym wieku. ;) To numer 5/97 (29) - znów pochyliłem się nad szafką ze starociami.

 

Artykuł ze strony 42. informuje:

W Ameryce Północnej, Europie i Japonii rozpoczęto szeroko zakrojone prace nad stworzeniem próbnych sieci IPv6. Udział w nich biorą producenci sprzętu i administratorzy sieci. Większość producentów oczekuje, że protokół IPv6 przyjmie w połowie tego roku postać, która pozwoli na pełne wykorzystanie w przyszłym roku jego zalet w rzeczywistych sieciach.

Minęło kilkanaście lat i co? Jeśli chodzi o wdrażanie IPv6 w Internecie, nadal jesteśmy w ciemnej... leśnej gęstwinie.

Nadchodzi czas IPv6 - informuje inne pismo IDG, PC World. Tym razem z 2008 roku. ;)

Kiedy więc można spodziewać się przejścia na IPv6? Powinno to nastąpić wkrótce, gdyż przewiduje się, że pula adresów IPv4 zostanie wykorzystana do 2012 roku.

To jak to w końcu jest, skończą się te adresy IPv4 czy nie?

 

Prawdę mówiąc, świat tak dobrze czuje się z IPv4, że chyba jedynym motywatorem do migracji do IPv6 jest faktyczne wyczerpywanie się 32-bitowej przestrzeni adresowej.

 

 

 

Poza tym, adresy IPv6 są paskudne i trudne do zapamiętania. Zapamiętywanie adresów IPv4 jest łatwe i podobne do zapamiętywania numerów telefonów - nasze społeczeństwo jest do tego ewolucyjnie przystosowane. ;-)

 

O tym, że adresy IPv4 się wyczerpują, słyszymy od wielu lat. Tak wielu, że już się człowiek do tego przyzwyczaił. Wypracowano różne rozwiązania przedłużające życie IPv4. NAT pozwala podłączyć do sieci więcej komputerów niż mamy faktycznie adresów. SNI pozwala hostować wirtualki HTTPS na jednym adresie IP. Regionalni rejestratorzy wywierają presję ekonomiczną na organizacje, którym przypisano fragmenty przestrzeni adresowej, w tym posiadaczy klas PI. Trwa odzyskiwanie bloków adresowych, które przydzielano zbyt lekką ręką. Rozdawane są adresy z bloków zaznaczonych uprzednio jako zarezerwowane (sławetna sprawa alokacji 83.0.0.0/11 dla TP, która była firewallowana z wielu miejsc na świecie przez nadgorliwych administratorów; dziś prowadzi się debogonizację adresów).

 

Nieuchronnie jednak zbliżamy się do ściany. Spójrzmy do rejestru IANA. Nawet gdyby uwolnić bloki tzw. klasy E, a zrodzi na pewno wiele problemów z różnych urządzeń sieciowych, to wciąż tylko kilka dodatkowych lat.

 

Czy IPv6 oferuje coś więcej poza większą przestrzenią adresową? No cóż, na pewno wiele nowych problemów i dalszą komplikację sieci, szczególnie w czasie koegzystencji sieci IPv4 i IPv6 w Internecie. Z tematem rozprawia się Ivan Pepelnjak w poście IPv6 myths.

 

 

Na koniec smakołyki z wspomnianego numeru NetWorld z 1997, aby oddać ducha epoki... i pochichotać.

• Modnym tematem były NC
• "Plan rozszerzenia nazw domen internetowych o siedem nowych (.firm, .store, .web, .arts, .rec, .info i .nom) zyskuje coraz szersze poparcie"
• Na reklamach szacownych 3Coma, SMC czy HP widzimy, zarządzalne, stackowalne huby
• NT kontra Unix
• Przenoszenie użytkowników NT do schematu NDS
• Test wypasionego serwera HP LX Pro 6/166 SMP z 4 procesorami Pentium Pro 166MHz. Cena - skromne 30 tys. USD.
• HTML i okolice. Nowe możliwości WWW (I), a na screenshocie strona HotWired, layout przyprawiłby o zawał dzisiejszych specjalistów ;)
• Narzędzia projektowe Javy: "Istnieje już tak wiele produktów określanych mianem narzędzi projektowych Javy, że wybór między nimi staje się niemal tak kłopotliwy, jak wybór marki samochodu". (Biedacy, nie wiedzieli jeszcze o szykującej się mnogości frameworków).

Całość dopełniają dwa bardzo solidne artykuły:

• Dystrybucja strumieni multimedialnych MPEG z wykorzystaniem technologii ATM
• System RDS w Polsce

Kaszmirowy sweterek informatyka

Kiedy na spotkaniu projektowym nie jesteś w stanie rozróżnić po ubiorze szeregowych przedstawicieli IT od eleganckich Kierownika Produktu i Kierownika Projektu, to może być sygnał, że z firmą coś jest nie tak. Kiedy firma ma za dużo pieniędzy, manifestuje się to nie tylko rozdętymi systemami, ale także przesiąkaniem świata menedżerów do świata informatyków.

Idziesz do kuchni i nie słyszysz rozmowy o optymalizacji wydajności albo użytecznych bibliotekach, tylko np. o quick winach, challengowaniu, celach premiowych i wdrażaniu inicjatyw polepszających komunikację. Na spotkaniu projektowym grupa średnio zorientowanych osób debatuje nad niezbyt złożonym technologicznie problemem. Grupa nie dochodzi do konsensusu więc zaprasza się jeszcze więcej osób i dyrektorów.

Paul Graham, znany popularyzator idei start-upów, w felietonie "What Happened to Yahoo" opisuje wynaturzenia, jakie zrodziły dla tej spółki łatwe pieniądze. Zwraca szczególną uwagę na odpływ kompetencji technicznych i zestawia to z przykładami firm takich jak Google czy Facebook, które potrafią kultywować "kulturę hakerską". Ostatecznie Yahoo oddał walkowerem rynek reklam w wynikach wyszukiwania Googlowi.

Pozwolę sobie podprowadzić fragment felietonu na zachętę:

In technology, once you have bad programmers, you're doomed. (...) Most technology companies eventually get taken over by suits and middle managers. At Yahoo it felt as if they'd deliberately accelerated this process. They didn't want to be a bunch of hackers. They wanted to be suits. (...) Why would great programmers want to work for a company that didn't have a hacker-centric culture, as long as there were others that did? I can imagine two reasons: if they were paid a huge amount, or if the domain was interesting and none of the companies in it were hacker-centric. Otherwise you can't attract good programmers to work in a suit-centric culture. And without good programmers you won't get good software, no matter how many people you put on a task, or how many procedures you establish to ensure "quality".

BSNMP

Pakiet Net-SNMP (dawniej UCD-SNMP) to bardzo popularna implementacja agenta SNMP. Dostarcza oprogramowanie użytkowe (sam agent jak i narzędzia) oraz biblioteki udostępniające API dla innych programów i języków programowania.

Każdy kto pracował chwilę z Net-SNMP wie, że prostota nie jest atutem tego pakietu... podobnie jak i samego protokołu (Simple Network Management Protocol), prostotę mającego chyba tylko w nazwie.

Harti Brandt, jeden z deweloperów FreeBSD, stworzył swego czasu uproszczoną implementację agenta, zwaną BSNMP: "It is intended to serve only the absolute basic MIBs and implement all other MIBs through loadable modules".

Wydaje się, że nie jest on jakoś powszechnie stosowany - ociężałego Net-SNMP ciężko się pozbyć. ;) Warto więc zauważyć, że BSNMP jest rozwijane i Shteryana Shopova otrzymała tegoroczny grant (o GSoC więcej pisałem tutaj) na implementację obsługi SNMPv3 i lepszą integrację ze statystykami sieci bezprzewodowych. Do wielu zastosowań, sprowadzających się do monitorowania wydajności narzędziami opartymi o RRDtool, BSNMP jest wystarczający.

Poza tym, w portach dostępne są dodatki: bsnmp-jails, bsnmp-regex, bsnmp-ucd, bsnmptools.

Aplikacje jak krzyże

Nowe aplikacje w organizacji są jak krzyże - łatwo się je stawia, a trudno usuwa.

W gruncie rzeczy to zrozumiałe i zasadne. Komplikacja świata rośnie i znajduje odbicie w komplikacji i mnogości systemów w danej organizacji. Ale czy to jedyny powód mnożenia systemów? Wydaje mi się, że nie.

Czasem nowa aplikacja pojawia się, bo ktoś dał się przekonać slajdom na prezentacji Bardzo Drogiego Produktu, że taki produkt jest naprawdę dobry i profesjonalny. Umożliwi naszej firmie podążanie w kierunku, w którym podążają już inni. Rzeczywiście, znajomy prezes innej firmy podczas gry w golfa wspomniał, że właśnie go wdrażają. Nie możemy być gorsi - wdrażamy i my. (Charakterystyczne dla firm, które mają za dużo pieniędzy).

Kiedy indziej okazuje się, że pewien obszar działalności organizacji powinien zostać wsparty systemami IT, ale niestety kilka dotychczas wdrożonych systemów jakimś cudem nie nadaje się do tego celu. Kupujemy więc kolejny i spokój. Albo lepiej, dewelopujemy jakieś własne rozwiązanie, które ukrywa braki produktów komercyjnych.

Z czasem może się okazać, że takie własne rozwiązanie nieco się rozrosło i bez niego firma nie może funkcjonować. Co by nie mówić, rozwój własnych aplikacji daje niemal nieograniczoną elastyczność w reagowaniu na zmiany potrzeb biznesowych. Nie ma jednak wsparcia producenta - na kogo dyrekcja zwali ewentualne problemy? (Jakie problemy? - zastawia się deweloper aplikacji znający ją na wskroś i usuwający błędy "od ręki"). Doskonały powód, by wymienić je na jakieś nowe, komercyjne rozwiązanie ze wsparciem. Drogim wsparciem. W praktyce może się okazać, że co prawda wdrożono nowe, ale z jakiegoś powodu wciąż nie można wyłączyć tego starego...

Mamy więc systemy, które nie były przeznaczone do likwidacji, takie, które chciano zlikwidować, ale się nie udało, i oczywiście te nowe, które były mniej lub bardziej potrzebne.

Tych nowych nie będziemy przecież likwidować - tyle pieniędzy na to wydaliśmy... już lepiej wydać drugie tyle, by je "udrożnić" i zacząć stosować.

Tych starych nie będziemy przecież likwidować - są filarem naszej firmy, za duża rewolucja. Czasem nawet upgrade jest zbyt ryzykowny - a że utracimy wsparcie? Cóż, korzystamy z tego X lat i ile tych zgłoszeń do supportu poszło? Trzy? I rozwiązywali je ile? Dwa... tygodnie? To o całe 13 dni dłużej niż robili to nasi administratorzy.

Można spróbować zlikwidować te już raz przeznaczone do likwidacji, a co się dotąd nie udało. Pozostaje życzyć powodzenia. :-)

FreeBSD 8.1 - zmiany zwracające uwagę

W lipcu wydano FreeBSD 8.1. Wpis - suchar? Trochę tak. ;) Na liście zmian tej wersji systemu znalazłem kilka interesujących rzeczy.

Rozbudowane IPFW ("ipfw3"), czyli natywny firewall FreeBSD (pf jest importowany z OpenBSD). Pojawiła się w końcu możliwość eksportu do pseudourządzenia ipfw0 (analog do pflog0). Śledzenie pracy firewalla narzędziami typu tcpdump jest naprawdę przyjemniejsze niż syslog. Wiele algorytmów wyszukiwania zmieniło złożoność czasową na niższą. Mocno przepisany został dummynet.

Widać też postępujący proces migracji sterowników ATA pod interfejs CAM, który obejmował dotąd SCSI. Dzięki temu można będzie stosować wspólne API przy dostępie do obu rodzin urządzeń dyskowych.

Zmiany od Polaków: pojawił się HAST, ale o tym wspominałem wcześniej. Jest także wsparcie dla NFSv4 ACLs (więcej).

Enterprajsowo, pojawiła się komenda service sterująca usługami. ;)

Wreszcie pojawiło się wsparcie w skryptach startowych do hurtowego tworzenia puli VLAN-ów na danym interfejsie fizycznym, ponazywanych według konwencji znanej z ruterów, np. em0.X (VLAN X na pseudointerfejsie em0).

Migracja zawodowa w IT

Zdarzyło mi się zmienić miejsce zamieszkania celem uzyskania dostępu do lepszego rynku pracy IT (czytaj: przeprowadziłem się do Warszawy). Nigdy jednak nie rozważałem serio wyjazdu z Polski. Powodów jest kilka:

• w Polsce są rodzina, znajomi i przyjaciele
• odwiedziny kogoś w innym mieście zwykle są w zasięgu kilkugodzinnej podróży
• w Warszawie można uzyskiwać bardzo dobre dochody
• pomijając niektóre sklepy, koszty życia w Polsce są stosunkowo niskie
• bariera językowa - angielskiego używam głównie do czytania dokumentacji technicznej

Jednak od czasu do czasu dociera do człowieka impuls, który każe się zastanowić, czy nie lepiej byłoby stąd wyjechać do jakiegoś milszego kraju, np.:

• majstrowanie rządu przy VAT i OFE
• oszołomstwo obrońców krzyża i innych
• tor przeszkód między żebrakami, wszelkiej maści cwaniaczkami i agresywnymi pijanymi wyrostkami, jaki trzeba czasem zaliczyc idąc przez Centrum
• śmieci na trawnikach, palenie papierosów na przystankach i inne przejawy buraczanej mentalności
• irracjonalnie wysokie wyceny nieruchomości w Warszawie

Do tego dodałbym czynniki strategiczne:

• fatalne perspektywy demograficzne i praktycznie pewne załamanie systemu emerytalnego
• brak klasy rządzącej z prawdziwego zdarzenia i długofalowej strategii rozwoju Państwa
• podtrzymywanie iluzji dobrobytu poprzez bieżące przejadanie majątku narodowego
• mentalność "Państwo powinno mnie wspomóc" i silne poparcie polityków, którzy obiecują rozdawnictwo
• potencjalnie groźnych sąsiadów

Mówiąc wprost, o ile nie nastąpi jakaś istotna zmiana, perspektywy Polski za 20-30 lat widzę w barwach raczej ciemnych niż jasnych.
 
Wracając jednak do migracji zawodowej - do podjęcia rozważań i umieszczenia tego posta zainspirowali mnie rekruterzy firm zagranicznych, którzy zechcieli do mnie zagadnąć. Oczywiście, zagadują oni pewnie wiele osób, a tylko niektórym faktycznie udaje się przejść rekrutację (po czym jeszcze mniej z nich faktycznie decyduje się na przeprowadzkę). Konkretnie, poproszono mnie o wysłanie CV w następujących kierunkach:

1. Dublin (Irlandia)
2. Zurych (Szwajcaria)

Przyznam, że nigdy nie byłem w tych krajach i nie wiem o nich wiele. Szybkie skojarzenia miałem następujące:
 
Irlandia

• w niedalekiej przeszłości przepychanki z Wielką Brytanią i bieda
• wielka migracja Polaków w tym kierunku
• załamanie na rynku nieruchomości i ogólnie kryzys
• zdolność do szybkiego powstawania z kryzysów i rozwoju (ich kiełbasa łatwo przegoni naszą)
• niskie podatki, którymi narażali się UE
• są za wodą i jeżdżą po złej stronie ulicy

 
Szwajcaria

• neutralność i bezpieczeństwo, broń pod łóżkiem a za oknem góry
• jedno z centrów finansowych świata
• obywatelskie społeczeństwo
• autonomia - własna waluta, "nie" dla meczetów i UE
• bardziej przyda się tam niemiecki (którego nie znam) niż angielski

Podsumowując szybkie skojarzenia - oba kraje wyglądają fajnie, ale Szwajcaria bardziej, tyle że asymilacja jest zapewne trudniejsza/niemożliwa.
 
Oczywiście, wyboru nie podejmuje się na podstawie danych tak marnej jakości. ;) Zacząłem się więc zastanawiać, jakimi kryteriami posłużyć się przy bardziej szczegółowej analizie - o ile zdarzyło by się, że faktycznie stanę przed takim dylematem.

Wymyśliłem na razie następujące:

1. obecny stan i prognozowany rozwój (demografia, gospodarka)
2. bezpieczeństwo geopolityczne
3. bezpieczeństwo fizyczne
4. system podatkowy
5. czystość środowiska
6. zamożność społeczeństwa, liczność i realny wpływ warstw domagających się tzw. socjału
7. zarobki minimalne, średnie i średnie zarobki w IT
8. realne koszty pobytu i życia (żywność, komunikacja, rozrywki)
9. ceny nieruchomości i ceny najmu, dostępność
10. kultura społeczeństwa
11. łatwość i koszt podróżowania między Polską a danym krajem

Coś jeszcze? W tzw. wolnej chwili może jeszcze do tego wrócę.

Drżyj - nadciąga TRILL

Ivan Pepelnjak, posiadacz najwyższych stopni wtajemniczenia w sekcie siskoitów ;) silnie skupił się na krytyce promowanego ostatnimi czasy TRILL-a.

Czym jest TRILL? Bardzo upraszczając, to takie przełączanie ramek, gdzie poszczególne przełączniki wymieniają informacje o trasach podobnie jak rutery, czyli z użyciem protokołu rutingu. (Klasyczne przełączniki uczą się po prostu, na którym porcie jaki MAC jest osiągalny, a jak nie wiedzą, to ślą ramkę do wszystkich). Teoretycznie ma uprościć życie i np. pozwolić budować wielkie (tysiące hostów) domeny rozgłoszeniowe w środowisku datacenter. Bardzo modne w czasach wirtualizacji i chmur.

Dlaczego należy drżeć przed TRILL-em? Ivan zastanawia się nad tym w serii postów. W szczególności polecam:

• Dlaczego bridge w ogóle nie powinny zaistnieć? - Bridges: a kludge that shouldn't exist
• Jaka jest różnica między przełączaniem a rutowaniem? - Bridging and Routing: is there a difference? oraz Bridging and Routing, Part II
• O wysypie standardów - How many large-scale bridging standards do we need?

Ivan obawia się, że debugowanie problemów w takich sieciach stanie się prawdziwym koszmarem, ze względu na różnice leżące u podstaw działania warstwy drugiej i trzeciej. Znamienne dla L2 są m.in.:

• brak licznika hopów
• brak wsparcia dla fragmentacji
• brak sygnalizacji problemu do nadawcy
• powielanie ramek
• mobilność adresu

No cóż, sieci podobnie jak wszystko inne robią się nam coraz bardziej skomplikowane. ;)

Dyktat Business Case

Przeczytałem niedawno artykuł Zasada skautów. Nie jestem programistą, ale obserwuję takowych oraz całą otoczkę związaną z wprowadzaniem zmian w systemach. Artykuł proponuje, aby programiści stosowali zasadę zawsze zostawiaj kod czystszym niż go zastałeś. Udoskonalenia mogą być drobne, ale tak jak skumulowane przez lata drobne niedoskonałości doprowadzają do erozji kodu, tak skumulowane przez lata drobne usprawnienia mogą wydźwignąć kod z bagna.

Do umieszczenia tego wpisu zainspirowały mnie komentarze pod artykułem, że tego typu podejście w realnym świecie bywa niemożliwe do zastosowania. Zupełnie się z tym zgadzam albowiem obserwuję zjawisko, które nazwałem roboczo dyktatem business case'u (BC).

W firmach skupionych na działalności biznesowej, dla których IT pełni rolę służebną, nie dewelopuje się dla przyjemności, tylko do zaspokojenia określonych potrzeb biznesowych organizacji. Decyzja o wykonaniu lub nie określonej zmiany podejmowana jest po analizie BC przez zarządzających, bywa że najwyższego szczebla (zależnie od budżetu). Na tym poziomie nikt nie wnika, czy kod jest ładny. Na słupku w arkuszu kalkulacyjnym widzimy, że wydamy kwotę X i uzyskamy z tego tytułu przychody albo oszczędności na kwotę Y w horyzoncie k-letnim - to jest coś, co przemawia.

Problem jest taki, że istnieją rzeczy, które inżynier uważa za stosowne by je wykonać, ale bardzo trudno biznesowo uzasadnić związane z tym koszty. Dokumentacja, refaktoryzacja pewnych części, przeprojektowanie API, lepsze walidacje, większa uniwersalność, lepsza integracja z systemem operacyjnym, czytelniejsze logi, itd. - z punktu widzenia użytkownika biznesowego to mogą być rzeczy "mało ważne", "ryzykowne dla harmonogramu", "możliwe do realizacji w terminie późniejszym", "na inny projekt".

I rzeczywiście jest tak, że nie powstają rozwiązania dobre, tylko wystarczająco dobre. Nie obsługują niektórych specyficznych przypadków i trzeba dane poprawiać ręcznie (tańsze to niż poprawka aplikacji). Wymagają restartu co noc (akceptowalne, w nocy nie pracujemy). Mają SQL injection (ale używają ją tylko zaufani pracownicy, którzy prawdopodobnie tego nigdy nie odkryją). Działa przy zbyt dużych uprawnieniach (ale działa, a mogłaby nie działać). Ma bardzo niestandardowe skrypty uruchamiające (uczulimy administratorów). Loguje pełno śmieci i rzuca wyjątkami na lewo i prawo (dyski są tanie). Konsumuje duże zasoby (RAM jest tani). Ale za to było połowę tańsze, dzięki czemu BC w ogóle się spiął. Z punktu widzenia klienta biznesowego to może być wręcz pełny sukces.

Te drobiazgi kumulują się w czasie, a niesmak z pracy z kodem rośnie. Rośnie również kulka hacków i workaroundów, ale póki to jakoś istotnie finansowo nie uderzy w organizację (system stanie się krwiobiegiem organizacji i zacznie być blokerem jej rozwoju ze względu na trudność wprowadzania zmian), wszyscy będą z tym żyli pchając całość do przodu. Może to trwać wiele, wiele lat...

Update - w pewien sposób ilustracja tego o czym piszę ;) Brytyjski rząd: Internet Explorer 6 jest wystarczająco bezpieczny.