Designing Implementing an OSPF Network | OSPF Network Design Solutions

Table of Contents

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.

Figure 7-24 OSPF on-demand circuit operation.

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

TIPS:
If the router is part of a point-to-point topology, then only one end of the demand circuit must be configured with this command. However, all routers must have this feature loaded within the area and must be configured with the ip ospf demand-circuit command. If the router is part of a point-to-multipoint topology, only the multipoint end must be configured with this command.

Implementation Considerations for OSPF over On-Demand Circuits

Please evaluate the following considerations before implementing on-demand circuits on a Cisco router:

• Because LSAs that include topology changes are flooded over an on-demand circuit, it is advised to put demand circuits within OSPF stub areas, or within NSSAs to isolate the demand circuits from as many topology changes as possible.

• To take advantage of the on-demand circuit functionality within a stub area or NSSA, every router in the area must have this feature loaded. If this feature is deployed within a regular area, all other regular areas must also support this feature before the demand circuit functionality can take effect. This is because Type 5 external LSAs are flooded throughout all areas.

• You do not want to implement this OSPF feature on a broadcast-based network topology because the overhead protocols (such as hellos and LSAs) cannot be successfully suppressed, which means the link will remain up.

Multicast OSPF

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.

Notes:
If you have a need to run MOSPF, then you will need to contact one of these five router vendors: 3Com, Bay Networks, IBM, Proteon, and Xyplex as they are the only manufacturers to have implemented MOSPF.

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 doesn’t 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.

Notes:
A nice example of the added load MOSPF will put on your network are some figures surrounding Proteon’s implementation of MOSPF. When adding MOSPF into the base OSPF code, it caused a 30 percent increase in its size. Extra load will be placed upon a router to support such a jump in size and the operational requirements of MOSPF. My suggestion is: be very sure of the benefits you expect to gain if ever you decide to implement this feature. Due to scalability issues, Cisco does not see a need to go to MOSPF right now. Additionally, PIM is getting pushed now as the multicast protocol of choice.

Table of Contents