LINUX.ORG.RU
Форум — Admin  

arp запрос с 0.0.0.0 при получении ip

 , ,


0

2

Наблюдаю такую проблему в Centos 6.3 (да и в Fedora 17):

    Dec 23 16:24:02 localhost dhclient[6707]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3 (xid=0x2df8462d)
    Dec 23 16:24:02 localhost dhclient[6707]: DHCPOFFER from 31.159.8.1
    Dec 23 16:24:02 localhost dhclient[6707]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x2df8462d)
    Dec 23 16:24:02 localhost dhclient[6707]: DHCPACK from 31.159.8.1 (xid=0x2df8462d)
    Dec 23 16:24:02 localhost dhclient[6707]: DHCPDECLINE on eth1 to 255.255.255.255 port 67 (xid=0x2df8462d)
    Dec 23 16:24:06 localhost dhclient[4525]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 13 (xid=0x3f9da378)
    Dec 23 16:24:06 localhost dhclient[4525]: DHCPOFFER from 31.159.8.1
    Dec 23 16:24:06 localhost dhclient[4525]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x3f9da378)
    Dec 23 16:24:06 localhost dhclient[4525]: DHCPACK from 31.159.8.1 (xid=0x3f9da378)
    Dec 23 16:24:06 localhost dhclient[4525]: DHCPDECLINE on eth1 to 255.255.255.255 port 67 (xid=0x3f9da378)
    Dec 23 16:24:06 localhost dhclient[4525]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3 (xid=0x3ebbf754)
    Dec 23 16:24:06 localhost dhclient[4525]: DHCPOFFER from 31.159.8.1
    Dec 23 16:24:06 localhost dhclient[4525]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x3ebbf754)
    Dec 23 16:24:06 localhost dhclient[4525]: DHCPACK from 31.159.8.1 (xid=0x3ebbf754)
    Dec 23 16:24:06 localhost dhclient[4525]: DHCPDECLINE on eth1 to 255.255.255.255 port 67 (xid=0x3ebbf754)

и т.д. до бесконечности

MAC = 00:1E:73:81:81:A1

Ковыряние трафика показало следующую картину: после пакета DHCPACK от сервера, где подтверждают выдачу 31.159.11.227, моя машина делает запрос ARP

    No.     Time        Source                Destination           Protocol Length Info
          5 0.203383    Zte_81:81:a1          Broadcast             ARP      42     Who has 31.159.11.227?  Tell 0.0.0.0

    Frame 5: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
    Ethernet II, Src: Zte_81:81:a1 (00:1E:73:81:81:A1), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Address Resolution Protocol (request)
        Hardware type: Ethernet (1)
        Protocol type: IP (0x0800)
        Hardware size: 6
        Protocol size: 4
        Opcode: request (1)
        [Is gratuitous: False]
        Sender MAC address: Zte_81:81:a1 (00:1E:73:81:81:A1)
        Sender IP address: 0.0.0.0 (0.0.0.0)
        Target MAC address: Broadcast (ff:ff:ff:ff:ff:ff)
        Target IP address: 31.159.11.227 (31.159.11.227)

    No.     Time        Source                Destination           Protocol Length Info
          6 0.203396    Zte_81:81:a2         Zte_81:81:a1          ARP      42     31.159.11.227 is at 00:1E:73:81:81:A2

    Frame 6: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
    Ethernet II, Src: Zte_81:81:a2 (00:1E:73:81:81:A2), Dst: Zte_81:81:a1 (00:1E:73:81:81:A1)
    Address Resolution Protocol (reply)
        Hardware type: Ethernet (1)
        Protocol type: IP (0x0800)
        Hardware size: 6
        Protocol size: 4
        Opcode: reply (2)
        [Is gratuitous: False]
        Sender MAC address: Zte_81:81:a2 (00:1E:73:81:81:A2)
        Sender IP address: 31.159.11.227 (31.159.11.227)
        Target MAC address: Zte_81:81:a1 (00:1E:73:81:81:A1)
        Target IP address: 0.0.0.0 (0.0.0.0)

После чего машина посылает DHCPDECLINE 

No.     Time        Source                Destination           Protocol Length Info
      7 0.206309    0.0.0.0               255.255.255.255       DHCP     342    DHCP Decline  - Transaction ID 0x3653e725

