Názory k článku TRILL: Konečně náhrada za Spanning Tree?

neuvěřitelné - článek o sítích a technologiích na Lupě. Už jsem myslel, že se toho nedožiju. Kam se poděla Rita Pužmanová, kam pan Satrapa?

Chválím, palec nahoru, doufám že pro takovéto články má Lupa nějakou výjimku ze sazebníku a platí podle profesionality spíš než podle návštěvnosti. Ale zas na druhou stranu chápu že takhle bez článků těžko budete mít inzerenty, co cílí na lidi, co ty články čtou a tedy ani peníze pro ty autory. Ale myslím, že nějakou tu tisícovku by jistě nějaký technologický inzerent našel.

Přidávám se k pochvale. Výborně, už se těším na druhý díl.
Jen víc takovýchto článků a méně SEO :-)

Zase na druhou stranu, fungují alespoň mezi sebou, což se o jiných říct nedá :-)

Grrr, to už se IETF musí s.át úplně do všeho? Tento protokol by měl zcela spadat do kompetence IEEE, stejně jako všechny ostatní protokoly na této vrstvě.

Vážně by mne zajímalo, jak je možné dodržet standard 802.3, který říká, že rámce (od stejného zdroje ke stejnému cíli se stejnými parametry) se nesmějí předbíhat a současně mít multipathing. To bude asi nějaká vyšší magie :-)

hmm, když o tom tak uvažuju, tak ta podmínka bude spíš v 802.1

to má tu drobnou nevýhodu, že to nepřináší zvýšení výkonu, pokud mezi sebou komunikují ty dvě stanice (viz link agregace 802.3ad)

TRILL je implementace postavená na IEEE 802.1. STP je mimochodem taky RFCčkovaný

Multipathing je tam zakázaný? Co já vím, tak je tam zakázané jenom předbíhání a to se ošetří tím, že multipathing probíhá jenom na linkách se stejnou cenou

Multipathing samozřejmě zakázaný není. Je zakázané předbíhání. Předbíhat se dá i na linkách se stejnou cenou, takže to není řešení.

Tohle zjisteni me stalo nastesti jen pul dne zivota. grrr

Multipathing v TRILLu je možné si velmi zjednodušeně představit jako automatický multi-hop Port-channel, který vznikne "sám" bez konfigurace všude tam, kde SPF algoritmus protokolu IS-IS (viz další díly) vypočítá stejně výhodné cesty k cíli.

Návrh standardu TRILL zmiňuje, že pro minimalizaci nežádoucích důsledků předbíhání rámců pro vyšší vrstvy by rámce patřící ke stejnému datovému toku (flow) měly cestovat po stejné trase. Mechanismus určení toho, co je "stejný flow" je uveden odkazem na standard IEEE 802.1AX. Tj. řešení je stejné jako pro IEEE Port-Channely a je mimo rámec TRILLu.

http://en.wikipedia.org/wiki/802.1AX#Order_of_frames

Analogie s Port-channelem samozřejmě není přesná, v TRILL síti při multipathingu nevznikne žádná entita "interface Port-channel" aj. Použil jsem ji jen pro ilustraci řešení předbíhání rámců.

TRILL podporuje jakoukoliv topologii, tj. odstraňuje závislost na stromech, kruzích, segmentech aj.

IEEE vyvíjí vlastní protokol IEEE 802.1aq, který STP také nahrazuje. Zvolili však trochu jiný přístup. Srovnání snah IETF a IEEE je popsáno ve čtvrté části série.

Pokud to vydržíme, poprosím o vyčkání s diskusí (která k tomuto bezesporu vznikne) až ke čtvrtému dílu :-).

ok, to vypadá rozumně.

Pokud vám nestačí pro propojení dvou stanic plná kapacita jedné linky, máte problém který je třeba řešit jinak. Ale to skoro nikdy nenastává - dnes je běžně dostupný 10 Gbps ethernet!

Bohužel z pohledu L2 jsou koncovými stanicemi třeba dva propojené routery. Tedy překvapivě není na L2 možné dosáhnout zvýšení kapacity linky tím, že přidám další linku. V praxi to znamená, že musím nasadit nějaký protokol na L3, který ovládá multipath (a z toho plynoucí důsledky)

Ano, ATOM je hezký protokol... pro vytvoření dvoubodového propojení pomocí VC naprosto ideální. Bohužel pro propojení více stanic v rámci lokální sítě ale dost nevhodný.

Takže pro L2 síť propojující cílové stanice problém není, a routery zase lze propojit jinak než jedinou L2 sítí - takže opět žádný problém. Mixovat na jedné L2 síti koncové stanice s více routery stejně není dobrý nápad.

rád si nechám představit řešení 2x 10Gbit mezi dvěma poskytovateli běžícími BGP bez toho, aby při tom vznikla konfigurace, kde se škrábete levou nohou za pravým uchem :-)

No a co se týká L2 sítě, tak stačí srovnat cenu 10x 1Gbit a 1x 10Gbit a je taky celkem zřejmé, v čem může být problém.

Ano, obávám se, že jste přesně popsal to škrábání se levou nohou za pravým uchem :-)

je jednoznacne firma CISCO a jeji parodie na STP, ktera nefunguje s nicim jinym.

Co tak pouzit kruhovu topologiu? MRP - Metro Ring Protocol, skoda, ze je to Foundry proprietarny protocol.

http://www.foundrynet.com/pdf/wp-mrp.pdf

V port-channelu k předbíhání docházet nemůže, pokud je to správně implementované. Tj. je to nějakým způsobem staticky hashované podle MAC adres. V tom případě jde jeden tok vždy jednou trasou.

pokud předbíháš, porušuješ standard. Nic víc, nic míň.

Asi se zbytečně omezujete na uvažování o multipathingu přímo mezi dvěma cílovými stanicemi. Co takhle brát to spíš jako multipath mezi dvěma nebo více množinami cílových stanic? Pak se pomocí nějaké šikovné hashovací funkce (můžete si ji nazvat vyšší magií, chcete-li) dá pro každou konkrétní komunikující dvojici vybrat jedna konkrétní cesta, která nemusí být nutně pro každou komunikující dvojici stejná.

Já ti dám, to vono samo! Určitě jsi to tam musel nějak nakonfigurovat, pochybuju, že by někdo měl nějaký nerozumný default (teda s výjimkou cisca a jeho pvst :-)