Wpisy otagowane ‘LACP’

LACP – errata

poniedziałek, 27 Kwiecień 2009

3COM LACPTo co napisałem i narysowałem wcześniej nie do końca jest prawdą. Otóż LACP działa pomiędzy dwoma urządzeniami spiętymi bezpośrednio. Wyjątkiem są przełączniki, które można połączyć w logiczną całość, ale ja takowych nie posiadam. Wcześniej robiłem konfigurację tylko po stronie serwerów, ale to nie wystarczy (mimo, że działało jako tako). Trzeba po drugiej stronie też odpowiednio poustawiać.

Nie wiedzieć czemu jedne serwery raportują połączenie 2 Gbps (przy dwóch kartach), inne tylko 1 Gbps. Prawdopodobnie zależy to od sterownika. Te które mogą więcej to na pewno Intel PRO/1000 EB, te które nie mogą (lub po prostu ja nie wiem jak je zmusić do takiego działania) to:

  • Intel PRO/1000 PM + Intel PRO/1000 PL (serwery Actina z płytami SuperMicro mają różne karty, więc może to być powodem; poza tym ta pierwsza nie wspiera Jumbo Frames),
  • Broadcom BCM5708C NetXtreme II GigE.

Jeśli ktoś wykorzystuje obie karty do dwóch różnych sieci, też może korzystać z LACP. Zawsze w parze z tym idzie VLAN, więc pierw spinamy karty razem, a potem je dzielimy.

Logi z operacji spinania przełączników poniżej:

2009-04-16 14:50:53     generic     information     INFO - LACP: Trunk group 1 created with ports=25, aggregator id=1024, partner system=32767,00:22:57:45:D8:A0, actor oper key = 26436, partner oper key = 14881
2009-04-16 14:50:55     generic     information     INFO - LACP: Trunk group 1 updated with ports=1,25 for aggregator 1024

2009-04-16 14:50:49     generic     information     INFO - LACP: LACP is disabled on port 16
2009-04-16 14:50:49     generic     information     INFO - LACP: Trunk group 1 removed for aggregator 1039
2009-04-16 14:50:50     generic     information     INFO - LACP: Fixed group ID for port 16 set to -1
2009-04-16 14:50:50     generic     information     INFO - LACP: Fixed group ID for port 16 set to 0
2009-04-16 14:50:50     generic     information     INFO - LACP: Fixed group ID for port 39 set to 0
2009-04-16 14:50:50     generic     information     INFO - LACP: LACP is enabled on port 16
2009-04-16 14:50:50     generic     information     INFO - LACP: LACP is enabled on port 39
2009-04-16 14:50:53     generic     information     INFO - LACP: Trunk group 1 created with ports=39, aggregator id=1039, partner system=32767,00:22:57:45:D6:A0, actor oper key = 14881, partner oper key = 26436
2009-04-16 14:50:55     generic     information     INFO - LACP: Trunk group 1 updated with ports=16,39 for aggregator 1039
2009-04-16 14:50:56     generic     information     INFO - RSTP: Set Port Parameters: Admin Path Cost, Value: 0
2009-04-16 14:50:56     generic     information     INFO - RSTP: Set Port Parameters: Admin Path Cost, Value: 0
2009-04-16 14:50:56     generic     information     INFO - LACP: Trunk group 1 updated with ports=16 for aggregator 1039
2009-04-16 14:50:56     generic     information     INFO - LACP: Trunk group 1 updated with ports=16,39 for aggregator 1039
2009-04-16 14:50:56     generic     information     INFO - RSTP: Set Port Parameters: Admin Path Cost, Value: 0
2009-04-16 14:50:58     generic     information     INFO - RSTP: Set Port Parameters: Admin Path Cost, Value: 0

LACP + RSTPOK, skoro LACP to tylko połączenia bezpośrednie, w takim razie przełącznik nadal pozostaje single point of failure. Owszem, ale można rozwiązać to np. za pomocą (R)STP.

W mojej sieci RSTP wyniknęło samo z siebie. Bez żadnych planów osób przeciągających kable. Niektóre idą z poziomu 0 na 2 bezpośrednio, niektóre przez duże przełączniki na piętrach. Taka wolna amerykanka. Oczywiście nie ma tego złego, co by na dobre nie wyszło. Wykorzystałem bałagan dla zwiększenia niezawodności sieci :>
Ciągle mamy newralgiczne połączenia, ale staram się to eliminować.
Przykładowy log RSTP (prawdopodobnie restart jednego z przełączników):

