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のドキュメントの正確性のための修正に加えて、発行以降に行われてきた改良が反映されています。差分を以下にまとめます。

• ブリッジドメインの言葉の正確な使用
• EVPN PEモデルの解説と用語の説明
• RFC8214のEVPN Layer 2 Attributes Extended Communityの反映とFlow Labelのための拡張
• VXLAN/NVGREなどのMPLS以外のカプセル化を考慮した記述への変更
• 高速収束のための経路の優先度付アルゴリズムの追加
• RFC8317のE-Treeのサポートを考慮した記述への変更
• MP2MP LSPの考慮
• RFC8584のバックアップDesignated Forwarderの定義の追加
• NDプロキシの記述の追加
• デフォルトゲートウェイのベストパス選出アルゴリズムの追加
• ietf-bess-mvpn-evpn-aggregation-labelのDomain-wide Common Block (DCB)の使用
• ループ防止機能の追加
• Flow Labelの追加
• RFC6790のエントロピーラベルの使用

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

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

免責

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

目次

RFC7209 Ethernet VPN(EVPN)の要件

はじめに

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

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

免責

いつものやつ

目次

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

はじめに

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

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

免責

いつものやつ

目次

RFC7432 BGP MPLS-Based Ethernet VPN

はじめに

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

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

免責

いつものやつ

目次

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

はじめに

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

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

免責

いつものやつ

目次

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の設定を疑って漁ってみたが、見つからなくて途方に暮れたので友人たちに訪ねてみると早速ヒントを貰った

NICか何かがオフロードしちゃって応答してたとかいう事象があったような… https://t.co/qOrKDpdi4u

— Masayuki Kobayashi (@markunet) 2020年6月2日

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 !!

JANOGのCode of Conduct

JANOG

こんにちは。JANOG(日本ネットワーク・オペレーターズ・グループ)というコミュニティで運営委員をやってるゆやりんです。

adventar.org

コミュニティ•カンファレンス運営 Advent Calendar 2019ということで、JANOGの運営について紹介しようと書いていたら、あまりにも長大なポエムが出来上がってしまったので、ほとんど捨てて要点を絞って最近話題のCode of Condactについて話したいと思います。

JANOGは7000名のネットワーク技術者のコミュニティ

日本ネットワーク・オペレーターズ・グループ(JANOG)はネットワーク運用者が集まる技術コミュニティです。インターネットはいろいろな組織や事業者のネットワークが相互接続することで形成されています。そのためそれを運用する技術者たちも繋がりを持ち、組織の壁を超えて技術的な情報を交換したり、共通の課題を解いていく必要があります。JANOGはそのためのコミュニティです。

1997年に北米のNANOG (North American NOG) に参加して刺激を受けた技術者たちが立ち上げ、今年で22年目になります。会員はメーリングリストの登録者数で数えており約7000名です。

活動のメインは年２回のMeeting

JANOGでは年２回ミーティングを開催しています。例年1月と7月に開催しており、最近では水曜の午後から金曜日までの2日半の開催になっています。

最近ではJANOG44ミーティングが神戸で開催され過去最高の1602名が参加しました。

JANOG44ミーティング in 神戸

参加者は増え続けてついに1600名に

JANOGミーティングの参加者数の推移

私が学生のときに初めて参加したJANOG26の時期は都内だと700名、地方だと300-400名程度の出席でした。それがここ５年くらいでどんどん増えてJANOG41で1000名超え、今回のJANOG44では1600名になりました。

JANOGのCode of Conduct をつくった

1600名も参加するミーティングともなると、色々な人が参加することが想定されます。JANOGでは2016年6月頃から検討をはじめて、2017年8月に「JANOG行動規範」として公開しました。

https://www.janog.gr.jp/doc/janog-comment/jc11.txt

JANOG行動規範

JANOGの価値は幅広い参加者の知見と興味、率直な意見交換に支えられています。
これはメーリングリストやミーティング、ワーキンググループなど、
JANOGがその目的を達成するための様々な活動の全てに共通しています。

それぞれの参加者は、異なる背景や状況、意見を持ちうることを認識し、
お互いに思いやり尊重しあいましょう。あらゆる嫌がらせや誹謗中傷、
反社会的行為は許容されません。この行動規範に反する行為や言動に対して、JANOG運営委員会は当該人物の退出や除名などの必要な措置を講ずることがあります。

共に楽しみ、共に課題を乗り越え、充実したコミュニティを作っていきましょう。

以上

なにか個別の問題が発生したので制定したという経緯ではなく、海外を中心に他のコミュニティでCoCを制定することが当たり前の流れになってきており、JANOGでもこれが必要になるだろうという判断を行いました。

ドラフトを策定して公開、次のJANOGミーティングで説明、意見募集。その次のJANOGミーティングのオープンマイクで採択という流れを取りました。そのため検討から約１年を要しています。

他のコミュニティのCoCを参考にした

CoCは同じく運営委員の金子さんや松崎さんが中心となって策定をしていただきました。策定にあたって他のコミュニティ、特にネットワーク系でアジア圏でカンファレンスを行っているAPNICやAPRICOTなどを参考にしており、APNICのCoCをベースに作成しました。

• APNIC Community Code of Conduct – APNIC 

• APRICOT Code of Conduct / Anti-harrassment Policy | APRICOT 2017

• HOWTO design a code of conduct for your community | Ada Initiative

• Code of conduct evaluations | Geek Feminism Wiki | Fandom

• Slack Developer Community Code of Conduct | Slack

• The Ruby Community Conduct Guideline

前向きなCoCを作ろう

なぜCoCが必要だと判断したのかは、松崎さんがJANOG39で開催してくれたJANOG行動規範BoF (Bird of feather, 同好会)の資料でも書かれている通り、

• 僕たちがどういう価値観や倫理的指針を持って活動しているか明文化しておきたい
• 嫌がらせ（ハラスメント）は許されない行為だと明確にしておきたい
• この思いに賛同する人がどんどん参加して、このコミュニティが発展してくれると嬉しい

という３点が主な理由です。会員やミーティング参加者の行動を厳しく縛るような後ろ向きな規約を決めるのではなく、参加する人が安心して参加できるように前向きなCoCにしたいと作る際に方針を決めました。

JANOG39 :: [JANOGCOC] コミュニティの行動規範 - JANOGはどうする？

JANOGというコミュニティがどのような価値観を持っているかを表明するとともに、ハラスメントに対して許容しない、ハラスメントがあればアクションを取るということを明文化することで、そうした行為が行われた際にミーティング実行委員（スタッフ）のみなさんが自発的に行動できる指針を示しておくという効果ももあります。

CoCはコミュニティの価値を高めるために必要

「昔はそんなもの必要なかった」というご意見もいただきますが、我慢させられ泣き寝入りしてしまう人もたくさんいたのではないかと思います。

コミュニティ運営者がCoCを作ることで、そうしたハラスメントを受けた方をケアし、またハラスメントを抑止することで、コミュニティの価値や魅力を上げていくことに繋がります。それによりコミュニティが活性化して会員や参加者もその恩恵を受けることができるようになり、良い循環が生まれます。

検索するとCoCの雛形なども公開されていたりするので、まだCoCを制定していないコミュニティ運営者はぜひ制定してみてください。