QUICやHTTP/3で利用を避けるべき送信元ポートの議論についての考察

f:id:yuyarin:20210722233918p:plain

https://www.slideshare.net/yuyarin/quicnat

最近QUICとNATについての話をJANOGで紹介するぐらいQUICという新しいプロトコルに既存のネットワークインフラがどう適応していくかを考えています。

id:asnokaze さんの記事で紹介されているように、QUICやHTTP3/3で送信元UDPポートとして利用を避けるべきポートの議論が行われています。これはUDPのリフレクション攻撃のへの対応としてインフラストラクチャ側で特定のUDPポートのトラフィックをブロックしているケースがあるからです。実際に私もこのブロックの設定を行ったことがあります。 これはUDPというプロトコルの特性に起因する問題であり、QUIC, HTTP/3に限らずUDPを使うプロトコルに広くある問題です。

asnokaze.hatenablog.com

QUICクライアント側で送信元ポートとして利用を避けた場合でもインフラストラクチャ側のミドルボックスによって避けるべきポートを送信元ポートとして使用されてしまう可能性があります。一番大きな障害となるのがIPv4 Source NATでしょう

この記事ではHTTP/3を提供する場合についてのみ考察します。この記事でHTTP/3に対して問題ないと判断しても、QUICを使用する別のまだ見ぬ新しいアプリケーションレイヤープロトコルでは問題が生じるかもしれません。

結論

結論から述べるとHTTP/3でサービスを提供する事業者が制御可能な範囲内でこの問題を回避することができます。ただし世の中には例外があり100%ではありませんが、おおよそ問題になることはないでしょう。

IPv4 Source NATとUDP増幅問題

IPv4 Source NAT(以下SNAT)では一般のNATでもCGN/LSNでもwell-knownポートを送信元ポートには使用しませんので、問題になるポート番号は1024 - 65535の範囲でUDP増幅攻撃に使用されるポートです。これに該当するポートを増幅率の順で並べると次のようになります。

問題になりそうなポートをUDPの増幅率で並べ替えると次のとおりです。増幅率はA10さんの資料を参考にしました。

ポート番号 プロトコル 増幅率 主な利用者
11211 memcached 10,000-51,000 コンテンツプロバイダ
27910 Quake 2 63.9 Eyeball/クラウド
1900 SSDP 30.8 Eyeball
1433 MSQL 25 エンタープライズ/クラウド
4672 Kad 16.3 Eyeball
27000-27030 Steam Protocol 5.5 Eyeball/コンテンツプロバイダ/クラウド
1024-65534 BitTorrent 3.8 Eyeball
5353 mDNS 2-10 Eyeball

本来であれば増幅率の他にプロトコルの普及率などで考える必要があります。個人的な感覚では危ないのは次の3つかなと思います。これはMLの元のリストのうちwell-knownポートのプロトコル以外のものと一致します。

ポート番号 プロトコル 増幅率 主な利用者
11211 memcached 10,000-51,000 コンテンツプロバイダ
1900 SSDP 30.8 Eyeball
5353 mDNS 2-10 Eyeball

memcachedはオンメモリのKey-Valueデータベースで主にコンテンツプロバイダなどのサービス提供側で使用されることが多いソフトウェアでありプロトコルです。UDP増幅攻撃においては非常に大きな増幅率を誇っており、一時期大きな問題になりました。

SSDPUPnP(Universal Plug and Play)で使用されるプロトコルです。UPnPに対応している機器は家庭用ブロードバンドルータやプリンタなど主にEyeball側で利用される機器が多く、ターゲットもEyeball側になることが多いです。

mDNSは元々ローカルで提供されるサービスですが、一部の実装が外部からの問い合わせに応答してしまうことでUDP増幅攻撃に利用されています。

SNATで送信元ポートとしてこれらのポートを使うかどうか

結論から言うと使われる可能性があります。仕様として明確に禁止しているものがないため、実装や運用に依存します。

