classic.ISPforum.cz

Nastavil jsem Mikrotik RB751U-2HnD tak, aby skrz něj procházelo několik VLAN přes port 1 do portu 3. Každou VLANu jsem vytvořil pod patřičným portem a nakonec tyhle dané VLANy zbridgoval. Všechno fungovalo, až do doby než se zjistilo, že po nasazení Mikrotiku přestalo fungovat propojení dál do sítě, která je za Mikrotikem. Teda přestalo. Na bránu ping šel a na další počítače taky, ale na několik z těch dvaceti počítačů pingnout chvíli šlo, chvíli ne. Nedokážu si představit, čím by to mohlo být způsobeno. Jediné, co mě napadlo a co jsem zkusil, je že jsem na Bridgích zapnul RSTP a zatím to funguje. Co si o tom myslíte?

V době výpadku bylo na Mikrotiku přes Torch vidět, že packety přes MK procházely ven, ale už se nevracely. Napadlo mě, že by to mohlo být tím, že by došlo kvůli smyčce v síti chyba v CAM tabulkách switchů. Ale to by se muselo projevovat pořád, když jsme ten mikrotik zkušebně vyloučili, bylo po problémech. Pak jsem to asi spravil až tím nastavením RSTP, ale to se dozvím zítra

Docela by mě zajímal váš názor. Díky.

Petr S. píše:Nastavil jsem Mikrotik RB751U-2HnD tak, aby skrz něj procházelo několik VLAN přes port 1 do portu 3. Každou VLANu jsem vytvořil pod patřičným portem a nakonec tyhle dané VLANy zbridgoval. Všechno fungovalo, až do doby než se zjistilo, že po nasazení Mikrotiku přestalo fungovat propojení dál do sítě, která je za Mikrotikem. Teda přestalo. Na bránu ping šel a na další počítače taky, ale na několik z těch dvaceti počítačů pingnout chvíli šlo, chvíli ne. Nedokážu si představit, čím by to mohlo být způsobeno. Jediné, co mě napadlo a co jsem zkusil, je že jsem na Bridgích zapnul RSTP a zatím to funguje. Co si o tom myslíte?

V době výpadku bylo na Mikrotiku přes Torch vidět, že packety přes MK procházely ven, ale už se nevracely. Napadlo mě, že by to mohlo být tím, že by došlo kvůli smyčce v síti chyba v CAM tabulkách switchů. Ale to by se muselo projevovat pořád, když jsme ten mikrotik zkušebně vyloučili, bylo po problémech. Pak jsem to asi spravil až tím nastavením RSTP, ale to se dozvím zítra

Docela by mě zajímal váš názor. Díky.

L2 smycka muze vzniknout tam , kde se muze packet ktery odejde jednim rozhranim muze vratit do stejneho zarizeni jinym rozhranim. Mas tam opravdu takovehle zacykleni? Po nasazeni (R)STP by v pripade smycky melo byt nekde videt, ze Spanning tree prerusil smycku (popravde nevim jak se to na MT pozna - vzdy jsem tuhle praci radsi sveril Ciscu)

Nerozumim vyrazu 'a nakonec tyhle VLAN zbridgeoval' - navozuje to dojem, ze jsou vsechny vlanky v jednom bridge. To mi nejak nedava smysl.

Bez nejakeho schematu Ti tezko nekdo urci co se tam muze dit..

No právě, že tam nikde nic takovýho nemám, ale vypadá to, že RSTP pomohlo, což nechápu...

To jak jsem o tom mluvil jen znamenalo tohle: eth1 - vlan 1 - bridge 1 - vlan1 - eth3 . Udělal jsem bridge mezi vlanama připojených k těmhle dvou portům. Schéma zkusím zítra pořešit

Petr S. píše:No právě, že tam nikde nic takovýho nemám, ale vypadá to, že RSTP pomohlo, což nechápu...

