EtherChannel, Bonding nepracuje podla predstavy

[zvukarmiso]

Ahojte mám nasledovný problém:

Poskytovatel služby má zariadenie ukončene 10Gbps portom. Zariadenie je Cisco 4500. Od neho nám ide optika cca 80km do nášho mikrotiku. Všetko funguje ako ma. V poslednej dobe nám stupa vyťaženie linky. tak sme sa rozhodoli, že vymenime DX Gbic za SX GBIC WDM (z dvoch na jedno vlákno). Stále mám pocit že to viac ako 1Gbps nedá. Vymenil som Mikrotik za Cisco 3650, ale stále ten istý problém.

Rozhodol som sa zapožičat si meraký EXFO na meranie priepustnosti siete. A tie mi ukazuju stale len 1Gbps.
Existuje nejaké riesenie ?
Bonding - skusil som asi vsetky nastavenia ani s jedným to neslo.
EtherChannel - opat som vyskusal všetky nastavenia ale aj tak nic. Stale to ide len 1Gbps

Dokonca som nasiel aj taketo nejaké info (co sa mi troska nepozdáva):
Etherchannel technológia využíva vždy loadbalancing, bez ohľadu na to ci je to PAgP, LACP alebo napevno zapnutý etherchannel.
Zmyslom Etherchannelu je okrem iného zvýšiť šírku prenosového pásma (bandwidth 2x1Gbps=2Gbps), ale priepustnosť (throughput) je vždy len 1Gbps

Ako to riesite vy ? Máte nejaký nápad ako to poriešit ?
Ďakujem

S pozdravom Michal

[iTomB]

No pokud mas privod v 10G, tak bych to protahnul dal a neresil down na 1G a pak to nejak spojovat ... Proste 10G az na konec.

[Dalibor Toman]

pokud se meri propustnost na bondu/etherchannelu/portchannelu/dosad_nazev_podle_vyrobce je potreba si uvedomit jak to spojovani linek vlastne funguje. Bez premysleni si muzes rict: jeden packet do prvni linky druhy do druhe atd. Jenze takhle by vznikl problem s predbihanim packetu (ktery nektere protokoly neumi resit). Takze se pouziva nejaky mechanismus, ktery zajisti, ze packety, ktere patri k sobe pobezi vzdy stejnou linkou (to zaruci ze vylezou ve stejnem poradi v jakem prisly). Jak se to zaridi lze obvykle nastavit hashovanim podle src/dst MAC, IP atd). Dusledkem ale je, ze pri mereni rychlosti nejakym obvyklym zpusobem, pobezi mereni vzdy jen jednou z tech spojenych linek. Takze pokud jsou bondovane 1gbps linky, vic jak 1gbps test neukaze. Aby ukazal vic, muzel by na kazde strane pouzit vic IPcek (ci MACek). A jeste by musel mit kliku, aby se trefil do hashovaci funkce tak, aby vysly ruzne hashe.

[Dalibor Toman]

a tu 3650 bych obesel velkym obloukem nebo daroval nejakemu nepriteli. Jestli se neco za poslednich par let nezmenilo (tj nezmenil se HW), tak tenhle switch nema temer zadne buffery. A ty by se zrovna v situaci, kdy ti prichazi data 10gbps interfacem a odchazi 1gbps doost hodily. Doporucuju nastavit QoS (ne kvuli prioritam ale kvuli prideleni bufefru na port ale ono to stejne skoro nepomuze) a kontrolovat discard countery - pokud uz je 3650 umi pocitat a publikovat do SNMP tak kreslit graf, jinak alespon "sh platform qos queue config gigabitEthernet XY"

[zvukarmiso]

Linku neviem prehodit na 10Gbp - nedovoluje mi to dlzka trasy a utlm na trase. To som skusal bola tam velka chybovost.

Tu 3650 mam zapozicanu na testovanie

pokud se meri propustnost na bondu/etherchannelu/portchannelu/dosad_nazev_podle_vyrobce je potreba si uvedomit jak to spojovani linek vlastne funguje. Bez premysleni si muzes rict: jeden packet do prvni linky druhy do druhe atd. Jenze takhle by vznikl problem s predbihanim packetu (ktery nektere protokoly neumi resit). Takze se pouziva nejaky mechanismus, ktery zajisti, ze packety, ktere patri k sobe pobezi vzdy stejnou linkou (to zaruci ze vylezou ve stejnem poradi v jakem prisly). Jak se to zaridi lze obvykle nastavit hashovanim podle src/dst MAC, IP atd). Dusledkem ale je, ze pri mereni rychlosti nejakym obvyklym zpusobem, pobezi mereni vzdy jen jednou z tech spojenych linek. Takze pokud jsou bondovane 1gbps linky, vic jak 1gbps test neukaze. Aby ukazal vic, muzel by na kazde strane pouzit vic IPcek (ci MACek). A jeste by musel mit kliku, aby se trefil do hashovaci funkce tak, aby vysly ruzne hashe.

