SNR-S2950-24G dhcp relay & snooping

[31337Ghost]

На свиче конфиг такой:

SNR-S2950-24G#sh running-config
!
no service password-encryption
!
hostname SNR-S2950-24G
sysLocation Ak.Vonsovskogo str. 1-118, Ekaterinburg, Russia
sysContact support@nag.ru
!
username admin privilege 15 password 0 admin
!
!
!
web language english
!
service dhcp
!
ip forward-protocol udp bootps
ip dhcp relay share-vlan 101 sub-vlan 1
!
ip dhcp snooping enable
ip dhcp snooping vlan 1
ip dhcp snooping binding enable
!
ip dhcp snooping information enable
ip dhcp snooping information option subscriber-id format hex
ip dhcp snooping broadcast suppress
!
!
!
!
!
!
sflow version 0
!
!
vlan 1
!
vlan 101
name management
!
Interface Ethernet1/1
!
Interface Ethernet1/2
!
Interface Ethernet1/3
!
Interface Ethernet1/4
!
Interface Ethernet1/5
!
Interface Ethernet1/6
!
Interface Ethernet1/7
!
Interface Ethernet1/8
!
Interface Ethernet1/9
!
Interface Ethernet1/10
!
Interface Ethernet1/11
!
Interface Ethernet1/12
!
Interface Ethernet1/13
!
Interface Ethernet1/14
!
Interface Ethernet1/15
!
Interface Ethernet1/16
!
Interface Ethernet1/17
!
Interface Ethernet1/18
!
Interface Ethernet1/19
!
Interface Ethernet1/20
!
Interface Ethernet1/21
!
Interface Ethernet1/22
!
Interface Ethernet1/23
!
Interface Ethernet1/24
!
Interface Ethernet1/25
!
Interface Ethernet1/26
description Uplink
switchport mode trunk
!
interface Vlan101
description management
ip address 10.35.255.13 255.255.255.0
 !forward protocol udp 67(active)!
ip helper-address 192.168.0.100
!
ip default-gateway 10.35.255.1
!
!
no login
!
!
end

 

192.168.0.100 это DHCP-сервер

Клиент подключен в первый порт и пытается получить IP-адрес 10.36.5.10, но не получает.

В логах сервера следующие:

Feb 20 18:22:32 billing dhcpd: DHCPDISCOVER from 00:26:22:a4:81:16 via 10.35.255.13
Feb 20 18:22:32 billing dhcpd: DHCPOFFER on 10.36.5.10 to 00:26:22:a4:81:16 via 10.35.255.13

Свич пишет следующее:

SNR-S2950-24G#sh ip dhcp snooping interface ethernet 1/1

interface Ethernet1/1 user config:
trust attribute: untrust
action: none
binding dot1x: disabled
binding user: disabled
recovery interval:0(s)
Driver user number 0 : Max user number 1024
Alarm info: 0

Binding info: 0
Static Binding info: 0
Static Binding info from shell: 0
Static Binding info from server: 0
flag: D - Dynamic ; U - already upload server ;
S - static binding info from shell; R - static  binding info from server;
O - dhcp ack has option82; X - notify dot1x ok;
L - notify driver ok; E - notify dot1x error
P - binding protect;

Expired Binding: 0

Request Binding: 1
--------------------------------------------------------
DHCP Snooping Binding built at SUN JAN 01 00:03:02 2006
       Time Stamp: 187
       Ref Count: 1
       VID 1, Port: Ethernet1/1
       Client MAC: 00-26-22-a4-81-16
       Client IP: 0.0.0.0 0.0.0.0
       Gateway: 0.0.0.0
       Lease: 30(s)
       Flag: 0

 

Т.е. сервер получает запрос, отправляет ответ, а свич его игнорирует. Что я не так настроил?

[tunny]

а через 10.35.255.1 dhcp-ответ проходит?

[tunny]

ip dhcp snooping trust нету

[31337Ghost]

а через 10.35.255.1 dhcp-ответ проходит?

Сниффером не проверял, но проходить должен 10.35.255.1 - это обычный L3, длинки через него замечательно работают. И tcpdump на сервере показыает фактическую отправку пакетов.

 

ip dhcp snooping trust

На 26 порту - аплинке? Почему-то мне козалось, что данная опция влияет на Opt82. Видимо это заблуждение, которое взялось не пойми откуда. Спасибо. Попробую.

[31337Ghost]

Попробовал прописать - не заработало.

У меня в качестве сервера isc-dhcp, заметил интересный момент, что пакеты, которые он отправляет в ответ - с нулевой контрольной суммой (смотрел по выводу tcpdump). Следовательно возможно, что данный свич может их отбрасывать, как "битые". Господа, у кого работает данный функционал этих комутаторов в связке с isc-dhcp, можете посмотреть есть ли косяк с нулевой контрольной суммой пакетов, отправляемых в ответ сервером?

[s.lobanov]

Попробовал прописать - не заработало.

У меня в качестве сервера isc-dhcp, заметил интересный момент, что пакеты, которые он отправляет в ответ - с нулевой контрольной суммой (смотрел по выводу tcpdump). Следовательно возможно, что данный свич может их отбрасывать, как "битые". Господа, у кого работает данный функционал этих комутаторов в связке с isc-dhcp, можете посмотреть есть ли косяк с нулевой контрольной суммой пакетов, отправляемых в ответ сервером?

 

Контрольная сумма == 0 на 3ем или 4ом уровне? Если на третьем, то это нормально, просто она считается сетевой картой и tcpdump видет 0. Если на 4ом, то да, некоторые свитчи дропают такие pdu.

[31337Ghost]

Т.е. надо отснифать этот пакет за сетевой картой сервера и поглядеть на него?

[s.lobanov]

31337Ghost

Да

[passer]

Учитывая, что на свитче строится dhcp relay - добавить команды

 

ip dhcp relay information option

ip dhcp relay information option subscriber-id format hex

 

и убедиться что 192.168.0.100 знает где искать 10.35.255.13 (ошибка весьма распространена)

 

 

[f.dorokhov]

Вопрос к автору темы. Нельзя ли написать решение этой проблемы, я так понимаю она разрешилась.

[VVSina]

up