orm@doc-tcpip.org

Erstellt: November 2000 - Letzte Modifikation: Mai 2001

[ Main | Local ]

Zwei Interfaces im selben Subnetz

Zwei Interfaces im selben, logischen Sub-Netz sind generell keine gute Idee. Viele Leute erwarten Dinge, die dann nicht passieren.
Das Hauptproblem ist, das es auf ein Netz oder zu einem Ziel nur eine Route geben kann. Das hat technische Gründe (die Methode, wie der Rechner Routen speichert und sucht). Das führt dazu, das über beide Interfaces Pakete hereinkommen können - aber nur über ein Interface herausgehen. Und das Interface ist das, was zuerst angelegt wurde; es trägt die Route zum Netz.

Das sieht so aus:
Zwei Interfaces (en0 und en1) im selben Subnetz (man vergleiche Adresse und Netzmaske... ff ist übrigens 255 ...): 

lo0: flags=e08084f< UP,BROADCAST,DEBUG,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT>
inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
inet6 ::1/0
en0: flags=e080867< UP,BROADCAST,DEBUG,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT>
inet 192.168.140.1 netmask 0xffffff00 broadcast 192.168.140.255
en1: flags=e080866< BROADCAST,DEBUG,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT>
inet 192.168.140.2 netmask 0xffffff00 broadcast 192.168.140.255
Das ist der netstat -in Output.
Man sieht die beiden Links, also den Adapter mit seiner MAC-Adresse und dem zugehörigen Paket-Zähler. 

Name  Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
lo0   16896 link#1                           96394     0    96401     0     0
lo0   16896 127         127.0.0.1            96394     0    96401     0     0
lo0   16896 ::1                              96394     0    96401     0     0
en0   1500  link#2      8.0.5a.93.a.a2          11     0       35     0     0
en0   1500  192.168.140 192.168.140.1           11     0       35     0     0
en1   1500  link#3      8.0.5a.92.e6.ec         28     0        7     0     0
en1   1500  192.168.140 192.168.140.2           28     0        7     0     0
In der Routing Table findet sich aber nur ein Eintrag für en0 - das zuerst angelegte Interface. Das hat die Route für sich monopolisiert. Das man im netstat -ni trotzdem einige Pakete über den en1 rausgehen sieht (Opkts=7) liegt einfach daran, das ja nicht alle Pakete IP Pakete sind! Diese Pakete werden wahrscheinlich ARP-Pakete sein. 

Routing tables
Destination      Gateway           Flags   Refs     Use  If   PMTU  Exp  Groups

Route Tree for Protocol Family 2 (Internet):
default          9.39.0.191        UGc       0        0  tr0     -   -
9.39/20          9.39.3.19         U        46   161890  tr0     -   -
127/8            127.0.0.1         U         1     1958  lo0     -   -
192.168.140/24   192.168.140.1     U        20    28113  en0     -   -

Route Tree for Protocol Family 24 (Internet v6):
::1              ::1               UH        0        0  lo0 16896   -
Wie sieht jetzt die arp-Table aus?
Wir hatten an anderer Stelle gesagt, das es nie einen Eintrag für das eigene Interface gibt - IP schickt die Pakete über den Loopback und nicht über das Netz. Es ist also auch fruchtlos, mittels arp die eigene MAC zu suchen.
Auf diesem Rechner sieht das nun ganz anders aus: 

? (192.168.140.1) at 8:0:5a:93:a:a2 [ethernet]
? (192.168.140.2) at 8:0:5a:92:e6:ec [ethernet]
Was ist passiert? Die Adapter kennen sich gegenseitig nicht, arpen also einer nach dem anderen und tragen das Ergebnis in die arp-Table ein. Das sind also nicht die eigenen Interfaces, sondern Resultat der der Anfrage von .1 nach .2 und umgekehrt.
Hier der Ping im Trace:
Dabei sollte man daran denken, dass auf der IP-Ebene getraced wird. Und beide Interfaces stecken im selben Rechner - man sieht also alle Pakete rausgehen und dann nochmal reinkommen. Das ist am Anfang etwas verwirrend...
Es wird auf 192.168.140.2 gepingt -also auf das Interface, was keine Route ins Netz hat. IP auf dem Rechner hat keine Möglichkeit, zu wissen, das dieses Interface (.2) in der eigenen Maschine ist. In der arp-Table ist kein Eintrag, also wird zuerst gearpt: 

