[plamo:15624] Re: B-Flets の接続遅延

[早間義博]

From: Nobuhiro Kikuchi <kikuchi@be.to>
Subject: [plamo:15623] Re: B-Flets の接続遅延
Date: Sun, 13 Oct 2002 13:31:39 +0900
Message-ID: <20021013124037.EEE7.KIKUCHI@be.to>

> きくちです。
> 
> On Sat, 12 Oct 2002 10:58:43 +0900 (JST)
> 早間義博 <yossi@yedo.src.co.jp> wrote:
> 
> > B-flets で接続に時間が掛かる場合があります。Flets は不明点が多く
> > プロバイダに問い合わせると「ＮＴＴ地域網云々」と言われ
> > NTTに問い合わせると返事が無い
> > 結局は判らないと言うことが続きました。
> 
> この現象は PPP が異常終了したあとの再接続時のみ発生しているので
> しょうか。それとも正常時も?
>

idle タイム後の再接続でも同じ現象は起きていますが、原因が同問題だ
と言える資料（ログ）は持っていません。
当初、128KBPS を主回線として B-Flets に Web サーバのみを置こうかと
思っていました。このころは idle タイムによる再接続が頻繁に発生し、
再接続に要する時間が下記のように計測されています。（１日分です）
Sec.: Counts 
  0 :  109
  1 :   25
  2 :    7
  3 :    4
  4 :    2
  6 :    1
 70 :    1
 74 :    2
 84 :    1
134 :    1
141 :    1
187 :    1
194 :    1
221 :    1
226 :    1
270 :    1
272 :    1
273 :    1
275 :    1
323 :    1
327 :    1
336 :    1
337 :    1
350 :    1
352 :    1

蛇足ですが Sec. は /var/log/messages にある pppd のログで
 ppp session is nnnn と記入された時刻から 
 IP が得られるまでの秒数です。
この中で ２７０秒の場合のみ pppd が終了しています。

この接続時間に驚き、プロバイダにも問い合わせたのですがプロバイダか
らは idle time で切断してから再接続までが２秒しかないことが原因で
切断後６０秒置くようにと指示されました。
指示の内容が悪いとは言えませんが、実測値からも判るように根拠がある
数値とも言えません。

> > Linix で kdebug を指定すると LCP など PPP のパケットの内容が記録さ
> > れます。その結果ですがB-Flets では次の手順で接続されます。
> > （１）PADS が送られNTTのサーバとの接続が始まる。
> 
> 最初はクライアントからの PADI ですね。
>

私もそのように思うのですがログ(debug）に次のように載っているのです。
  pppd[283]: PADS: Service-Name: ''
  pppd[283]: using channel 2
  pppd[283]: sent [LCP ConfReq  

> > 切断が手順通り進まないとプロバイダが切断を認識できないと考えられま
> > す。複数IPでの接続の場合はルーティングの問題もあり重複接続を許可出
> > 来ません。
> > 前接続の完了を待たないと次の接続を許可出来ないのですが、この事が接
> > 続遅延の原因になっていると思われます。
> > 
> > クライアントは無信号時間を調べて一定時間後に切断再接続が出来るので
> > すがサーバ（プロバイダ）が何故復旧出来るのかが謎です。
> 
> クライアント側の異常終了時に切断を認識できないのはプロバイダではなく
> "NTTサーバ" (BASと呼びます)です。
> 
> BAS は LCP Echo を定期的に投げていて一定時間応答がないと PADT を
> 投げてセッション終了します。(NTT東と西でこの時間は異なります)
> 
> これにより ISP側 (正確にはIP網のISP接続点に置かれる LNS) も
> 切断を認識します。
> 
> 同一アカウントでの多重接続を防ぐために ISP の認証サーバで
> セッション管理している(はず)ですが、この情報は LNS から RADIUS
> Accounting で受けています。
> 
> ちなみに、PPPoE 同時接続数(異常終了のセッションも含む)を越えて
> セッションを張ろうとした場合は PADI に対して BAS から応答(PADO)が
> ないはずです。
> 

プロバイダはそのように言いますが次のログから地域網が拒否していると
は感じられません。

18:32:38 lred pppd[283]: PADS: Service-Name: ''
18:32:38 lred pppd[283]: using channel 2
18:32:38 lred pppd[283]: sent [LCP ConfReq id=0x1
18:32:38 lred pppd[283]: rcvd [LCP ConfReq id=0x1
18:32:38 lred pppd[283]: sent [LCP ConfAck id=0x1
18:32:38 lred pppd[283]: rcvd [LCP ConfAck id=0x1
18:32:38 lred pppd[283]: rcvd [CHAP Challenge id=0xf1
                  ここに地域網のサーバ名
18:32:38 lred pppd[283]: sent [CHAP Response id=0xf1
                  ここにこちらのプロバイダのログイン名
18:32:38 lred pppd[283]: rcvd [CHAP Failure id=0xf1 "Request Denied"]
18:32:38 lred pppd[283]: sent [LCP TermReq id=0x2 
                  "Failed to authenticate ourselves to peer"]
18:32:38 lred pppd[283]: rcvd [LCP TermReq id=0x1] 
18:32:38 lred pppd[283]: sent [LCP TermAck id=0x1]
18:32:41 lred pppd[283]: sent [LCP TermReq id=0x3
                   "Failed to authenticate ourselves to peer"]
18:32:54 lred pppd[283]: PADS: Service-Name: ''
18:32:54 lred pppd[283]: using channel 3

using channel が何を意味しているか判っていませんがこのログでは同じ
シーケンスで単調増加、増分 1 で using channel 31 まであります。
つまり
   sent [LCP ConfReq id=0x1 から
    "Failed to authenticate ourselves to peer"]
までが２９回続いて３０回目（今回は２から始まっているので）に
   rcvd [CHAP Success
に行き着けました。
この回線でプロバイダ２社使用できる状態にあり、NTT がプロバイダのロ
グイン名から回線使用者を割り出していると言うことは不条理です。

きくちさんの指摘を受けて、状況を考えているうちに次のように考えまし
た。
（１）クライアントが正常な手続きを経ず切断した場合にはプロバイダか
      ら NTT 地域網間の接続が維持されたままになる。
（２）クライアントに B-Flets で使用可能なチャネルが残っていると、
      残ったチャネルを使用して接続を試みることができる。
（３）このとき、（１）の状態にあるためプロバイダが接続を拒否する。
（４）一定時間経過後 NTT が回線の idle 状態が続いている事を認識し
      て（１）のセッションを切断し、プロバイダに切断を告げる。
（５）（４）が起こるとプロバイダが新しい接続を許可する。

ただ、クライアントが問題にしているのは利用状況であるのに対してプロ
バイダや NTT は技術的な問題を返答してくる。クライアントにとっては
理由は何であれ、接続出来ない状況を回避したいのです。

プロバイダに上記（３）の時に接続を変更（接続中のセッションを断って
新しい方を認める）ように要求してみるつもりです。

-- 早間  yossi@yedo.src.co.jp