はじめに

前回のコラムでは、「セグメントルーティング(Segment routing)」の基本的な概要について説明しました。今回のコラムでは、IPv6ネットワークの上で構成されるSRv6(Segment Routing IPv6)について、少し詳しく内容を解説します。

今回は、SRv6サービスを実現するパケットヘッダーについて、詳しく観察してみます。ここでは、簡単のため、Ubuntu上にNetwork Namespaceを用いてモデルネットワークを構成し、SRv6処理を行うノードにおいて、ネットワーク処理スタックにおけるさまざまなNetfilter hookポイントで、Python Scapyパッケージを用いて、疎通するパケットを取得、そのヘッダーについて、観察します。また、参考として、MPLS IPv6トンネルとの比較もします。

次に、SRv6を用いてVPNを構成するために必要な設定を実行するためのControl Planeについて、簡単に触れます。VPNのようなアプリケーションでは、IPv6アンダーレイネットワークの両端で、VPNユーザーのLAN Segmentに設置する、SRv6のSRv6トンネルの始点(Head End)、終点(Tail End)としてENCAP/DECAP処理を行うルーター機器（CPE（Customer Premises Equipment））を用いて、SRv6トンネルの設定に必要な通信先CPEのインターフェースアドレスやCPE配下のLAN SegmentのPREFIX情報を必要とします。これらの情報交換方法について、簡単に述べます。

SRv6とは？

前回のコラムで説明したとり、SRv6とは、IPv6の拡張ヘッダーを利用したセグメントルーティングです。送信先で作成した、経由するノード、パケット処理を定義した識別子(SID)（IPv6アドレス形式）を順番に、SRH(Segment Routing Extension Header)に格納します。Outer IPv6ヘッダーのDestination IPアドレスには、SRHで定義された、次に経由するノード、または、パケット処理を定義したアドレスが設定されます。ノードを経由するごとに、これは、順次変更されていきます。つまり、SRHに定義されたアドレスの中からOuter IPv6ヘッダーのDestination IPアドレスに相当する、SRv6機能が有効化されたインターフェースにパケットが到着すると、そこで定義された処理が実行され、SRHにおいて、その次に定義されたアドレスを、Outer IPv6ヘッダーのDestination IP アドレスとして設定し、パケットがフォワーディングされます。この処理を繰り返し、SRHで定義されたアドレスとそこで行われる処理が実行されたあと、最終的なオリジナルの着側ノードにパケットがフォワーディングされるものです。そのため、ネットワークリソースを有効に利用することを目的に、送信元で、経由するノード、処理に関するルーティングポリシーを適切に作成することで、より柔軟なルーティングを可能にします。

SRv6のパケットをのぞいてみると...

ここでは、図1に示すような説明用のネットワークモデルを構成します。簡単に検証できる環境として、ここでは、Linux(Ubuntu)上にNetwork Namespaceを用いて構成しました。図1にあるように、CPE間では、SRv6トンネルが設定されています。ここでは、さっそく、図中のhost4からhost1に向けて、Ping処理を行い、Namespaceで構築されたノードにおいて、パケットを取得、パケットヘッダーを観察します。

■ Pingの実行

hiroshi@hiroshi-VBox:~$ sudo ip netns exec host4 ping6 -c 1 1::1
PING 1::1(1::1) 56 data bytes
64 bytes from 1::1: icmp_seq=1 ttl=63 time=13.6 ms

--- 1::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 13.624/13.624/13.624/0.000 ms
    

host4から送信されたICMPv6 Echo Requestパケットは、host1に到着、処理して、host1からhost4に向けて、ICMPv6 Echo Replyパケットが送信されています。CPE1において、このパケットを取得し、観察します。

図1. Network namespaceで構成された説明用ネットワークモデル

図1のネットワークモデルは、アンダーレイネットワークとなるIPv6が動作するIPv6 Core Networkの両端に位置するLAN SegmentをSRv6トンネルで結ぶことで、VPNを構成したモデルです。両端のLAN Segment間を接続するために、Core Networkの両端では、SRv6機能を有するルーター端末(CPE)を設置します。

