- ナレッジセンター
- 匠コラム
L2サービスのコントロールプレーンとデータプレーン～BGP/SRv6～
- 匠コラム
- ネットワーク
- データセンター
- 仮想化
ビジネス開発本部
第3応用技術部 第3チーム
平河内 竜樹
本記事では、SRv6を用いてE-LANサービスを提供する構成に着目し、EVPN over SRv6の基本的な動作や他の技術と比較した際の特徴について、検証データを交えて紹介します。
本ページには、主に下記の情報が含まれています。
また、「おわりに」の項にて全体のまとめを記載しております。先に概要を把握された方はこちらからご覧いただければと思います。
|
はじめに
データセンターネットワークの分野では、IPのトランスポート上でイーサネットの接続性（以下、「L2サービス」と呼びます）を提供可能な技術として、VXLANが広く活用されています。VXLANは、主にレイヤ2の物理ネットワークに起因する課題への対処を発端としていますが、レイヤ2に対応したIP Fabricの構築技術としても多く利用されています。昨今では、VXLANv6などと呼ばれるコアネットワークのIPv6対応やBGP unnumberedに代表されるような技術との組み合わせに関してもサポートが進み、設定の簡素化などを実現できることから、新たに加味されて検討される要素も拡張されていると言えます。
一方、Traffic Engineering （TE）を実現する技術としては、今もMPLSが中心的な存在となっています。この要求は、制約の発生が多いWAN環境で多く発生する傾向にある一方で、環境によっては、データセンターのサーバ収容ネットワークといった箇所で挙がることもあり得ます。ただ、コストや複雑さなどの面から、このエリアへのMPLS導入は相当のハードルが存在し、多くは要求の変更やTE パスを必要としない範囲での実現といった形で対処していたことが想定されます。
この点に関してSRv6は、MPLSの利用をコントロールプレーン・データプレーンの双方から排した上で、仕様としてはMPLSと同様のTE機能を提供することが可能です。割り当てられるSRv6 SIDがSRv6 Locatorに属することから、特段の工夫が無くともlocally significantな値は存在しない状態が形成され、よりPure IP環境に近い運用性が期待できる点もメリットになり得ます。勿論、VXLANv6等と同様に、自然な形でリンクローカルアドレスを利用することも可能です。
こういった経緯からSRv6の活用によって、所要コストの側面は予測が困難なところがあるものの、TE導入の敷居を下げられることが期待できます。また、そのような要求が直近に存在していない環境においても、将来への対応に適した構成技術といった側面が採用のモチベーションとして作用する場面もあるかもしれません。データセンターはネットワーク新設の機会が多い領域でもあり、新規技術の採用ハードルという面でも、SRv6の導入検討が進む領域と言えます。
SRv6のL2サービス対応状況について
現在の商用SRv6実装の対応サービスはL3が中心です。データプレーンの機能だけであれば、既にL2サービスへ対応している実装も散見されますが、特に物理ネットワークで利用する場合は、エッジ機器に対する冗長化などの観点でコントロールプレーンの対応も重要となります。なお、以前の記事で挙がったMulti-Vendor Interoperability Test 2020における「EVPN over SRv6」の項ではE-Lineの文言が確認でき、また2021年の同イベントではキックオフ資料によると「L2/L3VPN Services using EVPN Control Plane and SRv6 Data Plane」がリストされています。今後E-Line以外のSRv6 L2サービス実装に関しても、試験結果として公開される可能性が考えられます。
今回は、SRv6によるEVPN Bridging（以下、本稿ではとりわけこれを指して「EVPN over SRv6」と呼びます）が既に実装されているfreeRouterを用い、基本的な疎通性の確認を通じて、その挙動を観察することにしました。事前の調査では準拠しているI-D版数の情報を発見することができず、仕様と照合する際には、試験の時点で最新であった以下の文書を用いて行っています。
|
draft-ietf-spring-srv6-network-programming-28 - SRv6 Network Programming draft-ietf-bess-srv6-services-05 - SRv6 BGP based Overlay services |
また、Segment RoutingおよびSRv6については、解りやすく整理された資料が多く公開されている他、以前の記事における補足資料でも技術情報を整理しています。必要に応じてご参照いただければと思います。
EVPN over SRv6：試験の環境と結果
以下の図1は、試験の構成図、表1・表2は、エッジノードとなるfreeRouterに投入した設定の抜粋となります。トランスポートネットワークでは、IPv6アドレスのみが設定された状態となり、トランスポートレイヤに対するSRv6 SIDは割り当てられないことを踏まえ、必要となるルーティングは全てstaticで行いました。サービスとしてはマルチポイントに対応したイーサネットの接続性が提供される形態です。なお、今回の環境では試験の都合上、コアネットワークに接続されるインタフェースに対してLAGを適用し、さらに各インタフェースへMACアドレスの設定を行っています。
|
Edge-10 |
bundle 1 exit vrf definition GLOBAL rd 65001:0 label-mode per-prefix exit interface loopback0 vrf forwarding GLOBAL ipv6 address 2001:db8::10 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff exit interface bundle1 macaddr 0000.0001.1010 vrf forwarding GLOBAL ipv6 address fd10::10 ffff:ffff:ffff:ffff:: exit ipv6 route GLOBAL :: :: fd10::1 |
|
Edge-20 |
bundle 1 exit vrf definition GLOBAL rd 65001:0 label-mode per-prefix exit interface loopback0 vrf forwarding GLOBAL ipv6 address 2001:db8::20 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff exit interface bundle1 macaddr 0000.0001.2020 vrf forwarding GLOBAL ipv6 address fd20::20 ffff:ffff:ffff:ffff:: exit ipv6 route GLOBAL :: :: fd20::1 |
|
Edge-30 |
bundle 1 exit vrf definition GLOBAL rd 65001:0 label-mode per-prefix exit interface loopback0 vrf forwarding GLOBAL ipv6 address 2001:db8::30 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff exit interface bundle1 macaddr 0000.0001.3030 vrf forwarding GLOBAL ipv6 address fd30::30 ffff:ffff:ffff:ffff:: exit ipv6 route GLOBAL :: :: fd30::1 |
|
Edge-10 |
bridge 2 rd 65001:2 rt-import 65001:2 rt-export 65001:2 mac-learn private-bridge exit vrf definition IP-VRF rd 65001:1 exit interface bvi2 macaddr 0000.0000.0210 vrf forwarding IP-VRF ipv4 address 10.68.2.201 255.255.255.0 exit interface tunnel1 tunnel vrf GLOBAL tunnel source loopback0 tunnel destination 2001:db8:0:10:: tunnel mode srv6 vrf forwarding GLOBAL ipv6 address 2001:db8:0:10:: ffff:ffff:ffff:ffff:: exit router bgp6 65001 vrf GLOBAL local-as 65001 router-id 10.0.0.10 address-family evpn neighbor 2001:db8::20 remote-as 65001 neighbor 2001:db8::20 local-as 65001 neighbor 2001:db8::20 address-family evpn neighbor 2001:db8::20 update-source loopback0 neighbor 2001:db8::20 pmsitun neighbor 2001:db8::20 segrout neighbor 2001:db8::20 send-community standard extended neighbor 2001:db8::30 remote-as 65001 neighbor 2001:db8::30 local-as 65001 neighbor 2001:db8::30 address-family evpn neighbor 2001:db8::30 update-source loopback0 neighbor 2001:db8::30 pmsitun neighbor 2001:db8::30 segrout neighbor 2001:db8::30 send-community standard extended afi-evpn 5002 bridge-group 2 afi-evpn 5002 srv6 tunnel1 afi-evpn 5002 encapsulation cmac afi-evpn 5002 update-source loopback0 exit |
|
Edge-20 |
bridge 2 rd 65001:2 rt-import 65001:2 rt-export 65001:2 mac-learn private-bridge exit vrf definition IP-VRF rd 65001:1 exit interface bvi2 macaddr 0000.0000.0220 vrf forwarding IP-VRF ipv4 address 10.68.2.202 255.255.255.0 exit interface tunnel1 tunnel vrf GLOBAL tunnel source loopback0 tunnel destination 2001:db8:0:20:: tunnel mode srv6 vrf forwarding GLOBAL ipv6 address 2001:db8:0:20:: ffff:ffff:ffff:ffff:: exit router bgp6 65001 vrf GLOBAL local-as 65001 router-id 10.0.0.20 address-family evpn neighbor 2001:db8::10 remote-as 65001 neighbor 2001:db8::10 local-as 65001 neighbor 2001:db8::10 address-family evpn neighbor 2001:db8::10 update-source loopback0 neighbor 2001:db8::10 pmsitun neighbor 2001:db8::10 segrout neighbor 2001:db8::10 send-community standard extended neighbor 2001:db8::30 remote-as 65001 neighbor 2001:db8::30 local-as 65001 neighbor 2001:db8::30 address-family evpn neighbor 2001:db8::30 update-source loopback0 neighbor 2001:db8::30 pmsitun neighbor 2001:db8::30 segrout neighbor 2001:db8::30 send-community standard extended afi-evpn 5002 bridge-group 2 afi-evpn 5002 srv6 tunnel1 afi-evpn 5002 encapsulation cmac afi-evpn 5002 update-source loopback0 exit |
|
Edge-30 |
bridge 2 rd 65001:2 rt-import 65001:2 rt-export 65001:2 mac-learn private-bridge exit vrf definition IP-VRF rd 65001:1 exit interface bvi2 macaddr 0000.0000.0230 vrf forwarding IP-VRF ipv4 address 10.68.2.203 255.255.255.0 exit interface tunnel1 tunnel vrf GLOBAL tunnel source loopback0 tunnel destination 2001:db8:0:30:: tunnel mode srv6 vrf forwarding GLOBAL ipv6 address 2001:db8:0:30:: ffff:ffff:ffff:ffff:: no shutdown exit router bgp6 65001 vrf GLOBAL local-as 65001 router-id 10.0.0.30 address-family evpn neighbor 2001:db8::10 remote-as 65001 neighbor 2001:db8::10 local-as 65001 neighbor 2001:db8::10 address-family evpn neighbor 2001:db8::10 update-source loopback0 neighbor 2001:db8::10 pmsitun neighbor 2001:db8::10 segrout neighbor 2001:db8::10 send-community standard extended neighbor 2001:db8::20 remote-as 65001 neighbor 2001:db8::20 local-as 65001 neighbor 2001:db8::20 address-family evpn neighbor 2001:db8::20 update-source loopback0 neighbor 2001:db8::20 pmsitun neighbor 2001:db8::20 segrout neighbor 2001:db8::20 send-community standard extended afi-evpn 5002 bridge-group 2 afi-evpn 5002 srv6 tunnel1 afi-evpn 5002 encapsulation cmac afi-evpn 5002 update-source loopback0 exit |
図1：試験の構成図 |
今回の試験では、3つのサイト間でそれぞれの組み合わせに対してIPv4のサブネット内通信を発生させることにより、SRv6ドメインが複数のサイトに対応したイーサネットの接続性を提供可能であるかの確認を行います。まず、転送対象のMACアドレスが学習されていない状態とするためにbviインタフェースのシャットダウンを行い、BGPピアの確立を行いました。この時の各ノードのCLI出力結果およびBGPのキャプチャ結果が表3・図2になります。
|
Core-01 |
Core01#show ipv6 route
IPv6 Routing Table - default - 14 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, RL - RPL, O - OSPF Intra, OI - OSPF Inter
OE1 - OSPF ext 1, OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1
ON2 - OSPF NSSA ext 2, la - LISP alt, lr - LISP site-registrations
ld - LISP dyn-eid, lA - LISP away, a - Application
LC 2001:DB8::1/128 [0/0]
via Loopback0, receive
S 2001:DB8::10/128 [1/0]
via FD10::10
S 2001:DB8::20/128 [1/0]
via FD20::20
S 2001:DB8::30/128 [1/0]
via FD30::30
S 2001:DB8:0:10::/64 [1/0]
via FD10::10
S 2001:DB8:0:20::/64 [1/0]
via FD20::20
S 2001:DB8:0:30::/64 [1/0]
via FD30::30
C FD10::/64 [0/0]
via GigabitEthernet1, directly connected
L FD10::1/128 [0/0]
via GigabitEthernet1, receive
C FD20::/64 [0/0]
via GigabitEthernet2, directly connected
L FD20::1/128 [0/0]
via GigabitEthernet2, receive
C FD30::/64 [0/0]
via GigabitEthernet3, directly connected
L FD30::1/128 [0/0]
via GigabitEthernet3, receive
L FF00::/8 [0/0]
via Null0, receive
Core01#
|
|
Edge-10 |
Edge10#show ipv6 route GLOBAL typ prefix metric iface hop time S ::/0 1/0 bundle1 fd10::1 00:14:36 C 2001:db8::10/128 0/0 loopback0 null 06:16:26 C 2001:db8:0:10::/64 0/0 tunnel1 null 06:16:26 LOC 2001:db8:0:10::/128 0/1 tunnel1 null 06:16:26 C fd10::/64 0/0 bundle1 null 00:14:36 LOC fd10::10/128 0/1 bundle1 null 00:14:36 Edge10# |
|
Edge-20 |
Edge20#show ipv6 route GLOBAL typ prefix metric iface hop time S ::/0 1/0 bundle1 fd20::1 00:14:30 C 2001:db8::20/128 0/0 loopback0 null 7d21h C 2001:db8:0:20::/64 0/0 tunnel1 null 7d20h LOC 2001:db8:0:20::/128 0/1 tunnel1 null 7d20h C fd20::/64 0/0 bundle1 null 00:14:30 LOC fd20::20/128 0/1 bundle1 null 00:14:30 Edge20# |
|
Edge-30 |
Edge30#show ipv6 route GLOBAL typ prefix metric iface hop time S ::/0 1/0 bundle1 fd30::1 00:05:26 C 2001:db8::30/128 0/0 loopback0 null 06:16:53 C 2001:db8:0:30::/64 0/0 tunnel1 null 06:16:52 LOC 2001:db8:0:30::/128 0/1 tunnel1 null 06:16:52 C fd30::/64 0/0 bundle1 null 00:05:26 LOC fd30::30/128 0/1 bundle1 null 00:05:26 Edge30# |
図2：EVPN Route Type 3のキャプチャ結果（Edge-10からEdge-20に向けて送信されたもの） |
図2より、SRv6 SID を含むBGP Prefix-SID attributeが付与された状態で、EVPN Route Type 3の経路が交換されていることを確認できました。またCLIの出力よりEVPNの経路がインポートされた様子が窺え、この状態でBUM転送が可能になったことが期待されます。
その後、bviインタフェースの有効化を行い、3サイトの組み合わせにおける各bviインタフェース間でIPv4のpingを3サイトの各ペアに対して順に実行したところ、いずれも成功が確認できました。その際のキャプチャ結果を観察すると、pingに伴って実行されたARPの通信は全て0.1秒以内に完了し、SRドメイン内で継続的に転送される状態は発生していないこと・Pingの通信は常に宛先となるlocatorに属するSIDでEncapsulationされていたこと・IPv6でEncapsulationされたすべての通信に対しHop Limitは最小で254であったことが読み取れました。
今回の試験結果より、L2 BroadcastとなるARPおよびL2 UnicastとなるIPv4のサブネット内通信が3つのサイト間で、それぞれ最短ホップにて疎通すること・SRドメインを出入りするようなループは発生していないこと、そしてL2 Unicastの通信は宛先が存在しないサイト宛には配送されていないことを確認できました。図3は本項で交換されていたBGPのキャプチャ結果になります。
図3：EVPN Route Type 2のキャプチャ結果（Edge-10からEdge-20に向けて送信されたもの） |
図3より、EVPN Route Type 3と同じく、自身のlocatorに属するSIDがエンコーディングされていることが窺えます。この値は、データ転送のEncapsulationに利用される宛先IPアドレスと一致することをあわせて確認しています。
Encapsulationに関する補足として、今回の環境ではSRHは一度も観測されませんでした。ヘッドエンドでは、H.Encaps.L2.Redに相当するbehaviorが実行されていることになります。また、送信元IPアドレスのフィールドでは、宛先IPアドレスと同じ値が利用されていました。設定上の不備を含め、この原因を明らかにするためには追跡調査を必要とする状況ですが、今回の試験においては確認項目を妨げるものとはなりませんでした。
また、図2・図3から、今回発生したEVPN経路に付与されるBGP Prefix-SID attributeでは、IANAで掲載されているL2サービス用の値（図4）を使用していることが確認できました。
図4：BGP Prefix-SIDのTLVタイプ（IANAのBorder Gateway Protocol (BGP) Parametersより抜粋） |
最後に、VLAN IDが関連付けられるbviインタフェースをEdge-10・Edige-20にて追加で作成し、疎通に必要となる設定を確認しました。以下の表4は、追加で投入された設定になります。これより、収容対象となるVLANが追加された際においても、設定変更が必要となる箇所はVLANが追加された部位のみであり、また接続先に依存した情報を含まないことが確認できました。
|
Edge-10 / Edge-20共通 |
bridge 3 rd 65001:3 rt-import 65001:3 rt-export 65001:3 mac-learn private-bridge exit router bgp6 65001 afi-evpn 5003 bridge-group 3 afi-evpn 5003 srv6 tunnel1 afi-evpn 5003 encapsulation cmac afi-evpn 5003 update-source loopback0 exit |
|
Edge-10 |
interface bvi3 macaddr 0000.0000.0310 vrf forwarding IP-VRF ipv4 address 10.68.3.201 255.255.255.0 exit |
|
Edge-20 |
interface bvi3 macaddr 0000.0000.0320 vrf forwarding IP-VRF ipv4 address 10.68.3.202 255.255.255.0 exit |
なお、トランスポートネットワークに対するルーティングテーブル関して、試験を通じて表3の状態から各ノード共に変化は無く、必要となる経路は唯一設定されたデフォルトルートで対応されていることが窺えます。これまでの結果より、E-LANサービスの形成に必要な基本的な動作は、概ね期待通りに行われていることが確認できました。
EVPN over SRv6：SRv6 SIDの値と冗長化構成における留意点
設定（表2・表4）とBGPのキャプチャ結果（図2・図3）の情報から、今回の試験で利用されているSRv6 SIDに着目すると、SRv6 Locator相当のprefixから動的に決定されていること、そしてUnicast転送とBUM転送で同一の値が利用されていることが窺えます。後者に関して、実行される基本的なSRv6 Endpoint Behaviorは、Unicast転送ではEnd.DT2U（またper-Host/CEでSIDがアサインされている場合の選択肢としてEnd.DX2）・BUM転送ではEnd.DT2Mとなります。BGPのエンコーディングにおいても、EVPN Route Type 2およびEVPN Route Type 3に付与されるBGP Prefix-SID attributeに対し、対応するbehaviorのSIDが格納されることが示されています（図5・図6）。
図5：EVPN over SRv6におけるRoute Type 2の情報（draft-ietf-bess-srv6-services-05より抜粋） |
図6：EVPN over SRv6におけるRoute Type 3の情報（draft-ietf-bess-srv6-services-05より抜粋） |
なお、SRv6 SIDを参照してbehaviorを特定するためには、各behaviorに固有のSIDが必要となる一方、通信がL2 のUnicastであるかBroadcast/Multicastであるかは宛先MACアドレスから判断することができます。今回の試験対象はSRv6 SIDには共通の値を用い、behaviorは、宛先MACアドレスの値によって決定する実装になっているものと推察されます。
上記の動作でunknown unicastのL2通信が発生した場合、対象のMACエントリが存在しないことを認識したingress nodeではflooding処理に伴い、BUM転送を行います。しかし、トランスポートネットワークがIP Unicastのみで構成される場合、ingress nodeにとってknownであるかunknownであるかの識別を受信側のegress nodeで行うための情報はヘッダ上に存在しません。今回のようにシングルホーム環境であれば、egress nodeにおけるMACエントリの有無で転送処理を決定できますが、All-Active redundancy mode のEVPN を用いたマルチホーム構成の場合、DFではないノードで受信したunknown unicastの通信をフィルタするという動作が実現できないことになります。
この問題は、EVPN Overlay標準化過程の段階で指摘され、VXLANの場合、予約フィールドをBUM識別のためのビットとして利用する方法がRFC8365で挙げられています（□□）。Unicast転送とBUM転送で異なるVPNラベルが割り当てられるEVPN-MPLSおよびPBB-EVPNの場合、この問題は発生しません。現象は通信の破棄ではなく重複送出であること・MAC学習が完了すれば解消されることなどから、必ずしも問題視されるとは限りませんが、対象とするSRv6実装でE-LANサービスのエッジ冗長が可能となった場合、その実現技術としてEVPNが利用されるか・利用される場合はBUM転送に固有のSRv6 SIDが割り当てられDF filteringが期待通りに実行されるは留意点の一つとなります。
なおDF filteringとは別に、All-Active redundancy modeで必須となるsplit-horizon filteringの動作については、End.DT2Mの中で定められています。ただシングルホーム構成であれば、フィルタ対象となる出力インタフェースは存在しないことになるため、結果として処理はEnd.DT2U でMACエントリが存在しなかった際のelseで行われるものと等価になります（図7・図8）。
図7：End.DT2Mの処理（draft-ietf-spring-srv6-network-programming-28より抜粋） |
図8：End.DT2Uの処理（draft-ietf-spring-srv6-network-programming-28より抜粋） |
シングルホーム構成では、End.DT2M固有の動作が行われる機会はなく、今回の試験対象に関しても、SIDの値だけでなくbehaviorもUnicast転送とBUM転送で共通のものとして実装されている可能性が考えられます。
また、IPトランスポートという点でSRv6と同様である、EVPN-VXLANのsplit-horizon filteringはLocal Biasと呼ばれる方式で行われています（図9）。Local Biasは識別情報にIPアドレスを利用し、フィルタ動作がEthernet Segment（以下、ESと呼びます）単位ではなくノード単位で行われるため、この点は環境によって設計上の制約になり得ます。SRv6を用いたEVPNでは、送信元IPアドレスが付与された上でES単位のSID割り当てが可能であるため、split-horizon filteringの方式を選択して利用することができます。この点の選択肢がより柔軟である点は、VXLANと比較したSRv6の利点の一つとして挙げられる一方、前述の通りシングルホーム構成ではこの仕組みが利用されることはありません。
図9：Encapsulationによる対応方式の違い（draft-nr-bess-evpn-mh-split-horizon-03より抜粋） |
冗長化を実現する技術として、All-Active redundancy modeのEVPNが利用されるか・利用される場合split-horizon filteringにどの方式が選択されるか・各方式で処理が正しく行われるかという点は、DF filteringと並んで、冗長化構成における固有の留意点と言えます。
EVPN over SRv6：必要な設定とSR-MPLSとの比較
表1・表2・表4の設定情報より今回の試験環境における各エッジノードの設定は、MACアドレスのような元から省略可能なものを除くと、「コア向けインタフェースのアドレス」「ループバックのアドレス」「staticの経路」「BGPピアのアドレス」「ルータID」「SRv6 Locator」が、異なる値を指定している項目として挙げられます。SRv6 SIDを手動で割り当てるケースでは、その値も設定項目となりますが、前項の通り、今回の環境では動的な割り当てが行われています。
このうち、トランスポートのIPv6アドレスおよびstaticの経路におけるネクストホップはリンクローカルアドレスを適用することで、BGPピアのアドレスはRRや中継となるASを経由させることで、それぞれ指定する値を共通化することができます。これより、固有となる設定は「ループバックのアドレス」「ルータID」「SRv6 Locator」のみで構成可能となります。またこれらの要素は、設計依存の部分もあるものの基本的にはSRv6ドメインに対し各ノードで一意に定まるものであり、割り当てのルール化も容易になります。特にリンクローカルアドレスを自然な形で導入可能な点はSR-MPLSと比較した際の利点と言えます。今回の設定はL2サービスで行った際のものとなりますが、この状態が条件に応じて形成可能であることはL3サービスで行った際も同様であることを以前に別のプラットフォームで実施した試験にて確認しています。
なお、トランスポートに対する経路の保持にIGPを適用する際も、リンクローカルアドレスを用いて構成されることになるため、設定の固有性に関しては同様です。データプレーンの動作としてはコントロールプレーンに依存するものではないとは言え、物理ネットワークに閉じてSRv6ドメインを形成する限りでは、トランスポートネットワークへの要求などを踏まえるとMPLSコアの様にIGPで構成する方法が第一の選択肢になると考えられます。アーキテクチャを定めるRFC8402で挙げられる各種のSegmentは、Binding Segmentを除けば、ルーティングプロトコルに関連付くものとして定義されています。
また、ホストOSにおける活発な実装状況やデフォルトルートで複数のActive Segmentを転送可能となる点も、SR-MPLSと比較した際のSRv6の特徴と言え、エンドシステムやCPEなどを含めてSRドメインを形成する構成になれば、特にこの点がプラスに作用することになります。これに関連する事項としては、加入者収容に関わる技術が発展している点もIPの特徴です。もし必要となるアドレスや経路に加えて、SRv6 LocatorをPrefix Delegationなどで割り当てが可能になれば、ネットワークの下位に位置するSRv6ノードで必要な設定は全て共通化することも可能となってきます。今のところ具体化された仕様は発見できていませんが、Transport SIDをDHCPで割り当てる提案は既に行われており（□□）、またSD-WANへの適用などを想定するとzero touch deploymentは要求に挙がる事項でもあります。Network Programmingを伴わない旧来のSRv6であればIPv6のアドレッシング・ルーティングに対する簡素化・共通化で実現可能な範囲となりますが、この場合VPNといった機能の提供には別の機構を併用することになります。今後、RFC8986に準拠したSRv6に関して、ゼロタッチプロビジョニングが意識された仕様や実装も登場することがあるかもしれません。
EVPN over SRv6：MAC学習の手段とSR-MPLSとの比較
試験過程でEdge-30を一度ネットワークから切り離し、MACエントリを空にした後に再度ネットワークに再参加させたところ、転送データの受信が行われない状態で、以前学習していたMACに対応するBGP経路が保持されることを確認しています。
通常、レイヤ2ネットワークに追加されたラーニングブリッジがMAC学習を行うためには、フレームの受信を必要とします。転送データを受信する前からMAC学習が行われる点はEVPNの動作結果であり、これはEVPN-MPLSやEVPN-VXLANと同様です。コントロールプレーンによるホスト情報の学習はEVPNの特徴となり、unknown unicast floodingの発生を抑制し、ARP/ND proxyの効率的な動作を実現するといった効果があります。
ただ、事前に通信の行われる可能性があるMACを全て学習することは、実際には通信を行わないホストに対するMACの学習も行われてしまうことにもなります。「MAC未学習状態の発生頻度」と「MACエントリの消費」のどちらが問題として顕在化し易いかは環境によって異なります。また、BGPの保持情報がホストに依存して増加する側面は、状態確認のオペレーションに少なからず影響を与えます。コントロールプレーンによるMAC学習は利点をもたらす一方で、それが総じて優位に働くかは環境に依存するという点には注意が必要となるかもしれません。
トランスポートがMPLSでありEVPNのベースとなるEVPN-MPLSも、コントロールプレーンによるMAC学習が行われ、関連する留意点は同様です。EVPN-MPLSはMP2Pのシグナリングであり、それがPE数に比例したラベル消費の排除というVPLSに対する優位性でもあるわけですが、VPNラベルだけではVPNピアを特定することはできずMACエントリの形成はコントロールプレーンからの学習が前提となりました。それによって、Host Mobilityや分散L3GWなどの様々な機能が提供できるようになった反面、要求が従来のE-LANサービスを実現したいというものである場合、その機能性を持て余すことになるかもしれません。
対して同様にMPLSをトランスポートするPBB-EVPNでは、Route Type 2で交換されるMACアドレスはPEが有するPBBのB-MACアドレスとなり、その情報を介してエッジ冗長などが実現されます。転送データのヘッダに付与されるB-MACアドレスはPE、もしくはES単位でユニークな値が割り当てられ、収容対象のホストに相当するC-MACの学習は、データプレーンを介して行われます。BGPによるホスト情報学習に起因したスケール阻害可能性の排除やBGPステートのシンプル化などが重視される環境では、より適した選択肢となります。二種類のEncapsulationが行われる点や冗長グループ内においてもMACの同期機構を持たない点などは、環境によって導入の障壁になり得るため、要求や環境条件に合わせて使い分けることになります。
加えてMPLSがトランスポートであれば、十分に成熟したVPLSもL2サービスを提供するための選択肢となります。SR-MPLSでは、VPN技術としてこれらのMPLS VPN資産を継承できるため、L2サービスを提供する際もその選択肢に恵まれていると言えます。一方、SRv6はVPNレイヤにもSRv6 SIDが利用され、そのコントロールプレーンにも専用のものが必要となります。現在、L2サービスのためにdraft-ietf-bess-srv6-servicesで定められている方式はEVPNのみで、エッジ機器の冗長化などのためにはコントロールプレーンのアシストが重要となるものの、その選択肢がEVPNしか存在しない点は特にSR-MPLSと比較した際のSRv6の留意点と言えます。
SRv6と同様にIPトランスポートであるEVPN-VXLANの場合も、RFC7432 / RFC7209の記述に沿う形でMACアドレスの学習はコントロールプレーンから行うことが基本となります。この点に関して、実装状況としては、「EVPNはBUM配送先識別のためにRoute Type 3だけを用い、MAC学習はデータプレーンから行う」といったものも存在しています。これは、Encapsulationに用いられるIPアドレスによってピアが特定できることに起因しています。AliasingやMass Withdrawalなどへの対応も踏まえれば、この例は一部の用途に特化した実装と捉えた方が適切かもしれませんが、IPトランスポートのEVPN構成においてデータプレーンからのMAC学習が実現可能であることの示唆と言えます。
なお、EVPN-VXLANの場合、エッジ冗長にはEVPNを用いず、Anycast VTEPと呼ばれるようなAnycast IPを利用したベンダー固有の冗長化機構との組み合わせも一般的です。この構成は、ホスト収容インタフェースの障害時に対向にそれを通知できず最短パスに推移できない点や、仕様として標準化されたものではない点など、マイナスに作用する要素も存在します。他方、無効になったピアの切り離しがトランスポートネットワークの収束で完結するため障害パターンによっては高速に復旧し得る側面があり、またEVPNを用いずデータプレーンからMAC学習を行うVXLAN構成にも適用可能な実装となっています。
さらに、シンプル・スケーラブルなIPネットワークにTE/FRR機能を付与するという視点に立ち返れば、VXLANv6にSRm6を組み合わせて構成することも選択肢となってきます。
このような状況下にあってか、SRv6に適用可能な、MAC学習を行わないL2サービスを実現するための提案も始まっています（□□）。EVPNの関わり方は提案によって異なるものの、VPNラベルの役割を担う部位にglobally uniqueな値を用いる点・冗長化のためにanycast な値を用いる点などが特徴として挙げられます。結果として、All-Activeのエッジ冗長といったEVPNの特徴的な機能を、IPトランスポート上で直接提供しながらPBB-EVPNのようにMAC学習をデータプレーンから行う形態が実現されます。このような仕様が具体化され実装が進めば、SRv6でL2サービスを提供する際にも、条件に合わせてコントロールプレーンやそのバリエーションを選択することが可能となり、より広範な領域に適応可能となることが期待されます。
おわりに
今回はfreeRouterを用いてE-LAN構成に対しEVPN over SRv6を適用した結果、ループ回避と最短パス伝送が実現された状態で、3つのサイト間それぞれの組み合わせにおいて基本的なレイヤ2の疎通性を確認することができました。これよりEVPN over SRv6では、MPLSやVXLANを用いて構成されたE-LANサービスと同様の品質で、3つ以上のサイト間をレイヤ2にて接続可能であることが窺えます。
また今回の試験結果では、Unicast転送とBUM転送の間で同一のSRv6 SIDを使用していることが確認できました。冗長化構成に必要となる動作の実現方式はEVPN-VXLANと比較した際のSRv6の優位性となりますが、それに関係する挙動は今回のシングルホーム構成では観測されなかったため、利用可能となった際には実現方式を含め改めて注視した方が無難です。
あわせて今回の試験環境より、EVPN over SRv6の構成において、固有となる設定は「ループバックのアドレス」「ルータID」「SRv6 Locator」のみで構成可能となることが示唆されました。これはL3サービスを提供する場合と同様であり、またSIDがlocatorに属す点などと合わせSR-MPLSと比較してよりシンプル化に寄与する側面を有すると言えます。
SRv6は、高度な機能やシンプルな構成が実現可能となることから、L2サービスを提供するケースにおいても価値のある技術となります。現状ではSR-MPLSと比較するとコントロールプレーンの選択肢に留意する必要はあるものの、この点に関しても今後の進展によって拡張される可能性があります。
関連記事
- SRv6、相互接続してます！
- トランスポートで光るIPv6～SRv6～
- RFC 7209 - Requirements for Ethernet VPN (EVPN)
- RFC 7348 - Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks
- RFC 7432 - BGP MPLS-Based Ethernet VPN
- RFC 7623 - Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)
- RFC 8365 - A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)
- RFC 8402 - Segment Routing Architecture
- RFC 8986 - Segment Routing over IPv6 (SRv6) Network Programming
- draft-ietf-bess-srv6-services-05 - SRv6 BGP based Overlay services
執筆者プロフィール
平河内 竜樹
ネットワンシステムズ株式会社 ビジネス開発本部
第3応用技術部 第3チーム 所属
ルータ分野を核とした新旧技術の調査・検証と共に、エンタープライズ・パブリック・サービスプロバイダのネットワーク提案および導入を支援する業務に、10年以上にわたり従事
- CCIE RS
- CCIE SP
Webからのお問い合わせはこちらから
ピックアップ
ナレッジセンターを検索する
カテゴリーで検索
タグで検索