JNCIP-SP: verifying OSPF DR/BDR operations.
Let’s have a look at a multiaccess segment on which four Juniper OSPF routers are present. The topology is the following:
Let’s activate OSPF on all the interfaces connected to the multiaccess segment. Since they will all have the same configuration, I’ll show only an example from R15:R15:
set protocols ospf area 0.0.0.1 interface xe-0/3/0.2000 authentication md5 1 key "$9$cuvlKWN-bwY4UjTFnC0O"
After the routers are configured for OSPF, they will start to form adjacencies with each other. When routers on a multiaccess segment decide to form an adjacency, they will determine the DR and BDR based on priority or router-id. The router with the highest interface priority or highest router-id will be elected DR, the second highest will be elected BDR. The rest of the routers on a multiaccess segment will simply be DRother.
Without any additional configuration, the interface priority on all routers will be 128, meaning the routers with the highest router-id will be DR and BDR.
On our multiaccess segment, we can verify this:
This command tells us that S1 is the DR. It became the DR because the router-id, 188.8.131.52, is the highest. The EX4500, with the second highest router-id 184.108.40.206, became BDR. The command also tells us that there are 3 neighbors on the segment. Let’s change the DR and the BDR routers to reflect the following:
To change R15 into the DR and S1 into the BDR, the interfaces running OSPF on the multiaccess segment need to have their priority altered. To achieve this, we can perform the following;R15:
set protocols ospf area 0.0.0.1 interface xe-0/3/0.2000 priority 200S1:
set routing-instances DR-BDR protocols ospf area 0.0.0.1 interface irb.2000 priority 175
After changing the priority, you’ll notice nothing has changed yet. The DR status is something that cannot be preempted by other routers.
What we can do is clear the neighbor relationship on R15:
The first command shows that R15 is DRother, even though it’s configuration is the highest on the LAN. When we clear the neighbor relationships on the router, R15 will rebuild its neighbor relationships. The last ‘show ospf interface’ shows that R15 has assumed the role of DR and that it has reestablished its neighbor relationship with the other routers.
Currently, on the multiaccess segment, the only routers with a full neighbor relationship to all the other routers will be R15 and S1:
Let’s verify this on R6:
There are three neighbors in total, but the adjacencies are only with the DR and BDR. If we really wanted to, we could even further reduce the number of adjacencies on our multiaccess segment.
A router with a priority of 0 cannot assume the role of a DR. If we were to change the interface priority of all routers other than R15 to 0, we would end up with the following situation;
This way, the multiaccess segment would only have a total number of 3 adjacencies. If R15 were to stop functioning however, we would end up with 0 adjacencies since all the other routers will continue to remain in the 2Way state.
The same thing would happen if we were to move on and reduce the priority on R15 to 0 as well, we would end up with this:
This would be a completely dysfunctional multiaccess segment. No full adjacencies means no exchange of LSAs.
To move on, I have restored R15 and S1’s priority. R15 is now back to being DR and it is advertising the multiaccess segment. Let’s verify this by examining the LSDB on another router.
The first command shows us there is only one network-LSA in the LSDB and that it is being advertised by R15. The second command shows us that the network-LSA carries the prefix for the multiaccess segment as well as all the routers attached to the multiaccess segment.
The fact that the DR is representing the multiaccess segment by advertising a type 2 LSA with all attached routers does not mean that the individual routers aren’t sending out router-LSAs anymore. The output below shows that the individual DRother routers are still advertising a router-LSA:
Another thing we can verify is the advertisement of LSAs. We can see this when we configure an additional subnet on R6. R6, being a DRother, will send a link-state update to 220.127.116.11. The DR, R15, will receive this update and notify the other routers on the segment by sending the LSU to 18.104.22.168 (the all OSPF routers address).
A last thing to point out is that during this lab, I was troubleshooting an adjacency on the multiaccess segment. On the MX480 , using flexible ethernet services and flexible vlan-tagging, I set the interface MTU to 9000. This led to the interface MTU being set to 8978.
On the EX4500 The ethernet MTU on the interface was 9000, but the inet family MTU was automatically set to 1500.
When I initially configured OSPF, the MX480 and the EX4500 were stuck in the exchange state:
Even though the routers were adjacent for quite some time, they remained in the Exchange state. When I monitored the interface without detailed options, I did not really notice anything:
Both routers were exchanging Hellos, LSUs, etc. When I started monitoring the traffic with the ‘monitor traffic interface xe-0/3/0.2000 detail’ option, I saw both routers sending Database Descriptions to and fro and I happened to notice this;
Next time, I’ll simply check the interface MTU right from the start.