左側のLAN Segment　(1::/64) は、1つのCPE（CPE1)で、SRv6のENCAP/DECAP処理を行います。Core Networkに対して、CPE1は、2つのインターフェースで接続をすることで、信頼性を向上させるとともに、設定したルーティングポリシーに従い、トラフィックフローが疎通するインターフェースを使い分けることを想定しています。

一方、右側のLAN Segment　(10::/64)は、SRv6のENCAP/DECAP処理をおこなう2台のCPE (CPE3, CPE4)を用意しています。LAN Segmentから利用するCPEを選択することができます。また、2台のCPEでは、CPE1の2つのインターフェースに向けたSRv6トンネルを2つ用意し、ルーティングポリシーに基づき、使用するSRv6トンネルを選択することができる設定を入れています。説明用のネットワークモデルにおける具体的なルーティングポリシーの設定の詳細は、ここでは説明を省略します。機会があれば、次回のコラムで説明します。

パケットの取得は、以下の要領で行います。

CPE1内部の以下の2つのnetfilter hook ポイント^[1]、NF_IF_PRE_ROUTING　(Prerouting Chain) とNP_IP_FORWARD（Forward Chain)において、パケットを取得、ヘッダー内容を観察します。CPE1では、nftablesサービスを動作させます。inet mangle テーブルには、Prerouting ChainとForward Chainにルールを設定します。図2のように、上記2つのnetfilter hookポイントに、netfilter-Queue^[2]を設定し、CPE1のネットワーク処理スタックの中で、取得したパケットのヘッダー内容を観察します。nftablesで設定された具体的なルールは下記のようになります。★印部分が、netfilter-Queueの設定になります。

hiroshi@hiroshi-VBox:~$ sudo ip netns exec CPE1 nft list table inet mangle
table inet mangle {
	chain prerouting {
	type filter hook prerouting priority mangle; policy accept;
	iifname "br0_1" counter packets 11 bytes 872 meta mark set ct mark
	ip6 saddr 4::1 iifname "wan-cpe1_0" counter packets 3 bytes 504 meta mark set 0x0000000a
	ip6 saddr 3::1 iifname "wan-cpe1_0" counter packets 0 bytes 0 meta mark set 0x0000000a
	meta mark 0x0000000a counter packets 9 bytes 1128 ct mark set meta mark
	ip6 saddr 4::1 iifname "wan-cpe1_1" counter packets 0 bytes 0 meta mark set 0x00000014
	ip6 saddr 3::1 iifname "wan-cpe1_1" counter packets 0 bytes 0 meta mark set 0x00000014
	meta mark 0x00000014 counter packets 0 bytes 0 ct mark set meta mark
	ip6 saddr 1::/64 counter packets 7 bytes 600 queue num 1 (★Netfilter-Queue(1)) 
	}
	chain input {
		type filter hook input priority mangle; policy accept;
	}
	chain forward {
		type filter hook forward priority mangle; policy accept;
		ip6 daddr 4::/64 counter packets 3 bytes 504 queue num 1　(★Netfilter-Queue(2)) 
	}
	chain output {
		type filter hook output priority mangle; policy accept;
	}
	chain postrouting {
		type filter hook postrouting priority mangle; policy accept;
	}
}
    

Prerouting Chainのnetfilter hookポイントでは、netfilter-Queueにパケットを挿入(Enqueue)するための条件として、「CPE1のネットワーク処理スタックに入ったパケットのうち、Source Addressが、1::/64に所属するものをQueueに導く」設定をしています。このため、host4からhost1に対してPingを行った場合、図1のhost1からhost4に向けて疎通するIPv6 Echo Replyパケットが取得されます。Prerouting Chainで取得されるパケットは、CPE1のネットワーク処理スタックに入ったパケットが、CPE1で設定されたルーティング判断処理が実行される前段階におけるパケットになります。(★netfilter-Queue(1))

また、CPE1では、図2で示すようにForward Chainのnetfilter hookポイントで設定されたnetfilter-Queueにパケットを挿入(Enqueue)するための条件として、「CPE1のネットワーク処理スタックに入り、ルーティング判断が実行され、転送されるパケットのうち、Destination Addressが、4::/64に所属するものをQueueに導く」設定をしています。(★Netfilter-Queue(2))

