• 締切済み

L3SWの内部機構がわからない

ネットワーク関係仕事に関わっている者(まだ1年目)で、現在L3SWの導入を行っています。とある事情から、L3SWを導入した場合、代理ARPを多用することが分かりました。先日メーカーに「代理ARPを使うと、L3SWの負担がかなり重くなる」と言われました。 そもそも通常のパケットはL3SW内部のLSI(？)で処理されている、ARPやICMP(pingなど)のパケットはL3SWのCPUで処理されているというのを何かの本で読みました。 代理ARPはL3SW内部のどういう機構(LSI/CPU)で処理されているのでしょうか。 また代理ARPもLSIで処理させるようなことは不可能なのでしょうか？ そのようなL3SWの内部機構について書かれているサイト、本などありましたら教えてください。

みんなの回答

  • dorochan
  • ベストアンサー率100% (1/1)
回答No.1

Proxy-ARP は L3 が PC からの ARP リクエストに対し、代理応答をする機能です。この場合 L3 が ARP リクエスト（ARP ブロードキャストを送出して、ある IP の MAC を学習する動作）に対して返答をするので、CPU をその度に使用します。 ASIC (専用プロセッサ）は IP ヘッダの Src と Dst の IP を元に L3 Switching を行う動作のみに特化しているので。 内部構造についてはメーカーから資料を取り寄せるのは一番です。 場合によってはメーカーサイトにホワイトペーパーが載っている場合もあります。

  1. カテゴリ
  2. [技術者向] コンピューター
  3. ITシステム運用・管理
  4. ネットワーク

関連するQ&A

  • L3SWのFDB情報が更新されるタイミング

    サーバAのNIC5に仮想IPアドレス「A」が、サーバBのNIC6に仮想IPアドレス「B」が付与されている状態で、L3SWを挟んだサーバX（ポート番号「3」側）と通信を行っている状態です。 L3SW2はL3SW1が故障した場合のスペアのため、通常は使用されません。 上記の状態で、サーバAに障害が発生し、仮想IPアドレス「A」がサーバBのNIC6に付与されたとします。すると、送信元IPアドレスが仮想IPアドレス「A」となる通信において、送信元MACアドレスがサーバAのNIC5から、サーバBのNIC6へと変更になる認識です。 実際、仮想IPアドレス「A」からL3SWを挟んだサーバXと通信を行ったところ、サーバXから応答が返ってこない現象が発生しました。 サーバAからL3SW1に対してARPパケット（arpingコマンド）を送信すると、本現象が解消されたことから、L3SW1はFDBを更新していないため、サーバBのNIC6ではなく、サーバAのNIC5にパケットを転送しているのではないかと想定しています。 サーバXに通信を行った段階でL3SW1はFDBを更新すると思っておりましたが、どのタイミングで検知・更新するのかご教示お願いします。

  • ネットワークにつながらない( PLANEX GU-1000T )

    年末、ルータを構築するためデスクトップを購入し、オンボードのLANとUSBのLANアダプタ(PLANEX GU-1000T)で,いざ設定しようと思ったのですが、さっそくハマっています。 このPLANEX GU-1000TのUSB　LANアダプタでつながりません。 OSはubuntu 8.10です。どなたか、同様の製品をUbuntuで利用している方はいらっしゃいますか？？？ もし、いらっしゃいましたら、どのようにしてつなげたか、何か必要な設定があるのか、教えて下さい。お願いします。 [パケット・ログ] IP=10.1.1.101がUSB LANアダプタ、IP=10.1.1.4がpingの送信先 10.1.1.101 -> 10.1.1.4 ICMP Echo (ping) request 377.881053 PlanexCo_f7:b8:d0 -> Broadcast ARP Who has 10.1.1.1? Tell 10.1.1.101 378.028078 10.1.1.101 -> 10.1.1.4 ICMP Echo (ping) request 378.513086 10.1.1.101 -> 10.1.1.4 ICMP Echo (ping) request 378.881023 PlanexCo_f7:b8:d0 -> Broadcast ARP Who has 10.1.1.1? Tell 10.1.1.101 379.028085 10.1.1.101 -> 10.1.1.4 ICMP Echo (ping) request 379.512113 10.1.1.101 -> 10.1.1.4 ICMP Echo (ping) request 380.032103 10.1.1.101 -> 10.1.1.4 ICMP Echo (ping) request 380.516079 10.1.1.101 -> 10.1.1.4 ICMP Echo (ping) request 380.885021 PlanexCo_f7:b8:d0 -> Broadcast ARP Who has 10.1.1.1? Tell 10.1.1.101 381.033036 10.1.1.101 -> 10.1.1.4 ICMP Echo (ping) request 381.516090 10.1.1.101 -> 10.1.1.4 ICMP Echo (ping) request 381.885045 PlanexCo_f7:b8:d0 -> Broadcast ARP Who has 10.1.1.1? Tell 10.1.1.101 ※10.1.1.4の端末ではパケットログに何もでてきませんでしたでの、USB LANアダプタからは、パケットはとんでいないと思われます。 [ハードウェア情報] user@host:~$ sudo lsusb Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub user@host:~$ lsmod |grep asix asix 22656 0 usbnet 24072 1 asix mii 13440 2 asix,usbnet usbcore 148848 6 asix,usbnet,btusb,ehci_hcd,uhci_hcd ※ドライバにはasixを使っているようです。 user@host:~$ dmesg [ 8587.249747] eth1: unregister 'asix' usb-0000:00:1d.7-6, ASIX AX88178 USB 2.0 Ethernet [ 8600.476090] usb 5-6: new high speed USB device using ehci_hcd and address 8 [ 8600.622567] usb 5-6: configuration #1 chosen from 1 choice

  • L3スイッチ導入後不安定になったネットワーク

    はじめて質問をします。よろしくお願いします。 最近社内のネットワーク機器の更新を行いL3スイッチの導入を行いました。 L3導入前は、Linux機２台をルータとして使用し、３つのセグメントに分割しておりました。 L3導入後は、３つのセグメントはそのままの状態で、ルーティングをL3で行わせるよう業者さんにお願いして設定してもらいました。 しかし、どうも１つのセグメントの調子が悪く業者に設定の再確認をお願いしましたが問題を特定できていません。 以下に、構成、traceroute, ping の情報を示します。 ■構成 ・ネットマスクは、全てのデグメントで255.255.255.0です。 　　　　　　　　192.168.0　　　　　　　192.168.1 -----|firewall|-----------|　　L3　　|------------ 　　[http proxy在り]　　　|　　　　　|------------ 　　　　　　　　　　　　　　　　　　　　192.168.2 ■調子が悪いくなったこととは １．192.168.1.xxからのWEBアクセス等でタイムアウトが頻繁に発生する。 ２．192.168.1.xx→192.168.0.xxへのルータ越のsshでは問題ないが、192.168.0.xx→192.168.1.xxへでは、ログインができなくなった。 ログインできたとしても、プロンプトが返ってくるまでに異常に時間がかかる。 ■Ping, Tracerouteの情報 192.168.0.1より $ traceroute -I 192.168.1.20 traceroute to 192.168.1.20 (192.168.1.20), 64 hops max, 60 byte packets 1 192.168.0.253 (192.168.0.253) 0.896 ms 0.870 ms 0.980 ms 2 192.168.0.253 (192.168.0.253) 0.853 ms 0.885 ms 0.984 ms 3 192.168.1.20 (192.168.1.20) 3.608 ms 0.282 ms 0.235 ms $ ping 192.168.1.20 PING 192.168.1.20 (192.168.1.20): 56 data bytes 64 bytes from 192.168.1.20: icmp_seq=0 ttl=253 time=21.453 ms 64 bytes from 192.168.1.20: icmp_seq=1 ttl=253 time=22.318 ms 64 bytes from 192.168.1.20: icmp_seq=2 ttl=254 time=0.362 ms 64 bytes from 192.168.1.20: icmp_seq=3 ttl=253 time=210.030 ms 64 bytes from 192.168.1.20: icmp_seq=4 ttl=254 time=2.928 ms 64 bytes from 192.168.1.20: icmp_seq=5 ttl=253 time=20.819 ms 64 bytes from 192.168.1.20: icmp_seq=6 ttl=254 time=0.362 ms 64 bytes from 192.168.1.20: icmp_seq=7 ttl=253 time=21.383 ms 64 bytes from 192.168.1.20: icmp_seq=8 ttl=254 time=0.307 ms 64 bytes from 192.168.1.20: icmp_seq=9 ttl=253 time=89.789 ms 64 bytes from 192.168.1.20: icmp_seq=10 ttl=254 time=0.369 ms 業者さんへは ●tracerouteの結果でL3スイッチ(192.168.0.253)が２回出現している。 ●pingの結果でTTLの値が254、253の２通りが交互に出現する。 ●pingのTTL同様time値にバラツキがある これらを指摘してみましたが、「回答は特に問題ない」とのことでした。 自分では、これらの結果がトラブル解決のヒントになるのではないかと思っております。 長々な駄文ではありますが、識者の方のアドバイスをお願い致します。 【構成図】が上手に表現出来ずごめんなさん。 よろしくお願いします。

  • ルータおよびレイヤ3SWの機能について教えてください。ふと疑問に思って

    ルータおよびレイヤ3SWの機能について教えてください。ふと疑問に思っています。 　ルータおよびレイヤ3SWは、OSIモデルではネットワーク層(レイヤ3）で動作しているのに、ルータ、レイヤ3SWのログを見ると認証やPPPOEなどのセッション（論理レベル）に関するものも確認できます。例えばAーB－C－Dというwan回線で接続されている4つのルータがあり、AからDへのIPパケットは、B、Cがルーティングして最終目的地であるDへ転送されます。Dは配下のLAN内へARPブロードキャストで届け先IPアドレスのMACアドレスを取得してフレームを転送します。フレームを受け取ったPCは、ポート番号からアプリケーションを判断し処理します。 　何を言いたいのかと言うと、ルータ、レイヤ3SWはIPパケットを処理するだけなのに、なぜ、ログを確認すると、認証やPPPOEなどのセッション（論理レベル）に関するものも確認できるのか？と、疑問に思ったからです。レイヤ4SWならば、ルータ、レイヤ3SWよりもさらに、トランスポート層からアプリケーション層までの中身を見て転送しているので、レイヤ4SWが認証やPPPOE、TCPなどのセッション（論理レベル）をログで確認できるのは理解できるからです。 　 　長文となってしまいましたが、よろしくご回答の程、お願い申し上げます。

  • FORWARDチェインについて

    FORWARDチェインとICMPについて悩んでおります。 10.10.10.0/24 　| ======================= IPTABLES linux ルータ（CentOS6.3) ======================= 　|　　　　　　　　　　　　　| 192.168.1.0/24　　　　172.16.1.0/24 FORWARDは、パケットに処理を加える（NAPT）等を行う時に必要ということが分かったのですが 「iptables -P FORWARD DROP」 のみ設定しております。 この時、192.168.1.1から10.10.10.1へのpingが通るのは、 「icmpのルーティング処理だけが必要だから、FORWARDのDROPチェインは有効にならない。」 という認識で間違いないでしょうか。 ご教授お願いします。

  • このようなウィルスが・・・

    現在管理しているネットワークがウィルスだと思われるものに犯されているのですが、ウィルスチェックにもかからないし、発生源も突き止められないため、現在困っていう状態です。 以下の状況です。 1.WANネットワーク上からブロードキャストでパケットが送られてくる。 →これが何らかの方法で内部に侵入したようです。 2.感染したパソコンから、近くのスイッチングハブに向けて偽のarpを送りつけ、テーブルをオーバーフローさせる（IP-MACの関係を破壊） そのため、フローした後にハブが聞きにいくのですが、このときに嘘の情報を流し、WANからのルートを確定させます。 3.これを何度か繰り返し、感染を進めていきます。 4.その後、ICMP（ping）パケットをPCに送りつけるのですが、このパケットも改変されています。 パケットの状態なのですが、まず返信先のアドレスが変更されていること、返信をUDPでやるように変更されていること。などが主な特徴です。 つまりICMPを送り、送り先のPCから帰ってきた情報を送り元ではなく別にUDPで送信しようとします。 5.またメールを大量に送ろうとしています。 ちなみにFTPサーバーなどは、構築していないようです。 現在以上のような状態になっていて、ネットワークを完全に封鎖している状態です。 ウイルスをインターネット上で検索しているのですが、該当するものが見当たりません。 以上と似たようなハックをするツールは見つけたのですが、ウイルスは見つかっていないので、現在は頭を抱えている状態です。 切羽詰っている状態です、誰か助けてください。 よろしくお願いしいます。

  • ppp接続後のソフトウェア処理についての質問

    エアエッジモデムでISPに接続してインターネットに接続するための装置を製作中ですがPPP接続をLCP、PAP,IPCP、処理してIPアドレスを割り当ててもらい、そのIPアドレスを使用してTCP/IP通信したいのですが 現在のところ、IPCP処理後にIGMP手続しています、それにより外部からのPING（ICMP）クエリを受信できます。ただしPINGそのものはタイムオーバーになりますが、問題は装置側からDNSサーバーに対してPING（ICMPクエリ）を送信した場合でこれは全く応答がありません、IPCP処理後になにかしないといけない手順があるのでしょうか？現在は外部からとりあえず受信はできるものの、送信ができていないようです、ただしIGMPパケットのみは認識しているようです、PINGの他にテストできるような方法というようなものはないでしょうか？装置というのはH8マイコンですのでwindowsやlinuxのようなOSは無いのでどうしたらいいのか苦労しています、なにかよい方法はないものでしょうか？

  • 異なるセグメントでのパケットの到達経路について

    現在、社内でCTIのシステムを運用しているため、IP電話機をPCからコントロール （オフフックやオンフック）していますが、コントロールできなくなることがあり、原因を調べています。 ネットワーク構成はこんな感じです。 L3SW　－－　L2SW　（PoE）　－－　IP電話機　－－　PC IP電話機は、172.16.xx.xx体系で、PCは192.168.xx.xx体系です。 L2SWは単純なPoESWのためVLAN設定はされていません。 L3SWでL2SWが接続されるポートについては、VLANで172体系と192体系が接続できるように設定してあります。 このような状態で、たとえばPCからオフフックの操作をし、電話機に対してオフフックの信号を 送出した場合に、実際のパケットはPC→電話機で到達するのか、IPアドレスのセグメントが 異なるので、上位のL2またはL3SWまで行ってから戻ってくるのか、どちらなのでしょうか？ 当然のことながらPC→電話機はpingはOKで、PCから電話機のIPアドレスにtracertすると 電話機のIPだけが表示されますので、L3SWは経由していないと考えています。 このパケットがTCPのパケットであっても、UDPのパケットであっても、直接　PC→電話機に 到達するものと思うのですが、違いますでしょうか？ どうぞよろしくお願いします。

  • インターフェイスが２つあるワークステーションとL3スイッチの絡みで・・・

    とあるネットワーク構成図を見て、疑問に思った点を質問させていただきます。 ［WS－A］------［L3スイッチ］---［L2スイッチA］---［WS-B］ 　　　　　　　　　　　　|　　　　　　　　　　　　　　　　　　　　　　　　| 　　　　　　　　　　　　|---------［L2スイッチB］----------| 【コンフィグ内容】 WS-A IPアドレス　【192.168.1.100】 L3にはVLANインターフェイスが設定してあり、 ※VLAN1インターフェイス　IP：192.168.1.1　対向先：ワークステーションのポートA　192.168.1.2 ※VLAN2インターフェイス　IP：192.168.2.1　対向先：ワークステーションのポートB　192.168.2.2 ※WS-BのデフォルトゲートウェイはL3スイッチのVLAN1インターフェイスIP：192.168.1.1となっています。 この時、WS-AからpingやTelnetをした場合、要求パケット経路は WS-A⇒L3スイッチ⇒L2スイッチA⇒WS-BのポートA　となっていて、 応答パケットは WS-B⇒L2スイッチA⇒L3スイッチ⇒WS-A　となっています。 【質問】 ここで、L2スイッチAを落します。 そしてWS-AからWS-BのポートB向けにpingを打った時、要求は大丈夫ですが、応答が出来るか疑問です。 WS-Bから見たデフォルトゲートウェイはVLAN1インターフェイス　IP：192.168.1.1　なので、WS-Aから打ったpingは通信不能になりませんでしょうか？ デフォルトゲートウェイは直結じゃないと駄目なような気もするので駄目かとは思うのですが、ひょっとしたらWS-BのポートB 192.168.2.2から送信され、L3スイッチ192.168.2.1に届き、L3スイッチで内部ルーティングされ、192.168.1.1になり、WS-Aに返される。 そんな動きしませんでしょうか？

  • NagiosのAlertメッセージについて

    ネットワーク機器の死活監視にNagios2.6を使用しています。 Alertに下記のようなログが上がってきました。 (1) OK [2010-11-29 14:09:49] HOST ALERT: L2SW-04;UP;HARD;1;PING OK - Packet loss = 0%, RTA = 5.01 ms (2) ! [2010-11-29 14:06:39] SERVICE ALERT: L2SW-04;PING;CRITICAL;HARD;1;(Return code of 139 is out of bounds) (3) ! [2010-11-29 14:03:53] HOST ALERT: L2SW-04;DOWN;HARD;10;Segmentation fault 該当時刻のL2SW-04(Catalyst2950)のログを見ましたが特にエラーは 記録されていなく、機器としては異常は見られません。 (2)の「Return code of 139 is out of bounds」や(3)の「Segmentation fault」は 今までの監視では表示されたことのないメッセージです。 このメッセージの内容をご存じの方がいましたら、ご教授願います。

注目のQ&A

カテゴリ

専門家に質問してみよう

職業から探して質問する

あなたにピッタリな商品が見つかる！ OKWAVEセレクト

質問する