Перейти к содержимому
Калькуляторы

SNR-S2950-24G dhcp relay & snooping не получается заставить работать

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

ip dhcp snooping trust

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

ip dhcp relay information option

ip dhcp relay information option subscriber-id format hex

 

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.