CPE1では、CPE4のWANアドレス(4::1)に向けてSRv6トンネルを設定し、パケットが疎通できるように、ENCAPを行う設定をしています。そのため、ルーティング処理判断後のパケットは、Forward Chainにおいて、Outer IPv6 ヘッダーのDestination Addressが4::1となるため、netfilter-Queueに挿入される条件を満たします。従って、ENCAP処理されたSRv6パケットが取得できます。

Prerouting　Chainで取得されたパケットのヘッダースタックは、LAN Segmentから送信されたICMPv6 Echo ReplyパケットにIPv6のヘッダーがついたオリジナルのパケットのヘッダースタックとなります。一方、CPE1の各インターフェースでは、システム制御コマンドで、seg6_enabled = 1, ipv6.forwarding = 1と、それぞれ、SRv6処理とIPv6パケット転送処理を有効化しています。また、CPE1では、ENCAP設定を行うルーティングエントリーがルーティングテーブルに設定されています。そのため、ルーティング判断処理を経て、Forward Chainで取得したパケットには、Prerouting Chainで取得したオリジナルパケットのヘッダースタックの上に、新たに、SRH( IPv6 Option Header Segment Routing)とこれらを合わせた全体のOuter IPv6 ヘッダーが追加されたヘッダースタックになります。

図2. Netfilter hookポイントとNetfilter-Queueの設定地点

では、モデルネットワークで取得したパケットの内容を観察してみます。

Prerouting ChainとForward Chainの2つのnetfilter hookポイントで用意したnetfilter-Queueから、パケットを取り出し、ヘッダーの中身を確認するPython Program(※ここでは、詳細は省略します) を作成し、パケットヘッダーの内容を観察します。ここでは、Python のScapyパッケージ^[3]を利用して、パケットヘッダー情報の内容を表示します。Scapyを使って、netfilter-Queueで取得したパケットのパケットヘッダーを操作し、パケットのPayloadをコピーし、Destination Addressなどを変更して、その先へ代行転送することも可能となります。

まず、Prerouting Chainで設定したnetfilter-Queueで取得したパケットについて、その内容を見てみましょう。ネットワーク処理スタックで、ルーティング判断処理が実行される前の状態のパケットになります。以下のように、IPv6パケットのヘッダーの下に、ICMPv6 Echo Replyパケットが格納されています。ここでは、もっとも外側にあるIPv6 ヘッダーのSource Address, Destination Addressは、SRv6トンネルの両端の、VPNを構成するLAN Segmentのアドレスに所属する、Pingコマンドを行ったホストの具体的なアドレスになっていることが確認されます。

なお、以下のScapyの出力形式についてです。出力データの中の###[パケットヘッダー名]###で、各パケットヘッダーを区別しています。

hiroshi@hiroshi-VBox:~/column$ sudo ip netns exec CPE1 python3 check_packet_mark_x.py
ICMP packet, 104 bytes
###[ IPv6 ]###
  version   = 6
  tc        = 0
  fl        = 106558
  plen      = 64
  nh        = ICMPv6　　# Next HeaderはICMPv6を示す
  hlim      = 64
  src       = 1::1	 # VPNのCPE1配下のLAN SegmentのPrefixに所属するアドレス(host1)
  dst       = 10::4	 # VPNのCPE3,4配下のLAN SegmentのPrefixに所属するアドレス(host4)
###[ ICMPv6 Echo Reply ]###
     type      = Echo Reply # host1からhost4へ向けたEcho ReplyのTypeであることを示す
     code      = 0
     cksum     = 0x6337
     id        = 0x74fa	# ICMP PacketのID番号
     seq       = 0x1	# ICMPのシーケンス番号
     data      = (省略)
     

