http://www.rtpro.yamaha.co.jp/RT/docs/relnote/Rev.07.01/relnote_07_01.26.txt Revision : 07.01.26 Release : Oct 2003, ヤマハ株式会社 RTX1000/RTX2000 Rev.7.01.26 リリースノート ========================================================================== ○ Rev.7.01.16/17からの変更点 ========================================================================== ■機能追加 [1] RTX2000で優先制御、帯域制御が動作するようになった。設定方法は RTX1000と同様。 http://www.rtpro.yamaha.co.jp/RT/docs/qos/priority.html http://www.rtpro.yamaha.co.jp/RT/docs/qos/band-shaping.html [2] IPsecのトンネルインタフェースで優先/帯域制御を使えるようにした。 http://www.rtpro.yamaha.co.jp/RT/docs/qos/tunnel_qos.html 以下の2つのコマンドにパラメータが追加される。 - queue INTERFACE class filter list INTERFACEパラメータとしてLANインタフェース名、ppに加えてtunnelが 指定できる。 - ipsec sa policy anti-replay-checkオプションが追加される。 [入力形式] ipsec sa policy POLICY_ID GW_ID ... [OPTION] [パラメータ] ... ・OPTION anti-replay-check=SW SW on ... シーケンス番号のチェックを行う off ... シーケンス番号のチェックを行わない [説明] ... 'anti-replay-check=on'の場合、受信パケット毎にシーケンス番号の 重複や番号順のチェックを行い、エラーとなるパケットは破棄する。 破棄する際には debug レベルで [IPSEC] sequence difference [IPSEC] sequence number is wrong といったログが記録される。 相手側が、トンネルインタフェースでの優先/帯域制御を行っている 場合、シーケンス番号の順序が入れ替わってパケットを受信すること がある。その場合、実際にはエラーではないのに上のログが表示され、 パケットが破棄されることがあるので、そのような場合には設定を offにするとよい。 [デフォルト値] anti-replay-check=on [3] 代理ARPで、VRRPマスターとして動作している時にはVRRPの仮想MACアドレ スを返せるようにした。 [入力形式] ip INTERFACE proxyarp SW ip INTERFACE proxyarp vrrp VRID no ip INTERFACE proxyarp [...] [パラメータ] INTERFACE ... LANインタフェース名 SW ... on 代理ARPを行なう off 代理ARPを行なわない VRID ... VRRPの仮想ID、1〜255 [説明] 代理ARP動作を行なうか否かを設定する。 'off'を設定した時には、代理ARP動作を行なわない。 'on'を設定した時には、代理ARP動作を行なう。この時利用するMACア ドレスは、LANインタフェースの実MACアドレスとなる。 'vrrp VRID'形式を設定した時には、指定されたVRIDでのVRRPの状態 がマスターである場合のみ代理ARP動作を行なう。利用するMACアドレス は指定されたVRIDの仮想MACアドレスとなる。 [デフォルト] off ■仕様変更 [1] DNSリカーシブサーバ機能で、EDNS0に対応したクライアントからの問い合 わせを処理できるようにした。 EDNS0はRFC2671に規定されており、DNS問い合わせパケットにOPT RRを含 んでいる。従来の実装では、OPT RRを含むDNS問い合わせパケットに対し ては問い合わせそのものを無視し何の返事も返していなかったが、 RFC2671に従ってエラーとしてFORMERRを返すようにした。エラーを受信し たEDNS0対応クライアントはEDNS0を使わないようにフォールバックし、処 理が先に進む。 この修正により、bind9の上位サーバとして動作する時に、bind9の設定で EDNS0を無効にする必要がなくなる。 [2] OSPFで、スタブが存在する時のそのネットワーク経路の扱いを、RFC2328 の記述に沿うように変更した。 従来は、あるネットワークに対して複数のスタブが同一コストで存在する 場合や、スタブと同じコストでネットワークLSAによる経路が存在する時 には、イコールコストマルチパス動作をせずに、スタブによる経路が無視 されていた。RFC2328に沿うと、このような場合はイコールコストマルチ パス動作をすることになるはずなので、そのように動作を変更する。ただ し、以下のコマンドで従来の動作も選択できるようにする。 [入力形式] ospf merge equal cost stub SW [パラメータ] SW ... on イコールコストになるスタブを他の経路とマージする SW ... off イコールコストになるスタブを他の経路とマージしない [説明] 他の経路と同じコストになるスタブをどう扱うかを設定する。 'on'の場合にはスタブへの経路を他の経路とマージして、イコールコ ストマルチパス動作をする。これは、RFC2328の記述に沿うものであ る。 'off'の場合には、スタブへの経路を無視する。 [ノート] Rev.7.01.16以前は'off'動作だった。 Rev.7.01.17以降は'on'動作がデフォルトとなる。 [デフォルト] on [4] IPsecトンネルの外側IPv4ヘッダを構築する時に、DFビットの値としては 従来は常にトンネルで運ばれる内側IPv4パケットのDFビットの値をそのま まコピーしていたのを、コマンドでどのようにするか設定できるようにし た。 [入力形式] ipsec tunnel outer df-bit MODE [パラメータ] MODE ... copy 内側のIPv4パケットのDFビットを外側にもコピーする set 常に1 clear 常に0 [説明] IPsecトンネルの外側のIPv4パケットで、DFビットをどのように設定 するかを制御する。 'copy'の場合には、内側のIPv4パケットのDFビットをそのまま外側に もコピーする。 'set'、'clear'の場合には、内側のIPv4パケットのDFビットに関わら ず、外側のIPv4パケットのDFビットはそれぞれ1、または0に設定され る。 トンネルインタフェース毎のコマンドである。 [ノート] トンネルインタフェースのMTUと実インタフェースのMTUの値の大小関 係により、IPsec化されたパケットをフラグメントしなくてはいけな い時には、このコマンドの設定に関わらずDFビットは0になる。 [デフォルト] copy [5] IPマスカレード変換時にDFビットを削除するかどうかをコマンドで変更で きるようにした。 [入力形式] nat descriptor masquerade remove df-bit SW [パラメータ] SW ... on IPマスカレード変換時にDFビットを削除する off IPマスカレード変換時にDFビットを削除しない [説明] IPマスカレード変換時にDFビットを削除するかどうかを設定する。 DFビットは経路MTU探索のために用いるが、そのためには長すぎるパ ケットに対するICMPエラーを正しく発信元まで返さなくてはいけない。 しかし、IPマスカレード処理ではIPアドレスなどを書き換えてしまう ため、ICMPエラーを正しく発信元に返せない場合がある。そうなると、 パケットを永遠に届けることができなくなってしまう。このように、 経路MTU探索のためのICMPエラーが正しく届かない状況を、経路MTUブ ラックホールと呼ぶ。 IPマスカレード変換時に同時にDFビットを削除してしまうと、この経 路MTUブラックホールを避けることができる。その代わりに、経路MTU 探索が行なわれないことになるので、通信効率が下がる可能性がある。 [ノート] RTX1000のRev.7.01.26以前のファームウェアでは、IPマスカレード変 換時にDFビットを削除するかどうかについては、実装の揺れがある。 Rev.7.00系: 常にDFビットを削除する Rev.7.01系: ファストパス処理ではDFビットを削除しない ノーマルパス処理ではDFビットを削除する ファストパス処理は、一度ノーマルパス処理で通過させたパケットの 情報を保存しておき、同じ種類のパケットであれば高速に転送すると いう処理を行なっている。そのため、例えばpingコマンドを実行した 場合、最初の1回目はノーマルパス処理、2回目以降はファストパス処 理となる。そのため、最初の1回はDFビットが削除されるが、2回目以 降はDFビットが削除されないという状況だった。 Rev.7.01.26以降はファストパス、ノーマルパスともこのコマンドの 設定に従う仕様となる。 [デフォルト] on [6] RTX1000のネットボランチDNS機能で、以下の変更をした。 - netvolante-dns timeoutコマンドのデフォルト値を30秒から90秒に変更 した。 - 何らかのエラーにより自動更新に失敗した場合、自動更新処理を3回ま でリトライするようにした。 [7] RTX2000で、ip INTERFACE tcp mss limitコマンドやpppoe tcp mss limit コマンドによるMSS書き換え機能で、本来であれば書き換えるべきMSS値よ りも小さなMSS値を受信した時には書き換えずにそのまま転送すべきとこ ろを、強制的に書き換えてしまうバグを修正した。 例えば、トンネルインタフェースで受信したパケットをPPPoEインタフェー スに転送する場合に、それぞれのMSS値がトンネルでは1240、PPPoEでは 1414という値になっていたとすると、トンネルを通ったために1240になっ たMSSはPPPoEを通っても1240のままでなくてはいけないが、1414に書き換 えられてしまうというバグである。 ■バグ修正 [1] MMIで以下のバグを修正した。 - ip routeコマンドでゲートウェイとしてIPアドレスを指定すると、1回 のコマンド実行あたり約80バイト程度メモリリークする - no isdn local addressコマンド、no lan typeコマンドで、パラメータ まで指定してコマンドを実行するとエラーになる - TFTPにより設定ファイルを送り込む時に、clear configurationコマン ドで設定を消去しようとすると、isdn local addressコマンドとlan type コマンドの設定が消えずに残ってしまう - NATの設定が何もされていない状態で、管理者モードでshow nat descriptor addressコマンドやshow nat descriptor interface address コマンドを実行後exitすると、設定を何も変更していないのに 設定を保存するかどうかを聞かれる - pp auth usernameコマンドで、clidパラメータがあり、かつ、着信用電 話番号が設定されていないと、show configでの表示が後続の行とつな がってしまったり、設定が保存できない - speedコマンドのオンラインヘルプでデフォルト値の表示を削除した - ip filterコマンドで、IPアドレスを範囲指定で指定する時に、IPアド レスとして不正な形のものを入力してもエラーにならず、不定な値が設 定されてしまう - ip filter/ipv6 filter コマンドで、始点IPアドレスに不正な値を設定 すると、コマンド設定のたびごとに数十バイト程度メモリリークする - ip INTERFACE ospf areaコマンドとospf virtual-linkコマンドで、 md5-sequence-modeオプションがオンラインヘルプに表示されず、TAB補 完も効かない - ip fragment remove df-bitコマンドで、filterキーワードの後にフィル タ番号の指定がなくてもエラーにならない [2] ipsec sa policyコマンドを設定したときに、以下のいずれかの操作をす るまで設定した内容が有効にならず、設定以前の状態のまま動作し続ける バグを修正した。 - ipsec refresh saコマンドを実行する。 - ipsec sa policyコマンドで指定したものと同じゲートウェイ番号につ いて、ipsec ike remote addressコマンドを実行する。 [例] ipsec sa policy 101 1 ... を設定したときには、 ipsec ike remote address 1 ... を設定する。 - 実行したipsec sa policyコマンドに対応するトンネルインタフェース で、ipsec tunnelコマンドを設定する。 [例] ipsec sa policy 101 1 ... を設定したときに、 tunnel select 1 ipsec tunnel 101 を設定する。 - 再起動する。 これらの操作は、すべてipsec sa policyコマンドを実行したルータで行 なう必要がある。IPsecの対向側のルータを操作しても状況は改善されな い。 Rev.7.01.15(RTX1000)、Rev.7.01.17(RTX2000)でエンバグした。 [3] DHCPクライアント機能を動作させていない状態で、show status dhcpcコ マンドを実行すると、実際に表示されるのは1行だけなのに、「---つづ く---」と表示されmore機能が動作してしまうことがあるバグを修正した。 more機能が動作するかどうかは、直前に実行した他のshow系コマンドの表 示行数に依存する。また、DHCPクライアント機能が動作している場合には この問題は発生しない。 [4] telnetd host、telnetd listen、telnetd serviceの各コマンドを実行す ると、デバッグログに [TELNETD] Invalid Message Code = 0x00002204 というログが記録されるバグを修正した。このログが記録されていても動 作上の問題はない。 [5] ipsec ike remote addressコマンドで相手としてIPアドレスではなくホス ト名を設定しているときに、ipsec ike local addressコマンドを設定す ると、ipsec ike remote addressコマンドの設定がホスト名から'any'に 変化するバグを修正した。 [例] コンソールから ipsec ike remote address 1 host-name ipsec ike local address 1 192.168.0.1 と入力すると、前者の設定が ipsec ike remote address 1 any に変化する。 設定が'any'に変化すると、動作も'any'としての動作になってしまうので、 相手と接続できなくなる。この場合、再度ipsec ike remote addressコマ ンドで正しい設定を行なえば、接続できるようになる。 [6] ipsec ike remote addressコマンドで、相手先としてホスト名を設定する と、その後設定をIPアドレスに変更してもIPsecの動作に変更が反映され ないバグを修正した。設定を保存して再起動すれば設定通りの動作をする ようになる。 [7] PPインターフェースでpp auth requestを設定して接続ユーザを認証する とき、そのユーザの接続と切断を繰り返すと使用できるメモリが減少し、 最終的にはルータの動作が不安定になるバグを修正した。メモリの減少量 は、pp auth usernameで設定したユーザ名の文字数に比例し、1回の接続や 切断で、ほぼ文字数と同じバイト数を浪費する。 RTX1000はRev.7.01.15以降、RTX2000はRev.7.01.17にあるバグで、 Rev.7.00系列にはこのバグはない。 [8] TFTPにより設定ファイルを送り込む時に、console lines、console columnsおよびconsole characterの3つのコマンドが、設定ファイル内に 記述したsaveコマンドではルータの不揮発性メモリに保存できないバグを 修正した。 これら3コマンドの設定変更は動作上は反映されており、設定ファイルを 送り込んだ後に、ログインしたコンソールからsaveコマンドを実行すれば 保存することができる。ただし、これら3コマンドはコンソール毎にそれ ぞれ状態が保存されているので、設定ファイルを送り込む前からログイン していた場合には、saveコマンドによって保存されるのはそのコンソール が持つ状態となり、TFTPにより送り込まれた設定は保存できない。 [9] BGPで、LANインタフェースのリンクがダウンしたまま起動したときに、そ のインタフェースに対応する経路を通知するバグを修正した。本来は、リ ンクがダウンしているLANインタフェースの経路を通知してはいけない。 一度でもLANインタフェースのリンクがアップすると、その後は正しく動 作し、インタフェースの状態に対応する経路情報を通知するようになる。 [10] BGPで、静的経路をBGPに広告する設定をしている時に、bgp neighborコマ ンドで指定している隣接ルータのIPアドレスをゲートウェイとする静的経 路が存在すると、その経路以外の静的経路がBGPに広告されなくなるバグ を修正した。 例えば、以下のような設定の場合に、デフォルト経路以外の、 100.1.1.0/24宛や100.2.2.0/24宛の経路が広告されなくなってしまう。 ip route default gateway 10.1.1.2 ip route 100.1.1.0/24 gateway 192.168.0.3 ip route 100.2.2.0/24 gateway 192.168.0.4 ip lan1 address 192.168.0.1/24 ip lan2 address 10.1.1.1/24 bgp use on bgp autonomous-system 1001 bgp neighbor 1 1000 10.1.1.2 bgp import 1000 static filter 1 bgp export filter 1 include all bgp export 1000 filter 1 [11] OSPFとBGPを併用する設定で、OSPFのエリアを設定しているインタフェー スが切断されたときに、そのインタフェースに対応する経路が消滅するに もかかわらず、その情報をBGPで通知しないバグを修正した。 [12] OSPF、BGP、RIPで、ネットワークバックアップ以外の各種バックアップ 機能と併用するときに、バックアップが設定されたインタフェースをゲー トウェイとする経路については、インタフェースの状態に関係なく常に有 効な経路として広告するようにした。 [13] OSPFで、ospf import from staticコマンドにより静的経路を外部経路と して広告する設定で動作している時に、clear ip dynamic routingコマン ドを投入したり、あるいはすでに存在する静的経路に対してまったく同じ 内容のip routeコマンドを投入した後に、ospf configure refreshコマン ドでOSPFを再起動すると、リブートすることがあるバグを修正した。 [14] OSPFで、ip INTERFACE ospf areaコマンドでエリアに参加しているLANイ ンタフェースの経路については、リンクがアップしている時には他のOSPF ルータに広告され、リンクがダウンしている時には広告されないのが正し い動作である。しかし、起動時もしくはospf configure refreshコマンド 実行時にリンクがアップしていないLANインタフェースの経路が広告され てしまうバグを修正した。 間違って経路が広告されているインタフェースも、いったんリンクがアッ プし、その後リンクダウンとなると経路が広告されなくなる。 [15] OSPFで、インタフェースで指定したOSPFエリアがospf areaコマンドで設 定されていないなど、設定が正しくない状態で起動、あるいはospf configure refreshコマンドが実行された時には、OSPFがまったく動作し ないように変更した。 従来は不完全な設定のままOSPFを動作させようとしていたため、設定の内 容によってはルータがリブートしてしまうことがあるなどの不具合があった。 この変更により、従来は動作していた設定でもOSPFが動作しなくなること がある。その場合は、設定に何らかの間違いがあるので設定内容の見直し が必要となる。 [16] 以下の条件をすべて満たす場合に、LAN上のPCのInternet Explorerからの WWWアクセスが名前解決ができないという理由で通信できなくなってしま うことがあるバグを修正した。 - PCのOSはWindows XPもしくはWindows 2000 - NAT/IPマスカレードを利用したインターネット接続 - ルータのDNSリカーシブサーバ機能は利用せず、PCは直接インターネッ ト上のDNSサーバを利用する - 動的フィルタでDNSを扱う設定にしており、かつ、DNSを通す静的フィル タが存在しない Internet Explorerからアクセスできない場合でも、コマンドプロンプト からのnslookupは正常に動作する。また、1台のPCがアクセスできなくなっ ても、他のPCからのアクセスに問題はない。アクセスできなくなったPCも 時間が経てばアクセスできるようになる。PCやルータを再起動してもアク セスできるようになる。 [17] IPマスカレードを使っている時に、Windows Messenger 4.7およびMSN Messenger 4.6で複数のファイル送信ができないバグを修正した。 [18] NATで、ICMPのエラーパケットを処理するときに、先頭のIPヘッダを変換 する必要がなければ、ICMPのデータ部に格納されたIPヘッダも変換しない バグを修正した。実際には、先頭のIPヘッダを変換する必要がなくても、 データ部のIPヘッダを変換しなければならない場合が存在する。 このような具体的な例として、次のケースがある。 PC -------- Router(1) ------------- Router(2) ----------- Server A1 : : A2 A3 MTU=1280 A4(VA) : : NAT(1) NAT(2) A4<->V4 A1<->A2 - A1〜A4、VAはIPアドレスを表す。 - ServerのIPアドレスはA4であるが、仮想的なIPアドレスとしてVAを割り 当てておく。PCはServerにアクセスするときには、A4ではなくVAに対し てアクセスする。 - Router(1)の2つのインターフェースにNATを設定する。NAT(1)はA4とVA を互いに変換し、NAT(2)はA1とA2を互いに変換する。 ここでPCがServerに対して送信したIPパケットにDFビットがセットされて おり、長さが1280バイトを超えるとすると、Router(2)はA2に対してICMP Destination Unreachableを送信する。このICMPパケットは、先頭から順 に次のような内容になる。 - IPヘッダ - 始点アドレス: A3、終点アドレス: A2 - ICMPヘッダ - Destination Unreachable - IPヘッダ(ICMPのデータ部) - 始点アドレス: A2、終点アドレス: A4 このICMPパケットがRouter(1)に到着したとき、まずNAT(2)のルールにし たがって、次のように変換する必要がある。 - IPヘッダ - 始点アドレス: A3、終点アドレス: A1 (A2をA1に変換) - ICMPヘッダ - Destination Unreachable - IPヘッダ(ICMPのデータ部) - 始点アドレス: A1、終点アドレス: A4 (A2をA1に変換) 次に、NAT(1)のルールにしたがって、次のように変換する必要がある。 - IPヘッダ - 始点アドレス: A3、終点アドレス: A1 - ICMPヘッダ - Destination Unreachable - IPヘッダ(ICMPのデータ部) - 始点アドレス: A1、終点アドレス: VA (A4をVAに変換) このとき、変換する必要があるのはICMPのデータ部のIPヘッダだけであり、 先頭のIPヘッダは変換する必要がない。 [19] ルータ自身宛にフラグメントされたパケットを大量に受信した場合に、 そのフラグメントされたパケットのメモリ領域が正しく解放できずに利用 できるメモリが少なくなってしまうことがあるバグを修正した。 [20] PCが複数のDNS問い合わせパケットを同じ始点IPアドレス、始点ポート番 号で連続して送信すると、先頭のパケットだけがトリガとして扱われ後続 のパケットがトリガにならないため、後続のパケットに対するレスポンス パケットを動的フィルタで通せないことがあるバグを修正した。 Windows XPおよびWindows 2000がDNSクライアントである場合に顕著に現 象が発生する。この現象が発生すると、DNSレスポンスパケットがフィル タで落されたログが記録される。 [21] RT自身がDNSのクライアントとなる場合、および、DNSリカーシブサーバと して動作している場合に、上位のDNSサーバに対しての問い合わせがタイ ムアウトして失敗するような状況になっていると、ルータ全体の動作が不 安定になってしまうバグを修正した。 DNS問い合わせがタイムアウトする状況とは、以下のような原因が考えら れる。 - DNSサーバに関する設定の間違い - DNSサーバとの間の通信回線が不安定でパケットロスがある また、ルータ全体の動作が不安定になっている時には以下のような現象が 現れる。 - show ip routeコマンド、show arpコマンド、show nat descriptor addressコマンドなどを実行すると、そこでコンソールがハングアップ する。ハングアップするのはコンソールだけで、パケット転送などは 動作し続ける - DHCPクライアント動作時に、アドレスを取得することができない - (UPnP対応機器のみ) "UPnP: Can't get event number"というログが記 録される [22] VRRPで、1つのLANインタフェースに2つ以上のグループを設定している場 合、一方のグループでシャットダウントリガが成立してバックアップ状態 に移行すると、他方のグループもシャットダウンしてバックアップ状態に なってしまうことがあるバグを修正した。 [23] ルータ自身を終端とするTCP通信で、MSSのネゴシエーションが正しくで きていないバグを修正した。 [24] RT自身がTELNETやBGP-4などのためにTCPの端点となって通信を行っている 時に、何らかの理由でTCPパケットを送信するためのメモリがRT内部で確 保できなくなるとリブートしてしまうバグを修正した。システム負荷が高 い時にBGP-4で経路交換を行おうとした時などが該当する。修正後は、そ のような状況が発生しても、その時にTCPパケットを送信できないだけで、 負荷が下がればまたTCP通信を再開できるようになっている。 [25] IPv6でRIPngを使う設定をしている時に、LANインタフェースのリンクが アップすると、DADによるリンクローカルアドレスの確認が終了する前に RIPng が動き出してしまい、DADが終了するまでの間、別のインタフェー スに付与されたリンクローカルアドレスを始点IPv6アドレスとする正しく ないRIPngのパケットを送出してしまうバグを修正し、DADが終了するまで はRIPngパケットを送出しないようにした。 LAN以外のインタフェースではDAD手順はなく、インタフェースがアップし たらすぐにリンクローカルアドレスが使用できるようになるのでこの問題 は発生しない。 [26] IPsecトンネルで、プロトコルとしてAHで通信している時に、ipsec sa policyコマンドでプロトコルの設定をESPに変更するとリブートしてしま うバグを修正した。 設定をESPからAHに変更したり、あるいは、ESP/AHのレベルは変更せず、 アルゴリズムだけを変更するといった場合には問題は発生しない。また、 トランスポートモードでも問題はない。 [27] IPマスカレードの内側にFTPサーバがある時、IPマスカレードの外側の FTPクライアントから内側のFTPサーバに接続すると、PASVモードでのデー タ転送がIPマスカレードで正しく変換できず、ファイル転送などが行えな いバグを修正した。非PASVモードの場合には問題はない。 Rev.7.01.15でエンバグ。 [28] PPPoEインタフェースにIPsecトンネルのパケットを送信する時に、イン タフェースの送信データサイズとしてカウントされるべき数字が送信パケッ ト数としてカウントされてしまうバグを修正した。 SNMPでは、ifOutOctetsとしてカウントされるべき数字がifOutUcastPkts にカウントされてしまっていた。また、show status ppコマンドで表示さ れる送信データ量も同様に間違っていた。 [29] UDPでチェックサムフィールドが0であるパケットに対して、ファストパ スでNATやIPマスカレードの変換処理をする時に、間違ったチェックサム を設定してしまうバグを修正した。間違ったチェックサムが設定されたパ ケットは受信側で破棄されるので、結果として通信できなくなる。 この修正後は、UDPでチェックサムフィールドが0であるパケットをファス トパスでNATやIPマスカレードの変換処理をする場合は、チェックサムを0 のままにする。 スローパスでの処理では、この修正以前はNAT変換では0のまま、IPマスカ レード変換では正しいチェックサムを再計算して付けるという動作になっ ていたが、この修正によりIP マスカレード変換でもチェックサムを0のま まにするよう変更されている。 UDPでチェックサムフィールドが0であるパケットは、通常のPCのアプリケー ションから送信されることはもうほとんどなくなっているが、一部のネッ トワーク機器でまだ利用されていることがある。 なお、チェックサムフィールドが0ではないパケットに対しては、チェッ クサム計算を間違えるバグはない。 [30] pp auth request chap arrive-onlyと設定したときに、発信側であって もCHAPの認証を接続相手に要求するバグを修正した。 [31] RTX1000で、LAN2もしくはLAN3インタフェース経由でIPsecトンネルを張っ ており、そのトンネルを通して自分宛のパケットを受信した時、LAN1イン タフェースの受信処理が最大1秒停止するバグを修正した。停止中に受信 したパケットは受信キュー(最大50パケット)に溜められ、動作再開後に処 理されるため、パケットが遅延したかのように見える。受信キューから溢 れたパケットは捨てられる。 例えば、LAN2インタフェースでIPsecトンネルを張っており、さらにトン ネルキープアライブとしてicmp-echoを利用している時にバグが発生する。 この時、キープアライブパケットを受信した時にLAN1インタフェースの受 信処理が最大1秒停止するので、LAN1インタフェースを使った通信に影響 が出る。 [32] RTX1000のネットボランチDNSの更新処理で、サーバとの間の通信が不安定 になるなどしてタイムアウトが発生した時に、ネットボランチDNSの動作 がそれ以降できなくなってしまうことがあるバグを修正した。この状態に なると、再起動しない限りネットボランチDNSが利用できない。他の通信 に影響はない。 [33] RTX1000で、ISDNリモートセットアップで接続をしている状態でPP[01]を 接続すると、誤ったタイミングで切断タイマによりPP[01]が切断されるバ グを修正した。 [34] RTX1000で、ほぼ同時に複数の対地とPPTPの接続処理を開始すると、その うちのいくつかの対地に対してはCCPのネゴシエーションに失敗して接続 できないことがあるバグを修正した。 [35] RTX1000で、PPTPで大量のトラフィックを扱う時に、動作が不安定になる ことがあるのを修正した。 [36] RTX1000のファストパスで、IPマスカレードを利用している場合、FTPでの ファイル転送を長時間に渡り行なっていると、nat descriptor timerコマ ンドで設定した時間でファイル転送が中断されてしまうバグを修正した。 nat descriptor timerコマンドのデフォルト値は900秒である。IPsecなど のトンネル経由の通信ではこの問題は発生しない。 FTPのデータセッションのトラフィックがある時には、FTPのコントロール セッションでデータが流れていなくてもそれを切断してはいけなかった。 [37] RTX2000で、ip INTERFACE secure filter nameコマンドでフィルタセッ トを指定してもフィルタが機能せず、パケットを通過させてしまうバグを 修正した。 [38] RTX2000で、PPPoEインタフェースで送受信されるパケットが、SNMPや show status pp コマンドの表示で正しくカウントされていないバグを修 正した。 [39] RTX2000で、30000バイトを超えるような大きなサイズでルータにpingを行 なうと返事が返ってこないバグを修正した。 [40] RTX2000で、トンネルから受信したパケットの宛先インタフェースが別の トンネルだった場合に、スローパスに回ってしまうのをファストパスで処 理できるようにした。 [41] RTX2000で、ip fragment remove df-bitコマンドやnat descriptor masquerade remove df-bitコマンドなどでDFビットを削除する機能が動作 していないバグを修正した。 [42] RTX2000で、PPPoEで送信するPADIなどに含まれるService-Nameタグの長さ フィールドのバイトオーダが逆になるバグを修正した。 [43] RTX2000で、NAT/IPマスカレードを利用していると、トラフィックがある にも関わらずNATエントリのTTLが更新されず、nat timerコマンドで設定 した時間以上の通信ができないバグを修正した。 Rev.7.01.17にだけあるバグである。 [44] RTX2000で、IPsecの受信側で処理しきれない程のトラフィックを受信し ていると、そのトラフィックが収まった後でも通信できなくなることがあ るバグを修正した。 [45] RTX2000で、PPPoE接続をしている場合に、PPPoEの向こう側にいるホスト とIPv4 over IPv4トンネルで接続しようとしても通信できないバグを修正 した。 [46] RTX2000で、パケットの受信がまったくできなくなることがあるバグを修 正した。その場合でもRTX2000からのパケット送信は可能である。この現 象が発生する前には、以下のようなログが記録されることがある。ログの 括弧内には16進数が出力されるが、その値に意味はない。 LAN1.1: invalid descriptor (xxxx) この現象は、以下の条件の時にまれに発生する。 - 100Mbit/sで接続された複数のLANポートからパケットを受信する - パケットが送出されるLANポートは10Mbit/sである - パケットの受信が、送出されるLANポートの帯域を越えるペースで長時 間続く - それぞれのLANポートの全二重/半二重の状態は現象とはあまり関係がな いが、受信ポートは全二重、送出ポートは半二重の場合に発生しやすい