2009-04-17 07:08:17 warning %LINK-W-Down: 19
2009-04-17 07:08:17 warning %LINK-W-Down: 13
2009-04-17 07:08:17 warning %LINK-W-Down: 12
2009-04-17 07:08:17 warning %LINK-W-Down: 20
2009-04-17 07:08:18 information %LINK-I-Up: 19
2009-04-17 07:08:19 information %LINK-I-Up: 12
2009-04-17 07:08:19 information %LINK-I-Up: 20
2009-04-17 07:08:19 information %LINK-I-Up: 13
2009-04-17 07:08:48 warning %STP-W-PORTSTATUS: 19: STP status Forwarding
2009-04-17 07:08:49 warning %STP-W-PORTSTATUS: 12: STP status Forwarding
2009-04-17 07:08:49 warning %STP-W-PORTSTATUS: 20: STP status Forwarding
2009-04-17 07:08:49 warning %STP-W-PORTSTATUS: 13: STP status Forwarding

Tak jak wszystko, warto takie rzeczy dobrze zaplanować od podstaw. Choć operacje na otwartym sercu mają swój urok ;-)

Swoją drogą chciałbym kiedyś trafić do takiej sieci bez dokumentacji w czasie awarii jednego z przełączników.

Tagi:, , , ,
Zaszufladkowany do Tech | 5 komentarzy »

IEEE 802.3ad

środa, 18 Marzec 2009

15:07 <@s1m0n> guzik: widze, ze tez ostro sie wkrecasz w macierze;]
15:09 <@s1m0n> MPIO i JF widze juz ruszyles, moze zainteresuje cie tez LACP - http://en.wikipedia.org/wiki/Link_aggregation

W sumie – czemu nie. Choć początkowo myślałem, że link aggregation robi się tylko celem zwiększenia prędkości połączeń, ale okazało się, że jestem gdzieś w tyle i w ogóle niedouczony. IEEE 802.1AX-2008 (IEEE 802.3ad) oprócz możliwości użycia wielu portów / kabli równolegle celem zwiększenia prędkości połączenia pozwala na redundancje tychże połączeń.

lacp_broadcom01No to ziu! Upewniłem się, że przełączniki wspierają LACP (3Com 2924-SFP Plus, 3Com 2948-SFP Plus). Wziąłem pierwszy z brzegu serwer (maszyna, która się jeszcze ‘wygrzewa’) – ma dwie karty Broadcom 5708C. Standardowy sterownik z Windows 2003 (4.4.11.0) zaktualizowałem do 4.6.15.0. Zainstalowałem oprogramowanie do zarządzania – Broadcom Advanced Control Suite 11.6.10.0 (wymaga .NET Framework 2.0), bo Windows 2003 (podobno) nie wspiera natywnie LACP. Stworzyłem odpowiedni team i działa:

C:\Documents and Settings\Administrator>ipconfig
Windows IP Configuration
Ethernet adapter Team 1:
Connection-specific DNS Suffix  . :
IP Address. . . . . . . . . . . . : 192.168.1.200
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.176

lacp_intel01Pełen zapału wziąłem się za serwer produkcyjny (zdalnie!) z kartami Intel(R) PRO/1000 PM i Intel(R) PRO/1000 PL (ta pierwsza nie wspiera Jumbo Frames). Niestety po połączeniu ich maszyna przestała odpowiadać. Już lokalnie sprawdziłem, że nowy interfejs ma adres nadany przez APIPA (169.254/16). Być może przepisał go z drugiego interfejsu, który w momencie konfiguracji był wyłączony. Broadcom przepisał adres z karty oznaczonej jako Primary. No ale ostatecznie zadziałało i mogłem potestować.

lacpNie sprawdzałem obciążenia, bo nigdy nie było to wąskim gardłem w naszej sieci. Testowałem losowe wypinanie kabli i wypadło nieźle, ale nie niezauważalnie. Może to przypadek, ale przepinanie z Primary na Secondary idzie szybciej niż w drugą stronę. Wpinanie dwóch kart do jednego przełącznika z punktu widzenia SPOF nie ma sensu, ale przełączanie ruchu pomiędzy interfejsami jest w takim przypadku oczywiście szybsze niż gdy karty są wpięte do różnych przełączników w kaskadzie (testowałem w środowisku jak na schemacie obok).

Nie testowałem agregacji w innych systemach operacyjnych, ale na pierwszy rzut pójdzie wkrótce Linux (bonding).

Symbol: BONDING [=n]
Prompt: Bonding driver support
Defined at drivers/net/Kconfig:60
Depends on: NET && INET
Location:
-> Device Drivers
-> Network device support

Na stworzonych team‘ach można tworzyć VLAN’y, więc mimo połączenia dwóch (lub więcej) kart ruch można potem rozdzielić.

Tagi:, ,
Zaszufladkowany do Tech, Windows | 2 komentarzy »