4.4 OSPF Over Non-Broadcast Networks
4.4.5 Point-to-MultiPoint interfaces
An OSPF point-to-multipoint interface is defined as a numbered point-to-point interface with the router having one or more OSPF neighbors. Because of this, OSPF will create multiple host routes.

An OSPF point-to-multipoint network has the following benefits compared to nonbroadcast multiaccess and point-to-point networks:

  • Point-to-multipoint is easier to configure because it requires no configuration of neighbor commands, it consumes only one IP subnet, and it requires no designated router election.
  • Point-to-multipoint has fully-meshed topology.
  • Point-to-multipoint is more reliable because it maintains connectivity in case of virtual circuit failure.

When you decide to configure nonbroadcast, multiaccess networks as either broadcast or nonbroadcast networks, OSPF assumes that there are virtual circuits from every router to every router or that you are running a fully-meshed network.

This is not true in many cases because you might only have a partially-meshed network because the cost required to fully mesh the network is prohibitive. In this case, you can configure the OSPF network type as a point-to-multipoint network. Routing between two routers not directly connected will go through the router that has virtual circuits to both routers.

To configure your OSPF network type on a specific interface (int s0), enter the following command in interface configuration mode:

ip ospf network {broadcast|non-broadcast| point-to-multipoint}

The figure to the left shows an example of OSPF in a point-to-multipoint networking environment.

Note Remember there are no Designated Routers or Backup Designated Routers on a point-to-multipoint subnet. The OSPF Hello protocol will find neighbors.

Referring to the setup in the figure and for demonstration purposes, assume the following scenario:

  • Denver uses DLCI 201 to communicate with San Diego, DLCI 202 to Los Angeles, and DLCI 203 to San Francisco.
  • San Diego uses DLCI 101 to communicate with Denver and DLCI 102 to communicate with San Francisco.
  • San Francisco communicates with San Diego (DLCI 401) and Denver (DLCI 402).
  • Los Angeles communicates with Denver (DLCI 301).

Given this setup, the configurations for Denver, SanDiego, SanFrancisco, and LosAngeles are shown in the figure to the left. (see Denver#show running-configSanDiego#show running-config, SanFrancisco#show running-config, and LosAngeles #show running-config command outputs)