Hello, In this document, I am going to represent how DR is elected in different cases. I have to skip some pictures since there would be so many pictures to demonstrate all the cases. I will try to explain them. In general, there will be the following cases when a router is selected as a DR. 1: There is no other OSPF router in the segment. 2- There is a DR in the segment and other routers join later after waiting state. 3- There are two or more OSPF routers coming up at the same time (During the waiting state) 4- There are two DRs in a segment. First, I am using the following topology for my presentation. With just looking at the topology, we say that R3 would be elected as a DR because it has higher IP address compared to other routers but it is not always the case. Just to mention priority is default on all interfaces. Lets talk about about the first case. I shut down R2 and R3 interfaces. Only R1 is presented in the segment. In broadcast and non-broadcast network type, we have DR and BDR election. It is said BDR is elected before DR but it is not important in this presentation. When we enable OSPF on broadcast or non-broadcast interfaces, we see DR, BDR fileds in hello packets. When a router comes up, it advertises 0.0.0.0 in DR and BDR fields in hello packets as you see in the following picture. It waits for 40 seconds in broadcast network ( default dead interval is 40 in broadcast) and then elects itself as DR and then continues sending hello packets specifying itself as DR in the DR field in hello packets.  The waiting timer (or state) is equal to OSPF dead interval on the interface. As you see in the picture above, at 15:40:31 interface comes up and at 15:41:11 waiting state ends and R1 elects itself as DR. Now, If I unshut R2 interface, R2 will be elected as BDR and both R1 and R2 will send hello packets. In their both hello packets, 172.16.1.1 is in DR field and 172.16.1.2 in BDR field.  Now, I unshut R3 interface. In this case, R3 receives hello packets but DR and BDR fields have already entries. R3 does not wait for wait state timer. It agrees on R1 and R2 being DR and BDR and goes directly for DBD exchange even though it has higher interface IP address (eligible to be DR). DR and BDR election happens before DBD exchange. We can say it is after two-way communication but in the first case, we saw that R1 elects itself as DR before receiving any hello packets(before going to two-way state). So far we have discussed case 1 and 2: Case 3: Lets talk about a case when several routers come up at the same time. In this case they all send hello packets with 0.0.0.0 in DR/BDR field. They all wait until waiting state ends and then elect DR and BDR. The result is going to be the same if one router comes up a little later during the waiting state. In the picture above, you can see R1 and R2 become DR and BDR after 40 seconds when Wait on the interface ends. ( Sometimes, we see it takes longer than usual in order for routers to become adjacent. one of the reason is Waiting state in DR election) Case 4: We noticed that when there is already a DR in the segment, there will be no election(current DR remains) but what if there are two DRs in the segment. In some cases it happens. I will explain it with the following topology: In the topology above, R2 is DR for the R1/R2 segment and R4 is DR for R3/R4 segment. It means in their hello packets, DR and BDR field have already entries. Now, we connect these segments. In this case, routers go for election process, but they do not wait for Wait state. R4 will be selected as DR and R3 as BDR after a few seconds. so we see we have preemption in election in some cases.  To refresh your memory OSPF state machine has different phases Init two-way Exstart (Master slave elect happens here) Exchange Full Adjacency. As I mentioned before, DR and BDR election happen before Exstart. I hope it was helpful. Best wishes. ... View more

Hello everyone, In this document, I am going to present how outbound route filtering can efficiently filters routes without occupying link bandwidth. I am going to use two simple methods to filter BGP routes and then introduce ORF. The following topology is used for this presentation. I used the terms ISP and customer in my example; however, this feature can be applied everywhere. In my example, ISP is advertising 3 subnets but customers is not interested in receiving 192.168.10.0/24. The current ISP configuration: Customer's routing table before applying any filtering. All 3 subnets are in the routing table. The easiest was is filtering 192.168.10.0/24. in customer site using prefix list. I applied the following configuration to the customer's router. I added a prefix list and applied that prefix list inbound under BGP in customer site. lets see the customer's routing table after applying the prefix list. 192.168.10.0/24 is not seen anymore in the routing table. So far so good, but the issue is it is waste of the link bandwidth between customer and ISP and also CPU processing in customer side if there are many routes that need to be filtered. We can filter the routes in ISP side. in this way, ISP does not advertise those routes and customer does not have to process and filter the routes locally. It is simple. We apply the same configuration on ISP's router but in outbound direction. Lets see the customer's routing table after applying the configuration. We achieved the same result. What if we do not have access to the other site. The other side might be under control of another administration groups  so we have to make a request each time or may be charged for each request. in this case, ORF comes to play. It is a great feature applied locally and filtering is done on the other site. We configure prefix list locally and prefix list is sent to the remote router and remote router filters the routes. ORF is a capability so we need to activate it first with specifying the direction. Customer is sending prefix-list and ISP receiving that. The configuration in customer's site is as follows: As seen in the picture above, I configured the same prefix list and applied it in inbound direction. The configuration is similar to filtering routes locally but in fact prefix list is sent to other side and filter is applied outbound in ISP. The configuration in ISP is simple and done only once. We just need to activate ORF feature. I used "receive" since ISP is receiving the prefix list Now, lets make a change in customer's router. I simply added a line to the prefix list to filter 172.16.1.0/24 as well. For the change to take effect, we need to clear BGP session inbound but with adding prefix-filter at the end. Customer#"clear ip bgp 1.1.1.1 in prefix-filter" Lets see the effect in the customer's routing table. As seen, only 192.168.1.0 is in the routing table. ISP can also verify the received prefix list by issuing the following command. Please rate if it is helpful. Best wishes. ... View more

