インターンシップ体験記 〜BGP-LSの機能をFRRに実装してみた〜

はじめに

こんにちは、インターンシップ生の金谷です。 2022年2月に2週間ほどNTTコミュニケーションズのインターンシップに参加させていただきました。 普段は大学院やWIDEプロジェクト、アルバイトなどで SRv6 BGP-EPEなどオーバレイネットワーク技術の研究開発をしています。

インターンシップには「次世代のサービスを生み出す検証網 Testbedの設計構築業務」というテーマで、2022年2月14日から25日までの2週間参加しました。 具体的にはFRRouting(FRR)というOSSのソフトウェアルータにBGP-LSという機能を実装するという内容に取り組みました。 この記事では、その体験談を記載します。

インターンシップに参加するまで

NTT Comという会社に非常に興味を持っていたため、会社の雰囲気を知りながら面白い開発が出来そうだと思い、参加を決めました。 また、インターンシップを通じて入社後どのプロジェクトに所属するかの参考にしたいと思ったのも参加を決めた理由の1つです。

インターンシップで取り組んだこと

インターンシップでは、主にFRRというOSSのソフトウェアルータにBGP-LSの機能を追加し、複数のメーカーの機器(Cisco、Juniper)と相互接続できるよう実装に取り組みました。

現在NTT Comでは大規模なMulti-AS Segment Routing(SR)網の構築、運用を行なっており、その網上で効率的な経路制御を実現するためPath Computation Element(PCE)によるコントローラ制御を目指しています。
Multi-AS SR網はマルチベンダに構成されており、SRv6環境の一部では拡張性を考慮しOSSのFRRを採用しています。 このFRRをコントローラ制御の対象に含めるため、FRRにBGP-LSの機能を実装し、トポロジ情報をコントローラに送信することが求められています。 また、Multi-ASの環境ではASの接続部分でBGP-EPEを行いたいという要求もあり、BGP-EPEの情報をBGP-LSで広告できること(RFC9086, draft-ietf-idr-bgpls-srv6-ext-09)なども鑑みて、BGP-LSは今後必要な機能であると考えられています。

私はBGP-LSというプロトコルの名前は知っていましたが、細かい内容については知らなかったため、始めはプロトコルの理解を目的としてRFC7752, 9085などを読み込んでいきました。
次にFRRの開発も少しかじったことはありましたが、BGPについての開発は初めてでしたので、どのファイルを読めば良いのかが分からず、printデバッグをしながら手探りでFRRの構成を読み解いていきました。 最終的にはFRRにBGP-LSのOpenメッセージを実装し、IOS-XRやJunosとの間でBGPのステートをEstablishedさせることができました。

以下では、BGP-LSの機能や必要性、インターンシップでの開発内容を具体的にご紹介します。

BGP-LSとは

BGP-LSとはBGP Link Stateの略称で、IGPのリンクステート情報や、トラフィックエンジニアリング(TE)情報を伝達するためのプロトコルです。
BGP-LSを利用すれば、複数のIGPドメインのトポロジ情報をPCE等のコントローラに収集することが容易となるため、NTT Comが現在検証を進めているSegment Routingを用いたMulti-AS TEに活用できると考えられます。

f:id:NTTCom:20220322110748p:plain

上図にPCEのユースケースを示します。PCEはPEからBGP-LSによってトポロジ情報を吸い上げて経路を計算し、PCEPでPEに経路を配布します。 これにより、発行済みの経路を一元管理できるようになると共に、帯域や信頼性など経路の状態を考慮した複雑なTEが行えるようになり、効率的な運用を実現できます。

FRRの構造

FRRoutingとは、LinuxやBSDなどの上で動くOSSのソフトウェアルータです。 以下の図がFRRの基本構造となっています。

f:id:NTTCom:20220322110755p:plain

FRRはLinux Server上で動くアプリケーションとなっており、vtyshでユーザの操作をCLIで取得し、その情報をisisdなどのプロトコルデーモンに送信します。
isisdにはLink State Database(LSDB)が存在し、IS-ISというIGPプロトコルによって交換された各Link State情報が格納されています。 このLSDBの情報をpathd内に存在するTraffic Engineering Database(TED)にZAPIを利用してZebra経由でエクスポートし、TEDの情報を元にbgpdがBGP Databaseを変更します。 そして、bgpdがBGP-LSにより他のルータとの間でBGP Databaseとの情報を共有します。
ネットワークスタックの利用にあたっては、ZebraがNetlinkを利用してユーザ空間の情報をカーネル空間に伝達することで行われます。

実装内容

BGP-LSによってLink State情報を複数ルータ間で交換するためには、前提としてルータ間でBGP-LSの接続を確立していなければなりません。BGP-LSの接続を確立するためには、以下の手順が必要となります。

  1. 対象となるBGPスピーカ同士でTCPセッションを確立する
  2. BGP-LSを示すCapabilityの含まれたBGP Openメッセージを送信/受信する
  3. BGP Keep Aliveメッセージを受信する