一般的なブロードバンドルータではそもそもSNATのエントリー数が数千と小さいため、エフェメラルポートの範囲で十分ですが、SOHO・中規模用のルータなどではSNATのポート範囲を1024まで拡張している場合があります。特定のポート番号についてそのポート番号を使用しないようにしている実装は稀だと思います(個人の感想)。

一番問題になるのがIPoEでのCGN/LSNの実装方式であるMAP-EなどのIPv6アドレスをIPv4アドレスとポート番号のレンジに静的にマッピングするタイプのSNATです。Subscriberあたり256個や512個のポート番号を連続した領域として割り当てるため、個別のポート番号だけを抜き取る実装はありません。そのポート番号を含むレンジをまるごと使用不可にすることは考えられますが、私の知る限りそのような実装はありません。

以降でこれらのポート番号が送信元ポート番号として使われたとしてもおそらく問題がないであろう(大きな問題にならないであろう)理由を述べます。

Eyeball側をターゲットとしたUDP増幅攻撃への対処

f:id:yuyarin:20210722233632p:plain

SSDPやmDNSはEyeball側の機器が増幅器になります。この攻撃を防ぐ箇所としては以下の8箇所が考えられます。これらのうち実際にブロックを行う可能性があるのは③か⑧です。

番号 場所 条件 ブロックするか
ISPIngress全般 送信元ポート しない
ISPからSubscriberへのEgress 送信元ポート しない
SubscriverのIngress 送信元ポート しているかもしれない
SubscriverのEgress 宛先ポート しない
ISPのSubscriberからのIngress 宛先ポート しない
ISPのEgress 宛先ポート しない
ISPのSubscriberや顧客や子ASへのEgress 宛先ポート しない
Subscriberや顧客や子ASのIngress 宛先ポート しているかもしれない
Subscriberや顧客や子ASのIngress 宛先ポート しているかもしれない

③のケースではSubscriberのCPEにおいて送信元ポート番号をブロックするケースですが、設定している可能性はそれほど高くなく、また、設定していたとしてもSNATのinside側で行われているかと思うので、無害でしょう。

⑧のケースでは宛先ポートですのでブロッキングを行っていたとしてもQUICには影響がありません。

③と⑧以外の箇所では「しない」としていますが、ISPによってはブロッキングしている箇所がある可能性があります。基本的にポート番号によるブロッキングは通信の秘密を侵害することになります。OP25Bのように正当業務行為による違法性阻却事由が成り立つ場合は、これを根拠に実施しているISPはありえます。ここはどの程度のISPが実施しているかを調査する必要がありますが、それほど多くはないかと思います。

HTTP/3でサービスを提供する事業者になりえるのは⑧、クライアント側になりえるのが③や⑧と考えたときに、上記のことからEyeball側がターゲットになるSSDPやmDNSについては、QUICの送信元ポート番号がこれらのUDP増幅攻撃対策のためのブロッキングから影響を受ける可能性は低いと思います。

コンテンツプロバイダ側をターゲットにしたUDP増幅攻撃への対応

f:id:yuyarin:20210722233647p:plain

memcachedはコンテンツプロバイダ側の機器が増幅器になります。この攻撃を防ぐ箇所としては以下の8箇所が考えられます。これらのうち実際にブロックを行う可能性があるのは③と④と⑧と⑪です。

番号 場所 条件 ブロックするか
ISPIngress全般 送信元ポート しない
ISPから法人顧客や子ASであるコンテンツプロバイダへのEgress 送信元ポート しない
コンテンツプロバイダのIngress 送信元ポート しているかもしれない
コンテンツプロバイダのEgress 宛先ポート しているかもしれない
ISPの法人顧客や子ASであるコンテンツプロバイダからのIngress 宛先ポート しない
ISPのEgress 宛先ポート しない
ISPのSubscriberや顧客や子ASへのEgress 宛先ポート しない
Subscriberや顧客や子ASのIngress 宛先ポート しているかもしれない
Subscriberや顧客や子ASのIngress 宛先ポート しているかもしれない
ISPのSubscriberからのIgress 送信元ポート しない
ISPのSubscriberのIgress 送信元ポート しているかもしれない

