【RTX1210】【RTX810】NTT(西)NGNにおけるIPv6通信で、パケットの優先制御情報によっては通信できなくなる問題と対応

■悩まされた問題について

NTT西日本のNGN(IPv6)網において、RTX1210を用いてIPsec VPNを構築していた。
問題なく通信できると思っていたが一部のパケットがうまく通らなかった。

それはローカルネットワークにあるVOIPゲートウェイからのパケット（UDPパケット）である。
その他のパケットは問題なくIPsec VPNを通過していた。

はじめはMTUの設定が悪いのかと思っていたが、MTUの調整では改善できなかった。



■原因について

試行錯誤した結果、結論として、優先制御情報の設定されたパケットが、
NGN IPv6網において落とされていたのではないかと考えられる。


○問題の生じていると考えられる箇所について簡略図を下記に示した。

IPsecと記されている箇所は全てNGN網(IPv6)である。

[VOIP gateway]-⇒(RTX810)--IPsec--⇒(RTX1210)--IPsec/IPIP★--⇒(VPN Server)--⇒[IP PBX(ASTERISK)]

VOIP gateway から出発したudpパケットは、RTX1210のtunnelインターフェイスに掛けた静的フィルタまで到達が確認できた。
しかし、VPN Serverには到達を確認できなかった。
そのため、上図の★印のIPsec/IPIPトンネル（NGN網内）において、パケットが落ちていると考えられた。


○MTUが原因ではなかった。

MTUが原因かと思い、pingのデータサイズを変えながら調査（調査方法について）したものの、
RTX810とRTX1210間を通過できる最大サイズパケットでも、RTX1210とVPN Server間を問題なく通過することができた。
RTX810とRTX1210間を通過できたパケットなら、サイズが問題になってRTX1210とVPN Server間を通過できないことはないと判断できた。


○パケットの優先制御情報について

問題の根本がパケットの優先制御情報と絡んでいるため、これについて理解する必要がある。

IPv4パケットの場合、IPヘッダ（最小20byte）内に、
自身の優先制御のための情報を記すための「TOS Byte」という領域（8bit）が存在する。
先頭から数えて、8bit目から15bit目迄の間（8bit）がその領域で、Type of service と呼ばれている。

これは、TOSフィールドやDS(Differentiated Service)フィールドと呼ばれる場所である。

記載された優先制御情報の扱われ方によって「TOS Byte」の呼び名が変わる。

＜「TOS Byte」領域が、TOSフィールドと呼ばれる場合＞

これは優先制御情報の基本である。

最初にTOSフィールドはRFC791(1981年)で定められ、

後にRFC1349(1992年)に更新された。

TOSフィールドとして扱われる場合、そこに記載される値は、

Precedence値(上位 3bit)と、Type of service値(下位 4bit)と呼ばれる。

xxx/xxxxx

Precedence値でIPパケットの優先順位が8段階で指定され大きいほど重要度が高まる。 

000　Routine

001　Priority

010　Immediate

011　Flash

100　Flash override

101　Critic/Critical

110　Internetwork Control

111　Network Control

Type of Service値はパケットの優先順位としては使用されない。

1000　Minimum delay

0100　Maximize throughput

0010　Maximize reliability

0001　Maximize monetary cost

0000　Normal Service

＜「TOS Byte」領域が、DSフィールドと呼ばれる場合＞

RFC2474(1998)でDFフィールドが策定された。
DSフィールドとして扱われる場合、優先制御のための値はDSCP値(6bit)と呼ばれる。

TOSフィールドのPrecedence値と互換性を保つように工夫されている。

xxx xxx/xx

パケットが通るルーター等はこのDSCP値を見て優先制御処理を施す。

たとえば、DSCP値として次の6bitの値を持つパケットはベストエフォート処理がなされる。

000 00 0　best effort

◯DSフィールドの上位3bitが定めるクラスについて

優先度を設定するDSCP値のbitの使い方はTOSのPreference値との互換性を維持するために特殊である。

下図のように上位3bit(Class-selector Code Points)を用いて大きく8クラスで優先度を意味付けする。

クラスはCS0〜CS7にわけられ、それぞれTOSのPreference値の「Routine」から「Network Control」に対応づけられる。

このように区分することで「TOS Byte」の情報をDSフィールド(6bit)でなくTOSフィールドとしてしか認識できないルーター等でもPrecedence値(3bit)として認識できる。