Packet Number 1
ETH: ====( 60 bytes transmitted on interface en0 )==== 10:51:44.305253734
ETH: 00000000     ffffffff ffff0800 5a930aa2 08060001     |........Z.......|
ETH: 00000010     08000604 00010800 5a930aa2 c0a88c01     |........Z.......|
ETH: 00000020     00000000 0000c0a8 8c020000 00000000     |................|
ETH: 00000030     00000000 00000000 00000000              |............    |
ETH:    [ 08:00:5a:93:0a:a2 -> ff:ff:ff:ff:ff:ff ]  type 806  (ARP)
ARP: hardware address format = 1 (ethernet)
ARP: protocol address format = 800 (IP)
ARP: address lengths ; hardware = 6, protocol = 4
ARP: arp operation = 1 (request)
ARP: source addresses: hw [08:00:5a:93:0a:a2]
ARP:             protocol [192.168.140.1]
ARP: target addresses: hw [00:00:00:00:00:00]
ARP:             protocol [192.168.140.2]
192.168.140.1 fragt hier nach der MAC Adresse, die zu 192.168.140.2 gehört. Das ganze ist ein Broadcast, wird also von allen gesehen. Das Paket geht über en0 heraus - über dieses Interface zeigt die Route ins Netz, deshalb hat das Ping-Programm dieses Interface angesprochen. 

Packet Number 2
ETH: ====( 60 bytes received on interface en1 )==== 10:51:44.305305463
ETH: 00000000     ffffffff ffff0800 5a930aa2 08060001     |........Z.......|
ETH: 00000010     08000604 00010800 5a930aa2 c0a88c01     |........Z.......|
ETH: 00000020     00000000 0000c0a8 8c020000 00000000     |................|
ETH: 00000030     00000000 00000000 00000000              |............    |
ETH:    [ 08:00:5a:93:0a:a2 -> ff:ff:ff:ff:ff:ff ]  type 806  (ARP)
ARP: hardware address format = 1 (ethernet)
ARP: protocol address format = 800 (IP)
ARP: address lengths ; hardware = 6, protocol = 4
ARP: arp operation = 1 (request)
ARP: source addresses: hw [08:00:5a:93:0a:a2]
ARP:             protocol [192.168.140.1]
ARP: target addresses: hw [00:00:00:00:00:00]
ARP:             protocol [192.168.140.2]
Der Adapter en1 hat das Paket aufgenommen und an ARP weitergeleitet. 

Packet Number 3
ETH: ====( 60 bytes transmitted on interface en1 )==== 10:51:44.305314486
ETH: 00000000     08005a93 0aa20800 5a92e6ec 08060001     |..Z.....Z.......|
ETH: 00000010     08000604 00020800 5a92e6ec c0a88c02     |........Z.......|
ETH: 00000020     08005a93 0aa2c0a8 8c010000 00000000     |..Z.............|
ETH: 00000030     00000000 00000000 00000000              |............    |
ETH:    [ 08:00:5a:92:e6:ec -> 08:00:5a:93:0a:a2 ]  type 806  (ARP)
ARP: hardware address format = 1 (ethernet)
ARP: protocol address format = 800 (IP)
ARP: address lengths ; hardware = 6, protocol = 4
ARP: arp operation = 2 (reply)
ARP: source addresses: hw [08:00:5a:92:e6:ec]
ARP:             protocol [192.168.140.2]
ARP: target addresses: hw [08:00:5a:93:0a:a2]
ARP:             protocol [192.168.140.1]
Das ist eines der Pakete, die über das Interface en1 gehen, obwohl die Route über en0 geht - es ist das ARP Protokoll, hat also mit IP nichts zu tun. Das arp-Reply ist ein Unicast. 