ISPでは基本的には法人顧客や子ASに対してトラフィックブロッキングは行いません。

③も④もブロッキングを行っている可能性がありますがネットワーク外部の(例えばクラウドサービス上に立てた)memcachedにアクセスするためには必要なのでブロッキングしている可能性は低いです。③がクライアントからのHTTP/3のトラフィックに関係しますが、これはHTTP/3でサービスを提供する事業者側で制御可能な範囲なので対処可能です。

⑧はブロッキングしている可能性が高いです。これはmemcachedUDP増幅攻撃に使用された場合の対処方法として、ネットワーク内部にmemcachedを立てている場合に信頼できるIPアドレス以外の外部からの宛先ポートが11211であるパケットを落とします。これはブロッキングを行っていてもHTTP/3には影響しません。

⑪はブロッキングされている可能性があります。これはEyeball側で内部でmemcachedがNW管理者の関知しない範囲で立てられていたときにUDP増幅攻撃に加担しないようにNW管理者側でブロックしているケースです。ただしこの場合もブロックはSNATを行う前に実施されるので、HTTP/3トラフィックに対する影響はありません。

HTTP/3でサービスを提供する事業者になりえるのは③、④、⑧ですが、いずれも影響がありません。

HTTP/3でサービスを提供するコンテンツプロバイダ側でできる対策

HTTP/3でサービスを提供しようとした場合に、UDP増幅攻撃の対処としてのブロッキングに影響を受けないためには以下の対応を行えば十分だと考えられます。

  • SNATされないケースを考えて、HTTP/3クライアント側で送信元ポート番号に増幅攻撃に利用されるポート番号を使用しない(現在のWGの方向)
  • 送信元ポート番号が11211であるトラフィックをブロックしているネットワークにHTTP/3のフロントエンドを設置しない(コンテンツ事業者の努力)
  • SNATが行われなくても済むようにIPv6でのサービスを提供する(コンテンツ事業者の努力)

というわけで今のWGの流れは方向性としては概ね正しいかと思います。

もう少し踏み込んで少しの可能性も潰したい場合、memcachedの11211のブロッキングを回避するためには、送信元ポート番号として偶数番号を使うことが対策になりえます。なぜならRFC4787にもあるように多くのSNATの実装ではPort Parityとして送信元ポート番号の偶奇を保つようにしているからです。ただし送信元ポート番号の枯渇が2倍速になる問題があります。

最後に

これらはあくまでコンテンツとEyeballと単純に分割して考察した場合です。コンテンツプロバイダやクラウドサービス同士でHTTP/3でAPI提供が行われた場合なども考察する必要があります。

いずれにせよ、新しいプロトコルの発展を阻害しないためにみんなで協力しあって頑張っていきたいところです。

考慮が足りない箇所があったら遠慮なくコメント欄か @yuyarin までお知らせください。

RFC7432bis-00 BGP MPLS-Based Ethernet VPN

はじめに

この文書は RFC7432bis BGP MPLS-Based Ethernet VPN (draft-ietf-bess-rfc7432bis-00) 、つまりRFC7432の改訂版のドラフト0版の日本語訳であり、RFC7432との差分を理解するためのものです。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。

RFC7432との差分

RFC7432bis-00ではRFC7432のドキュメントの正確性のための修正に加えて、発行以降に行われてきた改良が反映されています。差分を以下にまとめます。

まだ00版で、誤字脱字や用語の不統一、曖昧さなどが残っています。翻訳時点で00版はexpireしていますが、01版はでていません。

RFC7432から削除された部分は打ち消し線、RFC7432bisで追加された部分は太字で記載しています。

免責

この翻訳を信用して不利益を被っても責任取れません的なやつ。