次に、Forward Chainで設定したnetfilter-Queueで取得したパケットを観察します。Forward Chainのnetfilter hookポイントで取得したパケットは、図2にあるように、ルーティング判断処理が実行された後のパケットになります。先に述べたように、CPE1では、Core Network上に設定したSRv6トンネルの端点であるCPE4のWAN側インターフェースに向けて、ENCAP処理を行う設定をしたルーティングエントリーが設定されています。従って、Prerouting Chainで取得したパケットの上に、さらにSRv6処理に付随するヘッダーが付加され、以下のようなヘッダー構成となっています。

IGMP packet, 168 bytes
###[ IPv6 ]###
  version   = 6
  tc        = 0
  fl        = 106558
  plen      = 128
  nh        = Routing Header	# Next HeaderはSRv6用のOption Headerであることを示す
  hlim      = 63
  src       = 2::1	# CPE1のENCAP設定におけるdevパラメーターのインターフェースのアドレス
  dst       = 4::1	# ENCAP設定で定義したSegment(CPE4のWAN側インターフェース)のアドレス
###[ IPv6 Option Header Segment Routing ]###
     nh        = IPv6	# Next HeaderはENCAP前のオリジナルパケットのHeaderを示す
     len       = 2
     type      = 4
     segleft   = 0
     lastentry = 0
     unused1   = 0
     protected = 0
     oam       = 0
     alert     = 0
     hmac      = 0
     unused2   = 0
     tag       = 0
     addresses = [ 4::1 ]	# ENCAP設定で定義した、経由するSegment ID List
     \tlv_objects\
###[ IPv6 ]###
        version   = 6
        tc        = 0
        fl        = 106558
        plen      = 64
        nh        = ICMPv6	#  Next HeaderはICMPv6を示す
        hlim      = 64
        src       = 1::1	# VPNのCPE1配下のLAN SegmentのPrefixに所属するアドレス(host1)
        dst       = 10::4	# VPNのCPE3,4配下のLAN SegmentのPrefixに所属するアドレス(host4)
###[ ICMPv6 Echo Reply ]###
           type      = Echo Reply
           code      = 0
           cksum     = 0x6337
           id        = 0x74fa	# ICMP PacketのID番号
           seq       = 0x1	# ICMPのシーケンス番号
           data      =　（省略）
    

以上、説明用ネットワークモデルにおけるSRv6を利用した場合のフォワーディングプレーンに関して、パケットヘッダーについて観察してみました。

SRv6のEnd Pointの処理（ENCAP/DECAP)

上記のSRv6パケットの観察において述べたように、ネットワーク処理スタックにおいて、Prerouting Chainで取得したパケットとルーティング判断処理のあとのForward Chainで取得したパケットでは、ヘッダー構成が変わっていました。これは、CPE1において、各インターフェースでSeg6_enabed =1として、SRv6の処理を有効化し、SRv6のEnd Point Function処理を定義したルーティングエントリー（ENCAP/DECAP設定）に従い、SRv6の処理が実行され、その結果が反映されたためです。

[4]では、SRv6のEnd Point FunctionのListとその開発状況が整理されています（※この情報は古いです。例えば、End.DT4については、[5]にあるように、Linux Kernel Version 5.11で実現される予定です。）リストに掲載されたEnd Point Functionの仕様は、[6]のDraft資料に明記されていますので、これを参考願います。

今回の説明用モデルネットワークにおいて利用しているEnd Point Functionは、基本的なENCAP設定処理を行う(encap segs)とDECAP設定処理(End.DX6)を行う2つです。CPE1で定義された具体的な一例を下記に記します。

(a) ip netns exec CPE1 ip -6 route add 10::/64 encap seg6 mode encap segs 4::1 dev wan-cpe1_0 metric 1024 table 70
(b) ip netns exec CPE1 ip -6 route add 2::1 encap seg6local action End.DX6 nh6 :: dev br0_1
    

