ISP Routing Success through Best Practice Implementation

Part 2 of 2 – Implementation

Creating a concise, thorough, and practical guide to building a router config is not something that is easy to do in 1,000 words or less. Hopefully, I’m able to do this and make this worth your time.

Buckle up, we will be going fast as we discuss building smart configurations by avoiding common mistakes, disastrous mistakes and then land with a practical build checklist.

Avoid Common Router Mistakes

First and foremost, make sure that you not only have on-staff expertise but surround yourself with friends, co-workers and support partners who have a genuine interest in your success.

Maybe it should go without saying but looking at what your router is doing is one of the main ways to improve efficiency. If you have not mastered the regular use of the primary efficiency tools, then you aren’t very likely to have an efficient router setup. You can start by mastering the use and inspection of: 1) tools profile, 2) /interfaces, 3) /tools torch, 4) /system profile and 5) your log files!

A common culprit of CPU issues is the use of the masquerade action, especially with PPPoE concentrators. Yep, this common action should be avoided when possible. Every time an interface changes state or IP’s, the masquerade action will cause the router to have to reconcile all of its connections, purging anything related to that interface. An easy solution is to use src-nat instead of masquerade. Use masquerade when the source IP can dynamically change, just don’t overuse it.

Create solid network infrastructure by avoiding common router mistakes.

Operate on connections rather than packets. Make sure that you are not rechecking connections over and over again, especially with expensive tasks. You can murder the CPU on even high-end routers with a few poorly positioned, expensive rules. Once connections are marked, you can mark packets if needed.

Take, for example, blocking Facebook access with a layer 7 rule. Adding connection marks on new DNS lookups for Facebook can allow your router to only have to look deeply into the packet for the DNS request and then track and block all the communication related to that lookup thereafter.

Avoiding Uncommon But Disastrous Mistakes

It is a classic issue that is uncommon due to how fast exploits wreak havoc, however, don’t ever enable remote requests for DNS unless rejecting DNS queries from everyone except the hosts that you should be answering.

When using simple queues, use targets. When you don’t specify a target, your target is all traffic which means all packets must be processed by the queue. If you are using the dst option to specify your targets, then you are asking your router to do a bunch of work for no reward. One simple queue with a target of 0.0.0.0/0 can break your queues, making it capture all of your traffic.

If you have high CPU loads on your PPPoE server, you might be spamming your routers with /32 route updates. Unless required, avoid having PPPoE routes in OSPF. You don’t want to recalculate your routes every time a user’s status changes. This can be accomplished by excluding the PPPoE interface from OSPF with the passive flag. If you must include PPPoE routes in OSPF, then be sure to use stub areas to reduce the amount of information flooding through OSPF. This can cause customer speed issues and it can snowball from having overload conditions cause more PPPoE disconnects.

Learn best practices for smart router configurations.

Practical steps for building good configurations

• Understand chain, packet flow and how to get diagnostic data out of your router
• Use Smart Filter Rules
• Filter rules should be written in the proper order which means taking shortcuts, using fast tracks and working with the connecting tracking engine.
• Always accept established and related traffic before rechecking already accepted traffic.
• Where possible, use the RAW table to bypass connection tracking.
• Utilize connections for efficient packet processing whenever possible.
• Avoid overusing the address-lists as it is often more expensive than alternative solutions.
• Use src-nat instead of masquerade whenever possible.
• Don’t spam OSPF with rapid changes.
• Limit access to your router to include only the traffic that is required.
• Leave customer access open except where it makes your network vulnerable.

You can begin with an all-in-one core router but as you grow you will likely want to segment the services you run at your core into multiple routers.

You may want to block some traffic at your edge that is a potential threat to your network, like DNS & Time which can be used for amplification attacks or doesn’t belong on the Internet, like Windows local file sharing. Below is a non-exhaustive table of services that you may want to block as a standard policy for new connections on network ingress. You can always make source-based exceptions.

If you missed part one of this article on MikroTik Router Efficiencies, you can find it here.

Your may download the PDF guide here.