目次

  • はじめに
  • RFC7432との差分
    • 免責
  • 目次
  • Abstract
  • 1. はじめに
  • 2. 要件の仕様
  • 3. 用語
  • 4. BPG MPLSベースのEVPNの概要
  • 5. イーサネットセグメント
  • 6. イーサネットタグID
  • 7. BGP EVPN経路
    • 7.1. Ethernet Auto-discovery経路
    • 7.2. MAC/IP Advertisement経路
    • 7.3. Inclusive Multicast Ethernet Tag経路
    • 7.4. Ethernet Segment経路
    • 7.5. ESIラベル拡張コミュニティ
    • 7.6. ES-Import Route Target
    • 7.7. MACモビリティ拡張コミュニティ
    • 7.8. デフォルトゲートウェイ拡張コミュニティ
    • 7.9 EVPNレイヤー2属性拡張コミュニティ
      • 7.9.1. EVPNレイヤー2属性の分割
    • 7.9.7.10. MAC-VRFごとのRoute Distinguisherの割当方法
    • 7.10. 7.11. Route Targets
    • 7.12. 経路の優先度付け
  • 8. マルチホーミング機能
    • 8.1. マルチホームされたイーサネットセグメントの自動発見
    • 8.2. 高速収束
      • 8.2.1. Etherenet A-D per ES経路の構築方法
        • 8.2.1.1. Ethernet A-D経路のターゲット
    • 8.3. スプリットホライズン
      • 8.3.1. ESIラベルの割り当て
        • 8.3.1.1. Ingress Replication
        • 8.3.1.2. P2MP MPLS LSP
        • 8.3.1.3. MP2MP MPLS LSP
    • 8.4. エイリアシングとバックアップパス
      • 8.4.1. Ethernet A-D per EVPN Instance 経路の構築
    • 8.5. Designated Forwarder選出
    • 8.6. プライマリPEとバックアップDFに選出されたPEの伝達
    • 8.6. 8.7. シングルホームのPEとの相互運用性
  • 9. ユニキャストMACアドレスへの到達性の決定
    • 9.1. ローカル学習
    • 9.2. リモート学習
      • 9.2.1. MAC/IP Address Advertisementの構築
      • 9.2.2. 経路解決
  • 10. ARP and ND
  • 11. 複数宛先トラフィックの処理
  • 12. Unknownユニキャストパケットの処理
    • 12.1. Ingress Replication
    • 12.2. P2MP MPLS LSP
  • 13. ユニキャストパケットの転送
    • 13.1. CEから受信したパケットの転送
    • 13.2. リモートPEから受信したパケットの転送
      • 13.2.1. unknownユニキャストの転送
      • 13.2.2. knownユニキャストの転送
  • 14. ユニキャストパケットのロードバランス
    • 14.1. PEからリモートCEへのトラフィックのロードバランス
      • 14.1.1. Single-Active冗長モード
      • 14.1.2. All-Active冗長モード
    • 14.2. PEとローカルCEの間でのトラフィックのロードバランス
      • 14.2.1. データプレーン学習
      • 14.2.2. コントロールプレーン学習
  • 15. MACモビリティ
  • 16. マルチキャストとブロードキャスト
    • 16.1. Ingress Replication
    • 16.2. P2MP LSPとMP2MP LSP
  • 17. 収束
    • 17.1. PE間のトランジットリンクとノードの障害
    • 17.2. PE障害
    • 17.3. PEとCEの間のネットワーク障害
  • 18. フレームの順序制御
    • 18.1. フローラベル
  • 19. Domain-wide Common Block (DCB)ラベルの使用
  • 19. 20. セキュリティの懸念事項
  • 20. 21. IANAの懸念事項
続きを読む

RFC7209 Ethernet VPN(EVPN)の要件

はじめに

この文書は RFC7209 Requirements for Ethernet VPN (EVPN) の日本語訳です。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスが欠けた文章になっている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。

免責

いつものやつ