Hello everyone, In this document, I am going to present how prefix suppression in a WAN topology with many transit links can reduce the size of the routing table. In a WAN topology with many routers and almost full-mesh, there will be many transit links. From a router perspective, having routes for all the transit links is unnecessary. A router just needs to know the next hop to be able to forward the packets as opposed to having entries for all the transit links. In MPLS VPN environment, this feature is more applicable since only loopbacks of PE routers are used as the nexthops. First , I will demonstrate the result of applying this feature and then I will explain how OSPF achieves that. I am using the following topology for my presentation. In R1 routing table, 2.2.2.0, 3.3.3.0 and 4.4.4.0 are seen; however, R1 only needs to know the loopbak address of R2 and R3 and also stub networks behind them if any. I should mention, I have configured OSPF on all 3 routers and all interfaces are in area 0. Lets see R1 routing table. As shown, R1 has entries for all transit links. In a WAN environment, transit links are never used so R1 does not need to receive those entries. OSPF prefix suppression can be apply globally or under each interface. If it is applied under each interface, only prefix under that interface will be suppressed. here you see how OSPF suppression is applied globally or under each interface. Router OSPF 1 prefix suppression interface x/x ip ospf  prefix suppression. In the following picture, you see how prefix suppression can be applied globally or under the interfaces. I applied the commands on the R2 and R3 since I wanted to suppress transit links between R2 and R3. In the following picture, you see the routing table on R1 after applying prefix suppression globally on R2 and R3. Now, only R1 just have entries for loopback interfaces as well as its local links(1.1.1.0/24 and loopback) Lets see what changes OSPF make to suppress the transit links. There are two cases. First, the network type of transit links is broadcast. In this case, R1 receives two LSA types. LSA type 1 from R2 and R3. By LSA type 1, each router advertises its own links. LSA type 2 is advertised by DR. I am showing the result only for 2.2.2.0 subnet. It is the same for all other transit subnets too. In my case, R2 is a DR. R2 advertises 2.2.2.0 and its subnet mask as well as which routers are connected to this links. If you pay attention, you see the subnet mask for this link is 24. Lets apply prefix suppression and check the topology table on R1 again. Now you see the change after applying the command on R2 and R3. DR(R2) now advertises 2.2.2.0/24 with the subnet mask of 32. R1 now knows that it should not install that subnet in the routing table because suppression has been applied. Case 2 is for OSPF point to point network type. In point to point network type, there is no LSA type 2 generated so OSPF is relying on LSA type 1. Lets see the OSPF database for 2.2.2.0 on R1 before applying the prefix suppression feature. I applied IP ospf network type point to point on R2 and R3 under transit interfaces. The following picture shows the output of "show ip ospf database" on R1. R1 receives LSA type 1 from R2. There are two entries for point-to-point links. First, the ip address on the link and its neighbor and second the subnet and subnet mask of the link. ( just output for 2.2.2.0 is shown) Now you can guess how OSPF can suppress point to point links. The following picture shows the output of show IP ospf database on R1 Now, if you check the difference, you notice that the second entries for the point to point links do not exist anymore. It means that R2 and R3 do not advertise the second entries. Since R1 do not have subnet mask for transit links, it does not install the subnets in the routing table. You may ask why R2 and R3 are not suppressing those link completely. The answer is simple. OSPF needs to receive LSAs for all the link to be able to create shortest path tree and calculate metric. Just to mention, the behavior in OSPF v3 is different because more LSAs were introduced in V3. Please rate if it was helpful for you. Wish you the best. Masoud ... View more

