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

некорректная работа cisco ip dhcp snooping

Доброго времени суток, Уважаемые!

 

Недавно столкнулся с такой проблемой. Есть сеть, построенная на cisco 3400. Коммутаторы уровня доступа организованы в кольцо. Кольцо замыкается на cisco 4948 (уровень агрегации). Коммутаторы имеют имена вида 9-09-09-08, 9-09-09-09 и 9-09-09-09.2. И есть DHCP сервер раздающий адреса в vlan 190. В случае если трафик идет следующим образом: DHCP <- с4948 <- 9-09-09-08 <- 9-09-09-09 <- 9-09-09-09.2 -x- 9-09-09-10 -> с4948 -> DHCP, абоненты с коммутатора 9-09-09-09.2 адреса получить не могут! (-x- колбцо разорвано протоколом REP)

В логах DHCP пишет:

Dec 16 14:07:25 TESTdhcp dhcpd: DHCPDISCOVER from 00:06:4f:04:10:9f (Hostname Unsuitable for Printing) via 192.168.20.2

Dec 16 14:07:25 TESTdhcp dhcpd: DHCPOFFER on 192.168.40.2 to 00:06:4f:04:10:9f (Hostname Unsuitable for Printing) via 192.168.20.2

 

Если же траффик идет так: DHCP <- с4948 <- 9-09-09-08 -x- 9-09-09-09 -> 9-09-09-09.2 -> 9-09-09-10 -> с4948 -> DHCP, то абоненты с 9-09-09-09.2 настройки исправно получают. Иными словами, если запросы с коммутатора "09.2" на DHCP идут через основной ("09") коммутатор, то настройки абоненты не получают! Если запросы с коммутатора "09.2" идут через любой другой коммутатор (например через 9-09-09-10), то абоненты адрес получают. На коммутаторах настроен ip dhcp snooping.

 

Влан 190 проброшен по кольцу. Абоненты не получают адреса со всех коммутаторов которые имеют имя (.2). Причем если изменить имя на любое другое, но что бы не совпадало с основным коммутатором, то абоненты адреса получают (например <- 9-09-09-09 <- 19-09-09-09.2). Сломал голову. Может есть какие-нибудь идеи?

 

конфиг 9-09-09-09.2

ip dhcp snooping vlan 190

ip dhcp snooping information option format remote-id hostname

ip dhcp snooping

!

!

!

spanning-tree mode rapid-pvst

spanning-tree etherchannel guard misconfig

spanning-tree extend system-id

!

!

vlan internal allocation policy ascending

!

vlan 10

name MNG

!

vlan 190

name white_ip

!

!

interface FastEthernet0/10

port-type nni

switchport access vlan 190

spanning-tree portfast

 

!

interface FastEthernet0/24

port-type nni

switchport trunk allowed vlan 10,190

switchport mode trunk

ip dhcp snooping trust

!

interface Vlan10

description MNG

ip address 192.168.10.12 255.255.255.0

!

 

9-09-09-09.2#

 

на 4948 конфиг:

 

!

vlan 10

name MNG

!

vlan 190

name white_ip

!

interface FastEthernet0/1

no switchport

ip address 192.168.30.2 255.255.255.0

!

interface FastEthernet0/2

port-type nni

no switchport

no ip address

!

!

interface FastEthernet0/24

port-type nni

switchport trunk allowed vlan 10,190

switchport mode trunk

ip dhcp snooping trust

!

!

interface Vlan10

ip address 192.168.10.1 255.255.255.0

!

interface Vlan190

ip address 192.168.40.1 255.255.255.0 secondary

ip address 192.168.20.1 255.255.255.0

ip helper-address 192.168.30.1

!

 

КОнфиг DHCP

#DHCP pool for client ON SWITCH 9-09-09-09 PORT 10

class "9-09-09-09-10" {

stash-agent-options true;

match if binary-to-ascii(16, 8, "", substring(option agent.remote-id,2,10))= "392d30392d30392d3039" and binary-

 

to-ascii(10, 8, "", suffix( option agent.circuit-id, 1))="12";

}