目次

  • はじめに
    • 免責
  • 目次
  • Abstract
  • 1. はじめに
  • 2. Specification of Requirements
  • 3. 用語
  • 4. 冗長性の要件
    • 4.1. フローベースのロードバランス
    • 4.2. フローベースのマルチパス
    • 4.3. 地理的に冗長化されたPEノード
    • 4.4. 最適化されたトラフィックの転送
    • 4.5. 柔軟な冗長グループのサポート
    • 4.6. マルチホームされたネットワーク
  • 5. マルチキャスト最適化の要件
  • 6. プロビジョニングの簡便さの要件
  • 7. 新しいサービスインターフェイスの要件
  • 8. 高速収束
  • 9. フラッディングの抑制
  • 10. 柔軟なVPNトポロジーとポリシーのサポート
  • 11. セキュリティについての考察
  • 12. 標準への参考文献
  • 13. 有益な参考文献
続きを読む

RFC8365 Ethernet VPN(EVPN)を使用したネットワーク仮想化オーバーレイのソリューション

はじめに

この文書は RFC8365 A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) の日本語訳です。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスが欠けた文章になっている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。

免責

いつものやつ

目次

  • はじめに
    • 免責
  • 目次
  • Abstract
  • 1. はじめに
  • 2. Requirements Notation and Conventions
  • 3. 用語
  • 4. EVPNの特徴
  • 5. EVPNオーバーレイのためのカプセル化方式
    • 5.1. VXLAN/NVGREカプセル化
      • 5.1.1. 仮想識別子のスコープ
      • 5.1.2. 仮想識別子のEVIへのマッピング
        • 5.1.2.1. RTの自動計算
      • 5.1.3. EVPN BGP経路の構築
    • 5.2. MPLS over GRE
  • 6. 複数のデータプレーンカプセル化のEVPN
  • 7. シングルホームNVE - ハイパーバイザに存在するNVE
  • 8. マルチホームNVE - ToRスイッチに存在するNVE
    • 8.1. EVPNマルチホーミングの特徴
      • 8.1.1. マルチホームしているESの自動発見
      • 8.1.2. 高速収束とMass Withdrawal
      • 8.1.3. スプリットホライズン
      • 8.1.4. エイリアシングとバックアップパス
      • 8.1.5. DF選出
    • 8.2. EVPN BGP経路と属性に対する影響
    • 8.3. EVPN手順に対する影響
  • 9. マルチキャストのサポート
  • 10. データセンター相互接続(DCI)
    • 10.1. GWを使用したDCI
    • 10.2. ASBRを使用したDCI
      • 10.2.1. シングルホームNVEとASBR機能
      • 10.2.2. マルチホームNVEとASBR機能
  • 11. セキュリティについての考察
  • 12. IANAについての考察
  • 13. 参考文献
続きを読む

RFC7432 BGP MPLS-Based Ethernet VPN

はじめに

この文書は RFC7432 BGP MPLS-Based Ethernet VPN の日本語訳です。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。

免責

いつものやつ

