Názory k článku TRILL 4. část – Stav vývoje a alternativní řešení
-
davro (neregistrovaný)Mějme následující topologii - switche A, B, C, D uspořádané do čtverce. Ke switchi A je připojeno PC A1 a A2, ke switchi C počítače C1 a C2. Jakým způsobem bude vybrána správná cesta mezi koncovými stanicemi A1 - C1, A2 - C2 a další kombinace tak, aby byl zachován standard (rámce se nesmějí předbíhat) a současně byla využita možnost multipathu?
-
:-)
Tohle doufání vyšlo ze srovnání vlastností obou návrhů nebo srovnáním zastřešující značky ? :-)
Ale vážně. Asi by bylo lepší, kdyby Radia Perlman, Donald Eastlake a další mohli vydat TRILL jako IEEE standard, protože tento standardizační institut má k Ethernetu a STP blíže.
Z různých důvodů (IEEE pochopitelně rozvíjí své existující standardy, různá otevřenost vývoje v obou organizacích aj.) to však bude jinak.
Tuším, jak zrádné může být posuzování protokolů dle "katalogových" vlastností, ale osobně mám radši řešení, které je úplnější i za cenu (únosně) větší složitosti návrhu. Má tak ambice vydržet s námi déle.
Třeba i více než 25 let, co už existuje STP :-) -
davro (neregistrovaný)Moje preference jsou v tomto případě spíše administrativního charakteru. Prostě by se neměly do sebe míchat věci, které patří někomu jinému. To pak může přinášet zbytečný chaos.
Čím složitější návrh, tím větší šance, že tento protokol skončí na smetišti dějin. Jen si sentimentálně zavzpomínejme na ISO OSI (tedy, IS-IS je takový drobný relikt, asi jako přesličky), ATM a jistě i další hromada standardů, které byly svého času lepší a úplnější. -
Ano, o složitosti návrhu a úspěchu v praxi si myslím totéž. Vždycky je to o nalezení vhodné hranice, jak složitý evoluční krok bude v praxi přijat a který už nikoliv, protože je příliš revoluční.
Nezapomeňme, že ta revoluční změna je v našem případě nahrazení rodiny STP něčím novým. Souboj protokolů bych proto viděl spíš v rovině "STP vs cokoliv novějšího" než "TRILL vs SPB". Zdá se mi, že TRILL a SPB na tom nejsou z hlediska složitosti tak dramaticky odlišně jako tomu bylo u ATM vs. Ethernet nebo u OSI vs. TCP/IP.
SPBM se mi líbí z pohledu maximalizace využití toho, co už je hotové a nasazené. Relativně jednoduchým rozšířením je možné vyřešit dost věcí (včetně STP) a věřím, že si najde svoje místo nasazení. Ze strany IEEE to je logický inkrementální krok dále.
(oproti tomu z SPBV jsem rozpačitý a těžko si představím např. jeho troubleshooting v praxi)
TRILL byl jako náhrada STP přímo navržen a slibuje oproti SPBM zejména lepší možnosti troubleshootingu.
V pozici vlastníka/tvůrce/správce sítě je nejtěžší rozhodnutí o nahrazení STP. Pokud už toto rozhodnutí padne, pak se už se nemusí tolik koukat na složitost konkrétního nahrazujícího protokolu, protože oproti STP jsou revoluční všechny skoro stejně. Spíš bych se při této volbě soustředil na to, abych co nejlépe dotáhl do konce původní myšlenku, proč jsem vůbec STP nahrazoval - abych měl stabilnější a lépe troubleshootovatelnou L2 síť. A v tomto slibuje TRILL být trochu napřed.
Jsou samozřejmě situace, kdy by mě vyšlo SPBM lépe:
- Už mám v síti dost switchů, které umí MAC-in-MAC
- SPBM switche budou výrazně levnější (např. pokud Broadcom, Marvell a ostatní výrobci obvodů budou schopni vyrobit levněji ASIC pro MAC-in-MAC než pro TRILL)
- ...
A při věštění budoucnosti bychom neměli vynechat ani tu vizi, že STP bude mít silný kořínek a vydrží s námi dalších 25 let, protože řadu menších LAN sítí jeho nestabilita tolik netrápí. TRILL/SPB by se prosazoval jen pomalu ve speciálních využitích...uvidíme :-) -
davro (neregistrovaný)Mám pocit, že jste si celkem odpověděl na to, kdo vyhraje :-)
U malých sítí imho zůstaneme u STP a u větších sítí číhá třetí vzadu MPLS/VPLS.
Hlavně doufejme, že si do TRILLu cisco nenaimplementuje ať už technická nebo administrativní omezení, která budou vyhovovat jenom ciscu a nedopadne třeba jako PVST, který taky považuju za technicky lepší než MSTP. -
Poslední odstavec je jenom jedna z mnoha možností :-)
V těch nejmenších sítích bude STP jistě poskytovat dobrou službu i nadále.
TRILL/SPB mají ale dlouhodobě šanci nahradit STP i třeba ve středně velkých sítích, protože konfigurační úsilí bude minimální (tj. stejné jako na klasických přepínačích) a přínosy podstatné. To, co v těchto sítích rozhodne, bude pozdější dostupnost levných ASICů s TRILLem/MAC-in-MAC pro komoditní L2 switche.
TRILL je implementačně mnohem jednodušším transportem L2 nežli realizace služby VPLS přes MPLS. Pro VPLS přes MPLS se musí se nastavit pseudowires, zajistit redundance a split-horizon, vymyslet případná hierarchie, oželet multipathing, zajistit hardware aj. A všechno to předpokládá již dříve implementovaný fungující MPLS backbone - tj. rozhodně ne běžnou situaci větší LAN sítě. Jde spíš o SP záležitost.
Teoreticky můžeme TRILL považovat za další technologii, díky které je možné službu VPLS realizovat (a to mnohem jednodušeji než přes technologii MPLS). -
anonymníja tu vidim este 3 cestu a to je cez virtualizaciu hardveru ako ide na to juniper som velmi zvedavy co sa z toho vykluje
a ci sa na to nevykaslu ked bude softwareve riesenie
http://www.juniper.net/us/en/local/pdf/whitepapers/2000348-en.pdf -
davro (neregistrovaný)Což je věc nekompatibilní se zbytkem světa. Tyto technologie má nejen juniper, ale delší dobu i HP/3com/H3C nebo právě cisco. Ale stejně tam nějaký signalizační protokol musí běžet, tady se akorát schová do jedné virtuální krabice. Ale imho to není cesta kterou by se měl svět vydat v širším měřítku.
-
Netman (neregistrovaný)
Ze to neni cesta bych nerekl, to co ma prave HP nebo Juniper je rizeni vicero switchu z jednoho CPU a distribuce potrebnych informaci (FIB, nastaveni TCAMu apod.) do HW. TRILL i SPB vychazi z myslenky ze kazdy switch je samostatnou jednotkou a neexistuje ridici prvek site s dokonalym prehledem o topologii. A treba prave to bude budoucnost - kontroler s dokonalym prehledem topologie site, ktery programuje vsechny switche - takovy software muze delat multipathing na zaklade znalosti aktualni situace v cele siti, to nikdy TRILL ani SPB ani OSPF ani MPLS nedokaze (nevi kolik ceho kam a jak se kudy poslalo, neumi na zaklade QoS politik automaticky volit cestu nizke latence, vetsi propustnosti, mene hopu, udrzeni v geografickem regionu apod.) Kouknete na www.openflow.org - pokus o standardizovane reseni uplne noveho konceptu. HP labs ma OpenFlow firmware do nekterych switchu zatim neoficialne k dispozici, Broadcom zas pro nektere cipy. Zatim je to v plenkach, ale za 5 let muzeme treba stavet site uplne jinak
-
davro (neregistrovaný)Obávám se, že případ etherchannelu je řádově jednodušší protože se rozkládání zátěže dělá na jediné point-to-point lince.
Jde o to, proč a jak se vybere cesta ABC a ne ADC a jakým způsobem se dosáhne toho, aby byla cesta na všech switchích konzistentní. A taky bych chtěl použít ten multipathing pro různé datové toky. -
anonymníje to zjednoduseni, ale postacujici. RBridge pouzivaji LSDB pro vytvoreni distribucniho stromu(distribucnich stromu). LSDB je ve cele domene konzistentni. vyber cesty tedy probehne na kazdem hopu podle hashe dostupnych informaci (v zavislosti na platforme cokolikoliv od src/dst MAC pres src/dstIP po src/dstPORT) a je konzistetni tudiz kazdy jeden FLOW (komunikace dvou koncovych MAC) pujde vzdyc po jedne ceste. nicmene draft k tomu rika toto:
If applications are in use where occasional out-of-order unicast frames due to such transitions are a problem, the RBridge campus should be engineered to make sure they are of extremely low probability, such as by using the ESADI protocol, configuring addresses to eliminate unknown destination unicast frames, or using keep alive frames.
(https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-protocol/ kapitola 4.5) ale cely draft jsem jeste nemel cast precist. -
Distribuční stromy se používají jen pro multi-destination rámce (neplést s multipathingem). Tj. pro broadcastové, multicastové a neznámé unicastové rámce.
Původní dotaz jsem pochopil jako multipathing nad známým unicastem, tj. k využití distribučních stromů nedojde a vždy se počítají nejvýhodnější cesty k cíli, nikoliv po větvích stromu.
Multipathing pro multi-destination (uff) rámce je ale i přesto možný tak, že se v síti vypočítá větší počet distribučních stromů s různými kořeny (normálně stačí jeden). Rozkládání zátěže (zase hashem) je pak mezi různými stromy.
Ta poznámka v draftu je směřovaná k situaci, kdy začnu multipathovat na neznámou unicastovou adresu, která se průběhu komunikace změní na známou (cílová stanice odpoví). V okamžiku přechodu ze stromového multipathingu na destination multipathing se skutečně může pár rámců předběhnout. Nicméně opět jde o okrajový výskyt, který je řešitelný, jak je v draftu psáno. -
Je to opravdu stejné rozhodování jako v případě Etherchannelu (TRILL samotný toto řešení ponechal na standardu IEEE 802.1AX, na který odkazuje).
Tj. na prvku, na kterém je více stejně výhodných cest k cíli (představovaných několika hext-hopy) se na základě hashe hlavičkových položek zvolí jedna z cest. Pokud se vyberou ty správné hlavičkové položky, mělo by se dosáhnout toho, že v rámci jednoho toku se vybere vždy stejný next hop (a že pro jiný tok se s určitou pravěpodobností vybere next hop jiný). Zatím stejné jako pro Etherchannel.
To, že to je multihop, vůbec nevadí. Na každém dalším TRILL přepínači se toto rozhodnutí provede nezávisle znovu. Pokud jsou na zvolené cestě další rozvětvení, rámce se rozdělují mezi cesty jako by šlo o další Etherchannely. Pokud se cesty ještě před cílem spojí, nic se neděje. Jeden datový tok proběhne celou sítí vždy po jediné trase, není potřeba nijak synchronizovat switche mezi sebou.
Rámce se tedy mohou předběhnout jen v okamžiku rekonvergence sítě kdy se v mezičase, co už je rámec na cestě, nejvýhodnější cesty změní. To je ale problém i pro singlepathing v běžné Ethernetové síti bez TRILLu.
