dmvy Опубликовано 14 мая, 2012 · Жалоба коллеги возник вопрос при работе с ip unnumbered: используем L3-коммутатор Cisco Cisco IOS Software, C3550 Software (C3550-IPSERVICESK9-M), Version 12.2(55)SE4, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2011 by Cisco Systems, Inc. Compiled Tue 06-Sep-11 06:14 by prod_rel_team Image text-base: 0x00003000, data-base: 0x0160376C d1-test-3550#sh ip dhcp binding Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type Hardware address/ User name 10.2.1.10 000e.0829.8ea3 May 14 2012 09:37 AM Relay 10.2.1.100 0021.8548.67be May 14 2012 09:37 AM Relay 10.2.1.101 0800.2772.de03 May 14 2012 09:40 AM Relay d1-test-3550#sh run int lo3 interface Loopback3 description vlan1 ip address 10.2.1.1 255.255.255.0 secondary ip address 22.33.44.225 255.255.255.240 no ip redirects end d1-test-3550#sh run int vlan 11 interface Vlan11 ip dhcp relay information trusted ip unnumbered Loopback3 ip helper-address 10.60.1.2 end вроде бы все работает, но dhcp-сессии срываются. одной из возможных причин считаю, что при dhcp-relay cisco не отвечает на unicast renew 15:38:45.462602 IP (tos 0x0, ttl 128, id 19773, offset 0, flags [none], proto UDP (17), length 328) 10.2.1.101.68 > 22.33.44.225.67: BOOTP/DHCP, Request from 08:00:27:72:de:03, length 300, xid 0x82b7770b, secs 1024, Flags [none] Client-IP 10.2.1.101 Client-Ethernet-Address 08:00:27:72:de:03 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Client-ID Option 61, length 7: ether 08:00:27:72:de:03 Hostname Option 12, length 5: "winxp" FQDN Option 81, length 9: "winxp." Vendor-Class Option 60, length 8: "MSFT 5.0" Parameter-Request Option 55, length 11: Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery Static-Route, Classless-Static-Route-Microsoft, Vendor-Option обрабатываются только broadcast DHCP Request, которые dhcp-клиент отправляет, если несколько раз безуспешно пытался сделать unicast-запрос. ACL не включены, ip dhcp server не используется. в которую сторону копать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agach Опубликовано 8 июня, 2012 · Жалоба попробуй no ip dhcp relay information check но лучше сказать debug ip dhcp server events и debug ip dhcp server packet и посмотреть, почему renew не пропускает. кстати, у меня вопрос: поделитесь кому не жалко "правильным" отлаженным ACL на 3550 L3 relay... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
OKyHb Опубликовано 6 августа, 2015 · Жалоба Хоть тема и старая, но тоже с таким столкнулись - юникастовые запросы не попадали под relay. У себя проблему решили тем, что начали в dhcp option 54 (server-identifier) передавать ip адрес циски. И проблема исчезла :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 6 августа, 2015 · Жалоба можно на dhcp сервере подкрутить таймеры, чтобы клиент сразу по broadcast делал renew. У нас, когда были 3550, все работало без opt54. Сессии не падали. Причем время сессии было 5 или 10 минут. Еще не хватает proxy arp на vlan Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 6 августа, 2015 · Жалоба можно на dhcp сервере подкрутить таймеры, чтобы клиент сразу по broadcast делал renew. сомнительно, ренью всегда юникастом идёт, тк адрес у клиента ещё есть и адрес сервера он знает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
OKyHb Опубликовано 7 августа, 2015 · Жалоба Наверно, клиентам всё-таки вообще лучше не знать ip адрес настоящего DHCP сервера. У меня какая-то часть клиентов, как и в Странность в DHCP REQUEST (unicast), слала юникаст запросы напрямую на сервер с broadcast флагом.А dhcp сервер тупо броадкастом так и отвечал в своём влане. В итоге - лишний мусор в логах и ненужный броадкаст в влане с серверами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 7 августа, 2015 · Жалоба Надо крутить таймеры T1 и T2. Делать их близкими друг к другу или равными. https://www.ietf.org/rfc/rfc2131.txt If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its current network address. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message. Times T1 and T2 are configurable by the server through options. T1 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * duration_of_lease). Times T1 and T2 SHOULD be chosen with some random "fuzz" around a fixed value, to avoid synchronization of client reacquisition. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...