Smyčky v síti?

[Petr S.]

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

Když si dám arping na určitou mac a ty budou v síti dvě, tak by mi měli odpovědět obě nebo jen jedna z nich?

[hafieror]

Z linuxu mě vždycky odpovídají obě.

UPDATE: viz níže myšleno pokud pingám jednu ip, tak odpoví dvě mac, pokud má více zařízení stejnou ip.

[Dalibor Toman]

Když si dám arping na určitou mac a ty budou v síti dvě, tak by mi měli odpovědět obě nebo jen jedna z nich?

arping pinga na IP ne na MAC. Pokud stejnou IP ma nastaveno vice zarizeni pak prijde odpovedi vic nez jedna(kazda z jine MAC) . Linuxovy arping posila prvni ping jako broadcast a dalsi uz jdou unicastem, takze na Linuxu pridjou nejprve 2 (pokud maji stejnou IP 2 zarizeni) odpovedi a pak uz chodi jen jedna

[Dalibor Toman]

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

no tak za tenhle normalni feature bych nekomu mnohokrat podekoval. Resili jsme zahadne chovani paralelnich 2 ALCOMA tras, ktere byly mezi 3ma cisco switchi (na jedne strane 1 a na druhe 2 kazdy pro jednu ALCOMU navzajem propojene ethernetem a za tim dalsi switche s Linuxem, kde se pouzival jak nativni interface tak VLAN) a proudilo tim (resp melo proudit) nekolik VLANek zakoncenych na dalsich ciscach a a bohuzel i na Linuxech. Diky tomu, ze Linux na VLAN interfacech pouziva stejnou MAC jako na fyzickem interfacu, dochazelo k tomu, ze ALCOMA dostavala stejnou MAC jedno zleva a jedno zprava (a je jedno, ze pokazde to byl packet z jine VLAN) a diky tomu chvili jeji bridge potichu packety zahazoval (nez preklopil) takze vysledkem byla zahadna ztratovost. Cele se to vyresilo premistenim mista presuseni okruhu (pro nevyvazovane VLAnky) tak aby ty MACky k ALCOMAM sly jen z jedne strany.
Ano na prvni pohled fakt stejna MAC na VKAN jako na fyzickem rozhrani nevadi. Jenze VLAN neni tunel skrze ethernet jen jej rozsiruje a tak se ty v urcitych pripadech MAC potlucou a pak je to radost hledat.
PS: Cisco pro kazdou VLAN generuje novou unikatni MAC a asi vi proc.

[Majklik]

Jakmile používám VLANy, musím mít v síti prvky, co s tím umí pracovat (sestavují forward tabulku tripletů mac:vlan:port a ne jen mac:port), jinak z toho bude problém...
Stejně blbě se chová i softwarový bridge v ROSu, když přes něj chodí víc VLAN, musí se konfigurovat samostatný bridge pro každou VLANu.
A někdy to dělá problém i v situaci, když zrovna stejná MAC nechodí v různých VLAN z různých směrů.
Pěkná zrada od té Alcomy...

Jinak s tím Ciscem a generováním unikátní MAC na každou VLAN bych to tak jistě netvrdil. Dělají to jen některé. Něco to dělá, něco ne a jde ručně mac změnit, u nečeho s tím nejde hnout. Pro nejběžnější řadu 29xx/35xx viz tabulka zde:
http://www.cisco.com/en/US/products/hw/ ... html#fixed

[Dalibor Toman]

Jakmile používám VLANy, musím mít v síti prvky, co s tím umí pracovat (sestavují forward tabulku tripletů mac:vlan:port a ne jen mac:port), jinak z toho bude problém...
Stejně blbě se chová i softwarový bridge v ROSu, když přes něj chodí víc VLAN, musí se konfigurovat samostatný bridge pro každou VLANu.
A někdy to dělá problém i v situaci, když zrovna stejná MAC nechodí v různých VLAN z různých směrů.
Pěkná zrada od té Alcomy...

ono to vetsinou nevadi (kdyz nejsou L2 smycky). IMHO by se takhle zachovala spousta dalsich bezne pouzivanych radii. Kdysi jsme si podobne nabehli u Miraclu - to radio nebylo pouzitelne v okruhu vubec, protoze po preklopeni okruhu mu expirovala bridge tabulka asi 15 minut. Tenkrat kolega vyrobil vlastni eth modul s lepsim switchovacim chipem a 100mbps eth misto 10mbps a bylo po problemu.

Pri hledani zdroje potizi - stacil by counter zahozenych packetu na te ALCOMe. Takhle me to trklo az kdyz jsme analyzovali nasnifovane packety a tam bylo videt pro ruzne VLANky z Linuxu stale stejnou MACku.

Jinak s tím Ciscem a generováním unikátní MAC na každou VLAN bych to tak jistě netvrdil. Dělají to jen některé. Něco to dělá, něco ne a jde ručně mac změnit, u nečeho s tím nejde hnout. Pro nejběžnější řadu 29xx/35xx viz tabulka zde:
http://www.cisco.com/en/US/products/hw/ ... html#fixed