これらを行うことにより、BGPが確立されたステートとなり、BGP-LSのUpdateメッセージにより実際にBGP-LSのLink State情報を相互に交換し合うことができるようになります。

上記の手順をもう少し厳密に記述すると以下の図のようになります。

f:id:NTTCom:20220322110804p:plain

今回私はインターンシップ期間でBGP-LSが既に実装されているIOS-XRやJunosと、新たに実装を追加したFRRとの間でBGP-LSのEstablishedを実現しました。

初めに、FRRにはBGP-LSのAFIやSAFIが定義されていなかったため、RFCに準拠した定義を実施しました。この際、Zebraの認識するAFI/SAFIとIANAによって定義されているAFI/SAFIの値が異なるため、変換設定も必要となります。
続いて、TCP connectionがOpenになると、BGPのステートはConnectに遷移し bgp_reads_on()bgp_open_send()という2つの関数が呼ばれます。 bgp_reads_on()では、BGP Openメッセージを受信すると適切にパースし、ピアから受信したOpenメッセージの情報を構造体に格納します。 bgp_open_send()では、Openメッセージをピアに送信します。
これら2つの関数は非同期に実行されます。bgp_open_send()関数が呼ばれた際はOpen Sentステートに遷移し、 bgp_open_send()bgp_reads_on()の双方が行われた際にはOpen Confirmステートに遷移します。
あとは既存のBGP Keep Aliveメッセージによって自動でEstablishedステートへと遷移することとなります。

結果

以下がFRR側でBGP-LSのステートを表示させた結果です。

f:id:NTTCom:20220322110811p:plain Stateが(Policy)となっています。 これはBGPステートがEstablishedかつ、Export Filterがないという意味であるため、想定通りBGP-LSがEstabsliehdになっていることが確認できました。

また、以下がIOS-XRやJunos側でBGP-LSのステートを表示させた結果です。 f:id:NTTCom:20220322110818p:plain f:id:NTTCom:20220322110824p:plain

こちらも双方でBGPステートがEstablishedとなることが確認できました。

本インターンでは期間の関係でLSDBのExport機能や関連するshowコマンドの実装まではできませんでしたが、FRRとのコントローラ連携の実現を目指し、今後も開発を進めて行きます。

インターンシップの感想

2週間で名前程度しか知らないプロトコルの調査から始め、現在のBGP-LSの実装状況の調査やインターンシップのゴールをどこに置くかを考え、 ゴールを実現するために1000行以上のソースコードを読み必要な箇所に機能を追加していくという経験は、環境構築や多数のファイルを行き来するコード理解など大変な部分もありましたが最終的には非常に楽しかったです。
メンターの三島さんには頻繁に相談に乗っていただき、そこでプロトコルやFRRの概念の理解の補助をしていただいたり、 ソースコードを読んでいて詰まった時のネクストアクションを提示してくださったりなど、僕がインターンシップを完走出来るよう最大限フォローしていただいたことを大変感謝しています。

フルオンラインのインターンでしたが、業務以外でインターンシップの配属チームの社員さんとオンラインでお酒を飲みながらお話をして、チームの雰囲気を知れる場を用意してくださったり、 自分が興味のある別チームの方とミーティングをセッティングして業務内容を聞く会を開催してくださったりと、 インターンシップを通じて入社後のイメージを掴むための場を最大限提供してくださったことを大変感謝しています。

最後になりますが、本インターンシップでたくさんの貴重な経験をさせていただき本当にありがとうございました。

メンターからのコメント

メンターを担当したイノベーションセンターの三島です。2週間のインターンシップお疲れ様でした。

初日の説明日・最終日の成果報告日や祝日を除くと1週間に満たない作業日でしたが、 NTT Comの背景理解とテーマ設定から始まり、プロトコルのRFC調査を通じた理解やFRRのコードリーティングと実装、検証環境構築や相互接続試験まで検証業務を一連で進めていただきました。 応用的なルーティングプロトコルの機能開発という難易度の高いテーマであったにも関わらず、調査から検証までを自ら進めて成果を出していただけたこと、とても嬉しく思っています。

現在NTT Com イノベーションセンターではMulti-AS SRという独自の大規模SR網を運用しており、BGP-LSはコントローラ連携による効率的な運用のための重要な技術です。 今後も開発を続け、是非FRRへのコントリビューションなど、更なる成果をあげられればと考えています。 より面白いネットワークを実現し価値を提供できるよう、我々も頑張ります!

今回のインターンシップで得た経験が、今後の金谷さんの研究や取り組みに役立てば幸いです。
改めて、インターンシップへの参加とご活躍ありがとうございました!

© NTT Communications Corporation 2014