New Problem with a Static IPs

RouterOS General
1

Description

I have a new install that has been misbehaving for a few hours.

The site was initially set up about a month ago with a DHCP client on one ISP.

~11 days ago the customer changed to another ISP with static Public
IPv4 addresses.

Loaded the static IPs and swapped to the new ISP. We have used this
ISP before but in this region they have changed to using ONTs to their
gateway that is required to use the static IPs.

Today the system was "set live" for the soft opening of a restaurant.

The system appeared to drop offline. Rebooting the ISP gateway
returned operation.

We then sat on the site watching to see if the situation would repeat.
It did. The technician onsite plugged his computer into the gateway
and received a DHCP address from the gateway and could still reach the
internet. The RB5009 could not reach the internet and appeared to be
offline. But all internal routing was working fine. Gateway was
cycled. RB5009 started passing traffic.

Updated to latest RouterOS

Next test was to have a computer connected to the gateway with one of
the static IP addresses not used on the RB5009. We then waited for the
system to drop offline again. It did. The tech onsite computer still
worked with a static IP.

I had him disconnect the feed into ether-1 and reconnect it. The
RB5009 got right back online.

I wrote a netwatch to ping 1.1.1.1 using one of the static IPs as the
src address and waited. The down was set to disable ether-1 wait 5
seconds then enable ether-1.

Waited around and the RB5009 fell ofline... the netwatch caught it.
And "bounced" ether-1.

We set up ether-2 on the other ISP that hasn't finished its contract.
Using route disances and not recursive... if you remove ether-1... it
will fall to ether-2.

But what I have is a support file generated right after the RB5009
stopped passing traffic... bounced its ether-1. Then started passing
traffic again.

Edit Update:

Output from the log...

2026-08-12 00:36:20 netwatch,info event down [ type: icmp, host: 1.1.1.1 ]
2026-08-12 00:36:20 script,info !!! 1.1.1.1 DOWN !!!2026-08-12 00:36:20 interface,info ether1-WAN link down
2026-08-12 00:36:21 system,info device changed by netwatch:type: icmp, host: 1.1.1.1/action:0 (/interface set ether1-WAN disabled=yes)
2026-08-12 00:36:25 script,info Fired by Netwatch!
2026-08-12 00:36:25 system,info device changed by netwatch:type: icmp, host: 1.1.1.1/action:1 (/interface set ether1-WAN disabled=no)
2026-08-12 00:36:28 interface,info ether1-WAN link up (speed 2.5G, full duplex)
2026-08-12 00:37:20 netwatch,info event up [ type: icmp, host: 1.1.1.1 ]
2026-08-12 00:37:20 script,info 1.1.1.1 is good over Comcast.
2026-08-12 03:31:21 netwatch,info event down [ type: icmp, host: 1.1.1.1 ]
2026-08-12 03:31:21 script,info !!! 1.1.1.1 DOWN !!!
2026-08-12 03:31:21 interface,info ether1-WAN link down
2026-08-12 03:31:21 system,info device changed by netwatch:type: icmp, host: 1.1.1.1/action:0 (/interface set ether1-WAN disabled=yes)
2026-08-12 03:31:26 script,info Fired by Netwatch!
2026-08-12 03:31:26 system,info device changed by netwatch:type: icmp, host: 1.1.1.1/action:1 (/interface set ether1-WAN disabled=no)
2026-08-12 03:31:29 interface,info ether1-WAN link up (speed 2.5G, full duplex)
2026-08-12 03:32:21 netwatch,info event up [ type: icmp, host: 1.1.1.1 ]
2026-08-12 03:32:21 script,info 1.1.1.1 is good over Comcast.
2026-08-12 06:30:22 netwatch,info event down [ type: icmp, host: 1.1.1.1 ]
2026-08-12 06:30:22 script,info !!! 1.1.1.1 DOWN !!!
2026-08-12 06:30:22 interface,info ether1-WAN link down
2026-08-12 06:30:22 system,info device changed by netwatch:type: icmp, host: 1.1.1.1/action:0 (/interface set ether1-WAN disabled=yes)
2026-08-12 06:30:27 script,info Fired by Netwatch!
2026-08-12 06:30:27 system,info device changed by netwatch:type: icmp, host: 1.1.1.1/action:1 (/interface set ether1-WAN disabled=no)
2026-08-12 06:30:30 interface,info ether1-WAN link up (speed 2.5G, full duplex)
2026-08-12 06:31:22 netwatch,info event up [ type: icmp, host: 1.1.1.1 ]
2026-08-12 06:31:22 script,info 1.1.1.1 is good over Comcast.

2

Isn't it IP6 RA broadcast story?
Disable IP6 at all, check if you have any DHCP Client active on WAN interface, disable any LLDP/CDP traffic on WAN.

