Vlákno názorů k článku TRILL: Konečně náhrada za Spanning Tree? od davro - Vážně by mne zajímalo, jak je možné dodržet...

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

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

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)

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)

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

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

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

ok, to vypadá rozumně.