The last version of Mikrotik RouterOS that supports mipsle architecture is 6.32.x. As of this writing that appears to be 6.32.2
MTIN is excited to announce our newest support offering, Mnet. Mnet allows customers using Milkrotik and Ubiquiti routers an option of a tiered support level on a per device basis. This allows customers a guaranteed support level at a fixed price. This is an enterprise level support option for critical infrastructure.
The way Mnet works is a customer purchases one of our tiered plans below. They register the serial number with us and we simply provide the paid level of support on that device. This support includes technical support on that device as well as the services included with the purchased Tier.
Tier I (Overwatch) $199 per year (only $16 per month)
This tier is designed for the user who needs the occasional support but wants to make sure things like backups and software are being looked after.
- Basic Remote monitoring & notification of device
- Software notification of upgrades and personalized recommendations on needed action.
- Monthly configurations backup to online secured storage
- Next business day support of issues.
- Hardware replacement option available
- Initial configuration review
Tier II (Operator) $399 per year (only $34 per month)
This tier is for the user who needs that extra bit of help when it comes to configuration and wants an extra set of eyes.
Tier II includes all of the Tier I services and adds
- Weekly configuration backup via e-mail and online secured storage
- Enhanced monitoring & notification of devices
- Same business day support (6 hour maximum lead time)
- Weekend and holiday support (6 hour maximum lead time)
- Discount on consulting services
Tier III (Spec Ops) $599 per year (only $50 per month)
This tier is for absolute mission critical devices.
Tier III includes all of the previous tiers and adds
- Same day business support (2 hour maximum lead time)
- Weekend and holiday support (3 hour maximum lead time)
- Weekly backups of configuration via e-mail and online secured storage
- Quarterly review and recommendations on configuration
Do I have to get this on every device?
No, we recommend this on your critical routers or routers doing advanced services such as BGP or core routing functions.
Does this replace your normal consulting services?
No. This is an add-on to our consulting services. We find we have customers who need help with certain aspects of their network and this fills that gap.
Can I get quantity discounts?
Yes, contact us for a quote
I want to upgrade my router. How will this affect mNET?
We would simply transfer your support contract from the old device to the new one. Upgrade support is included.
What configuration support is included?
Technical support including configuration and troubleshooting is included on supported devices. Other devices can be included at our normal hourly consulting rate.
Do you make changes?
All changes are explained and signed off by customer before being implemented. Changes are done during an agreed upon maintenance window with a change management process.
How do I obtain support?
Customer is provided a login to the MTIN portal. Online tickets are the best method for opening a case. Telephone support is also included, but tickets are normally quicker.
How does the lead time work?
MTIN strives to meet customer expectations. Lead times are the maximum amount of time it will take. Some days this time may be measured in minutes, other times it may be longer.
Do you cover other devices?
Yes, we have plans for AirFiber, Mimosa, and other platforms.
Can I upgrade to a higher Tier?
yes, However it will take 3 business days for upgrades to process. During this time your Tier level will remain the same.
How is payment handled?
Payment is due at device registration.
Can I pay monthly?
No. If you need occasional support please see about hourly consultation services.
If you would like more information please fill out the form below.
So Mikrotik has a very cheap hAP Lite coming out. This is a 4 port, 2.4 b/g/n router/access point which retails for $21.95. Baltic networks has pre-orders for $18.95.
Why should you deploy this little gem and how? We have found over the years routers account for more than half of the support issues. In some networks this number is closer to 80-90%. Whether it be a substandard router, one with out of date firmware, or poor placement by the customer.
Deployment of the hAP lite can be approached in one of two ways. Both ways accomplish the same goal for the ISP. That goal is to have a device to test from that closely duplicates what the customer would see. Sure you can run tests from most modern wireless CPE, but it’s not the same as running tests m the customer side of the POE.
Many ISPs are offering a managed router service to their customers. Some charge a nominal monthly fee, while others include it in the service. This is a pretty straightforward thing. The customer DMARC becomes the wireless router. The ISP sets it up, does firmware updates, and generally takes care of it should there be issues. The managed router can be an additional revenue stream in addition to providing a better customer experience. Having a solid router that has been professionally setup by the ISP is a huge benefit to both the provider and the customer. We will get into this a little later.
Second option lends itself better to a product such as the hAP lite. With the relative cheap cost you can install one as a “modem” if the customer chooses their own router option. The actual method of setup can vary depending on your network philosophy. You can simply bridge all the ports together and pass the data through like a switch. The only difference is you add a “management ip” to the bridge interface on your network. This way you can reach it. Another popular method, especially if you are running PPPoE or other radius methods, is to make the “modem” the PPPoE client. This removes some of the burden from the wireless CPE onto something a little more powerful. There are definite design considerations and cons for this setup. We will go into those in a future article. But for now let’s just assume the hAP is just a managed switch you can access.
So what are the benefits of adding one of these cheap devices?
-You can run pings and traceroutes from the device. This is helpful if a customer says they can’t reach a certain web-site.
-Capacity is becoming a larger and larger issue in the connected home. iPads, gaming consoles, tvs, and even appliances are all sharing bandwidth. If you are managing the customer router you can see the number of connected devices and do things like Torch to see what they are doing. If a customer calls and says its slow, being able to tell them that little Billy is downloading 4 megs a second on a device called “Billy’s xbox” can help a customer. It could also lead to an upsell.
-Wireless issues are another huge benefit. If the customer bought their own router and stuck it in the basement and now their internet is slow you have a couple of tricks to troubleshoot without a truck roll. If the hAP is in bridge mode simply enable the wireless, setup an SSID for the customer to test with and away you go. This could uncover issues in the house, issues with their router, or it might even point to a problem on your side.
-Physical issues and ID10T errors can be quickly diagnosed. If you can’t reach your device it’s either off or a cabling issue. If you can reach the hAP and the port has errors it could be cabling or POE.
These are just a few benefits you can gleam from sticking a $20 Mikrotik device on your customer side network. It becomes a troubleshooting tool, which makes it money back if it saves you a single truck roll. The implementation is not as important as having a tool closer to the customer. There several vendoars you can order the hAP lite from. Baltic Networks is close to me so they are my go-to. http://www.balticnetworks.com/mikrotik-hap-lite-tc-2-4ghz-indoor-access-point-tower-case-built-in-1-5dbi-antenna.html .
This isn’t practical for business and Enterprise customers, but you should already be deploying a router which has these features anyway right? 🙂
Update: This article is not meant to be a permanent solution. It’s a way to stop the tidal wave of traffic you could be getting. Many times it’s important to just get the customers up to some degree while you figure out the best course of action.
Many of the Denial of Service (DDoS) attacks many folks see these days involve attacks coming from APNIC (Asia Pacific) IP addresses. A trend is to open as many connections as possible and overwhelm the number of entries in the connection table. You are limited to 65,535 ports to be open. Ports below 10000 are reserved ports, but anything above that can be used for client type connections.
Now, Imagine you have a botnet with 10,000 computers all bearing their weight on your network. Say you have a web-site someone doesn’t like. If these 10,000 machines all send just 7 legitimate GET requests to your web-server you can bring, even a big router to a grinding halt. Firewalls, due to the extra CPU they are exerting, are even more prone to these types of attacks.
So, how do you begin to mitigate this attack? By the time you are under attack you are in defensive mode. Someone, or alot of someone’s, are at your door trying to huff and puff and blow your house down. You need to slow the tide. One of the first things you can do is start refusing the traffic. A simple torch normally shows many of the attacking IPs, are from APNIC. If this is the case, we enable a firewall rule that says if the IP is not sourced from the below “ARIN” address list go ahead and drop it.
add chain=forward comment="WebServer ACL" dst-address=22.214.171.124 src-address-list=!ARIN action=drop
The above rule says if our attacked host is being contacted by anything not on the “ARIN” list go ahead and drop it.
Make sure to paste this into /ip firewall address-list . These were copied off the ARIN web-site as of this writing. APNIC and other registries all have similar lists. Keep in mind, this won’t stop the traffic from coming to you, but will shield you some in order to have a somewhat functional network while you track down the issues.
Some people will say to blackhole the IP via a BGP blackhole server, but if you have production machines on the attacked host taking them offline for the entire world could be a problem. This way, you are at least limiting who can talk to them.
add address=126.96.36.199/8 list=ARIN add address=188.8.131.52/8 list=ARIN add address=184.108.40.206/12 list=ARIN add address=220.127.116.11/11 list=ARIN add address=18.104.22.168/13 list=ARIN add address=22.214.171.124/8 list=ARIN add address=126.96.36.199/8 list=ARIN add address=188.8.131.52/8 list=ARIN add address=184.108.40.206/8 list=ARIN add address=220.127.116.11/8 list=ARIN add address=18.104.22.168/8 list=ARIN add address=22.214.171.124/8 list=ARIN add address=126.96.36.199/8 list=ARIN add address=188.8.131.52/8 list=ARIN add address=184.108.40.206/8 list=ARIN add address=220.127.116.11/8 list=ARIN add address=18.104.22.168/8 list=ARIN add address=22.214.171.124/8 list=ARIN add address=126.96.36.199/8 list=ARIN add address=188.8.131.52/8 list=ARIN add address=184.108.40.206/8 list=ARIN add address=220.127.116.11/8 list=ARIN add address=18.104.22.168/8 list=ARIN add address=22.214.171.124/8 list=ARIN add address=126.96.36.199/8 list=ARIN add address=188.8.131.52/8 list=ARIN add address=184.108.40.206/8 list=ARIN add address=220.127.116.11/8 list=ARIN add address=18.104.22.168/8 list=ARIN add address=22.214.171.124/8 list=ARIN add address=126.96.36.199/8 list=ARIN add address=188.8.131.52/8 list=ARIN add address=184.108.40.206/8 list=ARIN add address=220.127.116.11/8 list=ARIN add address=18.104.22.168/8 list=ARIN add address=22.214.171.124/8 list=ARIN add address=126.96.36.199/8 list=ARIN add address=188.8.131.52/8 list=ARIN add address=192.0.0.0/8 list=ARIN add address=184.108.40.206/8 list=ARIN add address=220.127.116.11/8 list=ARIN add address=18.104.22.168/8 list=ARIN add address=22.214.171.124/8 list=ARIN add address=126.96.36.199/8 list=ARIN add address=188.8.131.52/8 list=ARIN add address=184.108.40.206/8 list=ARIN add address=220.127.116.11/8 list=ARIN add address=18.104.22.168/8 list=ARIN
The GPON module allows any RouterBOARD device to be used for Fiber to Home installations without any special modems or software. A plug and play solution means you simply plug it into your device, and no special configuration is needed. It is supported by all our SFP products, with any RouterOS version – all configuration will be done on the ISP side. The GPON ONU integrates GPON OMCI Stack and is fully compliant with ITU-T G.984 standards. The ONU is in a standardized MSA SFP form-factor and is designed to simply plug into a standard SFP port in your router. The product provides a pluggable GPON ONU interface for networking equipment with an uplink SFP receptacle enabling these devices to be deployed in GPON networks for FTTx, business services, and wireless backhaul applications.
Below are some basic Filter Rules for Mikrotik BGP filtering. These are not complex and can be very easily implemented on your BGP peers.
Before we get to the code there are a few assumptions
1.Your own IP space in this example is 22.214.171.124/22
2.These filters are not fancy and are geared toward upstream ISPs, not your own internal routers or clients.
3.If you copy and paste the below code make sure there is one command per line. Some browsers will cut the line off and then it won’t paste right. If in doubt paste it into notepad, textedit, etc. and clean it up.
/routing filter add action=discard chain=INET-IN comment="BEGIN INET-IN" prefix=127.0.0.0/8 protocol=bgp add action=discard chain=INET-IN prefix=10.0.0.0/8 protocol=bgp add action=discard chain=INET-IN prefix=169.254.0.0/16 protocol=bgp add action=discard chain=INET-IN prefix=172.16.0.0/12 protocol=bgp add action=discard chain=INET-IN prefix=192.168.0.0/16 protocol=bgp add action=discard chain=INET-IN prefix=126.96.36.199/3 protocol=bgp add action=discard chain=INET-IN prefix=188.8.131.52/22 protocol=bgp add action=discard chain=INET-IN prefix-length=25-32 protocol=bgp add action=discard chain=INET-IN protocol=bgp add action=accept chain=INET-OUT comment="BEGIN INET OUT" prefix=184.108.40.206/22 protocol=bgp add action=discard chain=INET-OUT protocol=bgp
So what does this do?
-The first 6 lines filter out non routeable IP space. There should be no reason these are being advertised to you from the public internet.
-Next we are saying if we see our own IP space being advertised to us (in this case 220.127.116.11/22) discard that. There should be no reason we see our own IP space on a public peer.
-The next line filters out prefixes that are a /25 and smaller. Just about every provider out there has a minimum size of a /24 they will accept as an advertisement. If you are getting anything smaller it’s a good practice to drop that. If there happens to be smaller prefixes they can be sent to a default route to the provider. This helps trim your routing table, which makes lookups and convergence time quicker.
Under the INET-OUT rules we are advertising our IP space to our upstream.
Pretty simple eh? We could get complicated and add in chains, and more rules. But, this is a start. We will do some more advanced rules in a later post.
The fastTrack improvements are a big improvement for those of you doing such things.
What’s new in 6.29 (2015-May-27 11:19):
*) ssh server – use custom generated DH primes when possible;
*) ipsec – allow to specify custom IP address for my_id parameter;
*) ovpn server – use subnet topology in ip mode if netmask is provided (makes android & ios
*) console – allow ‘-‘ characters in unknown command argument names;
*) snmp – fix rare bug when some OIDs where skipped;
*) ssh – added aes-ctr cipher support;
*) mesh – fixed kernel crash;
*) ipv4 fasttrack fastpath – accelerates connection tracking and nat for marked
connections (more than 5x performance improvement compared to regular slow
path conntrack/nat) – currently limited to TCP/UDP only;
*) added ~fasttrack-connection~ firewall action in filter/mangle tables for marking
connections as fasttrack;
*) added fastpath support for bridge interfaces – packets received and transmitted
on bridge interface can go fastpath (previously only bridge forwarded packets
could go fastpath);
*) packets now can go half-fastpath – if input interface supports fastpath and
packet gets forwarded in fastpath but output interface does not support fastpath
or has interface queue other than only-hw-queue packet gets converted
to slow path only at the dst interface transmit time;
*) trafflow: add natted addrs/ports to ipv4 flow info;
*) queue tree: some queues would stop working after some configuration changes;
*) tilegx: enable autoneg for sfp ports in netinstall;
*) health – fix voltage on some RB4xx;
*) romon – fix 100% CPU usage;
*) romon – moved under tools menu in console;
*) email – store hostname for consistency;
*) vrrp – do not reset interface when no interesting config changes;
*) fixed async. ppp server;
*) sstp – fixed router lockup.
*) queue tree: some queues would stop working after some configuration changes;
*) fixed CRS226 10G ports could lose link (introduced in 6.28);
*) fixed FREAK vulnerability in SSL & TLS;
*) improved support for new hEX lite;
There are several reasons and benefits to using your Mikrotik as a DNS caching server. Queries to the client are just a tad faster, which makes the overall user experience seem snappier. It also allows you to quickly change upstream DNS servers in the even of an outage, attack, etc.
There are two main avenues to think about when protecting Mikrotik from DNS.
The first is the incoming port 53 requests to the router. You only want your customers to have access to query the Mikrotik. In a simple scenario we have this:.
ether1 is our upstream ISP connection. Customers are other ports. In this case if we want to block all port 53 requests from the outside world we specify the WAN interface to drop in the following code:
/ip firewall filter add chain=input in-interface=ether1 protocol=udp dst-port=53 action=drop add chain=input in-interface=ether1 protocol=tcp dst-port=53 action=drop
This will still allow your Mikrotik to send out DNS queries because they are sourced from a non reserved port. We are simply blocking the Mikrotik from not answering port 53 requests on the external interface.
In a later post we will talk about what to do if you have multiple wan interfaces or multiple exit paths on your router (say running OSPF)
/ip route print where received-from=<PEERNAME>
Replace <PEERNAME> with the name of one of your peers to show the routes received from that particular BGP peer.
another blog post will follow on this.
Need to use Winbox 3
FastPath + Connection Tracking
FastTrack Accelerates packet processing for specific connection tracking entries
Full NAT support
Works with IPv4/TCP and IPv4/UDP