You own a small WISP (Wireless Heroes) in your home town with about 200 subscribers. Up until now you have been using static routing on all of your backbone devices. You’ve grown enough that you would like to take advantage of OSPF for automatic route creation. This will allow you to add new tower sites or modify existing tower sites without having to modify that static routes in each device every time there is a change. This lab will focus on getting OSPF up and running for the first time. Although this lab will be very close to how a production network would be configured it should not be implemented exactly this way because some of the “fine tuning” that is involved with real world OSPF networks which will be not be presented until latter labs. This lab is intended to built out with MikroTik routers using Ethernet cables to simulate transparently bridged wireless links between towers. GNS3 and/ or Cloud Hosted Routers can also be used.
When this lab is finished, all of the routes needed to communicate with all devices should have populated to each router’s routing table. You should be able to ping each device and winbox into each device when it is all done. The following concepts will be introduced:
a) Adding networks to OSPF
b) Redistributing connected routes
c) Redistributing default routes
e) Routing Filters
Tested on ROS 6.34
9 MikroTik Routers (required)
9 Ethernet Cables (Required)
1 Connection to the Internet (optional)
Since this is a network upgrade, IP addresses have already be created and are part of the initial configs. The static routes that would otherwise have been present are missing so that when OSPF is running, it will be running all by itself and the static routes won’t be adding confusion to the troubleshooting. The Gateway Router will receive an Internet connection on Ether1 via DHCP. You will have to plug directly into each router to setup the initial config. You can add a LAN subnet to the routers for ease in connecting to them, but the LAN has not been pre-configured for you.
Steps to Complete This LAB:
Physically layout the network and connect the cables. Reset all router and remove any default configurations. Copy and paste the initial configurations for each router into a terminal window.
Build the Loopback into each router and assign the appropriate IP address to the Loopback. A loopback is a “free floating” interface that we can reach the router through. In this example, we are using a bridge interface without any ports as the Loopback. 95% of the time loopbacks are assigned an IP address with a /32 subnet, although they don’t have to always be a /32. In this lab, we are not actually gaining anything by using the loopback, however using loopbacks are a best practice approach and they will become necessary in future labs. This loopback IP address will be the address through which we communicate to the router instead of using the IP addresses that are assigned to their physical interfaces.
Set the Router ID to the Loopback address in OSPF. This is the address that the other routers will see and report this router as. To set the Router ID, go to OSPF -> Instances and edit the defualt instance.
Add the Networks to OSPF. Now we are going to tell each router which subnets will be participating in OSPF. This is done in routing -> OSPF -> networks. We are only going to add the subnets which OSPF will be running on and the Loopback address. This has to be an exact subnets, you can not aggreate subnet in the network statements. For example: The gateway router has 6 subnets for the lab plus 1 LAN subnet as follows:
Ether3 = 10.10.10.0/30
Ether2 = 10.10.10.8/30
Ether5 = 10.10.10.16/30
Ether4 = 10.10.10.24/30
Ether1 = 192.168.1.0/24 (Brought in through DHCP for Internet connectivity)
Ether8 = 192.168.88.0/24 (LAN Subnet)
Loopback = 172.16.0.1/32
The networks for Ethernet ports 2,3,4,5 and the Loopback subnet will be added, but the subnets for Ethernet ports 1 and 8 will not be handled until latter.
Repeat steps 2-4 for all of the routers. Now its time to check our work. First we want to check the adjacentcy by going to routing ->OSPF ->neighbors. We should see all of the other routers we are connected to and their state should be “Full”. You may see other states like “int” or “2-way” while the connection is being established, but within a minute or two it should settle on “Full”. Anything else indicates a problem.
Now we want to check the routing table in IP -> Routes. We are using 8 subnets to communicate between the nine routers, 9 Loopback subnets, one subnet to reach the Internet, and one subnet for our LAN. Some of the subnets will be DAC (Dynamic Active Connected) routes, but the other routes we are using to communicate between the routers and the Loopback routes should be DAo (Dynamic Active OSPF) routes. Sort the routes by DST address and make sure all of the subnets are there. If any are missing, check the connection between those routers and look for typos. Typos and Layer 1 problems will be the most likely culprits if something is wrong.
You will notice at this point, that all of the subnets (minus a defualt gateway and our LAN subnet) should be present on all of the routers. All of the routers should be able to ping each other.
Redistribute the default route and connected routes. At this point we are not able to winbox into each router without moving our cable. The reason for this, is that the other routers we are not physically connected to do not have a route to our LAN subnet. They are also missing a default route to be able to access the internet. To redistribute these routes we go to routing -> OSPF -> instances and edit our default instance. We will want to redistribute our default route as Type 1, which means that the sum of all internal and external costs is taken into account. (Type 2 means to use the external costs, internal costs are trival. Since we don’t have any external decisions to make, this wouldn’t work for us.) Once that is applied all of the routers should receive a DAo default route and should be able to ping out to the Internet. If you have the route, but can’t reach the Internet, double check the masquerade rule in the Gateway Router.
Next we will redistribute the connected routes as Type 1. Once we have applied this setting, we should now be able to winbox into all of the routers without moving our cable anymore. If this were a real WISP, there would be additional subnets on each Tower Router for the APs (Access Points) and our customers. This setting will build out the routes to those subnets as well, providing the two way connectivity they need to reach the Internet and everything on our network. Why not add everything to the networks tab or use the connected setting for everything? In the networks tab we are telling OSPF what subnet (which equates to which interface) we are going to run OSPF on. It then starts sending and listening for “Hello” packets on those interfaces. This would have worked if we had added all subnets to the networks tab, but we would have introduced a very serious problem as a result. Every time there is a network change on any interface/ subnet that is participating, all of the routers rebuild their routing tables. That means, for a moment, (maybe even a couple of minutes depending on the size and complexity of the network) the routing table is empty and no one can communicate. This would happen every time we added a new customer, lost a customer, or had a customer cycle the power on there equipment. Only our backbone subnets go in the networks tab. Everything is treated as a connected route.
Apply Routing Filters. As our network is configured, every subnet on every router is advertised to the entire network. Sometimes, we really don’t want to do that. For example, I may need to add a pair of /30 addresses across a tunnel to test connectivity. If OSPF built routes to those subnets, I would get a false positive when I tried to ping across the tunnel. Routing Filters can remove unwanted subnets that are being advertised out or that are coming in. To see this work, add a new subnet to the Gateway Router (I used 192.168.50.0/24 for this example). Since we are advertising all connected routes, we should see that route populated in all of the other routers. Now go to Routing -> Filters and create a new rule. Use the following syntax:
add action=discard chain=ospf-out prefix=192.168.50.0/24
Filters only apply to the router they exist on and are not populated to other routers. The rule that we just created prevented the Gateway Router from advertising that subnet and we saw the change occur on all of the Tower Routers. Conversley, sometimes we want to exclude a router from receiving a subnet. To see this work, disable the rule on the Gateway Router, and create this new rule on one of the Tower Routers:
add action=discard chain=ospf-in prefix=192.168.50.0/24
Pros to this Approach:
OSPF is usually the best choice for networks which have more than one routed segment. Not only does it provide automatic route creatation, it can also provide failover, load balancing, and be used to communicate with other routing protocols.
Cons to This Approach:
The only con to this approach is that cost, security settings, and network types were not taken into consideration. Those peices are included in other labs.