The solution would be to allow the OSPF interface found in R1 and R2 that are the area 0 links to also belong to NSSA 1. Under the current specification, each routers interface can only belong to one area. This draft creates a new parameter known as secondary areas with the original area becoming the primary area. Using Opaque LSAs, routing information is provided between participants. This Internet Draft is highly recommended for additional reading as it has a lot of merit. Hopefully this Draft will be advanced to an RFC very soon. OSPF Optimized Multipath (OSPF-OMP)Date Published: March 1998 Author: Curtis Villamizar Expiration Date: September 1998 File Name: draft-ietf-ospf-omp-00.txt AbstractOSPF may form multiple equal cost paths between points. This is true of any link-state protocol. In the absence of any explicit support to take advantage of this, a path may be chosen arbitrarily. Techniques have been utilized to divide traffic somewhat evenly among the available paths. These techniques have been referred to as Equal Cost Multipath (ECMP). An unequal division of traffic among the available paths is generally preferable. Routers generally have no knowledge of traffic loading on distant links and, therefore, have no basis to optimize the allocation of traffic. Optimized Multipath is a compatible extension to OSPF, utilizing the Opaque LSA to distribute loading information, proposing a means to adjust forwarding, and providing an algorithm to make the adjustments gradually enough to ensure stability yet provide reasonably fast adjustment when needed. Draft SummaryThe author of this draft does an excellent good of explaining the need for this draft, and he goes through the various type of ECMP. He covers the three different techniques used in ECMP, as shown in the following list:
Additional discussion then ensues on how and why they fall short in properly providing the required load-sensitive routing to demonstrate the need for the Internet Draft. To expect any protocol to perform load-sensitive routing, it is necessary for the protocol to gain information on the different possible paths to the required destination. This Internet Draft proposes the use of Opaque LSAs that will flood the load information. After this information is received by OSPF, it can calculate the correct route. The Opaque LSA will be responsible for providing the correct route calculation. In addition, Opaques LSAs will provide the following information:
The information provided in the following list comes from sampling interface counter values that are available via SNMP:
Chapter SummaryThis chapter discussed IETFs Working Drafts, specifically those that apply to OSPF and its future. This information will enable you to be proactive in understanding how the upcoming changes to OSPF are going to affect your organizations network. It is important to note yet again that these drafts are considered works in progress and as such they can change at any time. Case Study: NetFlow SwitchingNetFlow Switching is part of Ciscos new Internet of Quality Services initiative. It enables enterprise networks to meet and exceed many critical benefits by providing the following enhancements:
What is NetFlow exactly? NetFlow is defined as a sequence of packets in one direction between given source and destination endpoints, which are identified by IP address. These flows can be extremely granular. The difference between regular network switching and NetFlow Switching is that regular switching handles incoming packets with separate serial tasks for switching, services, and traffic measurements. The typical process involved with switching a packet is shown in Figure 11-2. With NetFlow Switching, however, the process is applied to only the first packet of a flow. Information is extracted from the first packet and is used to build an entry in the NetFlow cache for this flow. Subsequent packets are handled via a single streamlined task, which handles switching, services, and data collection concurrently. Figure 11-3 illustrates the processes of NetFlow Switching. NetFlow Requirements and Deployment StrategyNetFlow does not require the adoption of any new or proprietary protocols or new networking equipment. NetFlow may be deployed in an extremely flexible manner to include interface-by-interface deployment. NetFlow does require a server upon which a software program referred to as Flow Collector is run. This software collects the data and stores it for use by network engineers. It has a variety of features to optimize the data collected based upon user requirements. This software also acts as a management platform of sorts for routers with the NetFlow capability. These Flow Collectors are designed to be deployed throughout the network and all will report to a central station referred to as the Central Flow Analyzer. It is this flow analyzer that enables the network engineers to manipulate the data and reports from the data collected by the flow collectors.
|