CS0　000  xxx
CS1　001  xxx 
CS2　010  xxx 
CS3　011  xxx 
CS4　100  xxx 
CS5　101  xxx 
CS6　110  xxx 
CS7　111  xxx 

下位3bitは、Drop Probability値として使用される。

◯DSフィールドの下位3bitが定めるDrop Probability値について

その後、RFC2597によってAF(Assured Forwarding)が定められた。

これに対応するルーター等のネットワーク機器は重要なパケット転送を確実にするために、

Drop Probability値に応じてパケットをDrop（落とす）する。

IPパケットの「TOS Byte」においてDSフィールドDSCP値の下位3bitはそのための値を設定する。

01 0　LOW Drop probability

10 0　Midium Drop probability

11 0　High Drop probability

より高い値を持つパケットが先に落とされる。

DSCPの上位3bit(Class-selector Code Points)と、下位3bit(Drop Probability)とを併せると、次のようにAFが定まる。

(CS1 Priority)

001 01 0  …AF11

001 10 0  …AF12

001 11 0  …AF13

(CS2 Immediate)

010 01 0  …AF21

010 10 0  …AF22

010 11 0  …AF23

(CS3 Flash)

011 01 0  …AF31

011 10 0  …AF32

011 11 0  …AF33

(CS4 Flash override)

100 01 0 …AF41

100 10 0 …AF42

100 11 0 …AF43

さらに、次のDSCP値は、特別にEF(Expedited Forwarding)と呼ばれる。

VOIPパケット等で使用されるらしい。

(CS5 Critic/Critical)

101 11 0 …EF

○NGN網が優先制御情報を持ったパケットを落としている

どうやら、NGN網の場合、ベストエフォートに設定されたパケットでなければ、
途中で落とされる仕様になっている可能性がある。
後で検証したように、優先制御情報の変更で通信が可能になったので、この線が濃厚である。

ローカルネット内ではIPv4パケットでも、先に示したネットワーク図の通り、
RTX1210によってNGN網内を通過するIPsec VPNは、IPv6でそのIPv4パケットをカプセル化している。

どうやら、RTX1210、RTX1200、RTX810ルーターなどのIPsecやIPIPトンネル機能の仕様によって、
カプセル化するIPv4の優先制御情報は、IPsecやIPIPトンネルのカプセリングIPv6パケットに転移されるようである。
このことは、以下のリリースノートから推測された。

[18] IPIPトンネル機能で、以下の通信においてカプセル化されたパケットのIPヘッダーの、ToSフィールドおよびTraffic Classフィールドが外側のIPヘッダーにコピーされないバグを修正した。
     - IPv4 over IPv4 ノーマルパス
     - IPv4 over IPv6 ノーマルパス/ファストパス
     - IPv6 over IPv4 ノーマルパス/ファストパス
     - IPv6 over IPv6 ノーマルパス/ファストパス

http://www.rtpro.yamaha.co.jp/RT/docs/relnote/Rev.14.01/relnote_14_01_33.txt

このリリースノートは、RTX1210のファームウェア Rev.14.01.33 のものである。
私は今回の問題が生じるまで、これより古いファームウェアを導入していた。
ファームウェアのアップデートでこのバグが修正されたことによって、皮肉にも、
IPIPトンネルでの通信がうまくできなくなってしまったのではないかと考えている。



■対策について

最初に挙げたネットワーク図の、VOIP gateway を接続しているRTX810で、
IPv4パケットの優先制御情報を解除しベストエフォート扱いされるように設定した。

次のコマンドで設定することによって可能である。

# ip tos supersede ?
    入力形式： ip tos supersede リスト番号 TOS [precedence=PRECEDENCE] F1
               [F2...]
               リスト番号 = 1-65535, TOS = 0-15, PRECEDENCE = 0-7
　    　説明： 転送するIPパケットのTOSフィールドを書き換えるか否かを選択します

F1とか、F2とか、記されている引数は、静的フィルタの番号である。
ルーター内をフォワードされるIPパケットがこの静的フィルタにマッチした場合、
コマンドで設定したように優先制御情報が再セットされるようになるということである。


そこで、VOIP gateway(192.168.1.254) から出発して IP PBX(192.168.0.0/16,172.16.0.0/12) へ向かうudpパケットにマッチする静的フィルタ（21番）を作成した。

