RSTP a path cost VS priority

okoun

nevíte níte náhodou jak je to s nastavením priority pro L2 trasy? co má přednost před čím? jestli path cost u portu na bridge nebo priority pro bridge? případně se to nějak sčítá? případně proč se zadává priority jako hex a path cost jako desítkové číslo?

ludvik

Switch s nejnižším Bridge ID se stane ROOTem. Je to složenina toho ID a MAC adresy.

Path cost je údaj pro výpočet nejkratší cesty k root bridge. Ve skutečnosti je to zase nějaký součet cost + priority + číslo portu (přesný algoritmus teď z hlavy nevím, ty priority se zapojují do výpočtu asi až v případě, že vyjdou dvě shodné trasy). Tak aby to bylo v rámci jednoho switche jednoznačné.

A cost se to jmenuje naschvál ... cena za přenesení bitu. A chceš přenášet tím nejlacinějším ... nejrychlejším. V rámci celé L2 domény.

Jsou to tedy dvě, na sobě přímo nezávislé hodnoty. Já je zadávám obě desítkově :-) Ale Bridge ID je 12 bitů, takže hex je to tak nějak čitelnější.

okoun

Switch s nejnižším Bridge ID se stane ROOTem. Je to složenina toho ID a MAC adresy.

Path cost je údaj pro výpočet nejkratší cesty k root bridge. Ve skutečnosti je to zase nějaký součet cost + priority + číslo portu (přesný algoritmus teď z hlavy nevím, ty priority se zapojují do výpočtu asi až v případě, že vyjdou dvě shodné trasy). Tak aby to bylo v rámci jednoho switche jednoznačné.

A cost se to jmenuje naschvál ... cena za přenesení bitu. A chceš přenášet tím nejlacinějším ... nejrychlejším. V rámci celé L2 domény.

Jsou to tedy dvě, na sobě přímo nezávislé hodnoty. Já je zadávám obě desítkově :-) Ale Bridge ID je 12 bitů, takže hex je to tak nějak čitelnější.

nějak se mi nedaří rstp nastavit, aby přepínalo třeba do dvou sec když mi vypadnou data na lince, ale port je stále running. nevím přesně jaké hodnoty naladit?

jinak pokud ten port shodím tak se to přepne hjodně rychle i bez výpadku paketu...

ludvik

Nějak nerozumím, co chceš. Ale změna výchzích parametrů (kromě cost a priority) je většinou cesta k tomu udělat si v síti bordel.

Kromě toho rstp není stavěný na změny bez výpadků, chvilku to prostě trvá. Na to jsou jiné technologie, většinou pro nasazení v průmyslu.

okoun

Nějak nerozumím, co chceš. Ale změna výchzích parametrů (kromě cost a priority) je většinou cesta k tomu udělat si v síti bordel.

Kromě toho rstp není stavěný na změny bez výpadků, chvilku to prostě trvá. Na to jsou jiné technologie, většinou pro nasazení v průmyslu.

jasně tady se jedná o zálohu mezi dvěma routery kde mi chybuje ptp spoj, vůbec to není žádný velký úsek...

jinak ted to řeším pomocí scriptu že když vypadnou dva pingy hned interface vyhodí z rstp bridge a tím se to ihned překlopí, bohužel to nahození je trošku neštastné....

ludvik

Na chybující spoj není žádná existující technologie vhodná. Nevím o žádné, která by to dokázala vyřešit. RSTP neregistruje žádnou chybovost, reaguje na fyzický výpadek linku (a to si ještě nejsem jistý, zda u všech implementací) a na výpadky BPDU paketů (tedy vyprší timer a zajistí přepočet topologie). No a teď si představ, že ti to chybuje jen "trochu" a občas ti to přehodí linku sem tam. Nic dobrého pro síť. Vím o čem mluvím ... laser od MRV při mlze tohle dělal. Také neměl žádný threshold pro návrat do stabilního stavu.

Stejně se chová i OSPF, jen timeouty jsou delší.

Normálně se to řeší opravou toho PtP spoje ...

Zkus si ty spoje zdvojit, třeba VLANou. Scriptem pak ovlivňuj jen cost. Ale chtělo by to spíš MSTP, aby ti ty kontrolní VLAN jely vždy.

Nebo pomocí OSPF, tam bys měl dokázat (jelikož budeš mít dva spoje nezávislé) pingat do obou zároveň ... a ovlivňovat třeba cost.

Nic jiného mě momentálně nenapadá.

salamander

Na bezdratovych spojich je prave obecne lepsi STP nepouzivat, prave pro pripad ze switchum vypadnou BPDU a zacne se prepocitavat trasa, tohle dela v siti desny bordel.

Na L3 (OSPF) to bude urcite rozumnejsi

okoun

Na chybující spoj není žádná existující technologie vhodná. Nevím o žádné, která by to dokázala vyřešit. RSTP neregistruje žádnou chybovost, reaguje na fyzický výpadek linku (a to si ještě nejsem jistý, zda u všech implementací) a na výpadky BPDU paketů (tedy vyprší timer a zajistí přepočet topologie). No a teď si představ, že ti to chybuje jen "trochu" a občas ti to přehodí linku sem tam. Nic dobrého pro síť. Vím o čem mluvím ... laser od MRV při mlze tohle dělal. Také neměl žádný threshold pro návrat do stabilního stavu.

Stejně se chová i OSPF, jen timeouty jsou delší.

Normálně se to řeší opravou toho PtP spoje ...

Zkus si ty spoje zdvojit, třeba VLANou. Scriptem pak ovlivňuj jen cost. Ale chtělo by to spíš MSTP, aby ti ty kontrolní VLAN jely vždy.

Nebo pomocí OSPF, tam bys měl dokázat (jelikož budeš mít dva spoje nezávislé) pingat do obou zároveň ... a ovlivňovat třeba cost.

Nic jiného mě momentálně nenapadá.

nu tohle právě řeší ten script, že pokud se to jednou přehodí tak už se to jentak nepřehodí zpět aby se to furt nepřehazovalo dokolečka tam i zpět, ale jak tedy donutit to rstp aby po dvou sec výpadku BPDU už to zareagovalo?

MSTP snad mikrotik neumí ne?

salamander

Nevim jak moc se da na Mikrotiku ladit age, ale imho se u RSTP pod 6sec nedostanes (3x 2s pro hello time)

okoun

Nevim jak moc se da na Mikrotiku ladit age, ale imho se u RSTP pod 6sec nedostanes (3x 2s pro hello time)

tak potom si pohrát s tím edge jak psal maiklik kdysi, ale to netuším jak naladit zatím....