目次

  • はじめに
    • 免責
  • 目次
  • Abstract
  • 1. はじめに
  • 2. 要件の仕様
  • 3. 用語
  • 4. BPG MPLSベースのEVPNの概要
  • 5. イーサネットセグメント
  • 6. イーサネットタグID
  • 7. BGP EVPN経路
    • 7.1. Ethernet Auto-discovery経路
    • 7.2. MAC/IP Advertisement経路
    • 7.3. Inclusive Multicast Ethernet Tag経路
    • 7.4. Ethernet Segment経路
    • 7.5. ESIラベル拡張コミュニティ
    • 7.6. ES-Import Route Target
    • 7.7. MACモビリティ拡張コミュニティ
    • 7.8. デフォルトゲートウェイ拡張コミュニティ
    • 7.9. MAC-VRFごとのRoute Distinguisherの割当方法
    • 7.10. Route Targets
  • 8. マルチホーミング機能
    • 8.1. マルチホームされたイーサネットセグメントの自動発見
    • 8.2. 高速収束
      • 8.2.1. Etherenet A-D per ES経路の構築方法
        • 8.2.1.1. Ethernet A-D経路のターゲット
    • 8.3. スプリットホライズン
      • 8.3.1. ESIラベルの割り当て
        • 8.3.1.1. Ingress Replication
        • 8.3.1.2. P2MP MPLS LSP
    • 8.4. エイリアシングとバックアップパス
      • 8.4.1. Ethernet A-D per EVPN Instance 経路の構築
    • 8.5. Designated Forwarder選出
    • 8.6. シングルホームのPEとの相互運用性
  • 9. ユニキャストMACアドレスへの到達性の決定
    • 9.1. ローカル学習
    • 9.2. リモート学習
      • 9.2.1. MAC/IP Address Advertisementの構築
      • 9.2.2. 経路解決
  • 10. ARP and ND
  • 11. 複数宛先トラフィックの処理
  • 12. Unknownユニキャストパケットの処理
    • 12.1. Ingress Replication
    • 12.2. P2MP MPLS LSP
  • 13. ユニキャストパケットの転送
    • 13.1. CEから受信したパケットの転送
    • 13.2. リモートPEから受信したパケットの転送
      • 13.2.1. unknownユニキャストの転送
      • 13.2.2. knownユニキャストの転送
  • 14. ユニキャストパケットのロードバランス
    • 14.1. PEからリモートCEへのトラフィックのロードバランス
      • 14.1.1. Single-Active冗長モード
      • 14.1.2. All-Active冗長モード
    • 14.2. PEとローカルCEの間でのトラフィックのロードバランス
      • 14.2.1. データプレーン学習
      • 14.2.2. コントロールプレーン学習
  • 15. MACモビリティ
  • 16. マルチキャストとブロードキャスト
  • 17. 収束
    • 17.1. PE間のトランジットリンクとノードの障害
    • 17.2. PE障害
    • 17.3. PEとCEの間のネットワーク障害
  • 18. フレームの順序制御
  • 19. セキュリティの懸念事項
  • 20. IANAの懸念事項
続きを読む

RFC7938 - 大規模データセンター内でのルーティングのためのBGPの利用方法

はじめに

この文書は RFC7938 - Use of BGP for Routing in Large-Scale Data Centers の日本語訳です。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。

免責

いつものやつ

目次

  • はじめに
    • 免責
  • 目次
  • 概要
  • 1. 導入
  • 2. ネットワーク設計の要件
  • 3. データセンタートポロジーの概要
  • 4. データセンタールーティングの概要
    • 4.1 L2オンリー設計
    • 4.2 L2/L3ハイブリッドの設計
    • 4.3 L3オンリー設計
  • 5. ルーティングプロトコル設計
  • 6. ECMPの考察
    • 6.1 基本的なECMP
    • 6.2 複数のAS番号をまたがるBGP ECMP
    • 6.3 重み付けされたECMP
    • 6.4 コンシステントハッシュ法
  • 7. ルーティング収束の特性
    • 7.1 障害検知のタイミング
    • 7.2 イベント伝搬のタイミング
    • 7.3 Closトポロジーのファンアウトの効果
    • 7.4 罹障範囲
    • 7.5 ルーティングマイクロループ
  • 8. 設計の追加の選択肢
    • 8.1 サードパーティ・ルート・インジェクション
    • 8.2 Closトポロジー内の経路集約
      • 8.2.1 Tier 1機器レイヤーの集約
      • 8.2.2 単純な仮想アグリゲーション
    • 8.3 ICMP Unreachableメッセージのマスカレード
  • 9. セキュリティの懸念事項
続きを読む

Intel NICを搭載したLinuxサーバのLLDPが正しく動作しない問題

サマリー

Intel NICを搭載したLinuxサーバにおいて lldpd をインストールして設定を行ってもその設定が反映されず、ハードウェアの情報が表示される場合、Intel NIC (i40e) のLLDPオフロードが有効になっているためこれを無効にする必要がある。

詳細

lldpdを apt install lldpd でインストールしたのち、以下のように設定を行った。

configure system interface pattern eno*,ens*
configure lldp portidsubtype ifname

ネットワークスイッチ側からLLDPネイバーを表示すると以下のようになった。Chassis IdにはMACアドレス、Port infoにはLinux上でのインターフェイス名が見えることが期待値であったが、ハードウェア固有の値が表示されている。