To jak jsem o tom mluvil jen znamenalo tohle: eth1 - vlan 1 - bridge 1 - vlan1 - eth3 . Udělal jsem bridge mezi vlanama připojených k těmhle dvou portům. Schéma zkusím zítra pořešit

to je jasny - ale psal jsi , ze tam je nekolik VLAN a uz neni jasny jestli jsou vsechny take v tom stejnem bridge nebo ma kazda vlan svuj bridge

Každá má svůj bridge. Nebylo to z mého příspěvku zřejmé, pravda..

Lepší je smyčka, která vrací ty pakety do STEJNÉHO zařízení STEJNÝM portem. Běžné STP bez explicitní detekce loopback-detection to nevyřeší (alespoň dle mojich zkušeností).

Dalibor Toman píše:L2 smycka muze vzniknout tam , kde se muze packet ktery odejde jednim rozhranim muze vratit do stejneho zarizeni jinym rozhranim.

ludvik píše:Lepší je smyčka, která vrací ty pakety do STEJNÉHO zařízení STEJNÝM portem. Běžné STP bez explicitní detekce loopback-detection to nevyřeší (alespoň dle mojich zkušeností).

Dalibor Toman píše:L2 smycka muze vzniknout tam , kde se muze packet ktery odejde jednim rozhranim muze vratit do stejneho zarizeni jinym rozhranim.

STP nevyresi ani 'jednosmerne' linky v kruhove topologii (FDD radiove trasy tohle 'umi'). Vracet packety zpatky stejnym dratem, zase obcas umi Mikrotik.

Já si i myslím, že vyloženě klasickou L2 smyčku neudělal. Kdyby jo, tak si i všimne, že mu tam začne lítat tuna provozu v kruhu, a to RBčko by mělo porty a CPU na prášky.

Máš někde v síti dál prvky s aktivním STP/RSTP? Pokud určitě ne, tak se ze stavu RSTP na tom bridge se dá usuzovat, zda tam máš L2 smyčku přes víc portů. Pokud pro všechny porty na tom bridge bude /interface bridge port monitor tvrdit, že to je designated port, tak to smyčku nevidí (ale to plaít jen, když nebude jiné STP/RSTP zařízení v síti).

Máš všechny switche/zařízení přes ktere jdou ty VLANy s podporou VLAN nebo něco je třeba jen tupý switch? Potom jde i o to, že ROS neumí na 100% korektně na bridge spolupracovat s VLANama. Ale ta konfigurace co VLAN, to bridge, by měl problém tohoto typu celkem snižovat. Hodně věcí umí napravit to, pokud na každý takovýto bridge dáš ručně nastavit jedinečnou admin-mac adresu, která bude různá od ostantích bridgů a také od MAC adres těch fyzických portů. Tohle umí opravit spoustu podivností.

Info zjistím. Žádnej tupej switch by tam být neměl, ale radši to ověřím. Jinak jediný, co bylo znát na MK bylo to, že přes mikrotik odcházeli požadavek na ping ale už se nevracely. Zatížení cpu bylo stejné, tedy v pohodě.

Admin MAC adresu můžu dát jakoukoliv, kterou si vymyslím?

MAC adresa může být skoro cokoliv, musí být ale jedinečná v rámci dané L2 domény. Pro zachování funkcčnosti/kostelního pořádku nultý bit v nejvyšším bajtu musí být 0 (přiznak unicast/multicast) a první bit by měl být 1 (příznak lokálně přidělovaných MAC adres).
Takže třeba dávám MACky 02:00:ac:d, kde to a.b.c.d je haxa IPv4 adresa daného portu. Hlavní router v daném segmentu má obvykle 02:00:00:00:00:01, což se hodí i kvůli jednoduchému zápisu link-local IPv6 adres a psaní statických rout na LL adresy.

Důležité je, zda ten požadavek na ping odcházel z MK z toho bridge tím správným portem ven a ne nějakým jiným... V tomhle má občas MKčko problém v kombinaci bridge/VLAN.

