Dhcp offering lease without success mikrotik что это
Бесплатный чек-лист
по настройке RouterOS
на 28 пунктов
Offering lease without success. Странная проблема с DHCP.
Правила форума
Как правильно оформить вопрос.
Прежде чем начать настройку роутера, представьте, как это работает. Попробуйте почитать статьи об устройстве интернет-сетей. Убедитесь, что всё, что Вы задумали выполнимо вообще и на данном оборудовании в частности.
Не нужно изначально строить Наполеоновских планов. Попробуйте настроить простейшую конфигурацию, а усложнения добавлять в случае успеха постепенно.
Пожалуйста, не игнорируйте правила русского языка. Отсутствие знаков препинания и неграмотность автора топика для многих гуру достаточный повод проигнорировать топик вообще.
1. Назовите технологию подключения (динамический DHCP, L2TP, PPTP или что-то иное)
2. Изучите темку «Действия до настройки роутера».
viewtopic.php?f=15&t=2083
3. Настройте согласно выбранного Вами мануала
4. Дочитайте мануал до конца и без пропусков, в 70% случаев люди просто не до конца читают статью и пропускают важные моменты.
5. Если не получается, в Winbox открываем терминал и вбиваем там /export hide-sensitive. Результат в топик под кат, интимные подробности типа личных IP изменить на другие, пароль забить звездочками.
6. Нарисуйте Вашу сеть, рисунок (схему) сюда. На словах может быть одно, в действительности другое.
Есть вариант, что в сети есть второй DHCP сервер, который отдал клиенту IP раньше, чем это успел сделать микротик.
Еще есть вариант, что на микротике включен DHCP клиент, который что-то там не получает. А должен ли?
Вот здесь это обсуждается https://forum.mikrotik.com/viewtopic.php?t=130176
однозначно эффективного решения нет.
Хотя, справедливости ради, надо сказать, что с моим парком микротиков (наверное уже более 100 единиц) ни разу с такой ошибкой и проблемой не сталкивался. Надо искать проблему в физической организации сети.
Есть вариант, что в сети есть второй DHCP сервер, который отдал клиенту IP раньше, чем это успел сделать микротик.
Еще есть вариант, что на микротике включен DHCP клиент, который что-то там не получает. А должен ли?
Вот здесь это обсуждается https://forum.mikrotik.com/viewtopic.php?t=130176
однозначно эффективного решения нет.
Хотя, справедливости ради, надо сказать, что с моим парком микротиков (наверное уже более 100 единиц) ни разу с такой ошибкой и проблемой не сталкивался. Надо искать проблему в физической организации сети.
Микротики есть разные: черные, белые, красные. Но все равно хочется над чем нибудь заморочится.
Dhcp offering lease without success mikrotik что это
Fri Feb 17, 2017 5:57 am
I’ve tried every incarnation of brodcast, non-broadcast, bootp options, etc. I have reset and rebuilt the config from scratch on each device. I have tried plugged directly into the device and via a switch, a MT access point. There is no common thread that I can find. The clients range from iOS, MacOS X, Linux, windows 7, and embedded devices like APC SmartUPS cards and printers (likely busybox linux). MacOS X seems to work the best but even that is inconsistent. The problem seems to worsen over time, working fine for some time and then getting progressively worse. The network is dual stacked with IPv6, it also had a small set of static mappings, but I removed them when the problem began to surface again.
Right now I have moved to an external dhcp server running isc-dhcpd and it works just fine with no other adjustments to the switch or the mikrotik device.
Any ideas, thoughts, rotten fruit to throw?
Re: Yet another «dhcp,warning offering lease without success» issue
Sat Feb 18, 2017 6:18 am
Re: Yet another «dhcp,warning offering lease without success» issue
Sat Feb 18, 2017 4:26 pm
Re: Yet another «dhcp,warning offering lease without success» issue
Sat Feb 18, 2017 8:03 pm
I’ve encountered this problem at a number of subscriber installations, and never heard a good explanation of why it was happening. The only time I ever actually solved it was when it started occurring at a new installation and then several days later the service went out – I found that indeed, the outdoor cable had been chewed by pack rats. At another site where this occurs, we used a cable that had been installed by the homeowner, so that would be consistent with this diagnosis. However, at a third subscriber, we ended up replacing the entire outdoor cable for completely unrelated reasons (he wanted it rerouted), and the problem did not go away. Perhaps it’s due to a bad patch cable inside his house beyond our wiring.
In any event, it might be worth just running the built-in ethernet test for a significant period and seeing if it comes up with transient faults.
Sent from my iPhone using Tapatalk
Re: Yet another «dhcp,warning offering lease without success» issue
Sun Feb 19, 2017 1:05 am
Re: Yet another «dhcp,warning offering lease without success» issue
Sun Feb 19, 2017 3:23 am
Re: Yet another «dhcp,warning offering lease without success» issue
Sun Feb 19, 2017 3:31 am
I’m curious— have you replaced the Routerboard? A bad or intermittent ether port jack might create the same failure mode as an intermittent cable.
My gut feeling is that this is somehow hardware- or unit-related. DHCP server works perfectly at all but a couple of my sites, and when I see this message, it’s always at the same few sites.
Sent from my iPhone using Tapatalk
Re: Yet another «dhcp,warning offering lease without success» issue
Sun Feb 19, 2017 3:44 am
Re: Yet another «dhcp,warning offering lease without success» issue
Sun Feb 19, 2017 3:48 am
Sent from my iPhone using Tapatalk
Re: Yet another «dhcp,warning offering lease without success» issue
Sun Feb 19, 2017 9:18 pm
Re: Yet another «dhcp,warning offering lease without success» issue
Sun Feb 19, 2017 9:33 pm
That’s interesting information. It wouldn’t be applicable to my own experiences because we use a lease time of four hours (so we can have a reasonably close indication at any time of how many devices are likely to be connected in the household).
One other curiosity we have noticed is that the devices generating this message have been preponderantly Apple computers. But our sample size is low, plus our business runs exclusively on Apples and has never experienced this problem locally.
Re: Yet another «dhcp,warning offering lease without success» issue
Mon Feb 20, 2017 11:39 am
Re: Yet another «dhcp,warning offering lease without success» issue
Fri Mar 10, 2017 8:16 pm
Re: Yet another «dhcp,warning offering lease without success» issue
Sat Mar 11, 2017 10:55 am
Re: Yet another «dhcp,warning offering lease without success» issue
Sat Mar 11, 2017 4:34 pm
Packet loss is a problem everywhere, but I am unconvinced that it is the issue since I replaced everything including fiber, twisted pair, ROS devices, patch cables and structured cabling. Dropping in a stand alone dhcp server solved the issue immediately and permanently. I also saw no evidence of packet loss in the tcpdump packet traces I took.
Re: Yet another «dhcp,warning offering lease without success» issue
Wed Mar 15, 2017 8:16 pm
Re: Yet another «dhcp,warning offering lease without success» issue
Wed Mar 15, 2017 9:26 pm
Re: Yet another «dhcp,warning offering lease without success» issue
Wed Mar 15, 2017 11:37 pm
Oh no, I wasn’t clear. It just made it easy to reproduce in that I can update to that version and cause the behavior. It didn’t solve it for a number of locations. I still maintain that the dhcp server isn’t up to par. I’m moving almost everything to ISC at this point, which I know well and does quite a bit more. Downside is that it requires external resources to run and adds operational overhead.
Re: Yet another «dhcp,warning offering lease without success» issue
Thu Mar 16, 2017 2:21 pm
Re: Yet another «dhcp,warning offering lease without success» issue
Thu Mar 16, 2017 2:58 pm
Re: Yet another «dhcp,warning offering lease without success» issue
Thu Mar 16, 2017 4:00 pm
I have seen this happen where the DHCP server is on a bridge, and the admin-mac has not been set on the bridge.
It is always good practice to set an admin-mac
Re: Yet another «dhcp,warning offering lease without success» issue
Thu Mar 16, 2017 4:40 pm
I have seen this happen where the DHCP server is on a bridge, and the admin-mac has not been set on the bridge.
It is always good practice to set an admin-mac
Re: Yet another «dhcp,warning offering lease without success» issue
Thu Mar 16, 2017 4:58 pm
Re: Yet another «dhcp,warning offering lease without success» issue
Thu Mar 16, 2017 5:21 pm
Re: Yet another «dhcp,warning offering lease without success» issue
Thu Mar 16, 2017 9:57 pm
Re: Yet another «dhcp,warning offering lease without success» issue
Thu Mar 16, 2017 11:51 pm
I observed DHCP problems in conjunction with
— wrong MTU setting (expecially along with VLAN),
— no Admin MAC on bridge interface
— STP configured on bridge running DHCP
Apart from layer 1 problems, these points are most of the time the cause of all trouble.
Re: Yet another «dhcp,warning offering lease without success» issue
Fri Mar 17, 2017 10:55 am
Re: Yet another «dhcp,warning offering lease without success» issue
Thu Mar 30, 2017 3:28 pm
Hi! I can confirm this bug after upgrading to 6.38.5 on RB750GL. After upgrading all my VMs and Hyper-V host was unable to get an ip.
Disabling RSTP on bridge interface helped. Never saw this bug before. RB works about 2 years without issues till now. No Admin-MAC.
Re: Yet another «dhcp,warning offering lease without success» issue
Thu Mar 30, 2017 3:52 pm
Re: Yet another «dhcp,warning offering lease without success» issue
Sun Apr 02, 2017 7:08 pm
After upgrade to 6.38.5 (stable) i am saw error for dhcp, warning offering.
And some computers and devices do not given IP.
Admin mac in bridge with local interface solved my problem. Thank communnity for help. And personnally Ape!
Re: Yet another «dhcp,warning offering lease without success» issue
Tue Apr 04, 2017 1:33 pm
Help me with the same problem
dhcp offering lease
# apr/04/2017 12:45:54 by RouterOS 6.38.5
# software > #
/interface bridge
add name=bridge1
/interface ethernet
set [ find default-name=ether1 ] mac-address=C8:6C:87:3F:25:C8
set [ find default-name=ether2 ] advertise=10M-half,10M-full,100M-half,100M-full name=ether2-master
set [ find default-name=ether3 ] advertise=10M-half,10M-full,100M-half,100M-full
/interface l2tp-client
add add-default-route=yes connect-to=10.255.255.254 disabled=no max-mtu=1460 mrru=1600 name=flex password=**** user=****
/ip neighbor discovery
set ether1 discover=no
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=dhcp ranges=192.168.0.10-192.168.0.254
add name=dhcp_pool1 ranges=192.168.0.2-192.168.0.254
/ip dhcp-server
add address-pool=dhcp_pool1 disabled=no interface=bridge1 lease-time=51w3d6h name=dhcp1
/interface bridge port
add bridge=bridge1 interface=ether2-master
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5
/ip address
add address=192.168.0.1/24 comment=defconf interface=ether2-master network=192.168.0.0
add address=172.18.248.94/24 interface=ether1 network=172.18.248.0
/ip cloud
set ddns-enabled=yes
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid interface=ether1
/ip dhcp-server alert
add alert-timeout=1m disabled=no interface=bridge1 on-alert=»/log info \»unknown dhcp-server\»» valid-server=6C:3B:6B:70:43:4D
/ip dhcp-server lease
add address=192.168.0.3 client-id=1:b0:5a:da:87:c7:90 mac-address=B0:5A:DA:87:C7:90 server=dhcp1
add address=192.168.0.40 client-id=1:0:25:22:38:86:ad mac-address=00:25:22:38:86:AD server=dhcp1
add address=192.168.0.46 client-id=1:0:25
5e:81:2e mac-address=00:25:AB:5E:81:2E server=dhcp1
add address=192.168.0.51 client-id=1:dc:4a:3e:ed:c9:c1 mac-address=DC:4A:3E:ED:C9:C1 server=dhcp1
add address=192.168.0.54 always-broadcast=yes client-id=1:0:15:17:b3:88:47 mac-address=00:15:17:B3:88:47 server=dhcp1
add address=192.168.0.33 client-id=1:0:255d:2e:3e mac-address=00:25:AB:5D:2E:3E server=dhcp1
add address=192.168.0.100 mac-address=00:11:32:4D:95:8C server=dhcp1
/ip dhcp-server network
add address=192.168.0.0/24 comment=defconf gateway=192.168.0.1 netmask=24
/ip dns
set servers=80.252.130.254,80.252.130.253
/ip dns static
add address=192.168.0.1 name=router
/ip firewall filter
add action=fasttrack-connection chain=forward comment=»defconf: fasttrack» connection-state=established,related
add action=accept chain=forward comment=»defconf: accept established,related» connection-state=established,related
add action=drop chain=forward comment=»defconf: drop invalid» connection-state=invalid
add action=drop chain=forward comment=»defconf: drop all from WAN not DSTNATed» connection-nat-state=!dstnat connection-state=new in-interface=ether1
add action=accept chain=input protocol=icmp
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=drop chain=input in-interface=ether1
/ip firewall mangle
add action=mark-routing chain=prerouting in-interface=flex new-routing-mark=l2tp_m passthrough=yes src-address=192.168.0.2-192.168.0.254
/ip firewall nat
add action=masquerade chain=srcnat comment=»defconf: masquerade» out-interface=ether1
add action=masquerade chain=srcnat out-interface=flex
/ip route
add distance=1 gateway=flex routing-mark=l2tp_m
add distance=1 gateway=172.18.248.254
add distance=10 dst-address=192.168.1.0/24 gateway=192.168.0.4
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www address=192.168.0.0/24
set ssh disabled=yes
set winbox address=192.168.0.0/24
/ip traffic-flow
set cache-entries=256k enabled=yes interfaces=flex
/ip traffic-flow target
add dst-address=192.168.0.54 port=1234
/snmp
set enabled=yes trap-version=2
/system clock
set time-zone-name=Europe/Moscow
/system identity
set name=Zenit
/system logging
add disabled=yes topics=dhcp,debug
/system routerboard settings
# Warning: memory not running at default frequency
set memory-frequency=1200DDR
/tool mac-server
set [ find default=yes ] disabled=yes
add interface=ether2-master
/tool mac-server mac-winbox
set [ find default=yes ] disabled=yes
add interface=ether2-master[/spoiler]
Dhcp offering lease without success mikrotik что это
Wed Mar 15, 2017 12:21 pm
RB1100AHx2 ver 6.38.3(stable)
dhcp client Windows 7 (some Lenovo laptop) cant get dynamic IP from router.
log picture in attachment
if you need more info please let me know.
Re: DHCP server offering lease without success
Wed Mar 15, 2017 12:44 pm
Have you tried 6.37.5?
You may also enable dhcp debugging: go to System > Logging then add a new rule with Topics=dhcp and action=disk so that you can easily filter other logging by setting disk dropdown on log view.
Re: DHCP server offering lease without success
Wed Mar 15, 2017 2:52 pm
on version 6.37.5 i have problems with CAPSMAN and CAP devices (they can’t connect), but this is another story.
dhcp debug response from logs
Re: DHCP server offering lease without success
Wed Mar 15, 2017 4:04 pm
Re: DHCP server offering lease without success
Wed Mar 15, 2017 7:21 pm
Yes, could be related.
Try running wireshark on that windows machine, to see if the mikrotik offers are getting received on the windows interface.
You can run 6.37.5 on the CAPsMAN controller with 6.38.5 CAPs. verified.
Re: DHCP server offering lease without success
Thu Mar 16, 2017 11:22 am
if that session is enough? (please see attachment).
as i can see Windows PC only sent discover.
dump file in gzip archive
Re: DHCP server offering lease without success
Thu Mar 16, 2017 11:34 am
Re: DHCP server offering lease without success
Thu Mar 16, 2017 11:44 am
As I suspected, the windows machine isn’t receiving anything.
— problem with 6.38 L2; if DHCP server is run on a bridge, try disabling RSTP on it. Try (for a test) to set up a standalone DHCP server on a single ether and plug the lenovo there, does it make a difference?
— Try a different driver on Lenovo laptop. Make sure there’s nothing unusual in its ethernet configuration.
— Try disabling the drop invalid firewall rule on input chain.
Re: DHCP server offering lease without success
Fri Mar 17, 2017 10:11 am
tested with another device HAP ac(v6.38.3 and v6.38.5)
PC directly connected over LAN cable, routeros with default settings. same Windows PC only sent discovery packet and no answer from router.
maybe is is broken LAN card in PC.
Re: DHCP server offering lease without success
Fri Mar 17, 2017 12:37 pm
I had similar issue with HP laptop. Mikrotik offered IP but laptop never get it.
Solution was to turn OFF bootp on DHCP server.
Re: DHCP server offering lease without success
Mon Mar 20, 2017 9:29 am
5 min. after same result «dhcp1 offering lease XX:XX mac wihout success.». How i can find where this MAC address is blocked or something similar?
Re: DHCP server offering lease without success
Mon Mar 20, 2017 12:54 pm
Re: DHCP server offering lease without success
Tue Mar 21, 2017 8:17 am
Re: DHCP server offering lease without success
Tue Mar 21, 2017 8:58 am
Last news.
Upgraded firmware to version 6.38.5, disabled rstp on brige interface. and problem still exist. will start meeting with support.
(but currently my CAPSMAN is working)
Re: DHCP server offering lease without success
Tue Mar 21, 2017 1:44 pm
Re: DHCP server offering lease without success
Wed Mar 22, 2017 9:40 am
Re: DHCP server offering lease without success
Wed Jul 12, 2017 8:39 pm
hi niemi, Did you manage to solve the problem of DHCP server offering lease without success?
Re: DHCP server offering lease without success
Wed Jul 12, 2017 9:34 pm
Re: DHCP server offering lease without success
Wed Jul 12, 2017 10:05 pm
Re: DHCP server offering lease without success
Sun May 13, 2018 9:12 pm
Re: DHCP server offering lease without success
Wed May 08, 2019 12:53 pm
Re: DHCP server offering lease without success
Fri May 10, 2019 12:09 am
Well, final solution for me was :
get back from 6.44.3 to 6.42.6 and everything is working fine.
Re: DHCP server offering lease without success
Mon Jun 03, 2019 7:18 am
Well, final solution for me was :
get back from 6.44.3 to 6.42.6 and everything is working fine.
Re: DHCP server offering lease without success
Tue Jun 04, 2019 5:19 am
I found the issue that may be due to compatibility between the latest ROS DHCP driver and ethernet hardware/driver. In my setup of x86 hardware, I used to use routerOS KVM to create a virtural network interface for my linux client. The default network interface is based on redhat virtio.
Under the latest firmware, it can get network ip when boot up but somehow it loses its ip upon renewal. That means the client is not connecting to network or internet.
When I look back the KVM wiki, it found that the virtual network interface can be created to emulate e1000. When I re create a separate virtual network interface with hardware emulation to intel e1000, IP address renewed was successful. I did not make any setting changed under routeros DHCP server nor downgrade the firmware to a lower version as described above by other users.
But I have to monitor the situation for a longer period of time.
Re: DHCP server offering lease without success
Wed Jul 03, 2019 10:13 pm
Re: DHCP server offering lease without success
Thu Jun 18, 2020 6:32 am
Re: DHCP server offering lease without success
Tue Aug 25, 2020 6:10 am
Hello guys, after a lot of research on this problem that is taking the peace of thousands of people here on the forum regarding the DHCP Bug mikrotik (offering lease without success), I decided to speak up and carry out this outburst. From what I understand this bug affects all versions above 6.38.7 and it seems that there is nothing, nothing that can be done to solve this problem; with regard to the mikrotik people, it is absurd that no engineer or programmer is going to speak publicly about it.
Well, let’s go to the resolution of the facts, let’s go to the origin of this problem, which seems to be the masking of MAC ADDRESS.
Here I use a DD-WRT router in AP BRIDGE mode (ROUTED), in this mode this equipment is absolutely unable to pass the true mac address of the clients that are dependent on it, this generates a MAC duplication for the DHCP service to which it understands how to were it an attempt to duplicate or clone or attempt to breach because of this mikrotik displays the following error message:
defconf offering lease 192.168.10.xxx for 00: 30: 18: xx: xx: xx to 10: FE: ED: xx: xx: xx without success
So far so good, but this is a problem for those who use the MAC masking system, and in my view it seems that there is no minimum interest from mikrotik in solving this problem, or that at least it could create a LEGACY DHCP option that could handle MAC masking. I sincerely hope that mikrotik can help us, because as well as the other colleagues we are already discouraged from these bugs and these errors.
Dhcp offering lease without success mikrotik
Простенький скрипт, который можно запускать раз в минуту. Если будут обнаружены устройства, которые не могут получить адрес по dhcp, и статус offered то они будут заблокированы. При поступлении жалов можно выяснить причину и снять блокировку.
Возникла задача получать уведомления при подключении новых (не санкционированных) клиентов к сети и автоматически добавлять их в списки блокировки (adress-list=lock). Все зарегистрированные клиенты, у меня, имеют статическую запись в dhcp leases. Новые клиенты автоматически регистрируются как динамические, поэтому нам надо при очередной выдаче IP проверить является ли запись статической или динамической. В настройках DHCP сервера имеется параметр: Lease Script.
Этот скрипт выполняется при каждой выдаче IP. В этом скрипте определены глобальные переменные:
Далее нам понадобится php скрипт отправляющий SMS по параметрам, который будет вызываться при выдаче очередного IP. Для примера это будет: http://mysite.ru/sms.php?text=testmessage.
Если не хотите заморачиваться со скриптом на своем хостинге рекомендую зарегистрироваться на сервисе отправки smsc.ru и отправлять SMS используя простой HTTP запрос формата:
Если у вас есть сайт (любой) можете разместить у себя кнопку сервиса smsc.ru и через службу поддержки (они проверят линк) вам установят тариф “6” уровня, что сделает отправку сообщений дешевле. Так же после подтверждения вашего номера телефона на счете появится бонус – 15 руб., которых достаточно для отладки скрипта. Так что денег не понадобится.
В Lease Script приписываем саму логику:
Данный скрипт будет делать уведомления по каждой выдаче нового динамического IP. Выдача будет происходить при каждом запросе клиента даже если адрес будет тот же, что и в прошлой сессии.
Проблему постоянных уведомлений решит список блокировки в Firewall. Если выделенный IP уже в списке блокировки то не стоит повторно уведомлять. Итоговый вид скрипта будет таким:
Добавляем в начало firewall правила блокировки всех пакетов входящих в Adress-List “lock”:
В принципе можете нагрузить php скрипт дополнительным функционалом, который будет добавлять события в БД или через Router OS API разносить блокировку по другим узлам.
PS: Усилить блокировку можно сменив в настройка интерфейса бриджа (по умолчанию) arp=reply-only, и в настройках сервиса dhcp: add-arp=yes. Эти настройки позволяют передать “управление” ARP – DHCP серверу. Если во время настройки отвалится Микротик, подключайтесь к нему по MAC (для этого в списке найденных роутеров надо щелкнуть по МАС а не по IP адресу роутера).
26 мыслей о “MIKROTIK уведомления о новых узлах (DHCP LEASE)”
Спасибо, за статью пригодилась 🙂
Статья очень помогла. Не понравился костыль с фаерволом.
Использую GSM модем для оповещения о подключении.
Новую неизвестную запись делаю статической и вношу в список unknown. В фаерволе блокируется весь трафик для клиентов из списка unknown.
:if ($leaseBound = 1) do= Читайте также: Фото девушек без лица со спины
Господа, не поможете со скриптом для выдачи одного статического адреса из пула dhcp для конкретного устройства с известным именем, например server.
У Микротика есть понятие статический Lease. Не видя вашей задачи не ясно какое решение предложить. Например, если вам нужно чтобы определенный клиент всегда получал один и тот же IP, то достаточно просто подключить его к сети, дождаться выделения ему IP, после чего, зайти в ip dhcp server leases открыть нужную запись и нажать Make Static. Другой вариант можно создать статическую запись заранее, указав MAC и нужный IP. Так же если указать другой IP в статической записи, то при следующем переподключении (lease update) клиент получит новый указанный IP (это на тот случай если не нравится какой IP был выделен из пула автоматом). Как видите скрип тут не уместен. Если ваша задача сложнее, то опишите ее подробнее.
Задача экзотическая, единственное что может сделать скрипт: сменить IP уже выделенный IP на другой по имени записи, что даст при повторном подключении нужный вам результат. События (скрипт) позволяющее переопределить выделяемый IP в Микротике нет.
При этом должна появится статическая запись в списке dhcp-server lease, но ее нет. Скрипты пишу впервые. Возможно проблема с синтаксисом.
Да можно. Сделайте lease-time (время аренды IP) не большим 5-10 минут, в зависимости от необходимой точности. В начале скрипта добавьте /log info “dhcp event” и смотрите что происходит с переменными при выделении IP, повторном выделении и завершении аренды.
Нужно сделать статичную запись для проблемного узла и поставить 2 галочки:
1. Usr Src. MAC address
2. Block Access (если вам нужно полностью залочить клиента)
да я таки делаю, mac блокируется
но появляется новые
я штук 200 сделал так все равно выходить
Если вы поставили галочку “Use Src. MAC” то у вас в принципе не может выделится 2 IP на один MAC. Проверьте внимательно.
Добрый день!
У меня Mikrotik выдает IP по DHCP, адреса получаем с сервера по Radius.
В случае падения Radius на сервере, клиент не может получить IP.
Через Netwatch реализовал проверку IP сервера. В случае не доступности, рапускаем /ip dhcp-server lease make-static [/ip dhcp-server lease find]
НО есть минусы:
1) Сервер может быть в сети, а Radius не запущен. И клиенты не могут получить IP.
2) Netwatch стоит проверка в 5секунд. Довольно часто бывает, что в эти 5секунд(между падением сервера и назначением всем статических адресов), у когота закончилось время аренды. И он не получит адрес,пока не поднимется Radius на сервере.
Подскажите как реализовать:
Проверку ответов от Radius, и если нет ответа,выдавать клиенты IP, который выдавался ему ранее
?
Возможно это можно реализовать через скрипт, который будет запоминать все выданные IP+MAC. И в случае появления адреса 0.0.0.0 в IP-DHCP server-Leases, будет выдавать всем адреса статически?
Mikrotik вряд ли вам поможет с тем что у вас происходит за пределами его “владений”. Скрипты DHCP выполняются асинхронно и вы не сможете им управлять. Попробуйте найти watchdog со стороны вашего RADIUS сервера и при помощи Mikrotik API управляйте им. Или же не дожидаясь падения в реальном времени, при выделении IP RADIUSом, сразу его переносите в Mikrotik при помощи того же API, т.е. формируйте backup схему в автомате. Думаю, это самый перспективный вариант.
Маленько некропост, но всё же не удержусь. Несколько загадочно выглядит код в статье.
….
:foreach i in=[find dynamic=yes] do=
В микротике новичек, если можно поледовательность действий установки с уведомлением на почту.
Спасибо
Script находится в конкретном DHCP сервере, висящем на конкретном интерфейсе. Список этих серверов здесь: IP / DHCP Server / DHCP (вкладка Alerts не нужна).
Выглядить он будет так (уведомление на почту)
Я заменил вот эту строку
/tool fetch host=”mysite.ru” keep-result=no mode=http address=”mysite.ru” src-path=”/sms.php?
на вот эту
/tool e-mail send to=”$emailAddress”
Измененный скрипт
:if ($leaseBound = 1) do=
>
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.
Распространенные в сети материалы касаются работы именно маршрутизаторов MikroTik. И все они для отлова DHCP используют скудные ресурсы CPU. При этом, относительно свежая линейка коммутаторов хронически остается без внимания. Между прочим, совершенно напрасно.
Итак, подопытный аппарат CRS125-24G-1S установлен на доступе. С некоторых пор изредка на пользовательские устройства стали выпадать посторонние IP-адреса. Естественно возникла задача «найти и обезвредить». В стандартном арсенале RouterOS есть инструмент «DHCP-server Alert», способный вызывать некие действия при обнаружении в сети стороннего DHCP-сервера.
Отлично? Пожалуй. Только инструмент при ближайшем рассмотрении оказался не слишком информативный. Чтобы понять почему, рассмотрим типичную архитектуру маршрутизирующего оборудования MikroTik (картинка из вики):
По сути основная часть устройства делится на две:
1) програмно-конфигурируемый свитч, осуществляющий коммутацию на максимальной скорости;
2) CPU отвечающий за маршрутизацию, фильтрацию а также умеющий осуществлять коммутацию на программном уровне, медленнее и более ресурсоёмко.
IP-сервисы на таком устройстве, само собой висят на верхнем уровне. На Master-интерфейсе восходящем к CPU Routerboard или на программном бридже. Там и живет DHCP-сервер и его служба алертов. Все виденные мною ранее решения имели также два недостатка вытекающие из этой архитектуры:
1) Фильтрация трафика от злодея выполнялась на бридже, через «use ip firewall» и отнимала без того скудные ресурсы CPU;
2) Злодей подключенный к свитчу продолжал неконтролируемо пакостить абонентам на соседних портах этого свича.
Например, абоненты висящие на port2 и port3 всё равно продолжали получать бяку прилетающую со стороны port4. Но всё изменилось, когда у MikroTik появилась линейка CRS — ребята установили более мощный и функциональный свитч-чип, который я и решил попытаться использовать, победить и сохранить ресурсы CPU.
Шаг №1
Кхм. Сколько у нас портов? 24? Ладно. Я иду искать…
Шаг №2
Я пошел другим путем, создав локальную переменную с нормально интерпретируемым именем:
Как известно, настоящий джедай использует силу, а настоящий инженер использует мозг. Поэтому, идея тупо полностью отрубить найденный порт была мною отброшена — а вдруг за этим портом сидит несколько пользователей и/или устройств? К счастью свитч-чип в MikroTik CRS позволяет делать MAC-Based-Vlan. Решение пришло тут же — выделить трафик от злодея по MAC и завернуть в отдельный неиспользуемый Vlan. В итоге, получился компактный скрипт, надежно отключающий от сети чужое устройство с поднятым на нём DHCP-сервером.
Вызов алерта и скрипта у меня прописан следующим образом:
Спасибо, что дочитали до конца. Надеюсь, вам это когда-нибудь пригодится.
