Page 1 of 1

Cleaning Up an OSPF Mess and Future optimizations

Posted: Thu Jun 14, 2018 10:39 pm
by rushpro

I have been working for a large-ish WISP for a number of years. I have done a lot of work with Mikrotik, however the people before me have done very interesting things with the routing. I now have some time to to properly configure the network for OSPF and maybe MPLS, however I am not sure how far I should take it.

The network is configured using OSPF on a single area. There are about 300+ routes in this area for all the internal and external blocks and there are about 100 devices talking OSPF on the network. There is also a bunch of static routes here and there to make the hacked together network work. From my understanding, OSPF was implemented by poking it until it works. Before that, the entire network was just a flat mess with no routing.

As I get started with adding new areas to start cleaning up this mess, I am wondering how far I should go. Most devices doing routing at the edge of the network are either 433GL's or Netmetals, while a few CCR1036 handle the main routing points.

My main question is, how much should I care about overhead? While implementing MPLS would be ideal, Most links only see about 20-30Mbps at peak hours, and our two main backhauls max out at about 200-300Mbps each. Just wondering what your thoughts are on the latency/CPU load.

I have seen Mikrotiks have massive performance issues in the past, yet not show it on the profile tool or CPU usage. Usually this was caused due to poorly configured routing, bad firewall rules or someone deploying a RB133C3 in the place of a RB433GL :). I am slightly worried that I might already have speed problems and not know it.

Thanks in advance!

Re: Cleaning Up an OSPF Mess and Future optimizations

Posted: Fri Jun 15, 2018 5:14 pm
by Kevo
It sounds to me like the mess is a management mess, not necessarily a performance mess in terms of bandwidth delivered. OSPF is just populating routing tables. I can't imagine it's going to have a major effect on bandwidth delivered.

Now when you say there are random static routes and things were kind of just poked and prodded until they worked, that makes me think that it's quite likely there are potential speed issues due to haphazard implementation.

How you should go about cleaning that up is a different question. If it were me, I'd probably look for any complaints and work from there. I'd also want to understand why those static routes are in place and figure out what I needed to do to make them unnecessary.

Re: Cleaning Up an OSPF Mess and Future optimizations

Posted: Tue Jun 19, 2018 8:27 pm
by rushpro
Thanks for the feedback Kevo. In my mind, there shouldn't be a performance hit at all, however with the way the majority of white papers/case studies I have read, they say things like "3x more throughput" without providing any real hard numbers. I just wanted to make sure using cheap mikrotik gear for routing wouldn't bite me in the butt. :)

Calling this a "management mess" is probably going to go down as understatement of the year for me. I have done some more digging on the static routes that are live right now. It seems that since we are only using a single area for OSPF, but we have three different fibre backhauls, the static routes are in place to force traffic to the internet rather than the "Core" OSPF device that is sharing default gateway routes. This "Core" device is also two hops away from the closest fibre backhaul.

Technically, this shouldn't be too hard to clean up, just have to bring the network down for a few hours. The hard part is restructuring all of the internal IP blocks and building a system to create area id's and router id's that actually make sense. On the plus side, I can figure that out first without messing with the network and breaking everything.