OSPF over Frame-Relay – Part 3: Point-To-Point

In our last two installments we looked at the non-broadcast and broadcast network types for OSPF over frame-relay.  In this article we will be taking a look at the point-to-point network type.  One thing I always remember regarding frame-relay and OSPF is that a network type of “point-to-ANYTHING” does NOT have a DR/BDR.  So, point-to-point, point-to-multipoint, and point-to-multipoint non-broadcast will NEVER have a DR.  With the point-to-point network type we will have “fast” timers of 10/40 seconds.

Point-to-point sub-interfaces have a default network type of point-to-point in OSPF.  With this kind of setup, pretty much everything is done for you.  Point-to-point subinterfaces can already pass broadcast/multicast traffic, so we don’t need to worry about neighbor commands.  Also, as we already mentioned, there is no DR needed.  Why?  Well, it is designed for use on a point-to-point link.  With only two possible endpoints, it doesn’t make sense to have a DR responsible for everything going on like in an Ethernet environment. One thing to keep in mind is that a point-to-point OSPF network type is only designed to have a single neighbor.  If we were to put point-to-point on the spokes, but try to change our multipoint sub-interface on the hub to a point-to-point OSPF network type we’d run into all sorts of fun problems.

We have two ways to demonstrate point-to-point network types over frame-relay.  The first way is how it is “supposed” to work.  Very simple…we have two point-to-point sub-interfaces setup on the hub (will default to OSPF network type point-to-point) and we will leave our physical interfaces on the spokes and change them to network type point-to-point (remember the default is non-broadcast).  This should work nicely.

The other option I will show here is to leave the hub as a frame-relay multipoint sub-interface.  Because point-to-point networks in OSPF are only designed to have a single neighbor, we will have to make the hub a point-to-multipoint network type.  This gets a little into the troubleshooting section, and tweaking timers that we will get into in detail in the last part of this blog series on troubleshooting mismatched network types, but I will wet your appetite here.

OK, so let’s get the easy part out of the way.  First we will setup two separate subnets:  One going from the hub to one spoke, and another going to the other spoke.  On the hub, the OSPF network type will automatically be point-to-point because we will be using point-to-point sub-interfaces.  On the spokes, we will specify the network type as point-to-point since we are using physical interfaces. Here is the diagram and configuration!

R2(config)#int s0/1/0.25 point-to-point
R2(config-subif)#frame-relay interface-dlci 205
R2(config-fr-dlci)#ip address 100.100.25.2 255.255.255.0
R2(config-subif)#int s0/1/0.26 point
R2(config-subif)#frame-relay interface-dlci 206
R2(config-fr-dlci)#ip address 100.100.26.2 255.255.255.0
R2(config-subif)#router ospf 1
R2(config-router)#network 100.100.25.2 0.0.0.0 area 0
R2(config-router)#network 100.100.26.2 0.0.0.0 area 0
R5(config-if)#int s0/1/0
R5(config-if)#ip add 100.100.25.5 255.255.255.0
R5(config-if)#ip ospf network point-to-point
R5(config)#router ospf 1
R5(config-router)#network 100.100.25.5 0.0.0.0 area 0
R6(config)#int s0/1/0
R6(config-if)#ip add 100.100.26.6 255.255.255.0
R6(config-if)#ip ospf network point-to-point
R6(config-if)#router ospf 1
R6(config-router)#network 100.100.26.6 0.0.0.0 area 0

Sweet.  Let’s verify on R2…

R2(config-router)#do sh ip ospf neigh
Neighbor ID     Pri   State           Dead Time   Address         Interface
100.100.26.6      0   FULL/  -        00:00:34    100.100.26.6    Serial0/1/0.26
100.100.25.5      0   FULL/  -        00:00:30    100.100.25.5    Serial0/1/0.25

