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

cisco / dhcp opt82 / relay cisco ip unnumbered не реагирует на unicast dhcp

коллеги возник вопрос при работе с 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 не используется. в которую сторону копать?

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


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

попробуй

no ip dhcp relay information check

 

но лучше сказать debug ip dhcp server events и debug ip dhcp server packet и посмотреть, почему renew не пропускает.

 

кстати, у меня вопрос: поделитесь кому не жалко "правильным" отлаженным ACL на 3550 L3 relay...

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


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

Хоть тема и старая, но тоже с таким столкнулись - юникастовые запросы не попадали под relay.

У себя проблему решили тем, что начали в dhcp option 54 (server-identifier) передавать ip адрес циски. И проблема исчезла :)

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


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

можно на dhcp сервере подкрутить таймеры, чтобы клиент сразу по broadcast делал renew. У нас, когда были 3550, все работало без opt54. Сессии не падали. Причем время сессии было 5 или 10 минут. Еще не хватает proxy arp на vlan

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


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

можно на dhcp сервере подкрутить таймеры, чтобы клиент сразу по broadcast делал renew.

сомнительно, ренью всегда юникастом идёт, тк адрес у клиента ещё есть и адрес сервера он знает.

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


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

Наверно, клиентам всё-таки вообще лучше не знать ip адрес настоящего DHCP сервера.

У меня какая-то часть клиентов, как и в Странность в DHCP REQUEST (unicast), слала юникаст запросы напрямую на сервер с broadcast флагом.А dhcp сервер тупо броадкастом так и отвечал в своём влане. В итоге - лишний мусор в логах и ненужный броадкаст в влане с серверами.

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


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

Надо крутить таймеры 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.

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


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

Join the conversation

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

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

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

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

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

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

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