Frame 7: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits)
Ethernet II, Src: Zte_81:81:a1 (00:1E:73:81:81:A1), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol
    Message type: Boot Request (1)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x3653e725
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: Zte_81:81:a1 (00:1E:73:81:81:A1)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (t=53,l=1) DHCP Message Type = DHCP Decline
    Option: (t=54,l=4) DHCP Server Identifier = 31.159.8.1
    Option: (t=50,l=4) Requested IP Address = 31.159.11.227
    End Option
    Padding

Т.е. хост с 0.0.0.0 опрашивает 31.159.11.227 , который ему же и выдают, получает от себя ответ и решает, что этот ip используется?? Как это исправить?

З.Ы. в Debian\Ubuntu все работает в этой сети - ip выдается, arp-запрос от выданного айпи до сервера dhcp: 

        Sender MAC address: Zte_81:81:a1 (00:1E:73:81:81:A1)
        Sender IP address: 31.159.11.227 (31.159.11.227)
        Target MAC address: Broadcast (ff:ff:ff:ff:ff:ff)
        Target IP address: 31.159.8.1 (31.159.8.1)

А кто такой 00:1E:73:81:81:A2?

lnx ★
()
Ответ на: комментарий от lnx

Если верить пакетам, то это, как ни странно mac dhcp-сервера. Вот DHCPOFFER: 

No.     Time        Source                Destination           Protocol Length Info
      2 0.071767    31.159.8.1            255.255.255.255       DHCP     338    DHCP Offer    - Transaction ID 0x3653e725

Frame 2: 338 bytes on wire (2704 bits), 338 bytes captured (2704 bits)
Ethernet II, Src: Zte_81:81:a2 (00:1E:73:81:81:A2), Dst: Zte_81:81:a1 (00:1E:73:81:81:A1)
Internet Protocol Version 4, Src: 31.169.8.1 (31.159.8.1), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
    Message type: Boot Reply (2)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x3653e725
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 31.159.11.227 (31.159.11.227)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: Zte_81:81:a1 (00:1E:73:81:81:A1)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name: 0
    Magic cookie: DHCP
    Option: (t=53,l=1) DHCP Message Type = DHCP Offer
    Option: (t=2,l=4) Time Offset = 9 hours
    Option: (t=1,l=4) Subnet Mask = 255.255.252.0
    Option: (t=3,l=4) Router = 31.159.8.1
    Option: (t=54,l=4) DHCP Server Identifier = 31.159.8.1
    Option: (t=6,l=8) Domain Name Server
    Option: (t=51,l=4) IP Address Lease Time = 3 hours
    Option: (t=58,l=4) Renewal Time Value = 1 hour, 30 minutes
    Option: (t=59,l=4) Rebinding Time Value = 2 hours, 15 minutes
    End Option

new_sprite
() автор топика

Если я правильно понял приведённые цитаты, после получения ip от dhcp сервера осторожный centos выполняет arp запрос, с целью убедиться что адрес свободен. А криво (?) настроенный сервер говорит - это мой адрес, я его использую.

Варианты решения:

1) сделать всё красиво - почитать документацию к используемому dhcp серверу, исправить ошибку в настройке

2) на стороне centos отключить проверку на занятость адреса. Насколько я помню, в rhel/centos это вызов arping где-то в /etc/sysconfig/network-scripts/*

Посмотри grep -R arping /etc/sysconfig/network-scripts/

3) возможно, что dhcp сервер на самом деле использует это адрес, а в пул dhcp адресов его добавили по ошибке.

router ★★★★★
()
Ответ на: комментарий от router

Судя по моему ковырянию мануалов и спецификаций, ты правильно понял приведенные цитаты. Понравилось «осторожный centos» ) Дебиан/убунту тоже проверяют на незанятость адреса, но запрос идет от полученного айпи до сервера ДНСР. Ответ, соответственно, от ДНСР до хоста. Хотя это скорее всего передача МАСа хоста происходит серверу.

Проблему решил пока костылем, запретив ему страдать шизофренией, болтая с собой.

2) Вот за это спасибо - буду копать. Может что интересное нарою.

new_sprite
() автор топика
Ответ на: комментарий от new_sprite

1) никакой «передачи» нет и не должно быть.

2) клиент все правильно делает.

3) проверку делает не арпинг, и сам дхклиент.

4) согласно рфц, сервер не должен отвечать на такой ху-хез. все-таки айпи не его. что за сервер?

val-amart ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin