Vlákno názorů k článku TRILL: Konečně náhrada za Spanning Tree? od davro - Ano, obávám se, že jste přesně popsal to...

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

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.

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.

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)

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!

ok, to vypadá rozumně.

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

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ů.

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

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.

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í.

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

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)

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á.

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

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