Our neighbors are up and we are rocking and rolling! Notice that the priority field is “0″ and the state is “Full/ -” If we know our technology this should make sense.  There is no priority because there is no DR election.  The state is simply FULL meaning the adjacency is up, but again no indication of a DR here.  Perfect.  Now, we could have also used point-to-point sub-interfaces on the spokes.  This goes to show that we can have a physical interface but a point-to-point network type.  The interface type does not necessarily have to equal the OSPF network type.

To finish up, let’s change everything back to a single subnet (100.100.100.0/24), and make R2 a multipoint sub-interface and see how we can make this work.

R5(config-router)#int s0/1/0
R5(config-if)#ip add 100.100.100.5 255.255.255.0
R5(config-if)#router ospf 1
*Jun 27 13:27:55.911: %OSPF-5-ADJCHG: Process 1, Nbr 100.100.26.2 on Serial0/1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
R5(config-router)#no network 100.100.25.5 0.0.0.0 area 0
R5(config-router)#network 100.100.100.5 0.0.0.0 area 0
R6(config-router)#int s0/1/0
R6(config-if)#ip add 100.100.100.6 255.255.255.0
R6(config-if)#router ospf 1
*Jul 27 23:01:21.211: %OSPF-5-ADJCHG: Process 1, Nbr 100.100.26.2 on Serial0/1/0 from FULL to DOWN, Neighbor Down: Interfae down or detached
R6(config-router)#no network 100.100.26.6 0.0.0.0 area 0
R6(config-router)#network 100.100.100.6 0.0.0.0 area 0
R2(config-router)#no int s0/1/0.25

Not all config may be removed and may reappear after reactivating the sub-interface

R2(config)#no int s0/1/0.26
Not all config may be removed and may reappear after reactivating the sub-interface
R2(config)#int s0/1/0.256
R2(config-subif)#ip add 100.100.100.2 255.255.255.0
R2(config-subif)#frame map ip 100.100.100.5 205 broad
R2(config-subif)#frame map ip 100.100.100.6 206 broad
R2(config-subif)#frame map ip 100.100.100.2 206
R2(config-subif)#ip ospf network point-to-multipoint
R2(config-subif)#
R2(config-subif)#router ospf 1
R2(config-router)#no network 100.100.25.2 0.0.0.0 area 0
R2(config-router)#no network 100.100.26.2 0.0.0.0 area 0
R2(config-router)#network 100.100.100.2 0.0.0.0 area 0
R2(config-router)#do sh ip ospf neigh

Hmmmmmm…it’s been a while and we still see no neighbors.  Let’s hit our basic checklist:  Do both sides agree on the presence of a DR?  Let’s see…the spokes are point-to-point, and the hub is point-to-multipoint.  Neither need a DR, so we are good there.  Do we need neighbor commands?  Nope, we can multicast here no problem.  What about timers? Ahhhhhhh timers.  Point-to-point network type uses “fast” timers and point-to-multipoint uses “slow” times.  So let’s tweak the timers on the hub!

R2(config-router)#int s0/1/0.256
R2(config-subif)#ip ospf hello
R2(config-subif)#ip ospf hello-interval 10
*Jun 27 13:38:18.355: %OSPF-5-ADJCHG: Process 1, Nbr 100.100.26.6 on Serial0/1/0.256 from LOADING to FULL, Loading Done
*Jun 27 13:38:18.471: %OSPF-5-ADJCHG: Process 1, Nbr 100.100.25.5 on Serial0/1/0.256 from LOADING to FULL, Loading Done

Awesome!  Now that we have matched timers we can establish an adjacency and everything is FINE. Whenever you run into issues like this, go over your checklist. DR? Neighbor? Timers? Boom.  That is it for point-to-point network type in OSPF!

Tune in next time for point-to-multipoint!!!

Thanks!

Joe (Post contributed by Joe Astorino – CCIE #24347 R&S)

OSPF over Frame-Relay - Part 3: Point-To-Point, 1.9 out of 5 based on 15 ratings

Tags: ccie lab, CCIE R&S Lab, ipexpert, OSPF