Hello everyone, In this document, I am going to represent how Route Target Constraint (RTC) can highly reduce the number of routes advertised by route reflector to route reflector clients in MPLS VPN environment. The configuration is very simple but the result is very effective. Prerequisite: basic MPLS VPN configuration. By default, route reflectors advertise all routes to the route reflector clients even though clients do not have the corresponding VRFs. By applying Route Traget Constraint, RRs only send wanted routes to the clients. Wanted means that clients have corresponding VRFs so they can install the routes in the routing table. RTC is a capability in BGP. When BGP comes up, a client sends its route-target information to RRs so route-reflectors know which routes they need to advertise to the clients. I am using the following topology for my presentation. As you see in the topology, R3 has VRFs red and green but R3 has only VRF red. The following picture shows VRF configuration on R1. VRF configuration on R3. R3 has been configured with only VRF red. If we check the routes advertised by route reflector(R2) to R3 which is a route reflector client, we see that R2 is advertising 172.16.31.0/24 to R3. 172.16.31.0/24 is in VRF green and R3 has not been configured with VRF green. For R3, 172.16.31.0/24 is an unwanted route. R3 receives 172.16.31.0/24 and denies it because it does not have the corresponding VRF to import it. (it does not have Route-target import equal to the route target of the route it receives) As you see in the picture, route target of 172.16.31.0/24 is 200:200. Because R3 does not have route target import 200:200, it denies the route. In some IOS clients even do do not deny the routes. They keep the routes in the BGP table because denying these routes in the RFC is optional. Now we apply RTC to R2 and R3. The configuration is simple. We need to copy whatever under the address family VPNv4 below address family Rtfilter. Default originate is automatically generated on R2. It is different from default originate in IGPs. on RRs, It just means that Route reflector clients need to send all the routes to me(RR) and I will select which routes needs to be advertised to clients based on the Route Target information I receive. The configuration on route reflector clients is the same. In our case R3. After RTC configuration, R2 does not send unwanted route to R3 as you see in the following picture. We do not see 172.16.31.0/24 in the advertisement anymore. R2 still has 172.16.31.0/24 in its BGP table. As you noticed, the configuration is very simple; however, it can highly reduce the size of BGP table in RR clients and the number of advertisements in a large MPLS environment. Just make sure your IOS support RTC before applying this feature. I hope this document is helpful for you and wish you the best. ... View more

Hello everyone, When there are two ABRs connecting two areas, we should connect them via two links. For example, if there are two ABRs between area 0 and area 1, we need to connect them through two links, one in area 0 and other one in area 1. It may cause suboptimal routing if there is only one link between ABRs. I am using the following topology for my presentation. In this topology, R3 and R4 are ABRs for area 1 and area 0. The left link between them in area 1 and the right link in area 0. I increased the cost between R4 and R1 to 1000. The result of traceroute shows that R5 takes the path with the lowest cost to reach to 99.99.99.99. In this case, the best path is R4, R3 , R2, R1(last octet in the picture) .  The path between R4 and R1 was not used because of the high cost. Lets shutdown the left link( in area 1)  between two ABRs. And then try traceroute again. The link 4.4.4.0/24 is down now. First, you would think that the other link between R3 and R4 will be used to reach R1 because of the lowest cost, but surprisingly, the link between R4 and R1 with cost of 1000 is used as you see the result of traceroute from R5 to R1. The path is R5,R4, R1. Lets make sure the other link between R3 and R4 can be taken. The link between R4 and R1 is down now. As you see in the following picture, the path between R3 and are R4 was taken. When the link between R1 and R4 is down, R4 receives inter area route(IA) from R3. If there is only one link between two ABRs, route received by R4 from R3 is an inter area route(IA) and route received from R1 is an intra area route so route received from R1 is preferred even with higher cost. When there are two links( in area 1 and 0), R4 receives Intra area routes from R3 and R1 in area 1 and inter area routes from R3 in area 0, so the best path is intra area route coming from R3 since it has lower cost than route coming from R1. Now, the link between ABRs in area 1 is down and link between R4 and R1 is up.As you see in the above picture, inter area route coming from R1 is replaced the inter area route coming from R3. In short, we should connect two ABRs through two links since intra area routes are preferred over inter area routes so suboptimal path may be taken Thank you all and wish you the best. ... View more