2つのイーサネットアダプタを動作させようとしています。最初のeth0はデフォルトで動作します。 2番目のeth1は奇妙に動作します。このポートはLAN 9512。これは私の/etc/network/interfacesファイルです：
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.0.0.195
netmask 255.255.255.0
hwaddress ether 40:D8:55:1D:D0:B1
auto eth1
iface eth1 inet static
address 10.0.0.196
netmask 255.255.255.0
hwaddress ether 40:D8:55:1D:D0:B2
2つのイーサネットアダプタにケーブルを接続してハードウェアを起動したときに発生する起動ログの関連部分は、次のとおりです。
macb f802c000.ethernet (unnamed net_device) (uninitialized): invalid hw address, using random
libphy: MACB_mii_bus: probed
macb f802c000.ethernet eth0: Cadence MACB rev 0x0001010c at 0xf802c000 irq 35 (42:8a:61:6e:a2:bb)
macb f802c000.ethernet eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=f802c000.etherne:01, irq=-1)
[...]
usbcore: registered new interface driver smsc95xx
[...]
usb 1-1: New USB device found, idVendor=0424, idProduct=9512
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 3 ports detected
usb 1-1.1: new high-speed USB device number 3 using atmel-ehci
usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.1: Product: LAN9512
usb 1-1.1: Manufacturer: SMSC
usb 1-1.1: SerialNumber: 00951370
smsc95xx v1.0.4
smsc95xx 1-1.1:1.0 eth1: register 'smsc95xx' at usb-700000.ehci-1.1, smsc95xx USB 2.0 Ethernet, 00:80:0f:95:13:70
[...]
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
smsc95xx 1-1.1:1.0 eth1: hardware isn't capable of remote wakeup
IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[...]
macb f802c000.ethernet eth0: link up (100/Full)
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Starting sshd: IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
smsc95xx 1-1.1:1.0 eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
ifconfig期待される出力を返します。
eth0 Link encap:Ethernet HWaddr 40:D8:55:1D:D0:B1
inet addr:10.0.0.195 Bcast:0.0.0.0 Mask:255.255.255.0
inet6 addr: fe80::42d8:55ff:fe1d:d0b1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1795 errors:0 dropped:2 overruns:0 frame:0
TX packets:1671 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:108141 (105.6 KiB) TX bytes:115881 (113.1 KiB)
Interrupt:35 Base address:0xc000
eth1 Link encap:Ethernet HWaddr 40:D8:55:1D:D0:B2
inet addr:10.0.0.196 Bcast:0.0.0.0 Mask:255.255.255.0
inet6 addr: fe80::42d8:55ff:fe1d:d0b2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1352 errors:0 dropped:2 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:70740 (69.0 KiB) TX bytes:762 (762.0 B)
今私の質問です。異なるホストで両方のIPをpingすると正常に動作します。ただし、ケーブルをeth0にのみ接続すると、両方のIPに対してpingを実行できます。そして、10.0.0.195にのみpingを送ることができると予想しました。ケーブルをeth1にのみ接続すると、両方のIPをpingできませんでした。さて、10.0.0.196にpingできるようにしたいです。
どうしたの？この問題をどのように解決できますか？
編集する
質問によると：
$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
答え1
同じIPサブネットを共有すると、特定のIPインターフェイスの割り当てに関係なく、コンピュータが各インターフェイスに割り当てられているすべてのIPアドレスに応答するLinux機能があります。これはあなたに効果があるかもしれませんし、そうでないかもしれません。
これ特徴デフォルトでは有効になっており、次のように設定できます。システム制御。
発信トラフィックの場合、システムは次のように動作します。 UPで設定されているすべてのインターフェイスへのリンクがあるか、そのインターフェイスを介して他のノードに到達できるかどうかに関係なく、ルートエントリはルーティングテーブルに挿入されます。同じ IP サブネットに 2 つのインターフェイスがあるため、ルーティング テーブルには 2 つの同じルートがあります。オペレーティングシステムはそのうちの1つだけを使用し、どちらが使用されるかを制御することはできません！また、どちらを使用しても、出力パケットが送信される応答パケットの受信アドレスとは何の関係もありません。これは、フェイルオーバーが期待どおりに機能しないことが多いことを意味します。
arp_filter - ブール
1 - 同じサブネットに複数のネットワークインターフェイスがあり、カーネルがARP IPからそのインターフェイスにパケットをルーティングするかどうかに応じて、各インターフェイスに対してARPに応答できます（したがってソースベースのソースを使用する必要があります）。動作するようにルーティング）。つまり、arp要求に応答するカード（通常1枚）を制御できます。
0 - （デフォルト）カーネルは他のインターフェイスのアドレスを使用してarp要求に応答できます。これは間違っているように見えるかもしれませんが、成功したコミュニケーションの可能性を高めるので、しばしば意味があります。 IP アドレスは、特定のインターフェイスではなく Linux のホスト全体が所有します。この動作は、ロードバランシングなどのより複雑な設定でのみ問題を引き起こします。
conf/{all,interface}/arp_filter の 1 つ以上が TRUE に設定されている場合は、インターフェイスの arp_filter が有効になり、それ以外の場合は無効になります。
arp_announce - 整数
インターフェイスから送信されたARP要求のIPパケットからローカルソースIPアドレスを宣伝するためのさまざまな制限レベルを定義します。
0 - (デフォルト) すべてのインターフェイスに設定されたローカルアドレスを使用します。
1 - そのインターフェイスの宛先サブネットにないローカルアドレスを使用しないでください。このモードは、このインターフェイスを介して接続できるターゲットホストが、ARP要求の送信元IPアドレスが着信インターフェイスに設定されている論理ネットワークの一部である必要がある場合に便利です。要求を生成すると、宛先IPを含むすべてのサブネットが解決され、送信元アドレスがそのサブネットから来る場合は送信元アドレスが保持されます。そのサブネットがない場合は、レベル2の規則に従ってソースアドレスを選択します。
2 - 常にターゲットに最適なローカルアドレスを使用してください。このモードでは、IPパケットの送信元アドレスを無視し、宛先ホストと通信するために好ましいローカルアドレスを選択しようとします。これらのローカルアドレスは、宛先IPアドレスを含む送信インターフェイスのすべてのサブネットでプライマリIPアドレスを検索することによって選択されます。適切なローカルアドレスが見つからない場合は、発信元のIPアドレスに関係なく、要求への応答を受け取ることを望み、発信インターフェイスまたは他のすべてのインターフェイスの最初のローカルアドレスを選択します。
conf/{all,interface}/arp_announce で最大値を使用してください。制限レベルを上げると解決された宛先から回答を受ける機会が増え、制限レベルを下げると有効な発信者情報をより多く知らせることができます。