上記(a)の設定内容は、Prefix 10::/64へ行くための、CPE1のwan-cpe1_0のインターフェース (2::1) から（SRv6トンネルの始点）、CPE4の4::1のアドレス(Segment)（SRv6トンネルの終点）までのSRv6トンネル、を作成することを意味しています。加えて、Metric値を1024とし、このルーティングエントリーを、番号70のルーティングテーブルに設定する、ことを意味します。このように、ルーティングポリシールールとして、さまざまな条件に応じて、Lookupするルーティングテーブルを指定することができます。パケットは、Prerouting Chainを過ぎた後、ネットワーク処理スタックで、ルーティング処理され、転送されます。この時、(a)で設定されたENCAP処理が実行され、その結果、Forward Chainのnetfilter hookポイントで計測されたパケットのように、SRv6に関係するSRH（IPv6 Option Header Segment Routing）などがパケットヘッダーに追加されます。

上記(b)の設定では、Outer IPv6 ヘッダーのDestination Addressが2::1であれば、Outer IPv6 ヘッダーとその下にあるIPv6 Option Header Segment Routingヘッダーを取りさり、VPNとしてLAN間で疎通するオリジナルのパケット（先の観測事例であれば、[IPv6][ICMP]で構成されるパケット）を取り出し、devパラメーターで指定されたインターフェース(br0_1)へ転送します。End.DX6の場合、nh6で定義するnext hopとして、::(Default Route)を指定します。

以下、本章で関連する参考事項を2つ記載します。

参考1　ScapyのSRv6関連Headerについて

説明用のモデルネットワークでは、netfilter-Queueを用いて取得したパケットヘッダー内容の確認、パケットヘッダーフィールド情報の操作をPython Scapyパッケージを用いて操作しました。SRv6に関係するScapyパッケージで用意されているヘッダー定義などについて、参考のために下記に記します。

hiroshi@hiroshi-VBox:~/column$ python3
Python 3.8.6 (default, Sep 25 2020, 09:36:53)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from scapy.all import *　
>>> ls()　
(snip) # IPv6, Scapyに関係するものは下記になります。
IPv6       : IPv6
IPv6ExtHdrDestOpt : IPv6 Extension Header - Destination Options Header
IPv6ExtHdrFragment : IPv6 Extension Header - Fragmentation header
IPv6ExtHdrHopByHop : IPv6 Extension Header - Hop-by-Hop Options Header
IPv6ExtHdrRouting : IPv6 Option Header Routing
IPv6ExtHdrSegmentRouting : IPv6 Option Header Segment Routing
IPv6ExtHdrSegmentRoutingTLV : IPv6 Option Header Segment Routing - Generic TLV
IPv6ExtHdrSegmentRoutingTLVEgressNode : IPv6 Option Header Segment Routing - Egress Node TLV
IPv6ExtHdrSegmentRoutingTLVIngressNode : IPv6 Option Header Segment Routing - Ingress Node TLV
IPv6ExtHdrSegmentRoutingTLVPadding : IPv6 Option Header Segment Routing - Padding TLV
(snip)
    

今回ヘッダーの内容を観察するにあたり利用した、「IPv6 Option Header Segment Routing」の詳細なフィールド情報は、以下になります。

>>> ls(IPv6ExtHdrSegmentRouting)
nh         : ByteEnumField              = (59)
len        : ByteField                  = (None)
type       : ByteField                  = (4)
segleft    : ByteField                  = (None)
lastentry  : ByteField                  = (None)
unused1    : BitField  (1 bit)          = (0)
protected  : BitField  (1 bit)          = (0)
oam        : BitField  (1 bit)          = (0)
alert      : BitField  (1 bit)          = (0)
hmac       : BitField  (1 bit)          = (0)
unused2    : BitField  (3 bits)         = (0)
tag        : ShortField                 = (0)
addresses  : IP6ListField               = (['::1'])　# ここに疎通するSegmentのアドレスが入る
tlv_objects : PacketListField           = ([])
    

パケットスタックの中のヘッダーフィールド情報の取得は、以下に示す2つの例のように取得します。

>>> packet[0][IPv6ExtHdrSegmentRouting][IPv6].src
'10::4'　　→　ENCAPされたオリジナルIPv6パケットのSource Address
>>> packet[0][IPv6ExtHdrSegmentRouting].addresses
['2:1::1']　→　ENCAPされたSegment ListをSRv6ヘッダーから取得。List形式になっている。
    

参考2　Linux上のMPLS機能を用いたMPLS IP tunnelを用いたVPNとの比較