Packet Number 4
ETH: ====( 60 bytes received on interface en0 )==== 10:51:44.305322506
ETH: 00000000     08005a93 0aa20800 5a92e6ec 08060001     |..Z.....Z.......|
ETH: 00000010     08000604 00020800 5a92e6ec c0a88c02     |........Z.......|
ETH: 00000020     08005a93 0aa2c0a8 8c010000 00000000     |..Z.............|
ETH: 00000030     00000000 00000000 00000000              |............    |
ETH:    [ 08:00:5a:92:e6:ec -> 08:00:5a:93:0a:a2 ]  type 806  (ARP)
ARP: hardware address format = 1 (ethernet)
ARP: protocol address format = 800 (IP)
ARP: address lengths ; hardware = 6, protocol = 4
ARP: arp operation = 2 (reply)
ARP: source addresses: hw [08:00:5a:92:e6:ec]
ARP:             protocol [192.168.140.2]
ARP: target addresses: hw [08:00:5a:93:0a:a2]
ARP:             protocol [192.168.140.1]
Hier kommt die Antwort auf dem Interface en0 an. 

Packet Number 5
ETH: ====( 98 bytes transmitted on interface en0 )==== 10:51:44.305329824
ETH: 00000000     08005a92 e6ec0800 5a930aa2 08004500     |..Z.....Z.....E.|
ETH: 00000010     005469d0 0000ff01 b883c0a8 8c01c0a8     |.Ti.............|
ETH: 00000020     8c020800 be935ecc 000039f9 42200004     |......^...9.B ..|
ETH: 00000030     737f0809 0a0b0c0d 0e0f1011 12131415     |s...............|
ETH: 00000040     16171819 1a1b1c1d 1e1f2021 22232425     |.......... !"#$%|
ETH: 00000050     26272829 2a2b2c2d 2e2f3031 32333435     |&'()*+,-./012345|
ETH: 00000060     3637                                    |67              |
ETH:    [ 08:00:5a:93:0a:a2 -> 08:00:5a:92:e6:ec ]  type 800  (IP)
IP:     < SRC =   192.168.140.1 >
IP:     < DST =   192.168.140.2 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=27088, ip_off=0
IP:     ip_ttl=255, ip_sum=b883, ip_p = 1 (ICMP)
ICMP:   icmp_type=8 (ECHO_REQUEST)  icmp_id=24268  icmp_seq=0
Und das Ping-Paket geht raus, da ja jetzt die MAC-Adresse bekannt ist. 

Packet Number 6
ETH: ====( 98 bytes received on interface en1 )==== 10:51:44.305337644
ETH: 00000000     08005a92 e6ec0800 5a930aa2 08004500     |..Z.....Z.....E.|
ETH: 00000010     005469d0 0000ff01 b883c0a8 8c01c0a8     |.Ti.............|
ETH: 00000020     8c020800 be935ecc 000039f9 42200004     |......^...9.B ..|
ETH: 00000030     737f0809 0a0b0c0d 0e0f1011 12131415     |s...............|
ETH: 00000040     16171819 1a1b1c1d 1e1f2021 22232425     |.......... !"#$%|
ETH: 00000050     26272829 2a2b2c2d 2e2f3031 32333435     |&'()*+,-./012345|
ETH: 00000060     3637                                    |67              |
ETH:    [ 08:00:5a:93:0a:a2 -> 08:00:5a:92:e6:ec ]  type 800  (IP)
IP:     < SRC =   192.168.140.1 >
IP:     < DST =   192.168.140.2 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=27088, ip_off=0
IP:     ip_ttl=255, ip_sum=b883, ip_p = 1 (ICMP)
ICMP:   icmp_type=8 (ECHO_REQUEST)  icmp_id=24268  icmp_seq=0
Hier geht das Paket auf dem "anderen" Adapter rein: wie erwartet, über en0 alles raus, und über en1 nur eingehender Verkehr. 

Packet Number 7
====( 84 bytes transmitted on interface lo0 )==== 10:51:44.305344761
00000000     45000054 69d10000 ff01b882 c0a88c02     |E..Ti...........|
00000010     c0a88c01 0000c693 5ecc0000 39f94220     |........^...9.B |
00000020     0004737f 08090a0b 0c0d0e0f 10111213     |..s.............|
00000030     14151617 18191a1b 1c1d1e1f 20212223     |............ !"#|
00000040     24252627 28292a2b 2c2d2e2f 30313233     |$%&'()*+,-./0123|
00000050     34353637                                |4567            |
OTHER packet   (IP)
IP:     < SRC =   192.168.140.2 >
IP:     < DST =   192.168.140.1 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=27089, ip_off=0
IP:     ip_ttl=255, ip_sum=b882, ip_p = 1 (ICMP)
ICMP:   icmp_type=0 (ECHO_REPLY)  icmp_id=24268  icmp_seq=0
Hier wollte das System jetzt ein Paket an 192.168.140.1 schicken. Ein Blick in die Routing Tabelle hat den Kernel belehrt, das es sein eigenes Interface ist - deshalb schickt er das Paket direkt über den Loopback. 