# ip filter 21 pass 192.168.1.254 192.168.0.0/16,172.16.0.0/12 udp 

次に、上記フィルタ21番にマッチするパケットについて、優先制御情報をベストエフォートにセットするためのコマンドを実行した。
このコマンドは、TOSフィールドとして優先情報を設定する。
即ち、Precedence値(上位 3bit)と、Type of service値(下位 4bit)を設定できる。

# ip tos supersede 11 0 precedence=0 21

 ・11は、リスト番号であり任意である。
 ・0は、TOSフィールドのType of service値(4bit)に設定する値で、10進数で入力した。

（show config | grep tos で調べてみると、この0の部分は「normal」というニーモニックに変換されていた。）

ニーモニックとTOS 値（=DSCP値下位3bit(Drop Probability) xx xとして見た場合）

normal　　　　　　0 (=00 0  0)

min-monetary-cost　1 (=00 0  1)

max-reliability　　　2 (=00 1  0)

max-throughput　　4 (=01 0  0)

min-delay　　　　8 (=10 0  0)

DSCP値の下位3bitはAF値を設定する。（上記参照）

01 0　LOW Drop probability

10 0　Midium Drop probability

11 0　High Drop probability

より高いAF値を持つパケットが先に落とされる。

 ・precedence=0 は、TOSフィールドのPrecedence値(3bit)に設定する値で、10進数で入力した。
 ・21は、上で定義済みの静的フィルタ番号で、パケット選択するためのものである。

つまり、TOSフィールド(xxx xxxx -)として、000 0000 を設定したことになる。
しかし、これは、DSフィールド (xxx xx x --)として見ることもでき、000 00 0 を設定したことになる。



その結果、うまく通信することができた。

最初に挙げたネットワーク図のRTX810において、VOIP gatewayからのIPv4パケットの優先制御情報をベストエフォートに再設定したことによって、
IPSec/IPIP終端のRTX1210において、このIPv4パケットをカプセリングするIPv6のIPIPカプセリングパケットでもベストエフォートに設定されたと考えられる。

（上で参照したリリースノートで述べられている、カプセル化されたパケットのIPヘッダーの、ToSフィールドおよびTraffic Classフィールドが外側のIPヘッダーにコピーされるということ。）

ところが、TCPパケット通信（rsync、scpなど）はまた異なった設定が必要だった。

後述している。



■さらなる検証でわかったこと

次のように優先制御情報を書き替えて、通信できるか試した。

# ip tos supersede 11 15 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 1111
DSフィールド (xxx xxx --)として、000 11 1

結果→×
 
# ip tos supersede 11 14 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 1110
DSフィールド (xxx xxx --)として、000 11 1

結果→×

# ip tos supersede 11 13 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 1101
DSフィールド (xxx xxx --)として、000 11 0

結果→×

# ip tos supersede 11 12 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 1100
DSフィールド (xxx xxx --)として、000 11 0

結果→×

# ip tos supersede 11 11 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 1011
DSフィールド (xxx xxx --)として、000 10 1

結果→○

# ip tos supersede 11 10 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 1010
DSフィールド (xxx xxx --)として、000 10 1

結果→○

# ip tos supersede 11 9 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 1001
DSフィールド (xxx xxx --)として、000 10 0

結果→○

# ip tos supersede 11 8 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 1000
DSフィールド (xxx xxx --)として、000 10 0

結果→○

# ip tos supersede 11 7 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 0111
DSフィールド (xxx xxx --)として、000 01 1

結果→×

# ip tos supersede 11 6 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 0110
DSフィールド (xxx xxx --)として、000 01 1

結果→×

# ip tos supersede 11 5 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 0101
DSフィールド (xxx xxx --)として、000 01 0

結果→×

# ip tos supersede 11 4 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 0100
DSフィールド (xxx xxx --)として、000 01 0

結果→×

# ip tos supersede 11 3 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 0011
DSフィールド (xxx xxx --)として、000 00 1

結果→○

# ip tos supersede 11 2 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 0010
DSフィールド (xxx xxx --)として、000 00 1

結果→○

# ip tos supersede 11 1 precedence=0 21
TOSフィールド(xxx xxxx -)として、000 0001
DSフィールド (xxx xxx --)として、000 00 0

結果→○


# ip tos supersede 11 0 precedence=7 21

TOSフィールド(xxx xxxx -)として、111 0000
DSフィールド (xxx xxx --)として、111 00 0

結果→○


これらの結果から、TOS/DSフィールドの5bit目の値が、
1のときには通信がうまくできず、
0のときには通信がうまくできることがわかった。
ただし、precedence=0 の場合でしか試していない。

ちなみに、最後に挙げた結果の通り、precedence=7の場合でも通信可能だった。

結果としては、優先制御情報を変更したことで通信できるようになったものの
これらの結果は、優先制御フィールドの意味と合わなくなってくるので、解釈に困る。

◯TCPパケットは設定が異なった。

以上に見てきたように、udpのVOIP関係パケットにおいては次のコマンドの設定で、

そのパケットをカプセル化するVPNパケットをNGN網を通過できるようになった。

# ip filter 21 pass 192.168.1.254 192.168.0.0/16,172.16.0.0/12 udp 

# ip tos supersede 11 0 precedence=0 21

これは、TOSフィールド(xxx xxxx -)として、000 0000 を設定し、
DSフィールド (xxx xx x --)としては、000 00 0 を設定したことになる。

しかし、tcpのパケット（rsyncやscpなどの通信が該当）についても同様に設定を行ったがVPNカプセリング通信がNGN網でできなかった。

# ip filter 22 pass 192.168.1.254 192.168.0.0/16,172.16.0.0/12 tcp

# ip tos supersede 11 0 precedence=0 22

（パケット通らず×）

tcpのパケット（rsyncやscpなどの通信が該当）については次のように設定することによって、NGN網での通信ができるようになった。

# ip filter 22 pass 192.168.1.254 192.168.0.0/16,172.16.0.0/12 tcp

# ip tos supersede 12 0 precedence=1 22

（通信成功○）

 

（注意）

ただし、後ほどのiperf3による検証でわかったが、この設定をtcpに対して行うと、

今回問題にしているVPN経由の上りのスループットが犠牲になってしまった。

設定を解除すれば、5MB/secのスループットを得られるが、（もちろん、rsyncやscpは使えない）

設定を行うと1MB/sec程度のスループットしか得られなくなってしまった。

なにか、最適な設定があるのだろうと思うが、今後の課題とする。

こちらも解釈がよくわからない。

これは、TOSフィールド(xxx xxxx -)として、001 0000 を設定し、
DSフィールド (xxx xx x --)としては、001 00 0 を設定したことになる。

このPrecedence値が001は、000よりも優先度が高くなっている。

000で通らずに、001で通るようになるとはいったいどういうことなんだろうか。

# ip tos supersede 12 normal precedence=0 22 以外であれば、次の場合でも通信できた。

# ip tos supersede 12 normal precedence=1 22

# ip tos supersede 12 normal precedence=2 22

# ip tos supersede 12 normal precedence=3 22

# ip tos supersede 12 normal precedence=4 22

# ip tos supersede 12 normal precedence=5 22

# ip tos supersede 12 normal precedence=6 22

# ip tos supersede 12 normal precedence=7 22

いったいNGN独自の定義でもあるのだろうか。

それとも、RTX側の仕様のためなんだろうか。

よくわかりません。

以上

＜参考＞

・IP Precedence & DSCP Values (Quality of Service) QoS

< https://www.slideshare.net/NetworkersHome1/ip-precedence-dscp-values-quality-of-service-qos >  2021年2月17日

・https://ja.wikipedia.org/wiki/Type_of_Service

< https://en.wikipedia.org/wiki/Differentiated_services >2021年3月1日

・RTX810 で QoS（TOSとPrecedence）の設定
< https://www.lonnie.co.jp/network/rtx810-qos/ > 2020年1月18日

・DSCP ( Differentiated Services Code Point )
< https://www.infraexpert.com/study/qos7.htm > 2020年1月18日

・9.1.28 IP パケットの TOS フィールドの書き換えの設定
< http://www.rtpro.yamaha.co.jp/RT/manual/rt-common/ip/ip_tos_supersede.html > 2020年1月18日

・RTX810で050 plusとLINEのQoS制御をする
< http://kusoneko.blogspot.com/2018/10/rtx810-qos-control-for-voip.html > 2020年1月18日

・DSCP
< https://www.itbook.info/study/qos11.html > 2020年1月18日

・第2回　IPv6パケットの構造を知る (1/2)
< https://www.atmarkit.co.jp/ait/articles/1201/05/news113.html > 2020年1月18日