これまで、IPv6が動作するCore Networkの両端に、CPEとして、Linux(ubuntu)上でSRv6機能が動作するルーター機器を接続し、SRv6トンネルによってLAN Segment間を接続するVPNサービスについて、説明用のネットワークモデルを使いながら、SRv6について説明してきました。

MPLSが動作するCore Networkでも、サービスプロバイダーが提供するCore NetworkのL3VPNサービスがあり、同じようにCore Networkの両端にあるPE(Provider Edge) ルーターに、CE(Customer Edge)ルーターを接続して、Core Networkの両端にあるLAN Segmentを接続することができます。この場合、利用者は、MPLS Providerに対してPEにCEを接続、適切な設定を申し込みます。Provider側は、PE間にMPLS IP/IPv6 Tunnel を設定します。ユーザーのCEを接続するためにVRFを用意し、ユーザー側のCEとの間で、適切な設定を行います。ユーザー(VRF)を識別するLabelとMPLS IP/IPv6トンネルを実現するLabelの２つのLabelをスタックすることで、VPNサービスが提供されます。

これまで、説明してきたSRv6が動作するCPEを用意して、このCPE間でトンネルを用いてVPNを構成する場合と異なり、MPLSL3VPNの場合は、PE間でトンネルを設定します。

Linuxでは、MPLSの動作(LabelのPush/Swap/Pop)ができるので^[7]、ENCAP設定の比較のために、MPLS IP/IPv6トンネルの簡単な例も参考として、以下に記します。ここでは、説明のために、Network Namespaceを用いて、Core Networkの両端のLAN SegmentをMPLS IPv6トンネルを作成して接続する簡単なネットワークモデルをもちいて説明します。本来であれば、PE間でMP-BGPでVPNに関係するPREFIX交換や複数ユーザーを意識してVRFなどの設定が必要になりますが、ENCAP設定の比較ですから、これらの設定などは省略した簡単なモデルです。また、Core Network部分でもMPLSの設定を行う必要があるため、ここでは、簡素なCore Networkによる、図3に示すようなネットワークモデルで説明します。

説明用のMPLSネットワークとその設定