ja mel na mysli MAC adresy routovanych virtualnich rozhrani (int vlan xy na L3 switchi 3560G) - tedy ekvivalent VLAN rozhrani v Linuxu. Proc bych mel menit MAC na L2 interfacu mi nejak nedochazi. Abych zmenil src MAC pro BPDUcka? Ty stejne dorazi na tu ALCOMu vzdy z jedineho smeru takze zmatek by zpusobit nemely.

[Petr S.]

Jak si mám vyložit, když mi arping na IP odpoví a hodí správnou mac, ale ping na ip už neodpoví?

[Dalibor Toman]

Jak si mám vyložit, když mi arping na IP odpoví a hodí správnou mac, ale ping na ip už neodpoví?

pricin muze byt vic. Zacal bych ti, ze bych zjistil (sniffer) zda na cilovou stranu icmp request vubec dorazi. Pokud ano, tak zdroju problemu muze byt zase vice:
- firewall, ktery zahodi bud request nebo reply packet
- ma-li zarizeni vice interfacu stejnym smerem (zalozni linky a OSPF apod), muze jit o problem s arp_announce/rp_filter (nevim jak moc se to tyka MT - ale je to v podstate Linux a tam s defaultnim nastavenim jsou potize). Prvni je treba zjistit, zda cilova stanice ma v ARP tabulce IP/MAC druhe strany.
- dalsi moznosti nema cenu asi vymyslet bez znalosti konkretniho zapojeni/nastaveni

[Majklik]

Jak si mám vyložit, když mi arping na IP odpoví a hodí správnou mac, ale ping na ip už neodpoví?

Nejběžnější případ je tne zmíněný firewall na tom koncovém krámu.

Jinak s tím Ciscem a generováním unikátní MAC na každou VLAN bych to tak jistě netvrdil. Dělají to jen některé. Něco to dělá, něco ne a jde ručně mac změnit, u nečeho s tím nejde hnout. Pro nejběžnější řadu 29xx/35xx viz tabulka zde:
http://www.cisco.com/en/US/products/hw/ ... html#fixed

ja mel na mysli MAC adresy routovanych virtualnich rozhrani (int vlan xy na L3 switchi 3560G) - tedy ekvivalent VLAN rozhrani v Linuxu. Proc bych mel menit MAC na L2 interfacu mi nejak nedochazi. Abych zmenil src MAC pro BPDUcka? Ty stejne dorazi na tu ALCOMu vzdy z jedineho smeru takze zmatek by zpusobit nemely.

Máš to v té tabulce taté rezepsáno. Musíš koukat dál, jak na 1. sloupec.

[Dalibor Toman]

Jinak s tím Ciscem a generováním unikátní MAC na každou VLAN bych to tak jistě netvrdil. Dělají to jen některé. Něco to dělá, něco ne a jde ručně mac změnit, u nečeho s tím nejde hnout. Pro nejběžnější řadu 29xx/35xx viz tabulka zde:
http://www.cisco.com/en/US/products/hw/ ... html#fixed

ja mel na mysli MAC adresy routovanych virtualnich rozhrani (int vlan xy na L3 switchi 3560G) - tedy ekvivalent VLAN rozhrani v Linuxu. Proc bych mel menit MAC na L2 interfacu mi nejak nedochazi. Abych zmenil src MAC pro BPDUcka? Ty stejne dorazi na tu ALCOMu vzdy z jedineho smeru takze zmatek by zpusobit nemely.

Máš to v té tabulce taté rezepsáno. Musíš koukat dál, jak na 1. sloupec.[/quote]

asi si nejak nerozumime. Ja tvrdim, ze 3560G ma unikatni MACky na vlan interface (ne protoze si to myslim, ale protoze se mi to na vsech co mame takhle chova) a ta tabulka to pro 3560 potvrzuje taky (i kdyz 3560 nemusi nutne byt to same co 3560G).

rtsw_xy#sh int | in EtherSVI
Hardware is EtherSVI, address is 0023.5dc9.ffc0 (bia 0023.5dc9.ffc0)
Hardware is EtherSVI, address is 0023.5dc9.ffca (bia 0023.5dc9.ffca)
Hardware is EtherSVI, address is 0023.5dc9.ffc5 (bia 0023.5dc9.ffc5)
Hardware is EtherSVI, address is 0023.5dc9.ffc6 (bia 0023.5dc9.ffc6)
Hardware is EtherSVI, address is 0023.5dc9.ffc7 (bia 0023.5dc9.ffc7)
Hardware is EtherSVI, address is 0023.5dc9.ffc9 (bia 0023.5dc9.ffc9)

[Majklik]

Tou tabulkou jsem reagoval na:

PS: Cisco pro kazdou VLAN generuje novou unikatni MAC a asi vi proc.

s tím, že se tak nechovají všechny Cisco bedny. Máš 3560G, která patří mezi ně. Některé to neumí vůbec, u některých to jde nastavit ručně.
Bohužel stále platí, že u 802.1q musím počítat s výskytem stejné MAC v různých VLANách a jak se mi obejí v síti krám, který se s tím neumí korektně vyrovnat, tak je problém připraven.