{master:0}
me@myswitch> show lldp neighbors
Local Interface    Parent Interface    Chassis Id          Port info          System Name
xe-0/0/8           ae2                 39373638-3935-5099-4E99-303330309999Embedded ALOM, Port 1
xe-0/0/10          ae2                 39373638-3935-5099-4E99-303330309999PCI-E Slot 1, Port 1
{master:0}
me@myswitch> show lldp neighbors interface xe-0/0/8
LLDP Neighbor Information:
Local Information:
Index: 147 Time to live: 121 Time mark: Tue Jun  2 06:27:34 2020 Age: 12 secs
Local Interface    : xe-0/0/8
Parent Interface   : ae2
Local Port ID      : 521
Ageout Count       : 0

Neighbour Information:
Chassis type       : Locally assigned
Chassis ID         : 39373638-3935-5099-4E99-303330309999
Port type          : Mac address
Port ID            : 00:00:5e:a2:72:00
Port description   : Embedded ALOM, Port 1

System Description : HPE ProLiant DL360 Gen10

また、サーバ側からLLDPの自身の情報とネイバーの情報を表示すると、ChassisIDやPorIDが正しく設定されていることがわかり、ネイバーが見えていないこともわかる。スイッチ側の設定はスイッチ間のLLDP設定で正しく表示できていることが確認できていたため、これはスイッチからのLLDPDUがLinuxのレイヤーまで届いていないということになる。

root@myserver:~# lldpcli show chassis
-------------------------------------------------------------------------------
Local chassis:
-------------------------------------------------------------------------------
Chassis:
  ChassisID:    mac 00:00:5e:7b:a4:10
  SysName:      myserver
  SysDescr:     Ubuntu 18.04.3 LTS Linux 4.15.0-55-generic #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019 x86_64
  MgmtIP:       10.102.253.54
  MgmtIP:       fe80::ac91:afff:fe1f:aee0
  Capability:   Bridge, on
  Capability:   Router, on
  Capability:   Wlan, off
  Capability:   Station, off
-------------------------------------------------------------------------------

[lldpcli] # show interfaces ports eno5
-------------------------------------------------------------------------------
LLDP interfaces:
-------------------------------------------------------------------------------
Interface:    eno5, via: unknown
  Chassis:
    ChassisID:    mac 00:00:5e:7b:a4:10
    SysName:      myserver
  Port:
    PortID:       ifname eno5
    PortDescr:    eno5
  TTL:          120
-------------------------------------------------------------------------------
root@myserver:~# lldpcli show neighbor ports eno5
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------

生のハードウェアIDが表示されていたため、BIOSの設定を疑って漁ってみたが、見つからなくて途方に暮れたので友人たちに訪ねてみると早速ヒントを貰った

Intel NIC (i40eドライバ)でLLDPのオフロードが有効になっているようである。

centos6 - Disable internal Intel X710 LLDP agent - Server Fault

バージョン2.3.6以降のi40eのドライバーではethtool経由でLLDPオフロードを無効にできるようであるが、Ubuntu18.04で使っていたドライバはそれより若いバージョンであったため、 debugコマンド経由で無効にする方法を利用した。以下のようにdisable-lldp-offload.sh という名前でスクリプトを配置し、再起動時でもオフロードの無効化が自動でできるようにするため、/etc/cron.d/lldp から@rebootで呼び出すことにした(systemdではなく)。

#!/bin/bash 
i40e_path=/sys/kernel/debug/i40e
for dev in $i40e_path/*; do 
    [ -e "$dev" ] || break 
    echo lldp stop > "${dev}/command”
done
@reboot root sleep 60 && /root/disable-lldp-offload.sh

スイッチ側からも無事に正しい情報を参照できるようになった。

{master:0}
me@myswitch> show lldp neighbors
Local Interface    Parent Interface    Chassis Id          Port info          System Name
xe-0/0/8           ae2                 00:00:5e:7b:a4:10   eno5               myserver
xe-0/0/10          ae2                 00:00:5e:7b:a4:10   ens1f0             myserver

ありがとう @markunet !!