web-dev-qa-db-ja.com

2つのNICを備えたLACPは、両方が稼働しているときではなく、どちらかがダウンしているときに機能します

LACPトランクをUbuntu 12.04.2 LTSで適切に動作させるのに問題が発生しています。

私のセットアップは、vPCがマルチシャーシLACPを有効にするように構成された2つの10 Gbeインターフェイスで2つの別個のNexus 5548スイッチに接続された単一のホストです。 Nexusの設定はシスコのガイドラインに従っており、Ubuntuの設定は https://help.ubuntu.com/community/UbuntuBonding に従っています

サーバーは各NexusスイッチのポートEthernet1/7に接続され、そのポートは同一に構成され、ポートチャネル15に配置されます。ポートチャネル15はVPC 15として構成されており、VPC出力は問題ありません。これらは単純なアクセスポートです。つまり、801.1qトランキングは関与していません。

図：

    +----------+      +----------+      +----------+      +----------+
    | client 1 |------| nexus 1  |------| nexus 2  |------| client 2 |
    +----------+      +----------+      +----------+      +----------+
                           |                  |
                           |    +--------+    |
                           +----| server |----+
                           eth4 +--------+ eth5

いずれかのリンクがダウンすると、クライアント1と2の両方がサーバーに到達できます。しかし、セカンダリリンクを立ち上げると、新しく有効になったリンクでスイッチに接続されているクライアントがサーバーに到達できません。状態遷移と結果については、次の表を参照してください。

   port states (down by means of "shutdown")
     nexus 1 eth1/7        up     up    down   up
     nexus 2 eth1/7       down    up     up    up

   connectivity
    client 1 - server      OK     OK     OK   FAIL
    client 2 - server      OK    FAIL    OK    OK

さて、問題をLinux側に限定したと確信しています。アップ状態の場合、各ネクサスはサーバーへのローカルリンクを使用してパケットを配信します。これは、MACアドレステーブルを確認することで確認できます。サーバーで確認できるのは、tcpdump -i ethXを使用して、各クライアントからのパケットがethXインターフェイス（eth4上のクライアント1からのパケット、eth4上のクライアント2からのパケット）で受信されていることですが、tcpdumpを実行すると-i bond0私はどちらか一方のホストからのみトラフィックできます（上記で述べたとおり）。

ARPおよびICMP（IP）トラフィックについても同じ動作が見られます。両方のリンクがアップしている場合、クライアントからのARPは失敗し、一方がダウンしている場合は（pingとともに）機能し、リンクを再度有効にするとpingが失敗します（パケットはethインターフェイスで受信されますが、bond0では受信されません）。

明確にするために、私はこの構成で複数のサーバーを設定していますが、すべて同じ症状を示しているため、ハードウェアに関連しているようには見えません。

だから-それを修正する方法を理解することは私が扱っているものです;私のグーグルは今のところ私に運をもたらしていません。

どんなポインタでも大歓迎です。

/ etc/network/interfaces

    auto eth4
    iface eth4 inet manual
    bond-master bond0

    auto eth5
    iface eth5 inet manual
    bond-master bond0

    auto bond0
    iface bond0 inet static
    address 10.0.11.5
    netmask 255.255.0.0
    gateway 10.0.0.3
    mtu 9216
    dns-nameservers 8.8.8.8 8.8.4.4
    bond-mode 4
    bond-miimon 100
    bond-lacp-rate 1
    #bond-slaves eth4
    bond-slaves eth4 eth5

/ proc/net/bonding/bond0

    A little further information:
    Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

    Bonding Mode: IEEE 802.3ad Dynamic link aggregation
    Transmit Hash Policy: layer2 (0)
    MII Status: up
    MII Polling Interval (ms): 100
    Up Delay (ms): 0
    Down Delay (ms): 0

    802.3ad info
    LACP rate: fast
    Min links: 0
    Aggregator selection policy (ad_select): stable
    Active Aggregator Info:
    Aggregator ID: 1
    Number of ports: 1
    Actor Key: 33
    Partner Key: 1
    Partner Mac Address: 00:00:00:00:00:00

    Slave Interface: eth4
    MII Status: up
    Speed: 10000 Mbps
    Duplex: full
    Link Failure Count: 8
    Permanent HW addr: 90:e2:ba:3f:d1:8c
    Aggregator ID: 1
    Slave queue ID: 0

    Slave Interface: eth5
    MII Status: up
    Speed: 10000 Mbps
    Duplex: full
    Link Failure Count: 13
    Permanent HW addr: 90:e2:ba:3f:d1:8d
    Aggregator ID: 2
    Slave queue ID: 0

編集：Nexusから設定を追加

    vpc domain 100
      role priority 4000
      system-priority 4000
      peer-keepalive destination 10.141.10.17 source 10.141.10.12
      peer-gateway
      auto-recovery
    interface port-channel15
      description server5
      switchport access vlan 11
      spanning-tree port type Edge
      speed 10000
      vpc 15
    interface Ethernet1/7
      description server5 internal eth4
      no cdp enable
      switchport access vlan 11
      channel-group 15

編集：同じサーバーのnexus1の非VPCポートチャネルからの結果がIP変更の前後に追加されました（IPを変更して負荷分散アルゴリズムに影響を与えます）。これはまだサーバーで同じ設定を使用しています。

      port states (down by means of "shutdown")
        nexus 1 eth1/7        up     up    down   up
        nexus 1 eth1/14      down    up     up    up <= port moved from nexus 2 eth1/7

   connectivity (sever at 10.0.11.5, hashing uses Eth1/14)
       client 1 - server      OK     OK     OK   FAIL
       client 2 - server      OK     OK     OK   FAIL

IPを変更した後の結果は予測どおりです。使用されていない未使用のインターフェイスが起動すると、障害が発生します。

      connectivity (sever at 10.0.11.15, hashing uses Eth1/7)
       client 1 - server      OK    FAIL    OK    OK
       client 2 - server      OK    FAIL    OK    OK
linuxubuntubondinglacpetherchannel
5
Tolli

私がUbuntuで動作するようにしたLACP構成は次のとおりです。

auto bond0
iface bond0 inet dhcp
  bond-mode 4
  bond-slaves none
  bond-miimon 100
  bond-lacp-rate 1
  bond-updelay 200 
  bond-downdelay 200

auto eth0
iface eth0 inet manual
  bond-master bond0

auto eth1
iface eth1 inet manual
  bond-master bond0

つまり、私はボンドスレーブではなくボンドマスターを使用しています。何が違うのかはわかりませんが、この構成でうまくいきました。

私のセットアップではLACPに問題はありませんが、これは1Gbeネットワークに関するものです。

さらに、引き続き問題が発生する場合は、両方のケーブルを同じスイッチに接続して、LACPのポートを構成してみてください。マルチシャーシLACPの問題の可能性を排除するためだけに。

2
Matt

問題はLinux側ではなく、ネクサス側にあり、vPC構成でどのように機能するかです。

最初にネクサスでvPCを構成するには、2つのネクサススイッチを接続し、そのリンクを「ピアリンク」として構成する必要があります。

スイッチからサーバーへの両方のリンクが状態にある通常の状況では、vPCで構成されたvlan 11のUPトラフィックはピアリンクでドロップされます。

vPCの一部であるインターフェイスの1つがダウンしている場合のみ-vlan 11のトラフィックはピアリンクで許可されます。

これは、ネクサススイッチでvPCが機能する方法です。

この問題を解決するには、ファブリックパスを実行し、スイッチnexus-1とnexus-2の間に別の接続を作成します。

0
maxilee