YAMAHA業務向けルータ運用構築スレッドPart7

YAMAHA業務向けルータ ..

686:proxyarp>_<
10/04/04 22:17:07
>>685 ども。arpテーブルクリアですか？
LAN上、VPN上に過去一度も使われてないIPアドレスを
何度も選びなおして設定してみてるんだけど症状変わらんのです

試した限り、 1.1.1.1 とか 223.223.223.223 とかを指定しても
必ず RTX が「それオレオレ」って返事しちゃいますね。

こちらで調べて理解したことは proxyarp on での動作仕様として
RTXが把握してないネットワークセグメントのIPアドレスに対する
who-has ?? にも自動代返することで proxy として成り立ってるぽいので
同じセグメントのアドレスをRTXにも振るか、proxyarp off するしかないかな…と。

687:不明なデバイスさん
10/04/06 10:54:27
RT107eがとどいたのでさっそく設定してみました。
初期設定とプロバイダの設定をしてネットに接続できることと確認。
まずはNTPサーバーで自動同期するためにフィルタとやらの設定をしてみます。
自分で設定していくのってなんか育てていくような面白さがありますね。

688:a
10/04/07 12:36:04
RTX1100を使ってマルチホーミングでLAN2 ISP1(PPPoE)とLAN3 ISP2(PPPoE)に接続し、
LAN1に繋いであるサーバをNATでWWWとストリーミングを公開しようとしています。
(ISP1,ISP2それぞれに固定IPを一つずつ取得しています)

このとき、経路の設定は下記のようにしようと思いますが、

ip route default gateway pp 1 hide gateway pp2 hide

ISP1側の固定IPアドレスで接続に来たパケットをISP1へ
ISP2側の固定IPアドレスで接続に来たパケットをISP2へ
の経路で返す設定は上記のip routeの設定のみでOKなのでしょうか？

689:anonymous
10/04/07 14:54:35
hide って回線が接続されているかで、NATが有効かどうかではないのでは？

690:a
10/04/07 15:02:50
NATの設定は以下のようになっています。

pp select 1
pppoe use lan2
～省略～
ip pp nat descriptor 1

pp select 2
pppoe use lan3
～省略～
ip pp nat descriptor 2

nat descriptor type 1 masquerade
nat descriptor masquerade static 1 1 192.168.0.1 tcp www

nat descriptor type 2 masquerade
nat descriptor masquerade static 2 1 192.168.0.1 tcp www

NATの設定だけで経路設定はOKでしょうか？

691:名無しさん＠お腹いっぱい。
10/04/08 23:57:58
>>679
>>687
がんばれ(^^)

692:anonymous
10/04/09 10:01:08
RTX-1500(8.0.3.87)でトラぶっているのでお知恵を貸してください。
下記のような障害の場合、設定のどの部分をみたらいいでしょうか？
また、なんでもいいのでアドバイスあればよろしくお願いします。

【環境、設定】
・BフレッツのOCNのIP8で契約で、PPPoE接続
・LAN1：社内LAN、LAN2：DMZ、LAN3：ONU直結(unnumberd)
・IPマスカレード利用(社内LAN<->外部のみ、PP1で適用。nat descriptor type 1 masquerade)
・動的フィルターと静的フィルターを適用。侵入検知は停止
・IPマスカレード(NATテーブル)のセッションタイマー、動的フィルター(セッションテーブル)の
セッションタイマーは共にデフォルトの900秒
・利用PC台数は50台程度

【障害】
・外部のサイトにFTPやWEBブラザなどでファイルのアップ/ダウンロードしたり、
　動画サイトを視聴したりするとCPU使用率が100%近くなり、インターネットとの
　接続が不安定になる。外部サイト、クライアントPCによる依存性はない

693:anonymous
10/04/09 10:02:24
>>692 の続き

【RTX-1500のCPU過負荷の時の状況】(show techinfoで取得)
・CPU使用率は100%近辺、メモリ使用率は40%
・NATテーブルのエントリ数は700-800ぐらい
・通信のセッションテーブルのエントリ数(=動的フィルター管理対象セッション数、
　show ip connection)は400ぐらい
・過負荷時に、多数のrejectログが出力される(10行/秒)
・rejectログに出力されたコネクションは、NATテーブルにエントリはあるが、セッションテーブル
　のエントリーには存在しない。

【障害原因の推測】
・rejectログのコネクションは直前まで動的フィルターで管理されていたセッションであったが、
　何かしらの要因で動的フィルターのセッションエントリーから削除されてしまった。このため、
　ノーマルパスでパケットがCPU処理されて、負荷が上がってしまう

【疑問・気付いた点】
・IPマスカレードのNATテーブルのセッションタイマーと、動的フィルターのセッションテーブルの
　セッションタイマーは同じ期限のはずなのに、どうしてセッションテーブルのエントリだけ削除されて
　しまうのか