Packet Number 8
ETH: ====( 98 bytes transmitted on interface en0 )==== 10:51:45.308085814
ETH: 00000000     08005a92 e6ec0800 5a930aa2 08004500     |..Z.....Z.....E.|
ETH: 00000010     005469d2 0000ff01 b881c0a8 8c01c0a8     |.Ti.............|
ETH: 00000020     8c020800 80e55ecc 000139f9 42210004     |......^...9.B!..|
ETH: 00000030     b12b0809 0a0b0c0d 0e0f1011 12131415     |.+..............|
ETH: 00000040     16171819 1a1b1c1d 1e1f2021 22232425     |.......... !"#$%|
ETH: 00000050     26272829 2a2b2c2d 2e2f3031 32333435     |&'()*+,-./012345|
ETH: 00000060     3637                                    |67              |
ETH:    [ 08:00:5a:93:0a:a2 -> 08:00:5a:92:e6:ec ]  type 800  (IP)
IP:     < SRC =   192.168.140.1 >
IP:     < DST =   192.168.140.2 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=27090, ip_off=0
IP:     ip_ttl=255, ip_sum=b881, ip_p = 1 (ICMP)
ICMP:   icmp_type=8 (ECHO_REQUEST)  icmp_id=24268  icmp_seq=1
Und damit mir alle glauben, noch ein Ping-Paket: icmp_seq=1. 

Packet Number 9
ETH: ====( 98 bytes received on interface en1 )==== 10:51:45.309063258
ETH: 00000000     08005a92 e6ec0800 5a930aa2 08004500     |..Z.....Z.....E.|
ETH: 00000010     005469d2 0000ff01 b881c0a8 8c01c0a8     |.Ti.............|
ETH: 00000020     8c020800 80e55ecc 000139f9 42210004     |......^...9.B!..|
ETH: 00000030     b12b0809 0a0b0c0d 0e0f1011 12131415     |.+..............|
ETH: 00000040     16171819 1a1b1c1d 1e1f2021 22232425     |.......... !"#$%|
ETH: 00000050     26272829 2a2b2c2d 2e2f3031 32333435     |&'()*+,-./012345|
ETH: 00000060     3637                                    |67              |
ETH:    [ 08:00:5a:93:0a:a2 -> 08:00:5a:92:e6:ec ]  type 800  (IP)
IP:     < SRC =   192.168.140.1 >
IP:     < DST =   192.168.140.2 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=27090, ip_off=0
IP:     ip_ttl=255, ip_sum=b881, ip_p = 1 (ICMP)
ICMP:   icmp_type=8 (ECHO_REQUEST)  icmp_id=24268  icmp_seq=1

Packet Number 10
====( 84 bytes transmitted on interface lo0 )==== 10:51:45.309076791
00000000     45000054 69d30000 ff01b880 c0a88c02     |E..Ti...........|
00000010     c0a88c01 000088e5 5ecc0001 39f94221     |........^...9.B!|
00000020     0004b12b 08090a0b 0c0d0e0f 10111213     |...+............|
00000030     14151617 18191a1b 1c1d1e1f 20212223     |............ !"#|
00000040     24252627 28292a2b 2c2d2e2f 30313233     |$%&'()*+,-./0123|
00000050     34353637                                |4567            |
OTHER packet   (IP)
IP:     < SRC =   192.168.140.2 >
IP:     < DST =   192.168.140.1 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=27091, ip_off=0
IP:     ip_ttl=255, ip_sum=b880, ip_p = 1 (ICMP)
ICMP:   icmp_type=0 (ECHO_REPLY)  icmp_id=24268  icmp_seq=1

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]

Copyright 2001-2021 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )