[infery]

Добрый день. Наблюдаем следующую проблему: выдаем абонентам IP по Opt82, наблюдаем периодические (раз в ~30 мин.) разрывы, установили ноут в ящик с оборудованием, подключили ammy admin. При это на циске с unnumbered и helper-adress наблюдаем в дебаге вот что:

 

Oct 30 09:56:23.098: RT: del 12.12.12.3/32 via 0.0.0.0, connected metric [0/0]
Oct 30 09:56:23.098: RT: delete subnet route to 12.12.12.3/32
c1#
Oct 30 09:56:29.012: RT: SET_LAST_RDB for 12.12.12.3/32
 NEW rdb: is directly connected

Oct 30 09:56:29.012: RT: add 12.12.12.3/32 via 0.0.0.0, connected metric [0/0]

 

Т.е. по наблюдениям маршрут к абоненту пересоздается, TCP рвется.

(!)НО, если выдавать абоненту адрес не через opt82, а обычной записью host с fixed-address, то связь не рвется.

Вот пример из dhcpd.conf, при котором связь не рвется:

 

host nout {
hardware ethernet 00:23:81:16:e4:ff;
fixed-address 12.12.12.3;
}

 

А вот запись, с которой соединение рвется:

class "match_p_24_sw_17216058" {
  match if (
    binary-to-ascii(10,16,"",substring(option agent.circuit-id,4,2)) = "24"
    and
    substring(option agent.remote-id,2,15) = "172.16.0.58"
  );
}
pool {
  range 12.12.12.3;
  allow members of "match_p_24_sw_17216058";
}

 

Настройка влана на циске:

interface Vlan158
ip unnumbered Loopback10
ip helper-address 12.12.12.254
no ip redirects
no ip unreachables
ip local-proxy-arp
ip route-cache same-interface
end

 

sh ver

 

 

c1#sh ver
Cisco IOS Software, C3750 Software (C3750-IPBASEK9-M), Version 12.2(50)SE5, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Tue 28-Sep-10 12:56 by prod_rel_team
Image text-base: 0x01000000, data-base: 0x02900000

ROM: Bootstrap program is C3750 boot loader
BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.2(44)SE5, RELEASE SOFTWARE (fc1)

kbbx-c1 uptime is 2 weeks, 5 days, 16 hours, 10 minutes
System returned to ROM by power-on
System restarted at 22:52:19 utc Thu Oct 10 2013
System image file is "flash:c3750-ipbasek9-mz.122-50.SE5/c3750-ipbasek9-mz.122-50.SE5.bin"


This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

cisco WS-C3750G-12S (PowerPC405) processor (revision X0) with 131072K bytes of memory.
Processor board ID FDO1523Y0YC
Last reset from power-on
806 Virtual Ethernet interfaces
12 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.

512K bytes of flash-simulated non-volatile configuration memory.
------
тут информация по железу
------

Switch Ports Model              SW Version            SW Image                 
------ ----- -----              ----------            ----------               
*    1 12    WS-C3750G-12S      12.2(50)SE5           C3750-IPBASEK9-M         


Configuration register is 0xF

 

 

 

Настройки dhcp

authoritative;
ddns-update-style none;
ddns-update-style none;
shared-network local {
subnet 12.12.12.0 netmask 255.255.255.0 {
	option domain-name-servers 12.12.12.254;
	option subnet-mask 255.255.255.0;
	option routers 12.12.12.1;
	max-lease-time 7200;
	default-lease-time 3600;
        }
   }

Подскажите, в чем может быть проблема? Хотелось бы победить эти разрывы без перехода на выдачу ip по mac

[Abram]

Кто DHCP релей?

Откуда у циски берется маршрут на клиента?

[NikAlexAn]

И до какого хоста рвётся связь?

Пинг на шлюз рвётся?

Что в качестве браса? Как сервисы прописаны?

Изменено 30 октября, 2013 пользователем NikAlexAn

[infery]

Кто DHCP релей?

Откуда у циски берется маршрут на клиента?

 

Маршрут на клиента берется, исходя из источника запроса и ответа от dhcp-сервера. Разве нет? Релеем выступает циска.

 

И до какого хоста рвётся связь?

Пинг на шлюз рвётся?

Что в качестве браса? Как сервисы прописаны?

До любого в интернете. Тестируем на ноуте, к которому подключаемся через ammy admin. Ноут в ящике с оборудованием на доме. В качетсвет браса PC с linuxISG.

Изменено 30 октября, 2013 пользователем infery

[adnull]

А маршрут-то почему пересоздается? Может в этом дело? Если lease-time увеличить?

[infery]

А маршрут-то почему пересоздается? Может в этом дело? Если lease-time увеличить?

 

Мне тоже интересно почему он пересоздается. В другой сети opt82 не используется, на такой же циске маршруты ведут себя правильно

[Abram]

Маршрут по DHCP для ip unnumbered на циске создаётся на время действия лизы. По окончании лизы циска дропает маршрут.

Получается, что клиент почему-то слишком поздно делает renew.

Сделайте дамп dhcp трафика (udp port 67 or udp port 68) у клиента. Интересно посмотреть на dhcp опции, а конкретней - какой выдается dhcp-renewal-time.

Подзреваю, что он у вас почему-то криво считается - попробуйте указать одинаковые max-lease-time и default-lease-time.

[vitalyb]

или нет связи с dhcp сервером по юникасту

[dmvy]

Цыска подставляет себя в качестве gaddr и для продления Лизы она обращается к цыске на 67 порт. На цыске нет dhcp сервера - поэтому она молчит. После некоторых неудачных попыток после окончания Лизы клиентская часть сбрасывает адрес и переходит в состояние init, а цыска сбрасывает маршрут. Затем цыска видит брладкаст на порт 67 и helper отрабатывает как должен. Можно попробовать на сервере подкрутить таймеры в dhcp пакете, чтобы клиент сразу renew делал через broadcast.

[infery]

Цыска подставляет себя в качестве gaddr и для продления Лизы она обращается к цыске на 67 порт. На цыске нет dhcp сервера - поэтому она молчит. После некоторых неудачных попыток после окончания Лизы клиентская часть сбрасывает адрес и переходит в состояние init, а цыска сбрасывает маршрут. Затем цыска видит брладкаст на порт 67 и helper отрабатывает как должен. Можно попробовать на сервере подкрутить таймеры в dhcp пакете, чтобы клиент сразу renew делал через broadcast.

Мне кажется, если было бы именно так, то абоненты всегда бы отваливались, а так они отваливаются только при opt82. Кстати, все абоненты, релай и сервер в одной сети, но в разных broadcast доменах.

 

Маршрут по DHCP для ip unnumbered на циске создаётся на время действия лизы. По окончании лизы циска дропает маршрут.

Получается, что клиент почему-то слишком поздно делает renew.

Сделайте дамп dhcp трафика (udp port 67 or udp port 68) у клиента. Интересно посмотреть на dhcp опции, а конкретней - какой выдается dhcp-renewal-time.

Подзреваю, что он у вас почему-то криво считается - попробуйте указать одинаковые max-lease-time и default-lease-time.

Делал и одинаковые и разные. dhcpdump

12.12.12.3 -- DHCP сервер, 12.12.12.1 -- циска-шлюз

Изменено 30 октября, 2013 пользователем infery

[Abram]

infery,

Это вы на сервере дамп делали?

Здесь, во-первых, не видно общения клиента с циской.

Во-вторых - а перенесите-ка DHCP-сервер в другую подсеть; нечего ему в сидеть в одной сети с релеем и клиентами. Могут вылезти непонятные заморочки в плане unicast/broadcast - например, на сервер может прилетать что-нибудь лишнее. Или наоборот - не долетать, т.к. циска посчитает, что это нужно релеить.

Можно просто какой-нибудь адрес навесить на сервере на loopback, а у циски сделать к нему маршрут.