No a jak můžu ověřit, že to odejde tím konkrétním portem? V tom mi asi torch nepomůže... Nějaká ochrana proti tomu, aby k tomu nedocházelo je?

Mrkni do /interface bridge host print
Tam vidíš, jakou forwardovací tabulku RB aktuálně má. Je žádoucí, aby cílová MAC u daného bridge byla na správném odchozím portu. Případně se podívat, zda dnaé MAC se nevyskytuje ve vícero bridgích na různých fyzických portech. Pokud není aktivně používáno MSTP, tak obvykle by v různých bridgích neměla MAC adresa smrdělt na různých fyzických portech, když se používá VLANování (ale jsou i konfigurace, kde tomu může být, ale není to nejběžnější stav).
Samozřejmě se adresa nesmí stěhovat z portu na port a podobné vylomeniny.

Tak bude problém určitě někde na těch Bridge. Jakmile jsem tam zadal administrační MAC adresu, tak se problém začal opět projevovat (stejně jako předtím, když jsem měl vypnuté RSTP). Teď bylo RSTP vypnuté a nastavené adm. MAC a nešlo to zase. Jakmile jsem použil MAC adresy portů z defaultu, tak bylo opět po problému.

Petr S. píše:Tak bude problém určitě někde na těch Bridge. Jakmile jsem tam zadal administrační MAC adresu, tak se problém začal opět projevovat (stejně jako předtím, když jsem měl vypnuté RSTP). Teď bylo RSTP vypnuté a nastavené adm. MAC a nešlo to zase. Jakmile jsem použil MAC adresy portů z defaultu, tak bylo opět po problému.

BTW: nevim jakym zpusobem generuje MT MAC adresy pro VLAN rozhrani. Ale pokud pouzili stejne debilni ""nahodny"" algoritmus jako u EoIP tak muze nastat situace, kdy na nekolika zarizenich je stejna MAC. U EoIP obcas dokonce i po prostem rebotu/vypnuti/zapnuti zarizeni nekdy dojde k vygenerovani nove MACky a pokud se trefi do jiz v siti existujici, tak vznikaji 'zajimave' potize. Vetsinou se to nastesti projevi tak, ze zarizeni prestane odpovidat na TCP/IP. Detekce je pak vetsinou snadna - arping (kolik zarizeni a jak odpovidaji) a inspekce arp (stejna MACka u vice IP) tabulky na brane

VLANa přebírá jako svoji MAC adresu od nadřazeného interface. Což je normální a fakticky nemá ničemu vadit, že stejná MAC je v X VLANách - podmíka je, že přes všechny prvky, kde se VLANy šíří, musí umět s VLANama pracovat (občas něktěří chytráci propouští VLANový provoz přes switch, co VLANy neumí, ono to na pohled funguje OK, dokud nenastanou některé specifické případy nebo někdo toho záměrně nevyužije - a bohužel ROS s ena bridgi chová stejně blbě jako neVLAN switch).
Jedna ze zrad nastává, pokud se VLANa umístí nad bridge. Brige si normálně vezme jako svoji MAC adresu prvního aktivního interface, takže pokud vyškubnu port, tak se změní MAC na bridge, což VLANy nad tím trošku rozhodí. Hlavně pokud se VLAN nahodí ve chvíli, kdy ješt brirge žádnou MAC nemá (nemá aktivní interface). Proto je vhodnější u takových CFG tam dávat admin MAC natvrdo, ať se takovým atentátům předejde.

Je otázka, co tam má fakt nastaveno. Ale třeba dobrý atentát bývá, pokud ten bridge nefunguje jen jako L2, ale mám na něm i IP adresu a routuji na něm, tak pokud je IP nad portem (který je členem bridge) a ne tou vlastím bridge, to pak se jeví tak, že najednou část sítě funguje/nefunguje a podobné.