This feature is also very useful when you want to connect telecommuters or branch offices to an OSPF backbone at a central site. In this case, OSPF for on-demand circuits allows the benefits of OSPF over the entire domain, without excess connection costs. Periodic refreshes of hello updates, LSA updates, and other protocol overhead are prevented in this configuration from enabling the on-demand circuit when there is no real data to transmit. Figure 7-24 illustrates this type of OSPF setup.
Overhead protocols within OSPF such as hellos and LSAs are transferred over the on-demand circuit only upon initial setup and when they reflect a change in the network topology. This means that critical changes to the topology that require new SPF calculations are transmitted in order to maintain network topology integrity. Periodic refreshes that do not include changes, however, are not transmitted across the link.
To configure OSPF for on-demand circuits, enter the following command within the OSPF configuration mode:
ip ospf demand-circuit
This command is also shown in the following example:
OSPF_Router(config)#router ospf 200 OSPF_Router(config-router)#ip ospf demand circuit
Implementation Considerations for OSPF over On-Demand Circuits
Please evaluate the following considerations before implementing on-demand circuits on a Cisco router:
Multicast OSPF (MOSPF) was defined as an extension to the OSPF unicast routing protocol in RFC 1584. Multicast OSPF works by ensuring each router in a network understands all the available links in the network. Each OSPF router calculates routes from itself to all possible destinations.
Before discussing MOSPF any further, it is important to note that Cisco Systems does NOT support this feature of OSPF. Nevertheless, because many networks will have multiple router manufacturers in them or connect to other manufacturers, it is important to discuss this OSPF feature, as you will probably encounter it if your network has a blend of routers within it. This section will later discuss the reasons why Cisco does not support Multicast OSPF.
MOSPF works by including multicast information in OSPF link-state advertisements. A MOSPF router learns which multicast groups are active on which LANs.
MOSPF then builds a distribution tree for each source/group pair and computes a tree for active sources sending to the group. The tree state is cached on all routers, and trees must be re-computed when a link-state change occurs or when the cache times out. This eventuality in turn can hinder multicast performance, depending upon the size of the network and the volatility of the multicast groups.
As expected, MOSPF works only in internetworks that are using OSPF and have implemented routers manufactured by a company other than Cisco Systems.
MOSPF is best suited for environments that have relatively few source/group pairs active at any given time. It will work less well in environments that have many active sources or environments that have unstable links.
Some multicast group addresses are assigned as well-known addresses by the Internet Assigned Numbers Authority (IANA). These groups are called permanent host groups, similar in concept to the well-known TCP and User Datagram Protocol (UDP) port numbers.
Why doesnt Cisco Systems support this powerful enhancement to the OSPF protocol? You will not find this information on CCO nor in any of their corporate literature, and I had to open a trouble ticket with the TAC to find it. Various engineers within Cisco were consulted, and the problem with MOSPF is that every OSPF router in your network must have it turned on. Every router will then have to run the Dijkstra algorithm for every multicast source and group within the network. This feature will work properly within a multicast network that is very small but it will melt down routers as the number of multicast routers grows.
For example, this means that every receiver of a multicast is also a sender and will therefore cause another instance of the Dijkstra algorithm to be run within every router in the network. As the use of your multicast application grows, this would cause an increased load to be placed on the CPUs of your routers. Simply put, imagine if you have an ABR that was connected to multiple areas and every area had several hundred routers. Your ABR would have to run the Dijkstra algorithm for every router in every area, thus a network melt down would result.
Now extend that to every router in your network.