В-третьих - сделайте дамп в pcap, а то совсем неудобно читать :(. Можно сделать у клиента Wireshark-ом например. У него перед началом захвата в опциях можно сразу фильтр написать (НЕ фильтр отображения, а именно фильтр захвата, иначе за полчаса забьет под завязку).

[zero00]

Железка-клиент это что? под какой осью? логи получения адресов посмотрите.

так как default-lease-time 3600, то клиент начинает запрашивать продление в половину срока, это ваши 30 минут. Ну и если нет ответа на продление лиза у клиента, то он соответсвенно начинает делать по новой discover.

Изменено 31 октября, 2013 пользователем zero00

[infery]

Перенес на другую машину с другой подсетью, сделал tail -f /var/log/syslog | grep 12.12.12.72 (<-ip тестируемого ноута). Через некотторое время отвалился и в логах было вот что:

Oct 31 10:21:52 localhost dhcpd: DHCPREQUEST for 12.12.12.72 from 00:23:81:16:e4:ff via 12.12.12.1: lease 12.12.12.72 unavailable.

 

Нагуглил вот что

Handling Leases Marked as Unavailable

Отключил ping-check в DHCP, наблюдаю.

 

Похоже, что сервер просто не может найти лизы для адреса, который он уже выдавал, шлет NACK, абонент пытается переполучить IP, возникает разрыв. Уже рою исходники сервера =\

Изменено 31 октября, 2013 пользователем infery

[xcme]

А что при этом в файле лиз? Подобное поведение может быть если запросы приходят от разных агентов. Но в данной схеме он один, как я понял, так что лучше все же файл лиз изучить.

[infery]

В итоге все оказалось чуть проще, но проблема осталась. И проблема эта только с пользователями на длинках. Так выглядит настройка для dhcp для коммутаторов dlink:

class "match_p_24_sw_84c9b2172280" {
 match if ( 
   binary-to-ascii(10,16,"",substring(option agent.circuit-id,4,2)) = "24" 
   and  
   binary-to-ascii(16, 8, ":", substring(option agent.remote-id, 2, 6)) = "84:c9:b2:17:22:80"
 );
}
pool {
 range 12.12.12.72;
 allow members of "match_p_24_sw_84c9b2172280";
}

 

Вот настройка на dlink:

DES-1228/ME:5#show config current_config inc "local_relay"
Command: show config current_config include "local_relay"
enable dhcp_local_relay
config dhcp_local_relay option_82 remote_id default
config dhcp_local_relay vlan vlanid 158 state enable 
config dhcp_local_relay option_82 ports 1-24 policy replace
config dhcp_local_relay option_82 ports 25-28 policy keep

 

Так выглядит лиза абонента с dlink:

lease 12.12.12.72 {
 starts 3 2013/11/06 04:41:49;
 ends 3 2013/11/06 05:41:49;
 cltt 3 2013/11/06 04:41:49;
 binding state active;
 next binding state free;
 hardware ethernet 00:23:81:16:e4:ff;
 uid "\001\000#\201\026\344\377";
 option agent.circuit-id 0:4:0:9e:0:18;
 option agent.remote-id 0:6:84:c9:b2:17:22:80;
}

 

И только на них связь и рвется, на SNR и edge-core все нормально.

Изменено 6 ноября, 2013 пользователем infery

[xcme]

Попробуйте выключить релей на магистральных портах совсем.

[infery]

Попробуйте выключить релей на магистральных портах совсем.

Не подскажете, как это сделать?

 

config dhcp_local_relay option_82 ports 25-28 policy

дальше только параметры policy, state dis|en нет

[xcme]

Ммм. Знаю только как для обычного релея: config dhcp_relay ports 25-28 state disable

Для локал релей отдельной команды нет, но, быть может, там без разницы.

Мы используем dhcp_relay и, если он включен на магистральных портах, можно поиметь два глюка:

1. Примерно как у вас, когда дхцп пакет в итоге приходит не с того коммутатора, где абонент, а с другого, например, с вышестоящего. Сервер при этом скажем "lease xxx unavailable.", но тут на помощь приходит значение в "via yyy".

2. Зацикливание дхцп пакетов. Причина явления непонятна, либо глюк, либо повреждение кадра вместе с устареванием записи в fdb - пакет разлетается широковещательно, мак в нем меняется и он начинает релеиться бесконечно. Это приводит к загрузке CPU, невозможности получения адреса абонентом (с некоторой вероятностью). Также этот глюк не очень легко отловить, посколько в нашем случае такие фреймы рассылаются с маршрутизатора, хотя причина кроется в каком нибудь коммутаторе в конце ветки.

[infery]

Ммм. Знаю только как для обычного релея: config dhcp_relay ports 25-28 state disable

И такой команды нет,

DES-1228/ME:5#config dhcp_relay                     
Command: config dhcp_relay

Next possible completions: 
add                 delete              option_82           hops                
time                

DES-1228/ME:5#

Будем считать, что дело не в этом, но спасибо за помощь.

[max1976]

DHCP сервер не может продлить выданный адрес, т.к. коммутатор не вставляет option82 в юникастовые запросы клиента.

[xcme]

DHCP сервер не может продлить выданный адрес, т.к. коммутатор не вставляет option82 в юникастовые запросы клиента.

Видимо зависит от коммутатора. DES-3200 релеят уникаст и вставляют опцию туда. При обычном релей (не локал) это так.

 

И такой команды нет,

Может на данноый модели еще не запилили, у наших точно есть.

Изменено 6 ноября, 2013 пользователем xcme