- ナレッジセンター
- 匠コラム
トランスポートで光るIPv6～IPv6 link-local～②
- 匠コラム
- ネットワーク
- データセンター
ビジネス推進本部 応用技術部
コアネットワークチーム
平河内 竜樹
データセンターネットワークを構築する技術として、ここ数年IPネットワークをトランスポートとしてFabricを構成する「IP Fabric」の注目度が高まっています。本コラムではIP Fabricをよりシンプルに展開するための手段としてIPv6が有するlink-localアドレスの活用に着目し、具体的な構成方法について検証データを交えて紹介します。（後編）
| 連載インデックス |
|---|
IPv6 link-localアドレス上でのIPv4経路交換とBGPピアの自動発見
前回の構成ではIPv6でオーバーレイするため、ユニークとなる様に管理された32-bitのルータIDとは別に、各ノードでLoopbackに対するIPv6アドレスの割り当てが必要となっていました。ルータIDとして利用される値をそのままトンネル終端用のアドレスに転用できれば、ノード固有のIPv6アドレス設定は省略することができます。また、IPv4・IPv6のサービスが主となる場合においては、オーバーレイを併用せずに構成できた方がよりシンプルです。
IPv6のコアに対してトンネルを介さずにIPv4の到達性を確保する場合、保持するIPv4 Prefixに対してIPv6 Next Hopが関連付けられることになるため、それに対応した実装が必要となります。具体的には、上記の経路を生成し交換できること・該当するFIBおよびAdjacency Tableを構築できること・対象となる通信の転送処理が可能であることなどが要求されます。
また、IP FabricのルーティングをBGPのみで実現しようとした場合、シングルホップでBGPピアを確立することになるため、BGPピアに対するアドレスの指定がリンク単位で発生する点に留意が必要です。この点はOTT事業者のネットワークでも課題に挙げられており、一つの解決策としてLLDPによるBGPピアの自動発見機構が2017年に新しく提出されています（□ □）。この仕様はASNなどの情報もエンコーディングされることに加えて、IPv4・IPv6双方のトランスポートに対応しており、またLoopback間のピアリングにも適用できるものとなっています。
なお現段階でBGPピアの自動発見とIPv6トランスポート上でのIPv4経路交換を同時に満たすことが可能な実装としては、『BGP unnumbered』と呼ばれる機能が存在し、オープンソース実装として公開されているFRRouting（□ □）で利用可能になっています。この機能を利用した場合、BGPの設定はIGPと同様にインタフェースで指定する形式で行われ、またそのインタフェースに対するアドレッシングは不要となります。これにより、中継リンクに対するアドレス設定の省略とBGP設定の共通化を実現することが可能になります。
BGP unnumberedでは、IPv6 link-localアドレスを利用したBGPピアの確立が行われています。関連仕様とされるRFC5549では、IPv6をコアに用いたIPv4 / VPNv4サービスを実現するNLRIやCapability Advertisementが規定されている一方で、IPv6ピア自動発見の具体的な手順は含まれていません。本機能は、対象のリンク上で交換されるICMPv6のRA (Router Advertisement) を経由してBGPピアの自動発見を実現し、IPv6 link-localアドレスを利用して確立されたBGPセッションの上で前述のBGPメッセージを交換します。当初はFRRoutingのコントリビュータであるCumulus Networks社の製品で実装されていたものとなり、同社の資料で詳細が解説されています。
BGP unnumbered：試験の環境と結果
ここからはFRRouting 3.1-devを対象としてBGP unnumbered機能を利用した際の検証データを紹介します。図1は試験の構成図、表1・表2は設定の抜粋となります。
表1：設定の抜粋（iproute2）
| Core-01 |
ip address add 10.0.0.100/32 dev lo ip link set dev ens192 address 00:00:00:00:01:00 ip link set ens192 up ip link set dev ens224 address 00:00:00:00:01:00 ip link set ens224 up vconfig add ens192 101 ip link set dev ens192.101 address 00:00:00:10:11:00 ip link set ens192.101 up vconfig add ens224 201 ip link set dev ens224.201 address 00:00:00:20:11:00 ip link set ens224.201 up |
| Core-02 |
ip address add 10.0.0.200/32 dev lo ip link set dev ens192 address 00:00:00:00:02:00 ip link set ens192 up ip link set dev ens224 address 00:00:00:00:02:00 ip link set ens224 up vconfig add ens192 102 ip link set dev ens192.102 address 00:00:00:10:22:00 ip link set ens192.102 up vconfig add ens224 202 ip link set dev ens224.202 address 00:00:00:20:22:00 ip link set ens224.202 up |
| Edge-01 |
ip address add 10.0.0.1/32 dev lo ip link set dev ens192 address 00:00:00:00:00:01 ip link set ens192 up vconfig add ens192 101 ip link set dev ens192.101 address 00:00:00:10:10:01 ip link set ens192.101 up vconfig add ens192 102 ip link set dev ens192.102 address 00:00:00:10:20:01 ip link set ens192.102 up |
| Edge-02 |
ip address add 10.0.0.2/32 dev lo ip link set dev ens192 address 00:00:00:00:00:02 ip link set ens192 up vconfig add ens192 201 ip link set dev ens192.201 address 00:00:00:20:10:02 ip link set ens192.201 up vconfig add ens192 202 ip link set dev ens192.202 address 00:00:00:20:20:02 ip link set ens192.202 up |
| Core-01 |
router bgp 65001
no bgp default ipv4-unicast
neighbor CORE peer-group
neighbor CORE remote-as internal
neighbor CORE capability extended-nexthop
neighbor ens192.101 interface peer-group CORE
neighbor ens224.201 interface peer-group CORE
address-family ipv4 unicast
redistribute connected route-map LOOPBACK
neighbor CORE activate
neighbor CORE route-reflector-client
exit-address-family
route-map LOOPBACK permit 10
match interface lo
|
| Core-02 |
router bgp 65001
no bgp default ipv4-unicast
neighbor CORE peer-group
neighbor CORE remote-as internal
neighbor CORE capability extended-nexthop
neighbor ens192.102 interface peer-group CORE
neighbor ens224.202 interface peer-group CORE
address-family ipv4 unicast
redistribute connected route-map LOOPBACK
neighbor CORE activate
neighbor CORE route-reflector-client
exit-address-family
route-map LOOPBACK permit 10
match interface lo
|
| Edge-01 |
router bgp 65001
no bgp default ipv4-unicast
neighbor CORE peer-group
neighbor CORE remote-as internal
neighbor CORE capability extended-nexthop
neighbor ens192.101 interface peer-group CORE
neighbor ens192.102 interface peer-group CORE
address-family ipv4 unicast
redistribute connected route-map LOOPBACK
neighbor CORE activate
exit-address-family
route-map LOOPBACK permit 10
match interface lo
|
| Edge-02 |
router bgp 65001
no bgp default ipv4-unicast
neighbor CORE peer-group
neighbor CORE remote-as internal
neighbor CORE capability extended-nexthop
neighbor ens192.201 interface peer-group CORE
neighbor ens192.202 interface peer-group CORE
address-family ipv4 unicast
redistribute connected route-map LOOPBACK
neighbor CORE activate
exit-address-family
route-map LOOPBACK permit 10
match interface lo
|
各リーフノードにおけるLoopback間のIPv4通信可否を試験項目とし、上記の設定を行ったところ、通信の成功が確認できました。併せてこの状態では、IPv6 link-localアドレスを指定したpingによって、隣接ノードとの疎通確認が可能となっていました。また、本構成が該当する様にスパインノードのLoopbackにIPv4アドレスを設定している場合、IPv4のtracerouteに対して経由スパインが応答することを試験の過程で確認しています。
なお表1の中で、インタフェースのMACアドレスに関する設定は省略しても疎通性の上では何ら問題ありません。本環境のlink-localアドレスはMACアドレスから生成されるEUI-64形式ですが、BGP unnumberedではRAを経由して対向のアドレス情報を動的に取得するため、値が予測可能である必要はありません。試験の過程では一組のBGPスピーカ間でTCP/179を利用する側がタイミングによって異なることを確認しており、各々が発見したアドレスに対してピアリングを試みていることが窺えました。
中継リンクに接続されるインタフェース名は、試験環境の都合でトランスポートネットワークにVLANを適用しているため同じ階層のノード間で一致していませんが、実際には利用ポートのナンバリングが揃っている範囲で共通化が可能です。また今回の設定ではルータIDはLoopbackから選出したものを利用していますが、手動で指定する際も通常は同じ値を使用することになるため、どちらの方法でもノード固有の指定情報としては1種類の32-bit値とすることができます。
注目すべき点として、ルートリフレクタを利用しシングルASで構成している状態において、BGPネクストホップに関する特段の設定を行わずに疎通可能となっていることが挙げられます。BGP交換を観察した結果、ルートリフレクタとして設定されたスパインノードがBGPネクストホップを自身のlink-localアドレスに置き換えて送信している様子が確認できました（図2）。
なおルートリフレクタにおけるネクストホップの書き換えは、行われない動作が基本であり（□）、書き換えの設定を加えても効果が及ばない・専用の設定が必要となるといったBGP実装も存在します。RFC5549の記述でもルートリフレクタはネクストホップを維持する際の例として挙げられています。このため、他のケースで今回の様な動作が可能であるかは実装依存となる可能性があります。
また、IPv4の転送テーブルではネクストホップにIPv4のリンクローカルアドレスが表示されていました（図3）。Adjacency Table を参照すると隣接機器のMACアドレスがIPv4とIPv6双方のリンクローカルアドレスに対して表示されており、結果、転送テーブル上にIPv6アドレスが表出しない形となっていました。
上記の図4は、FRRouting内のshowコマンド出力になります。RFC5549の対応を踏まえればネクストホップの欄にはIPv6アドレスが表示されることが想定され、実際に別の製品で構成を組んだ際にはそのように出力されるケースを確認しています。対して本機能では図4の出力にある通りインタフェース名が表示され、人目にはより直感的に状態を把握することが可能になっていました。その他、表記に関連する内容としては、OPENメッセージにhostnameがエンコーディングされておりBGPのshowコマンドで表示されることを併せて確認しています。
なお図3における出力上の169.254.0.1は、互いがリンクの両端であっても常にこの値が用いられており、内部的な利用であることが窺えます。本機能はunnumberedの名称から連想される通り、リンクがポイントツーポイントであることを前提として動作し、またブリッジ経由で3ノードが接続される環境に適用した際には2ノード間でしかピアリングが行われないことを試験の過程で確認しています。RFC5549の内容はこのような制限を課すものではありませんが、前述の通りピアのアドレスを意識せずに設定や状態確認を行うことができ、管理のシンプルさを重視した実装と言えます。一面で複数のBGPスピーカとピアリングを行うケースには適用できないものの、配線に制約のない独立した環境に対して管理上の利点を提供できる機能となっています。
IPv6のBGPピア上で交換されたIPv4経路を利用して、オーバーレイ構成を取ることも勿論可能です。前回のIPv6アンダーレイと比較すると、共通化が困難な固有情報に関しては、今回の構成ではノード単位のIPv4アドレス1種類となっています。リンク数に依存した個別設定の排除は双方のパターンにおいて実現することができるため、他の要件や導入のハードルなど、利用の際には状況に応じて適切な技術を選択することになります。
実際には、サービス提供とは別の観点で、ホスト名や管理用のIPアドレスもノード固有の設定となります。各機器の初期設定を完全に共通化したい場合は、ゼロタッチプロビジョニングと呼ばれる機能で外部から設定情報を引いてくる手法が適合します。その際も配備する設定の可変要素がこれまで挙げた手法によって限定されれば管理情報がシンプルなものとなります。またそういった仕組みを併用しない際は、同様にノードのIDに類する情報のみをマニュアルで指定することによって、展開の簡素化を図ることができます。
BGP unnumbered：補足
追加の試験として、BGP unnumberedで構築されたIPv4ネットワークをアンダーレイに用い、FRRoutingのEVPNを併用したVXLAN通信の疎通性確認を行いました。
本項では3層の5-stage Closトポロジを組み、「サービスとなるEVPN経路の交換は外付けのルートリフレクタを用いたIBGP」「トランスポートとなるLoopbackに対する経路の交換は階層単位でASNを割り当てたEBGP」の構成を取りました。VPNシグナリングの中継をデータ転送の伝送路上に含めた際には、例えば同じスパインの階層でも、ノード間で設定に目立った差が生じることがあります。この場合VPNシグナリングの中継を専用のノードに切り出すことができれば、スパインノードに必要なルーティング設定はトランスポートに関するものだけとなり、オーバーレイ環境における設定の共通化においてもプラスに働きます。
以下に示す図5は利用したプロトコルの組み合わせ、図6は試験の構成図、表3・表4は設定の抜粋となります。
表3：設定の抜粋（FRRouting：アンダーレイ）
| CORE-01 / CORE-02 / CORE-03 / CORE-04 |
router bgp 64999
no bgp default ipv4-unicast
neighbor CORE peer-group
neighbor CORE remote-as external
neighbor CORE capability extended-nexthop
neighbor <i/f_1> interface peer-group CORE
neighbor <i/f_2> interface peer-group CORE
neighbor <i/f_3> interface peer-group CORE
neighbor <i/f_4> interface peer-group CORE
neighbor <i/f_5> interface peer-group CORE ##CORE-01/02_to_RR-00
neighbor <i/f_6> interface peer-group CORE ##CORE-01/02_to_RR-09
address-family ipv4 unicast
redistribute connected route-map LOOPBACK
neighbor CORE activate
neighbor CORE allowas-in
exit-address-family
route-map LOOPBACK permit 10
match interface lo
|
| CORE-100 / CORE-105 / CORE-200 / CORE-205 |
router bgp 65000
no bgp default ipv4-unicast
neighbor CORE peer-group
neighbor CORE remote-as external
neighbor CORE capability extended-nexthop
neighbor <i/f_1> interface peer-group CORE
neighbor <i/f_2> interface peer-group CORE
neighbor <i/f_3> interface peer-group CORE
neighbor <i/f_4> interface peer-group CORE
neighbor <i/f_5> interface peer-group CORE
address-family ipv4 unicast
redistribute connected route-map LOOPBACK
neighbor CORE activate
neighbor CORE allowas-in
exit-address-family
route-map LOOPBACK permit 10
match interface lo
|
| RR-00 / RR-09 / Edge-10 / Edge-20 |
router bgp 65001
no bgp default ipv4-unicast
neighbor CORE peer-group
neighbor CORE remote-as external
neighbor CORE capability extended-nexthop
neighbor <i/f_1> interface peer-group CORE
neighbor <i/f_2> interface peer-group CORE
address-family ipv4 unicast
redistribute connected route-map LOOPBACK
neighbor CORE activate
neighbor CORE allowas-in
exit-address-family
route-map LOOPBACK permit 10
match interface lo
|
| RR-00 / RR-09 |
router bgp 65001
neighbor VPN peer-group
neighbor VPN remote-as internal
neighbor VPN update-source lo
bgp listen range 10.0.0.0/8 peer-group VPN
address-family l2vpn evpn
neighbor VPN activate
neighbor VPN route-reflector-client
exit-address-family
|
| Edge-10 / Edge-20 |
router bgp 65001
neighbor VPN peer-group
neighbor VPN remote-as internal
neighbor VPN update-source lo
neighbor 10.0.0.0 peer-group VPN
neighbor 10.0.0.9 peer-group VPN
address-family l2vpn evpn
neighbor VPN activate
advertise-all-vni
exit-address-family
|
テスターからトラフィックを印加した結果、VXLAN通信が疎通することを確認できました。また期待通り、スパインノードの設定はトランスポート関連のものに限られました。
図7は各機器の経路表、図8はEVPNの状態、図9はテスターからのpingをキャプチャした結果になります。
EVPNにおけるRoute-Targetの自動生成にはASNの値が利用されるため（□）、各NVEには同一のASNを割り当てると自動生成機能をそのまま利用することができます。またトランスポートのEBGPに対しては、受信した経路の送信元と同一のネイバーASに対する経路広報およびASパスにおける同一ASNの再出現を許容するBGP機能を有効にすることによって、各階層でASNを再利用することができました。
まとめ
今回の試験構成としてFRRoutingで利用可能なBGP unnumbered機能を適用したところ、インタフェースの指定によってBGPのピアリングが可能となり、交換したIPv4経路に対する疎通性を確認することができました。この状態で機器固有の設定は、各階層で共通化が容易なインタフェース情報の他では、「Loopbackに対するIPv4アドレス」の1種類となりました。
追加試験としてBGPによって交換されたIPv4経路を基盤とするEVPN-VXLANを適用したところ、オーバーレイとアンダーレイ双方にBGPが適用された状態で、各階層で上記と同様に設定の共通化を実現することができました。
これまでの結果を総じて、実装の広まりが今後となる要素技術はあるものの、IP Fabricのシンプル化および高度化を実現する手段としてIPv6は有用な選択肢となることが期待されます。
関連記事
- RFC 7404 – Using Only Link-Local Addressing inside an IPv6 NetworkUsing Only Link-Local Addressing inside an IPv6 Network
- BGP in the Data Center
執筆者プロフィール
平河内 竜樹
ネットワンシステムズ株式会社 ビジネス推進本部
応用技術部 コアネットワークチーム
所属
ルータ分野を核とした新旧技術の調査・検証と共に、エンタープライズ・パブリック・サービスプロバイダのネットワーク提案および導入を支援する業務に、10年以上にわたり従事
- CCIE RS
- CCIE SP
Webからのお問い合わせはこちらから
ナレッジセンターを検索する
カテゴリーで検索
タグで検索