|
redeyes posted:Once in about 2.5 years on my router. When I remoted in the CPU was blasted at nearly 100%. A reboot and nothing else has happened in months and months. Solar flares or something Possibly NAT tables filling up? Mikrotiks are much better about this than standard home DSL routers, but given enough time/load it might be possible.
|
#
?
Aug 21, 2017 15:20
|
|
|
|
| # ? May 22, 2024 11:07 |
|
|
Masked Pumpkin posted:So I've got a weird mangling/routing issue I'm trying to get to the bottom of: I'm going to try to look at this later when my head is clearer, but a few things come to mind:
|
|
#
?
Aug 21, 2017 16:13
|
|
|
Masked Pumpkin posted:Possibly NAT tables filling up? Mikrotiks are much better about this than standard home DSL routers, but given enough time/load it might be possible. I really doubt it, I do reboot from time to time to install updates.
|
|
#
?
Aug 22, 2017 04:49
|
|
|
thebigcow posted:I'm going to try to look at this later when my head is clearer, but a few things come to mind: Thank you, yes - that PCC example seems to have been the missing link (also not sure what was going on with the srcnatting) - all is up and running as it should now, along with gateway checks by pinging 8.8.8.8 instead of the local router - for anyone interested, the updated and working code is below: pre:[admin@MikroTik] > /export # aug/22/2017 10:25:30 by RouterOS 6.35.4 # software id = JT3P-9RC9 # /interface ethernet set [ find default-name=ether4 ] name=3G set [ find default-name=ether3 ] name=DSL set [ find default-name=ether2 ] name=LAN set [ find default-name=ether5 ] master-port=LAN /ip neighbor discovery set ether1 discover=no /ip hotspot profile set [ find default=yes ] html-directory=flash/hotspot /ip pool add name=dhcp ranges=10.0.0.101-10.0.0.162 /ip dhcp-server add address-pool=dhcp disabled=no interface=LAN name=defconf /ip address add address=10.0.0.254/24 comment=defconf interface=LAN network=10.0.0.0 add address=192.168.1.254/24 comment=DSL interface=DSL network=192.168.1.0 add address=192.168.2.254/24 comment=3G interface=3G network=192.168.2.0 /ip dhcp-client add comment=defconf dhcp-options=hostname,clientid disabled=no interface=ether1 /ip dhcp-server lease #Whatever 'static' leases you need can go here /ip dhcp-server network add address=10.0.0.0/24 comment=defconf gateway=10.0.0.254 netmask=24 /ip dns set allow-remote-requests=yes servers=8.8.8.8 /ip dns static add address=10.0.0.250 name=router /ip firewall filter add chain=input comment="defconf: accept ICMP" protocol=icmp add chain=input comment="defconf: accept established,related" connection-state=established,related add action=drop chain=input comment="defconf: drop all from WAN" in-interface=ether1 add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related add chain=forward comment="defconf: accept established,related" connection-state=established,related add chain=forward dst-port=27 in-interface=DSL protocol=tcp add chain=forward dst-port=80 in-interface=DSL protocol=tcp add chain=forward dst-port=1194 in-interface=DSL protocol=tcp add chain=forward dst-port=3389 in-interface=DSL protocol=tcp add chain=forward dst-port=3390 in-interface=DSL protocol=tcp add chain=forward dst-port=3391 in-interface=DSL protocol=tcp add chain=forward dst-port=3392 in-interface=DSL protocol=tcp add chain=forward dst-port=3393 in-interface=DSL protocol=tcp add chain=forward dst-port=5901 in-interface=DSL protocol=tcp 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 /ip firewall mangle add chain=prerouting dst-address=192.168.1.0/24 in-interface=LAN add chain=prerouting dst-address=192.168.2.0/24 in-interface=LAN add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=DSL new-connection-mark="DSL Connection" add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=3G new-connection-mark="3G Connection" add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=LAN new-connection-mark="DSL Connection" per-connection-classifier=both-addresses:2/0 add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=LAN new-connection-mark="3G Connection" per-connection-classifier=both-addresses:2/1 add action=mark-routing chain=prerouting connection-mark="DSL Connection" in-interface=LAN new-routing-mark=to_DSL add action=mark-routing chain=prerouting connection-mark="3G Connection" in-interface=LAN new-routing-mark=to_3G add action=mark-routing chain=output connection-mark="DSL Connection" new-routing-mark=to_DSL add action=mark-routing chain=output connection-mark="3G Connection" new-routing-mark=to_3G /ip firewall nat add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=ether1 add action=masquerade chain=srcnat connection-mark="DSL Connection" disabled=yes to-addresses=192.168.1.1 add action=masquerade chain=srcnat src-address=10.0.0.0/24 add action=masquerade chain=srcnat out-interface=DSL add action=masquerade chain=srcnat out-interface=3G ###Whatever port forwards you need go here - make sure the appropriate router is also forwarding, and make sure they're allowed in /ip firewall filer too add action=dst-nat chain=dstnat dst-port=3389 protocol=tcp to-addresses=10.0.0.46 to-ports=3389 add action=dst-nat chain=dstnat dst-port=27 protocol=tcp to-addresses=10.0.0.200 to-ports=22 add action=dst-nat chain=dstnat dst-port=80 in-interface=DSL protocol=tcp to-addresses=10.0.0.240 to-ports=80 add action=dst-nat chain=dstnat dst-port=3390 protocol=tcp to-addresses=10.0.0.30 to-ports=3389 add action=dst-nat chain=dstnat dst-port=3392 protocol=tcp to-addresses=10.0.0.70 to-ports=3389 add action=dst-nat chain=dstnat dst-port=5901 protocol=tcp to-addresses=10.0.0.99 to-ports=5900 add action=dst-nat chain=dstnat dst-port=3393 protocol=tcp to-addresses=10.0.0.46 to-ports=3389 /ip route add distance=1 gateway=192.168.1.1 routing-mark=to_DSL add distance=1 gateway=192.168.1.1 routing-mark=to_DSL add comment=DSL distance=2 gateway=192.168.1.1 routing-mark=to_DSL add disabled=yes distance=1 gateway=192.168.2.1 routing-mark=to_3G add check-gateway=ping comment=3G distance=1 gateway=8.8.8.8 add comment="Validate 3G" distance=1 dst-address=8.8.8.8/32 gateway=192.168.2.1 scope=10 ###Add random routes that _have_ to go through one gateway here add distance=1 dst-address=50.23.197.94/32 gateway=192.168.1.1 /system clock ###Probably not the timezone you want set time-zone-name=Africa/Johannesburg /system routerboard settings set cpu-frequency=850MHz protected-routerboot=disabled /tool mac-server set [ find default=yes ] disabled=yes add interface=LAN /tool mac-server mac-winbox set [ find default=yes ] disabled=yes add interface=LAN
|
|
#
?
Aug 22, 2017 09:31
|
|
|
Oh good. I forgot all about you 
|
|
#
?
Aug 22, 2017 15:47
|
|
|
I'm having a bit of trouble with my 1100ahx2.. I'm getting some port flaps on a couple of my interfaces that start happening roughly 45 minutes after I reboot, then they start flapping on average every 15 minutes or so. I've tried upgrading routerOS, downgrading RouterOS, and changing autonegotiation settings and nothing really has helped (and turning off autonegotiation and forcing 1gbps just makes the port stay down forever). I noticed that in the recent bugfix release (6.38.7) that there were some fixes in place regarding the ethernet chip, so I was hoping that was the issue, and I installed it. It didn't fix the issue. I have been doing some internet detective work and it sounds like it might possibly be a capacitor issue on the motherboard itself? I'm not really too enthusiastic about opening this thing up, has anyone come across this issue before and had a solution? Most of the threads about this I've seen online have basically died with no resolution.
|
|
#
?
Aug 25, 2017 18:43
|
|
|
Sounds like you've already ruled out software.
|
|
#
?
Aug 25, 2017 18:56
|
|
|
thebigcow posted:Sounds like you've already ruled out software. So I did a little digging on my device, and I noticed in the logs that a lot of my devices were requesting DHCP addresses very often. Some chucklefuck (me) had dropped DHCP lease times to 10 minutes for some reason. I jacked the lease times up to a week, and suddenly my interfaces stopped flapping... ¯\_(ツ)_/¯
|
|
#
?
Aug 25, 2017 20:28
|
|
|
In relation to MaskPumpkin's stuff earlier, what does the ending of these mean/do? add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=LAN new-connection-mark="DSL Connection" per-connection-classifier=both-addresses:2/0 add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=LAN new-connection-mark="3G Connection" per-connection-classifier=both-addresses:2/1 I don't understand the both-address:2/0, and 2/1, anyone shed some light?
|
|
#
?
Aug 29, 2017 22:15
|
|
|
https://wiki.mikrotik.com/wiki/Manual:PCC It's a way of splitting traffic up
|
|
#
?
Aug 29, 2017 22:17
|
|
|
Atreus posted:In relation to MaskPumpkin's stuff earlier, what does the ending of these mean/do? It took me a bit of puzzling too, but basically (in this case) PCC will add the from and to address together, divide by 2, and put the one half through one link and the other half through the other. I should have updated my export though, since this meant that traffic was being divided evenly between the two connections. While this sounds great, it doesn't allow for either of the links being down, or that one link is faster and should get more traffic, or that SSL in particular really doesn't like seeing your session split between different IPs. In my case I opted not to use PCC at all, but you could probably get around the SSL issue by using just src-address instead of both-addresses.
|
|
#
?
Sep 1, 2017 11:23
|
|
|
Masked Pumpkin posted:While this sounds great, it doesn't allow for either of the links being down, or that one link is faster and should get more traffic, or that SSL in particular really doesn't like seeing your session split between different IPs. In my case I opted not to use PCC at all, but you could probably get around the SSL issue by using just src-address instead of both-addresses. SSL will be fine in the above case - you're matching on the ip addresses, not the port numbers, so the pcc calculations will be the same each time. Also, the pcc calculation is not per packet - you're only doing it at the beginning of the stream and then marking the stream to be sent out whatever path.
|
|
#
?
Sep 2, 2017 15:56
|
|
|
unknown posted:SSL will be fine in the above case - you're matching on the ip addresses, not the port numbers, so the pcc calculations will be the same each time. That's a good point - it is an odd one, since I kept getting SSL errors from the proxy server that Google could give no advice on other than 'don't use a proxy', and went away when I switched off PCC. I can't remember exactly what the error was, but if I get the chance I'll try it again and let you know.
|
|
#
?
Sep 4, 2017 08:18
|
|
|
A local ISP has gone completely IPv6 and of course I have a bunch of Mikrotik routers in use with no IPv6 configured. Is there a go-to script that enables it properly, sets up a DHCP pool, and enables the Firewall with a standard set of rules? I would be incredibly appreciative if someone could help.
|
|
#
?
Sep 11, 2017 16:15
|
|
|
There might be something on the Wiki, but I don't have anything. Make sure you allow ICMP on the input chain and forward chain or things will break in interesting ways. I drop other inbound connections on the forward chain unless they are established or related
|
|
#
?
Sep 11, 2017 17:22
|
|
|
thebigcow posted:There might be something on the Wiki, but I don't have anything. Right, I do remember all that. I have a working config on my own personal router. Maybe I'll just export it and trim out the junk.
|
|
#
?
Sep 11, 2017 19:03
|
|
|
I work for a WISP and we just did a big upgrade in our core a few months ago- 4 CCR-1072 running in full mesh with iBGP. The company has been using Mikrotik in the core with minimal issue for years as far as I'm aware. I personally don't have a ton of experience with the gear though outside of the past year that I've been with the company. The new core runs ok for a couple weeks at a time but I get these intermittent reboots on the core routers. To clarify, I have two "edge" routers that peer with our upsreams and are entirely focused on doing so, and the core routers peer with them and our internal OSPF network where our customer reside. For whatever unholy reason the latter will, as I said, reboot entirely at random. This has immediately led to me discovering that there's a lot of information hidden in the autosuppout.rif that can only be read by Mikrotik Support, which frankly makes me never want to use their gear again. They have been taking forever to responds and have been entirely unhelpful after doing so, generally just wanting me to update the firmware without any clear reason as to why this may help. There's really no point to this post aside from me venting to people that might understand my pain, unless somebody in here is either really knowledgeable about this stuff or has access to view the full autosuppout.rif file. I'm just getting really frustrated and regretting our decision to not spring for Cisco or Juniper gear.
|
|
#
?
Sep 13, 2017 00:10
|
|
|
Pendent posted:I work for a WISP and we just did a big upgrade in our core a few months ago- 4 CCR-1072 running in full mesh with iBGP. The company has been using Mikrotik in the core with minimal issue for years as far as I'm aware. I personally don't have a ton of experience with the gear though outside of the past year that I've been with the company. The thing about Mikrotik gear is you save (a poo poo LOAD) money upfront but don't even pretend you will get enterprise class support. Is it a tradeoff that is worth it? Up to your company. I think the Cloudcore routers are different (ARM) SOC based. Of course this means they have a lot more horsepower I think this is a new arch for Mikrotik and there are bugs. This is probably why they want you to upgrade firmwares without reason. Bugs and more bugs. If I am completely full of poo poo, feel free to chastise this statement. redeyes fucked around with this message at 00:21 on Sep 13, 2017 |
|
#
?
Sep 13, 2017 00:18
|
|
|
redeyes posted:The thing about Mikrotik gear is you save (a poo poo LOAD) money upfront but don't even pretend you will get enterprise class support. Is it a tradeoff that is worth it? Up to your company. This actually reminds of another little factoid I've discovered that is really turning me off to using these things in our core. Given that the 1072 is the most badass router that they produce with 72 cores, one would expect you would mostly see them in places where BGP might be a major consideration. I found out to my utter horror that these things will only run the BGP process on a single CPU core which is now pegged at all times with only a small handful of upstream peers. We tried tweaking our timers a bit and it absolutely wrecked everything across the core, with constantly flapping sessions. I'm looking at trying to use BFD to improve recovery times in a failover situation but I'm afraid this will just break things even worse. This was never a real issue in the past because we only had a pair of upstream providers and no access to peering exchanges or anything. We put a lot of effort into getting access to some of the local exchanges for cheaper transit etc and are finding that our hardware just doesn't work that well for what we want. I ended up having a long conversation with one of their official certified trainers about the issues we were having and he told me (to paraphrase since it's been a few months) "Yeah, don't tell anybody I told you this since I'm supposed to be one of their advocates but I would never trust these things with anything important. Tower sites? They work great. Anything bigger than that is just asking for trouble though." Pendent fucked around with this message at 00:30 on Sep 13, 2017 |
|
#
?
Sep 13, 2017 00:28
|
|
|
HAHAHA  Condolencesjesus, I really only use them in SOHO poo poo, minor non-critical situations
|
|
#
?
Sep 13, 2017 00:30
|
|
|
redeyes posted:HAHAHA For SOHO I feel like they'd be really solid, in all fairness. I'm just bitter right now because I killed myself for literally months designing, building and migrating to this new core and now we're having issues not due to any flaws with my design or configuration but due to lovely software. On the plus side I guess this will might convince my boss to make the leap to Cisco sooner rather than later.
|
|
#
?
Sep 13, 2017 00:40
|
|
|
I haven't used Mikrotik in years, but chimed in on a thread / opened a ticket for an ospf3 bug back in 2011 which effectively makes it impossible to setup IBGP ospf3 with loopback addressing. Anyway, this thread inspired me to see if it's fixed yet https://forum.mikrotik.com/viewtopic.php?f=14&t=51124 .. of course it's not. Also, anyone remember that time that RouterOS caused a significant internet outage because the OS allowed some Czech provider to prepend 47868 times? https://dyn.com/blog/the-flap-heard-around-the-world/ https://dyn.com/blog/longer-is-not-better/ At least everyone double checked their as-path limits after that.
|
|
#
?
Sep 13, 2017 01:34
|
|
|
Don't use Mikrotik for BGP like ever. Invest in a cheap Juniper for that.
|
|
#
?
Sep 13, 2017 17:36
|
|
|
I could've sworn I was saying earlier in the thread that the bgp was single threaded and take 5+min to process a single full table. you can't even do a route look up as it scans the full routing table record by record for the one you want (Ie 1+min lookup). route removal is the same.
|
|
#
?
Sep 15, 2017 04:09
|
|
|
Yeah, now that I know to look for it there's a bunch out there about how poo poo these things are for BGP. I had an opportunity to push harder to Cisco and I really regret not doing so. It just seemed at the time like our CCR-1036 was doing a pretty solid job and there is obviously a considerable price difference. It turns out that having two really stable peers on a single router is not nearly as hard as having several peers over some suprisingly unstable DWDM transport circuits. We're slowly coming to the conclusion that we're just going to buy an ASR. Live and learn, I guess.
|
|
#
?
Sep 15, 2017 04:18
|
|
|
Dont rule out Juniper MX if / when you ever do re evaluate.
|
|
#
?
Sep 15, 2017 13:08
|
|
|
The only real reason to buy the larger Mikrotik boxes is to put them somewhere where they are doing BGP, and they are poo poo at it. I've lost count of the amount of times that the next major RouterOS version is going to fix it, and will definitely be out soon.
|
|
#
?
Sep 15, 2017 23:19
|
|
|
The only role I'd use the bigger CCRs in is a BGP-less core for MPLS. If you can keep everything on the fast path with minimal control plane churn, they seem like a pretty solid value. Use Cisco or Juniper for large table BGP edge, and Linux servers for iBGP route reflectors if your network needs BGP-signalled VPN or VPLS.
|
|
#
?
Sep 16, 2017 00:27
|
|
|
Pendent - you haven't overlooked anything and it's not you, man. MikroTiks do very well in special cases - cheap CPEs, low-end routers with big router features - but they fall over and die when you expect them to work like the big name gear. It's super frustrating because you save a ton of money right up until you hit the brick wall of trying to get them to work properly with some of the more advanced routing features they offer. Time to pay the Juniper/Cisco tax. Or just upgrade to their latest half-tested firmware and roll the dice! 
|
|
#
?
Sep 25, 2017 02:35
|
|
|
CuddleChunks posted:Or just upgrade to their latest half-tested firmware and roll the dice! I actually just did this the other night, funnily enough. It definitely feels like we're going to be upgrading sooner rather than later. We have some more money available than we did previously so it really feels like the big name gear is in the cards. Pendent fucked around with this message at 03:06 on Sep 25, 2017 |
|
#
?
Sep 25, 2017 02:48
|
|
|
Anyone know if a p2p bridge using some SXT units would pass VLAN stuff without extra config?
|
|
#
?
Sep 27, 2017 18:32
|
|
|
redeyes posted:Anyone know if a p2p bridge using some SXT units would pass VLAN stuff without extra config? IIRC 802.1q VLAN tagging is not part of the 802.11 wifi spec, so probably won't work. more specifically: 802.11 wifi network frames do not have space in the header for 802.1q VLAN tagging bits. The way most "enterprise" wifi deployments separate VLANs over wifi is to use separate SSIDs per VLAN and then tag ingress/egress packets matching that SSID when it bridges back to ethernet links, a la Meraki, Ruckus, Aruba, Ubiquiti etc. CrazyLittle fucked around with this message at 18:39 on Sep 27, 2017 |
|
#
?
Sep 27, 2017 18:36
|
|
|
redeyes posted:Anyone know if a p2p bridge using some SXT units would pass VLAN stuff without extra config? Yes, they will pass VLAN tags from interface to interface using a stock/boilerplate Layer2 PtP config. I've got several in the field that pass about 300 VLANs each.
|
|
#
?
Sep 27, 2017 18:41
|
|
|
If you can deal with the lower MTU, you can use Ethernet over IP. https://wiki.mikrotik.com/wiki/Manual:Interface/EoIP edit: ^^^ Oh good. IIRC the 802.11 spec suggests ways to do bridging but doesn't have all the details so everyone's is a little unique.
|
|
#
?
Sep 27, 2017 18:45
|
|
|
thebigcow posted:If you can deal with the lower MTU, you can use Ethernet over IP. Agreed, everyone is definitely unique. However, both Mikrotik and Ubiquiti(at least on the broadband side, dont think UniFi will) will pass VLANs across their wireless links. Mikrotik even supports Q-n-Q if for some reason you feel the need to do that.
|
|
#
?
Sep 27, 2017 18:52
|
|
|
Huh, OK. Something about my network is not passing my VLAN tags to my main managed HP procurve switch. I just can't figure out wtf. Probably me bungling something Mikrotik I am sure. I have a unmanaged Procurve hanging off my main router and was thinking it was not passing VLAN tags but from researching that seems unlikely.
|
|
#
?
Sep 27, 2017 19:06
|
|
|
Wondering why I hadn't seen an update on the bugfix chain in months I wandered over to the MikroTik forums. I still don't have an answer, but they announced a product called the "Wireless Wire". Proprietary 60ghz ptp that "can even work through most windows". https://forum.mikrotik.com/viewtopic.php?f=21&t=125603
|
|
#
?
Oct 7, 2017 20:32
|
|
|
thebigcow posted:Wondering why I hadn't seen an update on the bugfix chain in months I wandered over to the MikroTik forums. I still don't have an answer, but they announced a product called the "Wireless Wire". Proprietary 60ghz ptp that "can even work through most windows". Excellent product. Got to peek at one about a month ago. Limited use cases, though. Outdoor direct line of site range is at most 500ft, with a very very low fade margin. Effective official rated range is like 300-400ft. Great alternative if you need to beam a link to a garage or a neighbors house or just dont want to string a cat5 cable somewhere inside. 60ghz, as a rule of thumb, doesn't travel through walls or other materials very well. Glass will work but it will cut your range down a bit.
|
|
#
?
Oct 8, 2017 01:51
|
|
|
I'm more interested in how they auto connect. 802.11ad is an actual ethernet standard so there will be other radios that can listen.
|
|
#
?
Oct 8, 2017 16:21
|
|
|
|
| # ? May 22, 2024 11:07 |
|
|
zennik posted:Excellent product. Got to peek at one about a month ago. Huh, I hadn't really considered point to point use case. My main internet connection is 2 SXT AC units point to point around 500ft. Wonder what kind of link speed it could maintain.
|
|
#
?
Oct 8, 2017 17:41
|
|