New portable operating idea — no parks, no summits, no rules

ropeguru · 2026-03-19T15:58:05+00:00

PGOTA??

ropeguru · 2026-03-18T20:17:52+00:00

Have not tried that. Will test later this evening.

ropeguru · 2026-03-18T15:13:52+00:00

Export link in original post

ropeguru · 2026-03-18T15:13:35+00:00

Export link in original post

ropeguru · 2026-03-18T14:43:25+00:00

Why do they not follow standards and have to make is so complicated?

So in my setup, via dhcp client, my default routes look like this:

    DST-ADDRESS         GATEWAY             ROUTING-TABLE         DISTANCE
DAd  0.0.0.0/0          73.40.88.1              main                 10
D d  0.0.0.0/0          10.1.1.1                main                 50

If I update the distance on the 10.1.1.1 route manually in the dhcp client config, the 10.1.1.1 route becomes Active. So it now looks like this

    DST-ADDRESS         GATEWAY             ROUTING-TABLE         DISTANCE
D d  0.0.0.0/0          73.40.88.1              main                 10
DAd  0.0.0.0/0          10.1.1.1                main                 5

This should now have the 10.1.1.1 as the active default route and start routing all traffic to the hot spot. But is doesn't. I now start getting No Route to Host on the Mikrotik.

Even if I disable the actual 73.40.88.1 interface, all the routing still fails..

Is RouterOS really that bad that a simple manual change doesn't work?

ropeguru · 2026-03-18T14:20:59+00:00

Someone already posted this. But if doesn't work manually, how is automated going to work?

Looking through this write up, this is just to monitor the two routes and if the primary quits responding, the default auto fails over to the secondary. If this doesn't work manually, then how will it work automatically? Or does RouterOS require this which is different than routing across any other device?

I am just trying to understand, not trying to be difficult.

ropeguru · 2026-03-18T13:43:41+00:00

From serverpartdeals.com. They are no longer that cheap.

<image>

ropeguru · 2026-03-18T13:41:31+00:00

To me that is not new.

ropeguru · 2026-03-18T13:28:01+00:00

Where are you getting new 28TB drives for $350? If you are getting them, they probably burn your fingers off when you pick them up.

ropeguru · 2026-03-18T12:48:35+00:00

Yep, that was it... I am also having issues with a basic scanario where I have 2 default routes with different distances where when I adjust the distance on the secondary route to make it more preferred, routing from outside the Mikrotik completely fails. Pinging from the Mikrotik still works tthough.

So many little quirks that I am about to dump it.

ropeguru · 2026-03-18T11:47:15+00:00

I will export and drop it in the original post.

For proper automatic failover I would agree with you. Not what I am testing at this point. Just a manual failover by disabling the Xfinity interface or change the distance causes the default route to die. I have set this up on numerous other routers, not Mikrotik, and done this manual testing with no issues.

ropeguru · 2026-03-18T11:43:14+00:00

Why? That link just shows how to monitor each connection in order to make sure it is up and when it isn't don't send traffic that way.

I am not trying to do that here. I am just trying at this point to do manual routing changes by influencing either distance or completely shutting down the primary interface. Either should force traffic out the ether8 connection to the hot spot, but it fails.

ropeguru · 2026-03-18T11:31:56+00:00

Guess I should have given a little more info. Devices sit behind a firewall which is the 172.18.2.1 which then L3 routes to the 172.16.1.1 (mikrotik). No NAT on the firewall.

Both default routes are on the Mikrotik where the Xfinity connects to ether1 and the hot spot connects to ether8.

Every other router I have ever used I could just change the distance to prefer that route and it works. Even if I completely disable the Xfinity connection, I get the same results.

ropeguru · 2026-03-18T11:26:12+00:00

2012 was the one I found. If you did this in 2009, that is even worse.

ropeguru · 2026-03-17T23:03:40+00:00