takže toto neplati ?
Zmyslom Etherchannelu je okrem iného zvýšiť šírku prenosového pásma (bandwidth 2x1Gbps=2Gbps), ale priepustnosť (throughput) je vždy len 1Gbps

Podľa mna mi to netecie viac ako 1Gbps. ako by som to vedel otestovat ?

[ludvik]

On to vlastně řekl Dalibor. Pokud je tam etherchannel s hashem na L2, tak ti to nikdy víc jak jednu linku nevytíží - na obou koncích je stejná MAC a pořád stejná. Hash musí být alespoň dle IP. Problém je spíš v tom, že to někde nastavovat lze (třeba u softwarových, např. na mikrotiku), někde ne ... a že nevím, co vlastně používá LACP.
Jednoduše to poznáš přeci na counterech těch portů, jak jsou jednotlivě vytížené.

[cerva]

Líbí se mi exaktnost popisu problému a způsobu měření Problém tipuju na špatnou metodiku měření a nebo nevhodně nastavenou hashovací funkci - ve tvém případě potřebuješ pravděpodobně nejlépe L3 + L4, ne L2, pokud tím na konci odděluješ svou síť.

[zvukarmiso]

Metodika mozno nie je spravna ale dam si poradit.

Moje otazka
Konfiguracia EtherChannel ( desirable, active, on) ???

To meranie skusim viacej googliť. možno niečo najdem.

[Dalibor Toman]

Linku neviem prehodit na 10Gbp - nedovoluje mi to dlzka trasy a utlm na trase. To som skusal bola tam velka chybovost.

pokud funguje 1gbps tak musi IMHO fungvat i 10gbps. Alespon utlum na to vliv mit nebude.

takže toto neplati ?
Zmyslom Etherchannelu je okrem iného zvýšiť šírku prenosového pásma (bandwidth 2x1Gbps=2Gbps), ale priepustnosť (throughput) je vždy len 1Gbps

Podľa mna mi to netecie viac ako 1Gbps. ako by som to vedel otestovat ?

proste si to predtav zjednodusene tak ze liche IP adresy jdou vlevo a sude vpravo. Takze pri testu prenosovky jednim TCP spojenim to jinudy nez jednou linkou bezet nemuze. A pokud zarizeni neumi nastavit jine hashovani nez L2 (mac) ci L3 (IP) pak abys vytizil obe linky musis mit 2 TCP spojeni a pousit lichou a sudou adresu. A aby to nebylo tak jednoduche tak ten bond ma 2 konce a na kazdem to hashovani muze byt nastaveno jinak. POkud umi zarizeni do hash funkce zaradit i cislo TCP/IP portu, pak muzes prenaset mezi 2ma ipcky 2me TCP spojenimi a pokud se porty trefi tak, ze kazde spojeni pobezi jinou linkou tak je vytizis obe .


u cisca pouzivam 'src-dst-ip'. L4 bohuzel ty zarizeni, co mame neumi.

port-channel load-balance ?
dst-ip Dst IP Addr
dst-mac Dst Mac Addr
src-dst-ip Src XOR Dst IP Addr
src-dst-mac Src XOR Dst Mac Addr
src-ip Src IP Addr
src-mac Src Mac Addr

[ludvik]

https://www.samuraj-cz.com/clanek/pripo ... ehlivejsi/

[ocior]

Linku neviem prehodit na 10Gbp - nedovoluje mi to dlzka trasy a utlm na trase. To som skusal bola tam velka chybovost.

pokud funguje 1gbps tak musi IMHO fungvat i 10gbps. Alespon utlum na to vliv mit nebude.

80km bude mit utlum do cca 18dB, coz neni pro 80km modul problem, ten ma PB 24dB.

Zadrhel, kdy jede 1G a nejede 10G by mohl byt v chromaticke dispersi. Ten modul bude zvladat cca 1600ps/nm a to uz muze byt pri 80km na hrane. Ale mame nasviceno i 110km bez kompenzace, tam uz je EDFA kvuli utlumu. Kompenzovat znamena dalsi vlozeny utlum. Daji se sehnat i 10G moduly na 100-120km, ale nikdy jsem je nepouzil.

Spis bych tipoval na spatny vyber modulu. Souhlasim s tim, ze bych se drzel 10G nez to bondovat.

Kdybys to chtel doresit, tak 10G EXFO na ethernet mame a 80km 10G modulu bych nasel taky dost.

[hapi]

