xchaos
Samozvany gubernator
Registrován: 13.05.2002
Příspěvků: 3362
Team Member: MOD |
Myslím, si že tohle je opět demagogicky tendeční výklad slova "směrování". Směrování v síti se dá nastavit i statické - to je platný český výrok, "používáme statický routing" (statické směrování) - což poněkud vyvrací tvojí teorii, že směrování zahrnuje pouze protokoly pro řízení směrování, a vše ostatní je forwarding. Podle mě směrování (routing) je především o sestavení routovací tabulky jádra - její využívání je forwarding.
Pokud si někdy slyšel o tom, že by někdo používal "statický forwarding", tak klobouk dolů - máš pravdu, směrování je v tom případě to co tvrdíš ty.
Kromě toho si troufám tvrdit, že zvládám jisté základy řízení směrování pomocí OSPF, což má sice význam pouze na společně administrované infrastruktuře (proto vznikly cloudy - protože společná správa celého CZfree nebyla přijatelná), ale přeci jen je to nějaký protokol pro řízení směrování (pro sestavení routovací tabulky na routeru). Možná používáme OSPF trochu jinak, než je to obvyklé, protože máme jen jednu areu - resp. ty agregace malých lokálních subnetů do většího subnetu nám občas někde fungují a občas ne - já taky připouštím, že OSPF nerozumím nijak do hloubky - ale pořád je to snad něco trochu jiného než "nerozumět směrování". Zkrátka když bys tvrdil, že "plně nerozumím protokolům pro řízení směrování", tak máš pravdu, říct že "nerozumím směrování" je flame.
To na co poukazuju je, že stávající konfigurace CZFree BGP redistribuuje do CZfree OSPF právě jednu nejlepší routu - což vede k agregaci tranzitního trafficu který teče přes cloud do jediného bodu, který vybere BGP podle ne zcela jasných kritérií (zatím umíme local priority řídit pomocí routomap, ale pořád je výsledkem jediná nejlepší cesta). Alternativní způsob, jak část peeringu mezi dvěma cloudy odklonit jinam, je mít ve svojí cloudové OSPF tabulce ještě vybrané prefixy z toho vedlejšího cloudu - na obou stranách. Pokud tohle nepřipustíme, tak můžeme mezi více hraničními body dvou cloudů balancovat jen tranzit, nikoliv lokální peering (ten ale často bývá nejdůležitější). Tohle není podle mě to samé jako "nerozumět směrování". Prostě jen nemám zkušenost s konkrétní BGP konfigurací, která by přes alternativní hraniční body směrovala s velkou prioritou menší části cloudu, a s velkou prioritou větší části cloudu. Nedostatečné znalosti ovládání BGP jsou skutečně hlavní důvod, proč se dnes cloudy více chovají jako "CZFree service providers" a už ne tolik jako meshující cloudy, mezi kterými je spousta lokálních přechodů pro "malý pohraniční styk" realizovaných levnými masově dostupnými technologiemi (drátem do zdi, Wi-Fi přes ulici...). Ono to je samozřejmě tím, že spoustě lidem je úplně jedno, kudy ty packety jdou, když mají internet za 300 měsíčně a CZFree traffic se jim nepočítá do FUPu na gatewayi.
Kromě toho já si pod slovem "rozumět směrování" představuju "rozumět tomu, kde se dělá rozhodnutí o tom, který packet kudy půjde" - což tě zejména začíná zajímat ve chvíli, kdy zjištuješ, proč se nějaký packet někam dostane a jiný ne - a jak říkám, jaký program tohle rozhodnutí konkrétně udělá, to je podle mě vedlejší. Třeba myšlenka Simandlova Sedla se mi vlastně docela i líbí - jenom bych ho kvůli větší efektivitě přespal do céčka, rozšířil bych ho i na rozhodování o jiných cílech než je default GW, a přidal bych další protokol, kterým by si konkrétní IPčko mohlo říct konkrétní běžící instanci Sedla kudy se chce nechat poslat do daných kritických bodů, tzn. volba tranzitní gateway :-) Myšlenka sundat TCP/IP packety z kolejí a přidělat k nim volant se mi popravdě docela líbí - mohl by z toho být nový Apple 1 :-)
Kromě toho mě neuvěřitelně irituje že používáš termín směrování, když každý normální člen CZFree místo směrování routuje (linuxové příkazy na rozdíl od chybových hlášek a manálových stránek nikdo do češtiny nepřekládá). Měl bys asi začít používat zvyklosti komunity do které se tlačíš.
__________________
Naposledy upravil xchaos 25.03.2005 v 17:21
|
25.03.2005 v 12:12