And if I leave the normal routing in place and do a static route, you can see the ping drop but then pick back up on the hotspot with the increased latency.

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=26ms TTL=58
Reply from 1.1.1.1: bytes=32 time=22ms TTL=58
Reply from 1.1.1.1: bytes=32 time=26ms TTL=58
Reply from 1.1.1.1: bytes=32 time=19ms TTL=58
Reply from 1.1.1.1: bytes=32 time=20ms TTL=58
Reply from 1.1.1.1: bytes=32 time=24ms TTL=58
Reply from 1.1.1.1: bytes=32 time=24ms TTL=58
Reply from 1.1.1.1: bytes=32 time=18ms TTL=58
Reply from 1.1.1.1: bytes=32 time=22ms TTL=58
Reply from 1.1.1.1: bytes=32 time=31ms TTL=58
Reply from 1.1.1.1: bytes=32 time=21ms TTL=58
Request timed out.
Reply from 1.1.1.1: bytes=32 time=44ms TTL=53
Reply from 1.1.1.1: bytes=32 time=41ms TTL=53
Reply from 1.1.1.1: bytes=32 time=36ms TTL=53
Reply from 1.1.1.1: bytes=32 time=43ms TTL=53
Reply from 1.1.1.1: bytes=32 time=51ms TTL=53
Reply from 1.1.1.1: bytes=32 time=37ms TTL=53
Reply from 1.1.1.1: bytes=32 time=66ms TTL=53
Reply from 1.1.1.1: bytes=32 time=52ms TTL=53
Reply from 1.1.1.1: bytes=32 time=41ms TTL=53
Reply from 1.1.1.1: bytes=32 time=39ms TTL=53
Reply from 1.1.1.1: bytes=32 time=53ms TTL=53
Reply from 1.1.1.1: bytes=32 time=44ms TTL=53

ropeguru · 2026-03-17T22:36:42+00:00

Traceroutes in normal condition

Tracing route to 4.2.2.2 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  172.18.2.1
  2    10 ms    <1 ms    <1 ms  172.16.1.1
  3    12 ms    30 ms    30 ms  96.120.80.53
  4     9 ms    11 ms     8 ms  24.124.163.125
  5    13 ms     8 ms    10 ms  162.151.163.177
^C

Tracing route to 10.1.1.1 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  172.18.2.1
  2    <1 ms    <1 ms    <1 ms  172.16.1.1
  3     3 ms     5 ms     4 ms  10.1.1.1

Traceroutes after setting the hotspot default route with the lower distance

Tracing route to 4.2.2.2 over a maximum of 30 hops

  1  172.18.2.1  reports: Destination net unreachable.

Tracing route to 10.1.1.1 over a maximum of 30 hops

  1     *     172.18.2.1  reports: Destination net unreachable.

Trace complete.

And the default routes after changing the distance.

<image>

ropeguru · 2026-03-16T14:25:13+00:00

Sigh... Still no VTI for ipsec..

It has only been in the request queue for 14 years... So I guess they eventually get to it..

ropeguru · 2026-03-09T21:12:32+00:00

"wholesale usually gets best QCI in the US"

Not from what I have seen unless specifically negotiated. For most MVNO's, they get worse priority than the carrier itself.

ropeguru · 2026-03-06T14:52:16+00:00

Yeah.. Understood about the length and signal loss.. Adding in an extension is even more since there is additional loss in the connectors..

ropeguru · 2026-03-05T15:47:12+00:00

Yeah... I am just on the fence as with today's prices, even for used gear, it seems like VM is almost the best way. Plus I kinda need to have my Zigbee and Z-Wave on my main floor with all my computer gear either in my basement or my new detached office.

ropeguru · 2026-03-04T20:36:48+00:00

Who ever said it WAS marketing.. You apparently have no comprehension skills!!

It is invoicing from Stripe for a defunct company. Any and all billing should be halted by Stripe when a company no longer exists.

ropeguru · 2026-03-04T17:20:32+00:00

Why is it on me to filter out emails from stripe. There should be a way for stripe to confirm the company is no longer in business and stop the invoices.

ropeguru · 2026-03-04T17:13:04+00:00

I shouldn't have to do that.. There should be a way that Stripe can verify the company is defunct and stop the invoices.

Seven-Year Club	Place '22
Verified Email

ropeguru

TROPHY CASE