pool {

stash-agent-options true;

option routers 192.168.40.1;

option subnet-mask 255.255.255.0;

range 192.168.40.2 192.168.40.2;

allow members of "9-09-09-09-10";

}

 

#DHCP pool for client ON SWITCH 9-09-09-09 PORT 10

class "9-09-09-09.2-10" {

stash-agent-options true;

match if binary-to-ascii(16, 8, "", substring(option agent.remote-id,2,10))= "392d30392d30392d30392e32" and

 

binary-to-ascii(14, 8, "", suffix( option agent.circuit-id, 1))="12";

}

pool {

stash-agent-options true;

option routers 192.168.40.1;

option subnet-mask 255.255.255.0;

range 192.168.40.3 192.168.40.3;

allow members of "9-09-09-09.2-10";

}

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


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

substring(option agent.remote-id,2,10)

теперь посчитайте длину имен коммутаторов, м.б. тут собака порылась? ;)

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


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

substring(option agent.remote-id,2,10)

теперь посчитайте длину имен коммутаторов, м.б. тут собака порылась? ;)

 

Извиняюсь, не поправил конфиг, при проведении экспериментов (option agent.remote-id,2,12). В случае, если длина не соответствует, то в логах dhcp пишет "no free leases". В нашем же случае (имя 9-09-09-09.2 и оption agent.remote-id,2,12) имеем DHCPDISCOVER DHCPOFFER.

 

Причем с конфигом на DHCP скорее всего все в порядке, т.к. если запросы летят с коммутатора "9-09-09-09.2" через, допустим, "9-09-09-10", настройки абоненты получают. Но только стоит топологии перестроиться (траффик "9-09-09-09.2" через "9-09-09-09"), то абоненты адрес получить не могут (в логах DHCPDISCOVER DHCPOFFER).

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


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

Влан 190 проброшен по кольцу. Абоненты не получают адреса со всех коммутаторов которые имеют имя (.2). Причем если изменить имя на любое другое, но что бы не совпадало с основным коммутатором, то абоненты адреса получают (например <- 9-09-09-09 <- 19-09-09-09.2). Сломал голову. Может есть какие-нибудь идеи?

 

По моему Вы уже сами нашли проблему. Если при смене имени всё работает то явно дело не в REP-e или снупинге. Может точки заменить на подчёркивание или чёрточку?

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


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

Влан 190 проброшен по кольцу. Абоненты не получают адреса со всех коммутаторов которые имеют имя (.2). Причем если изменить имя на любое другое, но что бы не совпадало с основным коммутатором, то абоненты адреса получают (например <- 9-09-09-09 <- 19-09-09-09.2). Сломал голову. Может есть какие-нибудь идеи?

 

По моему Вы уже сами нашли проблему. Если при смене имени всё работает то явно дело не в REP-e или снупинге. Может точки заменить на подчёркивание или чёрточку?

 

Пробовал.

На cisco:

ip dhcp snooping information option format remote-id string 9-09-09-09-2

 

на dhcp: match if binary-to-ascii(16, 8, "", substring(option agent.remote-id,2,12))= "382d30392d30392d30392d32" and binary-to-ascii(10, 8, "", suffix( option agent.circuit-id, 1))="12";

 

 

результат тот же (DHCPDISCOVER DHCPOFFER)

 

Но стоит только поменять первую цифру: ip dhcp snooping information option format remote-id string 8-09-09-09.2

адрес срезу же получает:

Dec 16 18:55:46 TESTdhcp dhcpd: DHCPACK on 192.168.40.3 to 00:06:4f:04:10:9f (Hostname Unsuitable for Printing) via 192.168.20.2

Dec 16 18:55:49 TESTdhcp dhcpd: DHCPACK to 192.168.40.3 (00:06:4f:04:10:9f) via eth1

 

