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. :-)