"Vreemde" routing van verkeer na installatie 2e netwerkkaart - Netwerken

zaterdag 3 augustus 2013 01:32

Acties:

Topicstarter

Ik heb een ietwat vreemd probleem. Ik heb drie netwerkkaarten, te weten:

em1 op 10.0.0.1/8, Intel 82579V op moederbord
p6p1 op 10.255.255.0/8, Realtek 8111E
p6p2 op 172.16.0.1/12, Realtek 8111E

Dit lijkt mij nog relatief simpel (als in, ik heb wel eens met meer NICs gedraaid). Echter, nu gebeurd er iets raars. Als ik vanaf OS X een verbinding (iSCSI, ping, iperf etc.) probeer op te zetten naar 10.255.255.0 dan word deze keihard naar het MAC adres van 10.0.0.1 gestuurd. Dit is ook in de routingtable van OS X te zien:

code:

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            link#10            UCSI            0        0     en3
10                 link#5             UCS             4        0     en0
10.0.0.45          127.0.0.1          UHS             0        0     lo0
10.0.0.254         58:6d:8f:f5:ac:bc  UHLWIi          0        0     en0   1199
10.255.255.0       4c:72:b9:31:7b:4b  UHLWIi          2      193     en0   1188
10.255.255.255     ff:ff:ff:ff:ff:ff  UHLWbI          0        1     en0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH             15 21152282     lo0
169.254            link#5             UCS             0        0     en0
172.16/12          link#10            UCS             1        0     en3
172.16.5.0         127.0.0.1          UHS             1        0     lo0
172.31.255.255     ff:ff:ff:ff:ff:ff  UHLWbI          0        1     en3

Schijnbaar is er ergens nog iets op het netwerk dat om de een of andere maffe reden onthouden heeft dat 10.255.255.0 MAC adres 4c:72:b9:... is ipv het juiste MAC adres. Zelfs na een reboot van OS X komt deze meteen weer terug! Ditzelfde gebeurt op een Fedora 19 VM bovenop dezelfde OS X host, en hetzelfde gebeurd ook op mijn Android tablet (geroot)...

Als ik de stekker uit die interface haal dan verliest Android alle contact, maar OS X en de Fedora VM passen het MAC adres in de routing tabel aan naar het juiste adres, en behouden dus gewoon contact. Wat kan hier aan de hand zijn?

Op Linux kan ik geen enkele verwijzing vinden welke dit IP adres op die interface zou moeten accepteren. ifconfig en ip a s zijn het hier met elkaar eens, IP adres 10.255.255.0 zit niet op interface em1 maar op p6p1:

code:

$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
4: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 4c:72:b9:31:7b:4b brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/8 brd 10.255.255.255 scope global em1
       valid_lft forever preferred_lft forever
    inet6 2001:470:7a5a:0:4e72:b9ff:fe31:7b4b/64 scope global dynamic 
       valid_lft 549sec preferred_lft 549sec
    inet6 fe80::4e72:b9ff:fe31:7b4b/64 scope link 
       valid_lft forever preferred_lft forever
9: p6p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether d8:9d:b9:00:0d:c9 brd ff:ff:ff:ff:ff:ff
    inet 10.255.255.0/8 brd 10.255.255.255 scope global p6p1
       valid_lft forever preferred_lft forever
    inet6 2001:470:7a5a:0:da9d:b9ff:fe00:dc9/64 scope global dynamic 
       valid_lft 549sec preferred_lft 549sec
    inet6 fe80::da9d:b9ff:fe00:dc9/64 scope link 
       valid_lft forever preferred_lft forever
10: p6p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether d8:9d:b9:00:0d:c8 brd ff:ff:ff:ff:ff:ff
    inet 172.16.0.1/20 brd 172.16.15.255 scope global p6p2
       valid_lft forever preferred_lft forever
    inet6 fe80::da9d:b9ff:fe00:dc8/64 scope link 
       valid_lft forever preferred_lft forever
$ ifconfig
em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.1  netmask 255.0.0.0  broadcast 10.255.255.255
        inet6 2001:470:7a5a:0:4e72:b9ff:fe31:7b4b  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::4e72:b9ff:fe31:7b4b  prefixlen 64  scopeid 0x20<link>
        ether 4c:72:b9:31:7b:4b  txqueuelen 1000  (Ethernet)
        RX packets 2141588  bytes 2859314717 (2.6 GiB)
        RX errors 0  dropped 22  overruns 0  frame 0
        TX packets 1241404  bytes 399509726 (381.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xf7e00000-f7e20000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 10203  bytes 1132833 (1.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10203  bytes 1132833 (1.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

p6p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.255.255.0  netmask 255.0.0.0  broadcast 10.255.255.255
        inet6 fe80::da9d:b9ff:fe00:dc9  prefixlen 64  scopeid 0x20<link>
        inet6 2001:470:7a5a:0:da9d:b9ff:fe00:dc9  prefixlen 64  scopeid 0x0<global>
        ether d8:9d:b9:00:0d:c9  txqueuelen 1000  (Ethernet)
        RX packets 9341  bytes 1330075 (1.2 MiB)
        RX errors 0  dropped 34  overruns 0  frame 0
        TX packets 19788  bytes 5876319 (5.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 51  base 0x6000  

p6p2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.0.1  netmask 255.255.240.0  broadcast 172.16.15.255
        inet6 fe80::da9d:b9ff:fe00:dc8  prefixlen 64  scopeid 0x20<link>
        ether d8:9d:b9:00:0d:c8  txqueuelen 1000  (Ethernet)
        RX packets 2438307  bytes 3690885804 (3.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1219085  bytes 80490168 (76.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 52  base 0x8000

zaterdag 3 augustus 2013 01:37

Acties:

Xesxen

Xudonax schreef op zaterdag 03 augustus 2013 @ 01:32:
em1 op 10.0.0.1/8, Intel 82579V op moederbord
p6p1 op 10.255.255.0/8, Realtek 8111E
p6p2 op 172.16.0.1/12, Realtek 8111E

Hier gaat het al mis: Deze twee netwerken overlappen elkaar. Hierdoor weet de desbetreffende machine ook niet meer wat die moet doen.

Rare vogel in spe

zaterdag 3 augustus 2013 09:03

Acties:

Xudonax

Topicstarter

Dat lost het probleem logischerwijs op ja. Maar dit zou toch niet zó moeilijk moeten zijn?

Ik bedoel, em1 heeft netjes een default gateway, maar is slechts 100Mbit/s vanwege een brakke kabel. p6p1 heeft geen default gateway, maar is wél 1Gbit/s. Op basis van dit soort simpele dingen moet het toch niet moeilijk zijn om "the right thing" te doen?

Naja, het werkt zo ook, en die 100Mbit/s zal ik ook niet écht missen denk ik