要約

  • RFC 8029のMPLS Echo requestはTarget FEC Stackに対応するdata pathを進み、受信したLSRがforwardingとcontrol-plane knowledgeを照合する。replyはそのprobe、そのFEC、そのnode、その時点の証拠である。
  • ECMPを完全に網羅できない場合があり、通常使わないbackup pathは手順の外にある。replyは通常のIPや別control channelを通ることもある。一回の成功も無応答も、service全体の判定にはならない。
  • 強いreceiptはprobe入力、実際のpathとreturn code、reply modeと復路、試験済み・未試験のpath、継続BFD状態、独立したcustomer transactionを接続する。

運用画面に緑が点く。MPLS pingが戻った。その瞬間、「serviceはup」という短い文が作られる。しかし戻ったpacketは、もっと狭い仕事のために設計された。

requestにはTarget FEC Stack、label context、sequence number、reply modeが入る。その値によって一つのforwarding結果が選ばれ、routerは定義された検査を行いcodeを返す。このexchangeを丸ごと「service」と呼べば、何を試したのかが消える。

2017年のRFC 8029は現在のLSP Ping仕様を統合したStandards Track RFCである。Kireeti KompellaはGeorge Swallow、Carlos Pignataro、Nagendra Kumar、Sam Aldrin、Mach Chenと並ぶ6人の著者の筆頭で、元のRFC 4379などを置き換えた。これはIETFの共同作業への貢献を示す。Kompellaが全implementationやdeploymentを所有するという意味ではない。

Probeが問う相手はFECである

LSPの終端addressをinitiatorが知らなくても、label-switched pathは検査されなければならない。そのためrequestはforwarding equivalence classを記述する。単一のLDP prefixやRSVP sessionで足りる場合も、VPNとtunnelを表す複数FECが必要な場合もある。

127/8のdestinationはMPLS内の転送判断には使われない。label stackがpacketを運ぶ。特別なaddressは、壊れたLSPから早く出た診断packetがcustomerへ普通のIPとして転送されるのを避ける。予定egressでは、自分がそのFECの終端かを確認する。traceroute modeはTTLを増やしながらtransit LSRへ問い、ずれた場所を絞る。

したがって「ping成功」では足りない。時刻、sequence、label stack、FEC、応答LSR、return code/subcodeが必要である。実際のMPLS payloadを運ぶserviceでは、追加labelを含めなければ露出しない故障もある。単純Echoが通っても、L2VPNやL3VPNのpayloadをinterfaceが運べないことがある。欠けたlayerは、probeの成功を借りられない。

ECMPの一経路は全体の代理ではない

同じFECに複数next hopがあり得る。address、UDP source port、entropy label、traffic class、payload判定、vendor固有algorithmがpathを変える。LSP Pingはfieldを変え、downstream mappingを追う方法を提供するが、完全な列挙を約束しない。

RFC 8029は、proprietaryな分配algorithmのため全alternate pathを網羅できないこと、通常使わないbackupを扱わないこと、複数段ECMPでは全組合せに届かないことを認める。positive replyは、そのpacketが選んだpathの結果である。触れていないmemberまで健康にはしない。

RFC 7882のBFD use caseも、一つのECMP path上のsessionがupのまま、別pathのtrafficがblackholeへ落ちる状況を示す。dashboardには分母が要る。「8経路中7経路、backup 1は未試験」と書くべきで、「MPLS正常」と圧縮してはならない。packet classも残す。低rateのIP probeと高負荷のnon-IP payloadではhash、queue、policerが違い得る。

Replyは別の道を持つ

Echo Replyはforward LSPを逆向きに通る必要がない。RFC 8029にはno reply、通常のIPv4/IPv6 UDP、Router Alert付きUDP、application-level control channelがある。RFC 7110がreturn path指定を追加したのは、reply pathがforward probeと別の証拠だからである。

management networkでreplyを受けてもreverse customer pathは証明されない。replyがなくてもforward failureとは限らない。nodeが未対応、control-plane policerがdrop、またはreturn routeが故障した可能性がある。RFC 8029はfalse negativeを認め、tracerouteではsilent nodeの先を試す。

receiptは二つのlegを分ける。forwardにはlabel、FEC、TTL、downstream、validation。returnには要求・実際のmode、address、transport、constraint、arrival time。通常IPならそう記す。reverse LSPのevidenceがなければunknownのままにする。

三つの時間軸を混ぜない

LSP Pingはある時点の診断である。RFC 5884はLSP PingでBFD sessionをbootstrapしLSPへ結び付け、その後BFDがnegotiated intervalでcontinuityを監視する。正午のEchoは12時5分を保証せず、一時間upのBFDも未使用ECMP memberを証明しない。

customer serviceは第三の時計で動く。CE interface、pseudowire、MTU、payload size、class、encryption、transport、applicationが残る。契約windowのloss、delay、availabilityも必要になる。LSP Pingはchain内のMPLS faultをlocalizeできるが、chainそのものではない。

return code、subcode、mappingは説明であってbadgeではない。hierarchical/stitched tunnelではFEC Stackが変わり、Nil FECで詳細が隠れることもある。handle、sequence、timestamp、rate limit、source filterはspoofingやreplayへの耐性を高めるが、customer outcomeを認証しない。

Heng Luのagency論は役割を明確にする。標準著者は共通grammarを作り、implementerがcodeを作り、operatorがcoverageを設計し、service ownerが目的を決める。著者名は製品をcertifyせず、router replyはSLAへ署名しない。minimum specificationはinteroperabilityを成立させるが、現地判断を中央のbadgeへ移さない。running codeも、実際に走らせたexperimentの範囲だけを証言する。

Joinを残したdiagnostic receipt

まず問いを保存する。initiator、時刻、LSP、Target FEC Stack、label stack、payload depth、TTL、mode、traffic class、entropy、ECMPに影響するfield。次にobservationとしてLSR、code、mapping、FEC change、interface、label result、response time、configuration epochを残す。

coverageはnext hop、試した組合せ、観測path、未到達path、backup、unsupported node、未知の母集団を列挙する。returnは独立blockにする。BFDはsession、discriminator、interval、transition、windowを足す。customer testはendpoint、payload、class、objectiveを持つ。

最終文は具体的になる。このFECへのprobeはこのforward pathを通り、条件下でmatched replyを受けた。これらのalternate pathは未試験で、continuityはこのwindowだけ観測され、別のservice transactionは目標を満たした、または満たさなかった。「ping OK」より長いが、判断に使えるのはこちらである。

出典