3

@BartoszP IPv6 was disabled before I even started writing firewall rules.

There is no DHCP client on ether-1. I had to add one on ether-2 when this made me wonder if the new ISP was "iffy"

Ether-1 is not included in LLDP discovery.

4

Could it be the 2.5 Gb link?

Negotiation at 1 Gb or more is mandatory, but I have seen reports of some 2.5 Gb ports misbehaving when they have both 1 Gb and 2.5 Gb advertised.

Try on ether1:

  1. advertising only 1 Gb
  2. advertising only 2.5 Gb

AND check the cable, 2.5 Gb is picky when it comes to cables.

OR try using one of the 1 Gbit ports (let's say ether 3) to connect to the ISP.

5

@jsclazjsclaz

I have seen problems with the 2.5 negotiation on other installs. But it looks like a bad or slow connection. Lots of retries and the sort. Then you set the port to Gigabit and the problem goes away.

This is different. The unit functions normally for some amount of time. Then suddenly stops forwarding traffic entirely. Bouncing the interface brings it right back. Physically rip the cable out. Reboot the Gateway. Or the fastest and easiest to implement is bouncing the interface with this netwatch...

/tool netwatch
add disabled=no down-script=
":log info "!!! 1.1.1.1 DOWN !!!"\r
\n/interface ethernet disable ether1-WAN\r
\n:delay 00:00:05\r
\n/interface ethernet enable ether1-WAN\r
\n:log info "Fired by Netwatch!"\r
\n" host=1.1.1.1 http-codes="" interval=1m packet-count=10 packet-interval=6s src-address=50.xxx.xxx.xxx test-script="" thr-loss-count=5 type=icmp up-script=
":log info "1.1.1.1 is good over Comcast.""

The wire negotiates as 2.5 consistently.

But this is the first time I have seen this ISP gateway using Fiber to the building. This isp is traditionally coax.

6

So question are:
what IP did the technican receive and why? Public, local?
why you cannot use DHCP on WAN side?
what happens when the technican sets his computer's address to the IP you got assigned?

7

@BartoszP

When he got a DHCP that worked 10.1.10.125 (Inside the DHCP scope of the ISP provided gateway) This worked when the RB5009 no longer passed data.

He loaded the 4th Public Static IP (/29 space) onto his computer for the test listed above. It continued to work when the RB5009 stopped passing traffic.

If we use DHCP on the WAN side we get a nat'd IP. Which negates the ability to use the purchased static IPs. The static IPs are used in access control lists for other services.

Same as above.

8

When you use public addresses do you connect to other ports on an ISP device or not?

Wondering if your WAN interface with public address is on the same L2 domain as devices that use ISP assigned 10.1.10.nnn addresses?

9

@BartoszP

The Gateway has 4 LAN ports. If you go DHCP... you get an IP from the gateway LOCAL DHCP.

If you enter in a public IP on your device... the same port then accepts the traffic without nat.

10

And that bothers me. Why they mix natted and unnated traffic?
That could be the source of problem. If "public ip" connection gets "broken" then it falls into nat rules of ISP's device as a new one and maybe (!!!) it gets blocked by their internal firewall rules as a suspicious one. Reboot clears the ban and everything works till the next hickup.

11

@BartoszP

Their gateway that works on coax works about the same. But remember.... I don't need to reboot the gateway. Simply cycling the port works.

12

OK, you just need to break the stale connection and establish the fresh new one that goes the "public IP" way again.

13

@BartoszP

Ether-1 has the Static Public IPs on it.

It stops passing traffic.

Cycling Ether-1 for 5 seconds between disable and enable starts traffic again.

Traffic can run for 20 minutes or 3 hours. When it stops I have netwatch do the bounce.

14

@gotsprings

When you find a wall on your path, you can:

  1. try demolishing it with your head
  2. walk around it
  3. jump or climb over it

If ether1 is not working - for one reason or the other - try another port (ether3) if the behaviour is the same, then likely the issue is with the ISP being somehow incompatible with Mikrotik, if instead it works, the issue is with ether1 (or 2.5 Gb, or both).

15

@jaclaz

I sent a sup file to support.

Let see if they have any input.

16

Have you checked other ports than Eth1? It is so easy and gives a stright answer to "problem of 2.5Gb port or not".

17

@BartoszP

Ether-1 worked with the other ISP for about a month without issue.

Can't recall if it came up as 2.5. But it was another ISP and used DHCP for a public IPV4.

18

@BartoszP
At least we tried ... :winking_face_with_tongue:

19

Do we look at the proper device? https://www.youtube.com/shorts/dzKXTVN34cQ

20

@jaclaz @BartoszP

Will try putting the Static Ips on Ether-2 and flipping the ports on next visit.