図3にNetwork Namespaceを用いた説明用のネットワークモデルを示します。4つのルーター(MPLS_R1,R2, R3, R4)で構成されたMPLSサービスを提供するCore Networkとなります。この両端のMPLSルータ(MPLS_R1, MPLS_R4)は、PEルーターとして機能し、トンネルの始点、終点となります。すなわち、ENCAP/DECAP設定処理を行います。MPLS_R1, R4の配下には、LAN Segment(10::/64と20::/64)が接続されています。MPLSルーター((MPLS_R2, MPLS_R3)は、ラベルの交換を行うPルーターの役割をします。

図3. 説明用MPLS IPv6トンネルを用いたネットワークモデル

NamespaceをMPLSルーターとして機能させるため、以下の設定を行います。まず、MPLS Router module^[7]をLoadします。次に、使用可能なLabelの最大値を定義し(net.mpls.platform_labels=64)、Namespaceで定義した各ノードのインターフェースでMPLSが機能できるようにアクティベートします（net.mpls.conf.｛Interface名｝.input=1）。各インターフェースは、IPv6パケットもForwardできるように設定します(net.ipv6.conf.{all, default, インターフェース名}.forwarding=1)。

sudo modprobe mpls_router
sudo sysctl -w net.mpls.platform_labels=64
sudo ip netns exec MPLS_R1 sysctl -w net.mpls.platform_labels=64
sudo ip netns exec MPLS_R2 sysctl -w net.mpls.platform_labels=64
(snip)
sudo ip netns exec MPLS_R1 sysctl -w net.mpls.conf.veth-m1_1.input=1
sudo ip netns exec MPLS_R1 sysctl -w net.mpls.conf.lo.input=1
(snip)
    

アンダーレイネットワークをIPv6ネットワークとして動作するように設定した後、下記のように、MPLS_R1, R2, R3, R4について、MPLS IPv6 トンネルに必要な設定をおこない、下記のようなLFIB(Label Forwarding Information Base)を構築します。これらの設定に従った場合のMPLS IP トンネルとLabel交換のための設定を図3に図示しました。

なお、説明用モデルでは、IPv6のネットワークにおいて、MPLS_R1, R4では、Default routeを下記のように設定しています。MPLS_R1とMPLS_R4の間のIPv6のルーティングテーブルに従う疎通経路は、図3における反時計回り(R1→R2→R4→R3→R1)となりますが、下記で構築するMPLS IPv6トンネルの場合は、意図的に、図における時計回り(R1→R3→R4→R2→R1)となるように設定しています。

hiroshi@hiroshi-VBox:~$ sudo ip netns exec MPLS_R1 ip -6 route show
(snip)
default via 1:2::2 dev veth-m1_0 metric 1024 pref medium	〇
default via 1:3::2 dev veth-m1_1 metric 2048 pref medium

hiroshi@hiroshi-VBox:~$ sudo ip netns exec MPLS_R4 ip -6 route show
(snip)
default via 4:3::2 dev veth-m4_1 metric 1024 pref medium	〇
default via 4:2::2 dev veth-m4_0 metric 2048 pref medium
    

LinuxのMPLS Moduleを用いたENCAP, DECAPの設定は、以下のようなコマンドで実現します。

・ENCAP設定は、以下の例のように設定します。

sudo ip netns exec MPLS_R1 ip -6 route add 20::/64 encap mpls 25 via 1:3::2 
dev veth-m1_1
    

・DECAP設定は、以下の例のように設定します。

sudo ip netns exec MPLS_R1 ip -f mpls route add 36 dev lo
    

・MPLSにおいて、特徴的なSwapの設定は、以下の例のように設定します。

sudo ip netns exec MPLS_R2 ip -f mpls route add 38 as 36 via inet6 1:2::1 dev veth-m2_0
    

図3で設定したネットワークモデルのLFIB(Label Forwarding Information Base)、PEにおけるENCAP設定のルーティングエントリーを以下になります。

・MPLS_R1では、20::/64向けのパケットに対して、Label値25を設定し、インターフェースveth-m1_1からパケットを転送します。MPLS IPv6　トンネルのNext Hopは、1:3::2(MPLS_R3ルーター)になります。 SRv6でいえば、CPEで設定するENCAP設定のRouting Entryに相当します。ENCAP設定で定義される経由アドレスリストと同様な役割をはたすものがLabel値の25に相当します。

hiroshi@hiroshi-VBox:~$ sudo ip netns exec MPLS_R1 ip -6 route show | grep mpls　
20::/64  encap mpls  25 via 1:3::2 dev veth-m1_1 metric 1024 pref medium
    

・MPLS_R４では、10::/64向けのパケットに対して、Label値38を設定し、インターフェースveth-m4_0からパケットを転送します。MPLS IPv6　トンネルのNext Hopは、4:2::2(MPLS_R2ルータ)です。この設定が、SRv6でいえば、CPEで設定するENCAP設定のRouting Entryに相当します

hiroshi@hiroshi-VBox:~$ sudo ip netns exec MPLS_R4 ip -6 route show | grep mpls
10::/64  encap mpls  38 via 4:2::2 dev veth-m4_0 metric 1024 pref medium
    

・MPLS_R1では、Label値36が設定されたパケットは、LabelをPopして(DECAP)、IPv6パケットを取り出し、loに転送します。次に、ルーターに設定されたルーティングエントリーに従い、DECAPされたパケットをHostノードに転送します。SRv6でいえば、End.DX6のDECAP設定のRouting Entryに相当します。

hiroshi@hiroshi-VBox:~$ sudo ip netns exec MPLS_R1 ip -f mpls route show
36 dev lo
    

・Core Network内のMPLS　Pルーターとして機能するMPLS_R2は、Label値 37をもつパケットのLabelをLabel値36に交換(Swap)します。SRv6の場合、Core Network内のルーターでは、パケットのもっとも外側にあるOuter IPv6 ヘッダーに設定されたDestination Addressに対して、ルーティングテーブルをLookupし、最適な経路を見つけて、パケットを転送します。この処理動作に相当します。

hiroshi@hiroshi-VBox:~$ sudo ip netns exec MPLS_R2 ip -f mpls route show
36 as to 36 via inet6 1:2::1 dev veth-m2_0
    

・Core Network内のMPLS Pルーターとして機能するMPLS_R3は、Label値 25をもつパケットのLabelをLabel値27に交換(Swap)します。SRv6の場合、Core Network内のルーターでは、パケットのもっとも外側にあるOuter IPv6 ヘッダーに設定されたDestination Addressに対して、ルーティングテーブルをLookupし、最適な経路を見つけて、パケットを転送します。この処理動作に相当します。

hiroshi@hiroshi-VBox:~$ sudo ip netns exec MPLS_R3 ip -f mpls route show
25 as to 27 via inet6 4:3::1 dev veth-m3_1
     

・MPLS_R4では、Label値27が設定されたパケットは、LabelをPopして(DECAP)、IPv6パケットを取り出し、loに転送します。次に、ルーターに設定されたルーティングエントリーに従い、DECAPされたパケットをHostノードに転送します。SRv6でいえば、End.DX6のDECAP設定のRouting Entryに相当します。

hiroshi@hiroshi-VBox:~$ sudo ip netns exec MPLS_R4 ip -f mpls route show
27 dev lo
    

hiroshi@hiroshi-VBox:~$ sudo ip netns exec host1 ping6 -c 2 20::2
PING 20::2(20::2) 56 data bytes
64 bytes from 20::2: icmp_seq=1 ttl=60 time=0.060 ms
64 bytes from 20::2: icmp_seq=2 ttl=60 time=0.154 ms

--- 20::2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.060/0.107/0.154/0.047 ms
    

hiroshi@hiroshi-VBox:~$ sudo ip netns exec MPLS_R1 tcpdump -i veth-m1_1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth-m1_1, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
10:18:08.772842 MPLS (label 25, exp 0, [S], ttl 63) IP6 10::2 > 20::2: ICMP6, 
echo request, seq 1, length 64
10:18:09.773123 MPLS (label 25, exp 0, [S], ttl 63) IP6 10::2 > 20::2: ICMP6, 
echo request, seq 2, length 64
    

hiroshi@hiroshi-VBox:~$ sudo ip netns exec MPLS_R3 tcpdump -i veth-m3_1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth-m3_1, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
10:18:08.772849 MPLS (label 27, exp 0, [S], ttl 62) IP6 10::2 > 20::2: ICMP6, 
echo request, seq 1, length 64
10:18:09.773147 MPLS (label 27, exp 0, [S], ttl 62) IP6 10::2 > 20::2: ICMP6, 
echo request, seq 2, length 64
    

hiroshi@hiroshi-VBox:~/mpls_linux$ python3
Python 3.8.6 (default, Sep 25 2020, 09:36:53) 
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from scapy.all import *
>>> load_contrib("mpls")
>>> pkt = rdpcap("encap_mpls0207.pcap")
>>> pkt[2].show()
###[ Ethernet ]### 
  dst       = 16:cb:97:e6:47:24	# MPLS_R3のveth-m3_0のインターフェース
  src       = 06:21:2d:67:a9:b5	# MPLS_R1のveth-m1_1のインターフェース
  type      = MPLS	# PayloadにMPLSパケットを持つ
###[ MPLS ]### 
     label     = 25	# MPLS shimヘッダーに、Labelとして25が設定されている
     cos       = 0
     s         = 1
     ttl       = 63
###[ IPv6 ]### 		# MPLS のPayloadにあるオリジナルのIPv6パケット
        version   = 6
        tc        = 0
        fl        = 485074
        plen      = 64
        nh        = ICMPv6	# Next Headerは、ICMPv6
        hlim      = 63
        src       = 10::2	# LAN Segment Host1のアドレス
        dst       = 20::2	# LAN Segment Host2のアドレス
###[ ICMPv6 Echo Request ]### 
           type      = Echo Request
           code      = 0
           cksum     = 0xf2f3
           id        = 0x4682
           seq       = 0x1
           data      = (snip)