v běžnym LACP mezi dvěmi body nedosahneš 2x větší propustnosti. Tohle umí jenom softwarově mikrotik kterej má round-robin rozdělování paketů a tam už to celkem funguje ale nešel bych do toho pokud vyloženě nemusim a šel bych do 10Gbit. Pokud by to byl extra problém tak bych si spíš našel mediakonvertory na 2.5 nebo 5Gbit který by to snad už daly.

[rsaf]

Pokud se 1gbps překračuje jen těsně, měl by etherchannel fungovat bez problémů. Výhoda proti 10gbps je i jistá redundance (modulu, vlákna, pokud by se použily switche ve stacku tak i toho switche..). U Cisca je potřeba dát do konfigurace něco jako port-channel load-balance src-dst-ip. Přes SNMP pak sledujte provoz na jednotlivých portech toho bondu a pokud po každém poteče řádově polovina provozu, je to ok.

[zvukarmiso]

80km bude mit utlum do cca 18dB, coz neni pro 80km modul problem, ten ma PB 24dB.

Zadrhel, kdy jede 1G a nejede 10G by mohl byt v chromaticke dispersi. Ten modul bude zvladat cca 1600ps/nm a to uz muze byt pri 80km na hrane. Ale mame nasviceno i 110km bez kompenzace, tam uz je EDFA kvuli utlumu. Kompenzovat znamena dalsi vlozeny utlum. Daji se sehnat i 10G moduly na 100-120km, ale nikdy jsem je nepouzil.

Spis bych tipoval na spatny vyber modulu. Souhlasim s tim, ze bych se drzel 10G nez to bondovat.

Kdybys to chtel doresit, tak 10G EXFO na ethernet mame a 80km 10G modulu bych nasel taky dost.

Cely problém je v trase. Podla OTDR je útlm trasy okolo 21,7 dB. Je tam veľa patchpanelov a prepojov. Máme to riešené komplikovane. Na trase si prenajímame vlákna ešte od iných, aby sa nám podarilo dostať k nášmu bodu. Proste 10Gbps modul nepomohol ci bol aj na 120km, nebudem špekulovať skúsim sa potrapit s tým EtherChannelom. Edfu mi zatiaľ dodávateľ nechce dovoliť umiestniť k nemu.

Pokud se 1gbps překračuje jen těsně, měl by etherchannel fungovat bez problémů. Výhoda proti 10gbps je i jistá redundance (modulu, vlákna, pokud by se použily switche ve stacku tak i toho switche..). U Cisca je potřeba dát do konfigurace něco jako port-channel load-balance src-dst-ip. Přes SNMP pak sledujte provoz na jednotlivých portech toho bondu a pokud po každém poteče řádově polovina provozu, je to ok.

Moja Konfigurácia je nasledovná

Kód: Vybrat vše

Switch# show etherchannel summary
Flags:  D - down         P - bundled in  port-channel
        I -  stand-alone s - suspended
        H - Hot-standby (LACP only)
        R  - Layer3      S -  Layer2
        U - in use       f - failed to allocate  aggregator
        M - not in  use, minimum links not  met
        u - unsuitable for  bundling
        w - waiting to be  aggregated
        d - default  port
Number of channel-groups in use: 2
Number of aggregators:            2

Configuring EtherChannel
Group   Port-channel  Protocol     Ports
------+-------------+-----------+-----------------------------------------------
1       Po1(SU)          LACP       Gi0/2(P)   Gi1/3(P)
Switch#
 
interface Port-channel1
 switchport mode access
 switchport access vlan 10
 no ip address

 
interface gigabitethernet 0/2
 channel-group 1 mode active
                             
interface gigabitethernet 0/3
 channel-group 1 mode active   


Ako by som to mal opraviť aby to bolo srpávne ? Ďakujem

[ocior]

Cely problém je v trase. Podla OTDR je útlm trasy okolo 21,7 dB. Je tam veľa patchpanelov a prepojov. Máme to riešené komplikovane. Na trase si prenajímame vlákna ešte od iných, aby sa nám podarilo dostať k nášmu bodu. Proste 10Gbps modul nepomohol ci bol aj na 120km, nebudem špekulovať skúsim sa potrapit s tým EtherChannelom. Edfu mi zatiaľ dodávateľ nechce dovoliť umiestniť k nemu.

Nejste schopni tu trasu rozdelit na cca poloviny, kdyz to mate takhle skladane? Stejne vam tech 2x1G casem prestane stacit a budete se brzy vracet k reseni 10G nebo 4x1G.
Namereny utlum na OTDR je na jake vlnove delce? Jake byly urovne prijimaneho signalu na obou stranach? Tech 22dB uz je potiz, on vyrobce sice rad udava PB 24-25dB, ale taky rika, ze pro BER 10E-12 to bude treba jen 22-23dB. SFP+ 10G na 100-120km maji skoro stejny PB, jen jsou odolnejsi k dispersi.