For those who run CHR systems , I think I found a bug
Information can be found here:
Since we are asked to make a new topic and there already is one.
@TomjNorthIdaho:
Does your ether1 have a static IP bind to it, and the DHCP is still coming back? Then it does actually sound like a bug. RouterOS should never change a configuration on its own..
Cause on my test CHR’s (RC20>) we CAN NOT replicate your problem after a restart. We only have a DHCP-Client on ether1 when first booted up. When we add a address, remove the dhcp-client and reboot it has the same configuration.
@MTStaff:
With first boot its fine that there is a DHCP-client for those who don’t have access to console but this should be noted better somewhere.
BUT :
When you deploy with the use of a OVA and have a little control how to push the configuration (you can enter IP-addresses).
Why it still has a DHCP-client even when you don’t configure it?
In one of my tests, I had both a static and a dynamic address on ether1.
Then it does actually sound like a bug. RouterOS should never change a configuration on its own..
It does change by itself. If you are very quick, you can login right after the CHR boots and do an “export”. Then about 5 seconds later do another “export” and you will see it has automatically created a dhcp-client.
Anyway, it has been acknowledged by Mikrotik support as a bug, so there is probably no value in discussing/testing further until they’ve at least attempted to fix it.
re: Does your ether1 have a static IP bind to it, and the DHCP is still coming back? Then it does actually sound like a bug. RouterOS should never change a configuration on its own..
YES (on every different CHR 6.4 and newer)
example configuration
ethe1 static IP addredd
ether2 static IP address
ether3 no IP address (this will be a dhcp-server)
ether4 no IP address (used for out-of-band Winbox MAC management)
There is no dhcp-client anywhere in the configuration - untill I reboot it.
After a reboot , there is a dhcp-client auto-injected into the configuration.
I am starting to think this might be a security hole and could lead to un-wanted IP addresses and un-wanted routes.
example:
A CHR has a WAN with a static IP address and optionally a default route
The CHR is also doing BGP and/or OSPF
If the up-stream WAN of the CHR has two or more other routers - and one of the upstream routers is a dhcp-server. Below are some of the possible problems I can think of that deserve some thoughts because of the auto-injected dhcp-client:
- The CHR now has two IP addresses on the WAN (one static and one from the dhcp-client auto-injected configuration.
- The CHR might now have a default route injected from the dhcp-client
- If a default route was supposed to be learned from BGP and/or OSPF , a new default route might now be injected into the CHR because of the now has an auto-injected default-route, resulting in two different 0.0.0.0/0 default routes - and these default routes might point to different up-stream WAN connected routers.
- BGP and OSPF routes might now be contanimated with an additional route from the auto-injected dhcp-client configuration
- With the auto-injected dhcp-client setting, is it now possible to hijack or kill a CHR that has a WAN on your network. Example, Your ISP has a /24 WAN and 10 customers on that /24 from your ISP have CHRs with static IP addresses -and- suppose somebody anywhere puts a dhcp-server on that WAN - then - anybody who reboots their CHR now gets what ever IP address was assigned to them from the dhcp-server and also received a default route to what ever the dhcp-server pointed it to. When a CHR on the /24 WAN network reboots, that CHR can receive corrupt network killing IP address and routes - and possibly get a duplicate IP address already used by something else on the /24 network - now resulting in another network now having problems also.
North Idaho Tom Jones
I’ve seen this recently with a few of my fresh installs. Best workaround I’ve found is to leave a dhcp client on the interface but disable it. It won’t regenerate and if you can live with it there but disabled it won’t trouble you again.
Funny - I did disable it on my CHR systems. After a reboot, there would be a new enabled dhcp-client and the one had disabled.
Then when I disabled the 2nd dhcp-client (now I had two disabled dhcp-client settings, another reboot would auto add a 3rd enabled dhcp-client.
As a work around, I just disabled the dhcp package. Not a good work-around but a work-around until it gets fixed.
North Idaho Tom Jones
We are aware of this problem. Hopefully it will be fixed in v6.42
mrz ,
Thank you - Thank you - Thank you for this information/post.
I’m looking forward to v6.42
FYI - On one of my CHRs, I need ether1 to be a dhcp-server — however - with the auto inject of dhcp-client on ether1 after a reboot , I end up with a static IP address on ether1 and a dhcp-client on ether1 — which I suspect will end up with two different IP addresses on ether1 and possibly two different default-routes
North Idaho Tom Jones
Odd.
I actually emailed support about this and the response was that it is intentional to create dhcp-client on ether1. I was advised to disable it and ignore if not needed.
It was probably intentional to create this client on initial boot when the config is empty, much as a default configuration is created on initial boot of the small routers.
However, in the case of recent CHR releases it was creating this thing even on a running config. I have seen it happen as well.
However, on my CHR running 6.42rc30 I have not seen it anymore, it has static addresses on ether1 and ether2 and no more spontaneous dhcp clients so far.
On my rc30, it’s still adding the dhcp-client every time, regardless of whether a static address is on ether1 or whether you’ve disabled the previously auto-created dhcp-client.
i.e. it’s no different to how it was when I reported this bug to support a month ago.
Hello, I can confirm this bug, dhcp client comes back, screwing up my routes for starters.
If I disable it, another entry gets enabled after reboot.
If I delete it, another entry gets created after reboot.
Only does this if there is an actual dhcp server around the network I suspect.
This is CHR why is Mikrotik not fixing this serious issue?
And it gets worse, the initial topic http://forum.mikrotik.com/t/problem-with-mount-point/94/1 was closed due to 6.41.2 being released, but the bug was not fixed.
So somebody had to create another ticket.
It is not happening for everyone. There must be some other setting or feature that makes it happen.
Putting ether1 in a bridge stops it happening because you can’t have a dhcp-client on a slave interface.
Congratulations, great workaround…
@mikrotik - have a definitive fix?
I did not have this problem with 6.42rc30 but now I installed 6.42rc35 and the problem is back!
It’s like Lassie on steroids. I have three CHRs to play with (bugfix/current/rc with latest versions), and it happens on all of them, even though there’s static IPv4 address configured on at least on one of available interfaces.
I get the idea that it might be good if the router doesn’t make it easy to end up without address and thus inaccessible in some scenarios. But it’s not good to make it unavoidable. There must be a way to turn this behaviour off. Add something like this if you must, but make it possible:
/ip dhcp-client
set chr-hardcore-mode=no-i-do-not-want-automatically-added-dhcp-client-and-i-will-not-blame-mikrotik-if-i-lock-myself-out
DHCP client is required on CHR installations since most of cloud services provide only access through IP address and you do not have direct access to console.
In order to make it happen, CHR checks if there is an IP address on ether1 interface or on bridge if ether1 is in it. If there is no IP address or DHCP client, then one is created automatically.
If client is disabled, then still new one will be created in case it was disabled by accident.
If there is a static IP address on ether1 (or bridge) new DHCP client will not be added.
But why not apply this config once after initial boot, like the default config of the low-end routers, and then not touch it afterward when the user decides to remove this item?
When I remove all config on a low-end-router it becomes inaccessible just as well, and the config is not changed to avoid it.
The problem is not that this client is automatically added after initial boot, the problem is that it is re-applied after the user has removed it.
Remember the user may even be managing the router only via IPv6 and not at all desires to have an IPv4 address on it.
Also, the mechanism you depict apparently does not work correctly, as on my CHR with ether1 and ether2 both with static address it still adds the DHCP client on ether2.
(in this CHR the ether ports are swapped between VMware config and RouterOS names, no idea why, reported before)
Well, the approach with ether1 does sound reasonable, and I’d probably not complain if it worked as described. The trouble is, it doesn’t work at all.
First problem, what is ether1? I have three CHRs in VMware Player. Interfaces listed in Player’s UI match the order in .vmx file (ethernet0-ethernetX). But they appear in different order in CHRs:
CHR1 (6.40.6): ether2, ether3, ether4, ether1
CHR2 (6.41.2): ether2, ether3, ether4, ether1
CHR3 (6.42rc37): ether2, ether4, ether5, ether1, ether3
I have all interfaces renamed, but these are “default-name” parameters taken from “/interface ethernet export verbose” and paired using MAC addresses.
Second problem, the behaviour is not predictable. If dhcp client got added where default-name=ether1, then I’d say it’s just a problem with interface order. But when I do few reboots, while removing existing dhcp client before doing so, I end up with new dhcp client not only on ether1, but also on ether2, empty bridge, disabled ovpn-out1, disabled cap1. No interface seems to be safe. Whether ether1 does have a static address or not, doesn’t seem to matter.