ソフトバンク株式会社でモバイルネットワークで5GとかSRv6とかやっていきます

f:id:yuyarin:20211001180819j:plain

TL;DR

2021年10月1日からソフトバンク株式会社にITインフラアーキテクトとして入社し、モバイルコア向けのクラウド基盤をやっていきます。まずは得意分野の仮想基盤のネットワークを中心に活動して最終的にはソフトバンクのネットワーク全体に目を向けられるようになりたいなと思います。

これに伴いまして2021年9月末で新卒から10年半お世話になったNTTコミュニケーションズを退職いたしました。職場の皆様からは次のチャレンジを応援して温かく送り出していただきました。最高のチームでとても愛着のあるサービスでした。今までありがとうございました。

時間がない人のための一問一答

Q. なんで転職したの?

いきなり一言で答えられないので動機が強い順で書くと

  • 80歳まで働かざるをえない世界に備えて5年後10年後を考えたキャリアパスを考えようと思った
  • 前職でスペシャリストとして再就職したときにコミットしていたプロジェクトが一区切りついた
  • 前職のチームもサービスも最高の状態で僕が辞めても大丈夫だと自信を持てた
    次にやりたい技術があった
  • 今の環境がコンフォートゾーンに入っているなと感じた
  • NTT以外の会社で働いてみたかった
  • 転職を経験しておいたほうが良いと思った
  • 居座り続けると後輩の成長機会を奪うことになると思った

Q. なんでモバイル?

こんなにたくさん使われているのに僕が理解してない通信インフラがあるなんてけしからんと思ったから

Q. なんで5G?

まわりがみんな5GCの話をしていてけまらしかったから

Q. なんでSRv6?

まわりがみんなSRv6の話をしていてけまらしかったから

Q. なんでソフトバンク

  • 超本気のラブコールをもらったから
  • SRv6を商用導入していたから
  • 元公社とは性質が正反対に見える「強い創業者の企業」で働いてみたかったから

Q. きっかけは?

f:id:yuyarin:20210930164900p:plain

友人のソフトウェアエンジニアが家を建てたので宅内ネットワークをローカル5GとSRv6にしようぜみたいな話をTwitterでやっていたら、ソフトバンクでSRv6と5Gに関わってるすごいエンジニアから「うちくる?」ってDMが飛んできたのでホイホイついていってしまった

Q. ITインフラアーキテクトってなにやんの?

モバイルテレコムクラウド基盤のアーキテクチャー策定と開発チームのリードをやるらしいけど、単にこの辺に応募してって言われて応募した職種のタイトルがこれだった感じです

Q. エンジニア?マネージャー?

部下なしのエンジニア(プロフェッショナル職)

Q. 給料あがった?

ベースの月収は下がってボーナス込みの年収の期待値は少し上がった感じ

Q. 他社は考えた?

3社から素敵なポジションにお誘いを頂いて3社とも内定を頂きました

Q. 他社のポジションは?

  • 外資系ネットワークサービスプロバイダのSRE職
  • 日系コンテンツプロバイダのSWE
  • 日系コンテンツプロバイダのNWE職

Q. 他社の待遇は?

前職と同等かそれ以上

Q. 他社と比べてソフトバンクの待遇が良かった?

一概には比較できないけどベースは前職より下がってるし一番高い他社と比べたらかなりの差があるのでそうでもない

Q. じゃあなんでソフトバンク

モバイルができるのが魅力的で抗えなかった

Q. 他社よりキツくない?(大企業的な自由度とか総務省案件とか)

だがそれがいい

Q. キャリアパスだいじょうぶ?

わかんねー

Q. そんなに給料上げてどうすんの?(前職の上司から訊かれた質問)

上げてるのは自分の給与ではなくて日本のネットワークエンジニアの給与だったり日本国民の平均所得なんだと思ってる

Q. NTT退職エントリ?

f:id:yuyarin:20211001085104p:plain

いいえ、退職したかったわけじゃなくて転職したら退職することになっただけで今のチームには感謝しか無いので特に退職にフォーカスを当てる気はないですhttps://twitter.com/u1/status/1067712835508039680?s=20

Q. ドコモじゃだめだったの?

だめじゃなかった

Q. じゃあなんでドコモに行かなかったの?

もともとモバイルの仕事をやる前提で転職しようとしていたわけではなかったので、内定先の中からソフトバンクに決めてからドコモに打診をするとタイミング的に合わなくなるから

Q. なんでNTTグループを出たかったの?

僕が感じていたことをタイミングよくDeNAの南場さんがズバッと言ってくれていたので引用します:

入社してから30年以上ずっと同じ会社しか見ていない人たちが集まって改革だ、イノベーションだって議論しているわけですが、さすがに無理があるように感じてしまいます。

business.nikkei.com

Q. 辞めると決めたときすっきりした?

むしろ最高の環境を捨てることがストレスになって盛大に肌荒れしたレベル

Q. NTTグループに戻ってくる可能性はある?

NTTコムであれば将来的に転職先の選択肢として十分に入るけどそのときにNTTコムが残ってるかはわからん

Q. 転職して後悔してない?

もう半年ぐらい遅らせておけばよかったなと思ってる…:

  • 住宅財形を解約する前に家を買っておけばよかった(非課税で継続できるか確認中)
  • ベース給与が下がる前に家を買って住宅ローンを組んでおけばよかった
  • プライベートで有給休暇が必要そうなタイミングで転職しなければよかった
  • 2年前の退職再就職時にお世話になった元上司の新しい職場でのミッションに貢献してから今のチームを離れればよかった

Q. 心残りは?

NTTグループ横断でエンジニアが集まってるSlackの在籍資格がなくなったこと

Q. 後任は?

前職の私のポジションの後任を募集していますので奮ってご応募ください(目安の値と違って実際は1000-1500ぐらい出ると思います)。

hrmos.co同じチームでエンジニアのポジションもありますのでこちらも是非ご応募ください(②がSDN寄りです)。

hrmos.co

Q. 一緒に仕事したいんだけど?

この辺に応募してください!

recruit.softbank.jp

さいごに

前職に向けてのメッセージ

Enterprise Cloud 2.0のSDNのチームに入って4年と2ヶ月でしたが、着任早々大障害が起きてその後もトラブルに見舞われ続けましたがなんとか安定させることができてSLAもいい感じの高い値を出すことができました。クラウドの開発チームはNTTコムの中では技術力的にもカルチャー的にもエンジニアにとって最高の環境で、僕のチームは最高のチームでした。あとはよろしくお願いします。ありがとうございました。また一緒に仕事しましょう。

f:id:yuyarin:20210930182628j:plain

現職に向けてのメッセージ

高く評価していただいて採用していただいてありがとうございました。今まで培ってきたインタードメインルーティングやデータセンターネットワーク・SDNなどのスキルと経験と成果を加味して将来性にベットしていただいたんじゃないかと思っていますので、皆様の期待に答えてリターンが出せるように精一杯頑張っていきたいと思います。これからよろしくお願いします!



IP Prefix Advertisement in EVPN (Draft 11)

はじめに

この文書は IP Prefix Advertisement in EVPN (ドラフト11版) (draft-ietf-bess-evpn-prefix-advertisement-11) の翻訳です。この文書ではEVPNのRoute Type 5 (IP Prefix)とサブネット間転送のための利用方法とユースケースの例が記述されています。

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

この文書はドラフトであるため、用語や表記が統一されていなかったり、仕様の内容について曖昧な部分がありますが、原文に忠実になるように訳しています。

免責

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

目次

続きを読む

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の懸念事項
続きを読む