This post is based on notes from my practicing OSPF vol1 labs. I want to have them saved
for later reference but I also think that this post can help others and clear some of the
confusions of OSPF.
Lets assume that we have some lab tasks that involve OSPF. The first thing we should do
is make a diagram with all the devices and the areas that the interfaces are connected
to. If this diagram is already provided for us and we find it usable, then don’t waste
time doing a new one! Otherwise if there isn’t one of if your not happy with it, make
a new one.
I like to make diagrams in Visio but when we diagram for the lab its about being
effective so don’t try to create some masterpiece. I just use circles for routers and
squares for switches and then I write the device name inside the circle or the square.
Then I write the interfaces on the devices and IP if needed and make circles for the
areas that include the interfaces.
So these are some of the things I have noted down when labbing.
- The default mode of OSPF on frame-relay interfaces is non-broadcast
What does this mean? Non-broadcast means a few things. Non-broadcast means we cannot
send multicast or broadcast. Non-broadcast also means that a DR will be used.
Remember that if you see the prefix non in the OSPF type then we need to use neighbors.
If we have a hub and spoke topology we want to make sure that the hub always becomes
the DR since we won’t have l2 mappings to the other spokes in our frame-relay cloud.
How can we accomplish this? Remember that electing the DR is not preemptive, so we can
set the hub to have the highest priority and it is elected the DR and everything is fine
and dandy. When we have an outage at the hub and it comes back up but reachability is
not restored, why? While the hub was away another device could have been elected the DR
and just because the hub is back does not mean that it will assume its previous role.
So we need to make sure that the hub is elected the DR and that the other devices are
not eligible to be elected DR or BDR. The way of doing this is by entering ip ospf priority 0
under the frame-relay interface. Devices with a priority of 0 are not eligible for being
elected as DR/BDR.
- Adjacencies and convergence can take a while in NBMA networks, dont panic!
What do I mean by this. While labbing I was noticing that forming adjacencies took quite
some time. I was typing show ip ospf nei and looking at the status and it would be EXSTART
or something else for quite some time before the adjacency was formed. So give it a few
minutes before you make the assumption that something is wrong with your config.
Remember that the timers on NBMA networks 30 seconds for hello and 120 for dead.
- Neighbor command is only needed on DR
We won’t break anything by entering the neighbor command on the spokes but isn’t it better
to know how something works than just throw config at it? The spokes will only communicate
with the DR and the DR will be responsible for forming the adjacency. When we enter the
neighbor command under OSPF config mode on the hub it will start sending unicast packets
to the IP addresses that we have specified. Remember that multicast is the default in
most routing protocols. The hub sends unicast packets to the spokes which will notice that
unicast is being used and start replying with unicast themselves.
- A router is not an ABR if no interfaces in area 0
This might sound a bit confusing. Lets say that we have a router with interfaces in area 1
and area 3. This must be an ABR right? Wrong! Unless it is connected to the backbone it
is not actually an ABR and it will not send type 3 summaries describing the other areas
networks. If you want some more background on this and a great article on OSPF I
recommend that you read Petr Laphukovs post at INE.
- Using point-to-point mode
This mode is the default for interfaces that use point-to-point type of encapsulations
like HDLC or PPP. This mode can also be used to force a loopback to be advertised with its
configured mask instead of a /32 host route. This mode uses multicast and no DR is elected.
There is no need for a DR here since there can only be two devices communicating to each other.
- Using point-to-multipoint mode
This mode is designed to work in partial mesh NBMA networks. When we use this mode
we will see that there is a /32 route for every spoke pointing to the hub. Also all routes
that are learned will have their next-hop changed to the IP of the hub. This means that
we do not need to have map statements for the other spokes. As this mode uses multicast
we need to have the keyword broadcast in our frame-relay statements.
- Using point-to-multipoint non-broadcast
This works the same way as point-to-multipoint but the traffic is sent via unicast packets
instead of multicast. This means that we must have neighbor statements in our OSPF config.
- Hints that we should use non-broadcast mode
If we have a broadcast segment like Ethernet and we are told that the OSPF
communication must be secured so noone can interfere with it then we should use
non-broadcast mode. Default on Ethernet segments multicast will be used but that
means that anyone can listen to the packets if they are connected to the segment.
If we enable non-broadcast the packets will be sent via unicast. Optionally we can
enable MD5 as well.
This post should give you an understanding of the different modes in OSPF,
remember that non-broacast always means neighbor statements.
One thought on “OSPF lab notes”
This is a pretty good treatment of OSPF, there are a lot of complexities in thr protocol. Fortunately things like demand-circuits for ISDN are not a part of the exam anymore! I would recommend knowing virtual links, they can be rather tricky at times.