вторник, 12 июня 2018 г.

OSPF: Area range vs Summary address




It seems like an easy one! I mean what could be so hard about area range and summary address command? You will be surprised how many people tend to forget this things or to apply them when not necessary or even worst where is their place to be added. It’s basic knowledge, but sometimes exactly this basic knowledge give us headache.
In the following line, I will try to explain briefly the difference between Area range and Summary address command. First let’s have a look at the following topology:
We have mixed network domain with EIGRP and OSPF. From documentation we know that along other routers in OSPF domain we have 2 important routers:
ASBR (Autonomous System Boundary Router) – One device at the edge of OSPF domain, that receive routes from another non-OSPF domain (e.g. RIP, EIGRP…)
ABR (Area Border Router) –
 One device inside the OSPF domain that assure Inter-area communication (e.g. area 0 and area 1)
You will find situation when only one physical device will be ASBR and ABR router. The functionality and rules remain the same, just that instead of having 2 device you have only one that connect to another non-OSPF domain and in the same time to multiple OSPF areas.
Why we would use this 2 commands? Well one simple explanation is that we want to summarize advertised subnets to reduce the total number of routes present in the routing table. Less routes means less overhead and load for a router.
Let’s have a look to the routers presented in the above topology. The dynamic IP routing protocols (EIGRP and OSPF) are already configured and functional. For the IP network clouds, I have used Loopback interfaces.
R1:
R1 - Interfaces and EIGRP config
On R1 the 2 IP subnets (192.168.1.0/24 and 192.168.2.0/24) are present in EIGRP routing protocol.
R2:

On R2, there is already a basic redistribution between OSPF and EIGRP. Also notice that the IP subnet which connect R2 and R3 is routed in OSPF area 0 (zero)
R3:

As well on R3, the IP subnet between R2 and R3 is present in OSPF area 0 (zero) and the other 2 subnets (10.10.1.0 /24 and 10.10.2.0 /24) are in OSPF area 1 (one). Now, if you remember from my older post, if you have a Loopback interface with a IP address (doesn’t matter what netmask) this will be always advertised in OSPF as /32. I did a little trick to be sure that they are still advertised in OSPF as presented under Loopack 1 (10.10.1.1 /24) and Loopback 2 (10.10.2.1 /24). You want to know how, check this post.
Until now, we saw how the routers are configured. Let’s have a look how the routing table appear now on this routers.
R1:

Among other routes, please notice that we receive the 2 networks from R3 each of them with a /24 prefix. Keep this in mind as it’s important for later.
R2:

On R2 we have both the EIGRP and OSPF routes, each with a /24 prefix. In some minutes we will change this. Let’s check the last router.
R3:

Here we have the 2 prefixes from EIGRP domain, again with /24.
After reviewing all the necessary information let’s apply the configuration. I will start with Area range command. For example in our case we want to advertise only one subnet from Area 1 to Area 0 in OSPF. We will combine the 2 x /24 subnets in one /22.
Why /22 and not /23? Because we have 10.10.1.0 /24 and 10.10.2.0 /24 and 10.10.1.0/23 will not be a valid prefix. Keep in mind that you have to stick to the subnetting rules. Indeed with this /22 we will “catch” also 10.10.0.0/24 and 10.10.3.0/24 in our range, but being in a test environment this is  not a problem for now. In the real world you have to take care about discontinuous networks and to apply summarization only when it’s possible.
On  our R3 router we should apply the following configuration:
R3
configure terminal
router ospf 1
area 1 range 10.10.0.0 255.255.252.0
If we check now R2, we should see:

Only one /22 subnet. IP subnet summarization is successfully taking place.
What about Summary address command? Remember that we redistribute from EIGRP into OSPF, so if you have a look about, right now in the OSPF cloud we have 2 /24 subnets imported from EIGRP domain. We want to summarize this 2 addresses in a /22 (the same reason like explained above). For this we will use the Summary address command. In short explanation, this command is only used on ASBR routers, when you want to summarize IP subnets imported from a non-OSPF domain.
On R2, we a apply the following configuration:
configure terminal
router ospf 1
summary-address 192.168.0.0 255.255.252.0
Let’s check what we receive on R1 and R3 after summarization:
We could see clear the advantage. Summary route 192.168.0.0/22 is present on R3 and again 10.10.0.0 /22 is on R1. This is the nice part and we achieved what we wanted.
Very important!
What about the blue line? That a big problem. Maybe your idea was that I did some mistake when using .1. and .2. in the third octet the subnet. It was more easier to use .0. and .1. and then I could summarize easy with /23. But I wanted to show you a hidden danger which lies beyond the summarization. Remember that I said I did just a basic redistribution  between EIGRP and OSPF? Forget that! In test environment is OK, but in real ones not. Always try to reduce the amount of redistributed subnets between 2 domains to only the necessary one using route-maps or route tagging. This should be mandatory, when redistributed summarized networks which are discontinuous.
Back to the blue line. We redistribute from EIGRP to OSPF, where we did the summarization. Due to the fact that we used 192.168.1.0/24 and 192.168.2.0/24 we had to summarize to /22, which include also the non-present subnets 192.168.0.0/24 and 192.168.3/24. Then we redistribute from OSPF to EIGRP. See the loop? EIGRP-OSPF-EIGRP. Since EIGRP see there a /22 prefix which include the 2 additional /24 subnets 192.168.0.0 and 192.168.3.0 of which R1 has no clue about, the router install this route in it’s routing table, thinking that R2 is the gateway for the 2 prefixes above. It sound complicated but I tried to simplify the explanation as much as I could. If we were using route-maps or route tagging this situation could be avoided.