Можно конечно не заморачиваться и выделить для коммутаторов (имя которых заканчивается на .2) отдельный пул имен (отличный от других), но блин, это не спортивно. хочется докопаться до истинны! :)

Изменено пользователем aDron

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


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

А когда все работает правильный адрес выдается?

Это я к тому, что agent.remote-id = "9-09-09-09.2" совпадает не только с class "9-09-09-09.2-10", но и с class "9-09-09-09-10".

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


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

Адрес выдается правильный.

 

Собрал стенд. dhcp <-> c4948 <-> 9-09-09-09 <-> 9-09-09-09.2

На коммутаторах настраивал зеркалирование портов, дабы проанализировать трафик. В результате было выявлено, что DHCPOFFER от dhcp-сервера теряются на пути к 9-09-09-09.2, а именно на аплинк-порту (который смотрит в 9-09-09-09.2) коммутатора 9-09-09-09. на коммутаторе 9-09-09-09 тоже включен ip dhcp snooping. Если же включить дебаг на коммутаторе 9-09-09-09, то можно увидеть, что DHCPOFFER считается как локальный пакет для коммутатора 9-09-09-09, поэтому отбрасывается и не пересылается дальше к коммутатору 9-09-09-09.2

Логи с коммутатора 9-09-09-09:

 

*Mar 19 03:47:57.127: DHCP_SNOOPING: received new DHCP packet from input interface (FastEthernet0/24)

*Mar 19 03:47:57.127: DHCP_SNOOPING: binary dump of option 82, length: 26 data:

0x52 0x18 0x1 0x6 0x0 0x4 0x0 0xBE 0x1 0xC 0x2 0xE 0x1 0xC 0x39 0x2D 0x30 0x39 0x2D 0x30 0x39 0x2D 0x30 0x39 0x2E 0x32

*Mar 19 03:47:57.135: DHCP_SNOOPING: binary dump of extracted circuit id, length: 8 data:

0x1 0x6 0x0 0x4 0x0 0xBE 0x1 0xC

*Mar 19 03:47:57.135: DHCP_SNOOPING: binary dump of extracted remote id, length: 16 data:

0x2 0xE 0x1 0xC 0x39 0x2D 0x30 0x39 0x2D 0x30 0x39 0x2D 0x30 0x39 0x2E 0x32

*Mar 19 03:47:57.135: DHCP_SNOOPING_SW: opt82 data indicates local packet

*Mar 19 03:47:57.135: DHCP_SNOOPING: process new DHCP packet, message type: DHCPOFFER, input interface: Fa0/24, MAC da: ffff.ffff.ffff, MAC sa: 0021.1b12.b9c3, IP da: 255.255.255.255, IP sa: 192.168.20.1, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 192.168.40.3, DHCP siaddr: 0.0.0.0, DHCP giaddr: 192.168.20.1, DHCP chaddr: 0006.4f04.109f

*Mar 19 03:47:57.135: DHCP_SNOOPING: remove relay information option.

 

Если же отключить снупинг на 9-09-09-09 или изменить remote-id на коммутаторе 9-09-09-09.2, то адрес абоненты получают.

Если изменить remote-id коммутатора 9-09-09-09.2, то в логах на 9-09-09-09.2 можно увидеть строку: DHCP_SNOOPING_SW: opt82 data indicates not a local packet

То есть 9-09-09-09 считает, что DHCPOFFER пришедший с 24 порта не локальный (не предназначен ему) и пересылет его дальше в 23 порт (на коммутатор 9-09-09-09.2)

 

Как я полагаю, cisco 9-09-09-09, получив пакет от dhcp, посимвольно пробегается по remote-id пришедшего пакета и так же посимвольно сверяет со своим remote-id. Достигнув конца remote-id пришедшего пакета, (и в случае, если remote-id совпали), cisco прекращает сверку (не смотря на то, что remote-id пришедшего пакета, осталось еще два символа ".2") и считает, что пакет предназначается ему.

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


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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас