Cisco Etherchannel és Linux Bonding

hello

az mért van hogy ha Cisco oldalon Etherchannel konfigolva van akkor a Linux bonding csak round-robin-al akar működni normálisan és az active-passive konfiguráció csak 1 csomagot küld. Komolyan, egyetlen egy ICMP pinget kaptam vissza.

Hozzászólások

Cisco etherchannel jo esellyel lacp-t takar (802.3ad), azt kellene beallitanod linux-on (bond mode 4).

Csak annyi, hogy a mode1-et _nem_ etherchannel-es switchkonfigban _kell_ használni, hanem a switchen csak két normál access portot kell konfigolni. (így lehet akár két külön switchen - azonos vlan-ban persze - switchredundanciát is biztosítani).
Etherchannelhez a round-robin kell, az LACP pedig külön téma, ott a switch is lerakja suspended-be a portot, ha nem kap LACP PDU-t a linux hosttól (pl olyan hálókártya hiba, amikor a link nem megy down-ba, csak megszűnik a kerettovábbítás.)

Személy szerint LACP-t tudok javasolni stack-elt switchpáron kialakított port-channel interfésszel.

ciscon az interfacen:
channel-group 1 mode active

az show port-channel summary meg mutatja hogy milyen protocol (none vagy lacp), regi ciscokon show ether-channel summary.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

dup

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Csatlakozva az előttem szólóhoz: milyen etherchannel?
Nálam lacp etherchannel-lel (mode active) jól működött linux alatt a 802.3ad bonding, csakúgy mint Windows XP és Windows 7 alatt az Intel teaming és Broadcom NetXtreme kártyával pedig a BACS.
Linux alatt korábban voltak olyan tapasztalataim, hogy a modul betöltésnél egyes kernelek nem voltak hajlandóak tudomásul venni az átadott paramétereket. Érdemes megnézni a /proc/net/bond-ban, hogy biztos azok-e a beállítások, amikre gondoltál. Windows alatt korábban az viccelt meg többször, hogy hiába volt az első dolgok között, hogy kikapcsoljam az alvó állapotot, valaminek a telepítése vagy valami frissítés mégis visszaállította. Amikor pedig elment aludni, akkor a switch interface konfigtól függően ezt akár azzal tolerálta, hogy huzamosabb ideig letiltotta az interface-t és kézzel kellett machinálni, hogy helyre álljon a rend és életre keljen a port...
Ha játszadozol a jumbo frame-mel, akkor oda kell figyelni, hogy stimmeljenek a beállítások a két linken, változtatás esetén pedig megszakadhat a forgalom.
show lacp neighbour
show lacp internal
show etherchannel summary
show logging

Majdnem úgy olvastam a nick-ed, hogy: juniper2005ster... ;-)

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Mondjuk a kérdező aktív-backup módot szeretne használni, ismétlem, ahhoz nem szabad etherchannelt használni!!!
A switchen két sima access port kell ugyanabban a vlanban és csá.

köszönöm a válaszokat. végül is elfogadtuk a round-robin módot
mint később kiderült az active-passive nem pálya mert az idő amíg a rendszer felismeri h az elsődleges útvonal nem megy az túl sok kiesés az alkalmazásnak. Ezért is lett etherchannel cisco oldalon.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Cisco switch egy régi 4948-10GE.
Egyik vas egy Dell R610, Debian 8, másik egy DELL PE1950, Debian 7.

Cisco: mindkét géphez 2-2db port van összefogva.
Az iface-eken az ide vonatkozó sor: channel-group 1 mode active

Az egyik portchannel:
Port-channel: Po1 (Primary Aggregator)

------------
Age of the Port-channel = 188d:15h:32m:10s
Logical slot/port = 11/1 Number of ports = 2
Port state = Port-channel Ag-Inuse
Protocol = LACP
Port security = Disabled

Ports in the Port-channel:

Index Load Port EC state No of bits
------+------+------+------------------+-----------
0 00 Gi1/47 Active 0
1 00 Gi1/48 Active 0

Time since last port bundled: 0d:00h:48m:36s Gi1/48
Time since last port Un-bundled: 0d:00h:48m:40s Gi1/48

Linux-okon is jónak tűnik minden:
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2+3 (2)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 2
Actor Key: 17
Partner Key: 4

A két linux között mérek IPERF-el sebességet, akár 10, akár 20 kapcsolati szálon, de csak kb.940Mbps tudok összehozni. Mintha nem fogná össze mégsem az ethernet portokat.

Nézz utána a hash policyknak.

Layer 3 hashelés esetén két IP cím között a forgalom mindig ugyanazon a linken fog haladni. (Az IP cím vége alapján dönti el, hogy melyik interfészt használja. Két interfész esetén a páros és a páratlan végű IP címek fognak külön-külön interfészen kommunikálni.)

Layer 4 hashelés esetén bejönnek még a képbe a TCP/UDP portok, tehát két gép között is kihasználható lehet az aggregált linksebesség, de csak külön TCP/UDP portokon, több szálon.

Emlékeim szerint (közvetlenül összekötött) Linuxos gépek között lehet valami proprietary megoldással valódi round-robin terheléselosztást csinálni, ahol egy TCP adatfolyam is képes aggregált sebességgel hasítani.

"lehet valami proprietary megoldással valódi round-robin terheléselosztást csinálni, ahol egy TCP adatfolyam is képes aggregált sebességgel hasítani."

ez az, amit nem akarsz csinalni, mert az out of order csomagok kinyirjak a performanszt :)

--
NetBSD - Simplicity is prerequisite for reliability

"Mintha nem fogná össze mégsem az ethernet portokat."
"Transmit Hash Policy: layer2+3"

Igy nem is fogja neked 2 gep kozott, layer4-el (amennyiben switchen is be van allitva) es ha iptraf tobb szalhoz eltero portokat hasznal vagy kulon inditasz tobbet akkor mukodhet. Vagy hasznalj tobb gepet/ip-t.