In order to solve problems the problem must be clearly defined and the purpose of the system must be known (Shibata, 1998). There are methods used to analyze complex systems either as a whole or at the individual component level. Holism looks at the system as a whole and presents the big picture (Raman, 2005). Both methods have their advantages and limitations (Mazocchi, 2008).

Problem solving is a very important but also a very misunderstood science. When attempting to solve problems it is essential to clearly define the problem. This is the first step but is often overlooked. A problem is identified in a system when the system is not performing its desired purpose. A problem is only considered a problem when it causes a deviation from the purpose. So the problem solver in order to identify the problem must understand the purpose of the system (Shibata, 1998).

Method

Several well-known approaches to understanding the purpose of a system and solving problems will be examined. These approaches are reductionism, holism, and systems thinking. Reductionism is an approach that was developed by the French philosopher and mathematician René Descartes. He was the first to introduce reductionism to western thinking and philosophy. Mazzocchi (2008) quotes Descartes who once wrote that “the world can be regarded as a clockwork mechanism; to understand it, one need only investigate the parts and then reassemble each component to recreate the whole” (para. 2). On the other hand Raman (2005) goes on to say “Holism states that by considering the whole picture one gets a more complete view than by analyzing it into its component parts. There is hardly a system without holistic properties” (p. 252) Thus, we will examine the reductionist/holist debate looking at the defining qualities of each approach and how each system of thought is organized (Edmonds, 1999).

Results

There is an ongoing debate on which approach is better reductionism or holism (Edmonds, 1999). Raman (2005) states the following:

Reductionism and holism are like the microscope and the telescope. Two powerful instruments to explore the world, one revealing the smallest constituents of what makes up the world, while the other makes us aware of the cosmic grandeur, and of the unity  behind the diversity. But this does not mean that truth depends on one’s perspective, rather that both reductionism and holism enrich our understanding and appreciation of a situation, each in its own way. (p. 252).

Furthermore, the truth does not depend on one’s perspective whether it be reductionism or holism. Both methods of analysis help to give a different but equally valid understanding of the situation (Raman, 2005).

Discussion

There are limitations of both the holist and redutionist methods of analysis. Mazzocchi (2008) writes about a limitation of the reductionist approach stating that it is “not able to analyse and properly account for the emergent properties that characterize complex systems” (para. 10). Mazzocchi goes on to say that a new theoretical framework needs to be developed that can keep distinction of what is connected while being able to connect without reduction. The methods used to analyze complex systems must be able to cope with many variables and conditions. Mazocchi (2008) gives an example stating “The metaphor of the ‘butterfly effect’—whereby a single butterfly beating its wings can cause a storm—describes, for example, the dependence of a complex system on its initial conditions.” (para. 7). There are often conditions that affect complex systems making analysis difficult.

Figure 1.  .The storm variable is dependent on the flap variable of the butterfly’s wings.

References

Edmonds, B. (1999). Pragmatic Holism (or Pragmatic Reductionism) [Electronic version]. Foundations of Science, 4, 57-82.

Mazzocchi, F. (2008, January). Complexity in biology. Exceeding the limits of reductionism and determinism using complexity theory. Retrieved on July 17, 2009 from http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=2246621#b19.

Raman, V. (2005). Scientific Reductionism and Holism: Two Sides

of the Perception of Reality [Electronic version]. Theology & Science, 3, 250-253.

Shibata, H. (1998). Problem Solving: Definition, terminology, and patterns. Retrieved on July 17, 2009 from http://www.mediafrontier.com/Article/PS/PS.htm.

http://www.whitehouse.gov/the_press_office/Statement-by-the-Press-Secretary-on-Conclusion-of-the-Cyberspace-Review/

Quality Approach to Measurements and Metrics: Doing it Right the First Time

Tim W. Steiner

Wilmington University

Metrics are defined as “A quantitative measure of the degree to which a system, component, or process possesses a given attribute. A calculated or composite indicator based upon two or more measures. A quantified measure of the degree to which a system, component, or process possesses a given attribute.” (Ragland, 1995). Metrics are different from measures in that they provide more meaningful information of a measurement in a specified context. For example if a patient has a temperature of 99.1 degrees Fahrenheit that is a measurement. This information alone tells very little about the patient. If say the patient’s temperature is regularly checked and there is a trend in the measurements showing that every hour the patient’s temperature rises this would be a metric. The measurements of the increasing temperature over time show that the patient’s condition is getting worse. This metric is meaningful information that can be used to diagnose the patient and hopefully improve the patient’s condition (Ragland, 1995).

Knowing what and how to measure are key to obtaining effective measurements. It is more than just taking a large quantity of complex measurements, organizations must identify the right measures to use. The main objective of a measurement is to communicate the progress or lack of progress in accomplishing the firm’s goals. Finding the right measurements at the right times can paint a clear picture of the current state of an organization and where that organization needs to go to achieve its corporate goals. Taking timely measurements can produce the best results but deciding when to measure is not always an easy question to answer. Some measurements must be taken continually while others may be dependant on other events. For example, some measurements are dependant on system and network availability, bandwidth and hardware capacity, project state, personnel availability, and man-hour requirements. Measurements need to done on a consistent and repeated basis. This enables effective reporting at the end of a specified period. Just as report cards are distributed at the end of a schools reporting period; reports should be consistently produced at the end of a businesses reporting period (Luftman, 2004).

There are four reasons for measuring processes, products, and resources. First to characterize, this is used to gain understanding of the processes, products, resources, and environments. Characterizing allows establishment of a baseline for comparison and future assessment. Next evaluation is to determine status with respect to plans. Evaluation is also used to assess achievement of quality goals and to observe the impact of technology and process improvements on products and processes. Prediction is used to plan for the future. Projections and estimates based on historical data also help to analyze risks. Improving is the final reason. This is the constant pursuit to make processes and products better. Taking measurements such as quantitative information to help identify roadblocks, root causes, and inefficiencies assist in the improvement process (Luftman, 2004).

Performance is directly related to the quality and effectiveness of measurements. Quality measurements help an organization understand if a process is effective and efficient. Processes can be measured and compared through benchmarking, trend analysis, and satisfaction surveys. Project managers rely on measurement tools to continuously monitor project schedules so that they can be alerted to project difficulties early enough to repair the problems and prevent delays (Luftman, 2004).

In the IT world CIOs often use models such as the 10 step approach to developing measurements, or some other form of benchmarking. The CIO is responsible for taking these measurements and engineering them back into the IT units improving weaknesses and utilizing strengths. The steps in the 10 step approach to developing measurements is designed specifically for IT but the concepts apply many departments. The first step is to establish teams from both IT and business to review and analyze the underlying IT processes. Next the goals of each IT process are defined, these goals should align IT strategy with business strategy. There are critical success factors that are identified, these determine the performance of the IT process in reaching its goals. Guidelines are established to measure if and to what degree the critical success factors have been met. Once these measurements are in place and have been tested, a complete pilot should be done with all team members participating in the pilot. After the pilot is completed successfully and the results are deemed acceptable the recommendation to apply these measurements is forwarded to senior management. Upon managements approval the implementation of the new measures begins. The last step in the process is to analyze the results and this step is an ongoing process of improvement (Luftman, 2004).

In order for any measurements or metrics to be effective they must be of high quality and efficacy. A measurement can be skewed and manipulated to reflect the desired results reflecting an inaccurate situation. There can be manipulation of ROI and other financial measures that can point to inaccurate results. Measurements that forecast trends are the best indicators because these measurements are difficult to manipulate and will paint a clear picture of the actual situation. These measurements are often described as metrics. Peter B. B. Turney states “How wrong we were. It’s poor quality that costs money (and loses customers). Poor quality is doing a job more than once. It’s wasting materials. It’s paying salaries for hordes of inspectors. It’s incurring the cost of warranties and customer returns. And it’s suffering the anger of disgruntled customers… Improving quality is a sure way to reduce cost. Do it right, the first time.” (p.361). It used to be some organization’s view that quality was costly. This perspective was taken by some who look at part of the picture and see that improving quality requires more inspectors and costly warranties. Quality is a process of give and take. Yes, there are substantial costs involved but in the long run quality saves money by doing the job right the first time. Quality measurements show how improvements are performing and justify incremental costs (Luftman, 2004).

Quality measurements and metrics are collected and developed so that indicators can be obtained. Indicators provide insight that enables managers to adjust the process to make things better. Indicators are usually metrics that are compared to a baseline. Back to the example where the trend of the patient’s increasing temperature is a metric showing that the patient’s condition is getting worse. If there was a baseline such as the normal body temperature of 98.6 degrees Fahrenheit to compare the patient’s increasing temperature to, this indicates that not only is the patient’s condition getting worse, but there is a quantifiable difference between the current temperature and the desired temperature. Indicators help us to see where we are, how far this is from the goal, and enable managers to take the required steps in order to reach the goal (Luftman, 2004).

In terms of indicators there are many types but the two types of our focus are process indicators and project indicators. Process indicators enable an organization to gain insight into the efficacy of an existing process. They enable managers to assess what works and what does not. The intent is to provide process indicators that lead to long term software process improvement. Project indicators enable a project manager to assess the status of an ongoing project, track risks, uncover potential problem areas, adjust workflow, and evaluate the project teams’ abilities. Having clear indicators help in the decision making process and enable managers to maintain control. Tom DeMarco, a metrics expert states that “if you don’t measure, then you’re left with only one reason to believe you are still in control: hysterical optimism (“The Foundation of Information Security”, 2009).

Many programs fail due to poorly defined objectives and having the wrong approach to measurement. There are a number of approaches for defining measurable goals. The most well known approaches are Goal-Question-Metrics (GQM), Quality Function Deployment Approch (QFD), and Software Quality Metrics (SQM). The fundamental idea of GQM is to set goals specific to the needs in terms of purpose, perspective, and environment. Refine the goals into quantifiable and traceable questions. Deduce metrics and data to be collected this is essentially answering the questions. The QFD approach is a technique that evolved from Total Quality Management principles and aims at deriving indicators from a user’s point of view. This method uses simple matrices with values weighted according to the judgments of the customer. The SQM approach was developed to allow customers to assess the product being developed. A set of quality factors are defined for the final product, the factors are refined into a criteria, and this criteria is further refined into a set of metrics (“Measurement Frameworks and Standards”, 1999).

Measurements, metrics, and indicators when used effectively in a goal-oriented approach can help to better define the processes and ultimately determine the organizations maturity level. The CMM capability maturity model (Whitten, Bentley, & Dittman, 2004) is “A standardized framework for assessing the maturity level of an organization’s information systems development and management processes and products. It consists of five levels of maturity” (p. 84). In the CMM each level builds and expands on the level preceding it. Most organizations start at Level 1. At this level projects don’t follow a consistent process. They may be unpredictable and tumultuous. Each team follows its own methods without regard for other teams. Projects typically encounter crises, are over budget, and behind schedule. Documentation is inconsistent which creates problems for anyone trying to manage the system (Whitten, Bentley, & Dittman, 2004).

In Level 2 the focus is on project management. Project management procedures are established to track project functionality, schedules, and cost. The system development process may vary from project to project but a process is always followed. Level 2 develops the foundation for the standardization that occurs in Level 3 (Whitten, Bentley, & Dittman, 2004). 

Level 3 develops the system development process into a standard. All projects use the standard process to develop and maintain information systems and software. Consistently using standards will result in high-quality documentation and deliverables. The process is repeatable, stable, and predictable (Whitten, Bentley, & Dittman, 2004).

Measurable goals are set for quality and productivity in Level 4. The measures are collected routinely and stored in a database. This data is used to improve project management. Whenever a project encounters a problem, the process can be adjusted based on predictable and measurable impacts (Whitten, Bentley, & Dittman, 2004).

Level 5 consists of continually monitoring and improving based on the measures and data analysis that was developed in Level 4. Technology is changed as needed and the process itself can be adjusted to meet requirements. Lessons learned are shared across the organization with emphasis on eliminating inefficiencies while sustaining quality (Whitten, Bentley, & Dittman, 2004).

            The CMM shows that organizational maturity is essential for development of processes and products. It follows that organizational maturity would be essential to producing quality solutions. Organizational maturity stimulates growth, increases operational efficiency, allows effective management, and ensures quality.

References

(1999). Measurement Frameworks and Standards. Retrieved Jun 22, 2009, from http://www.dcs.qmul.ac.uk/~norman/papers/qa_metrics_article/section_7_standards.html

(2008). Systems development life cycle (SDLC) resources from MKS. Retrieved June 22, 2009, from http://www.mks.com/sdlc

(2009). The Foundation of Information Security. Retrieved May 25, 2009, from http://www.safenet-inc.com/

Luftman, J. (2004). New Upper Saddle River, NJ: Person Education Inc.

Ragland, B. (1995) Measure, Metric, or Indicator. Retrieved June 22, 2009, from http://www.stsc.hill.af.mil/crosstalk/1995/03/Measure.asp

Whitten, J. L., Bentley, L. D., & Dittman, K. C. (2004). New York, NY: McGraw-Hill Companies, Inc.

Systems Analysis and Design in the Systems Development Life Cycle

Timothy W. Steiner

Wilmington University

The Systems Development Life Cycle (SDLC), sometimes also referred to as the Software Development Life Cycle, is the logical process used to develop an information system. In its simplest form SDLC is a project management method that breaks complex projects into smaller manageable phases. Segmenting projects enables management to verify the success of one phase before moving to the next. The SDLC is closely related to systems analysis and design and is an invaluable tool for systems analysts (“Systems Development Life Cycle from FOLDOC,” 2000).

To address the increasing complexity and size of IT projects, a wide range of SDLC models have been developed. Some models scale better to large long-term development projects while others scale better to smaller more rapid development. Agile SDLC models are used to combine the benefits from several models to fit specific project requirements. Models include the Waterfall, Fountain, Spiral, Build and fix, Rapid prototyping, incremental, synchronize and stabilize. The most well know SDLC model is the waterfall model (“Quick Study: SDLC,” 2002).

The Waterfall model consists of a sequence of phases in which the output of each phase becomes the input for the next (“Quick Study: SDLC,” 2002). The Waterfall model that will be analyzed includes 7 phases. These phases are the initiation phase, the planning phase, the design phase, the development phase, the testing phase, the implementation phase, the maintenance phase. Each phase lays the foundation for the subsequent phases and each plays an important role in the SDLC (“Systems Development Life Cycle,” n.d.).

Initiation begins when a need is identified and a system is requested through the presentation of a business case. Management will decide to either reject the proposal or accept it and proceed to a formal feasibility study. Issues to consider when compiling a feasibility study include Strategic goals, expected benefits, organizational changes, budget, scheduling, regulatory or legal issues, end-user functional requirements, security requirements, backup requirements, and network support requirements. Along with the feasibility study a cost/benefit analysis should be done to analyze alternative solutions, expected useful life of product, nonrecurring/recurring project costs, tangible benefits, and intangible benefits (“Systems Development Life Cycle,” n.d.).

The Federal Financial Institutions Examination Council (n.d) states that, “The planning phase is the most critical step in completing development, acquisition, and maintenance projects. Careful planning, particularly in the early stages of a project, is necessary to coordinate activities and manage project risks effectively. The depth and formality of project plans should be commensurate with the characteristics and risks of a given project” (Planning Phase section, para. 1). The project plans essentially refine the information that was gathered during the initiation phase into defined functions. Formal project plans will typically include project overview, roles and responsibilities, defined deliverables, control requirements, risk management, change management, standards, documentation, scheduling, budget, testing, and staff development (“Systems Development Life Cycle,” n.d.).

In the system design phase the requirements from previous phases are transformed into design specifications that developers will use to script programs during the development phase. The design specifications describe desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation. Good documentation enhances a programmer’s ability to write code and helps management to ensure the original goals and specifications are consistent with the design specifications (“Systems Development Life Cycle,” n.d.).

Once the design specifications are approved by management the development phase can begin. This phase involves converting design specifications into executable programs. Typically, individual programmers develop program modules which are small parts of the program that perform a specific task. These modules are integrated with other components and reviewed, often by a group of programmers, to ensure correct interaction and functionality. Documentation in the development phase should include system documentation, application documentation and a complete testing plan (“Systems Development Life Cycle,” n.d.).

The testing phase is crucial as it ensures the accuracy of the programmed code expected functionality and interoperability. Thorough testing will ensure that systems meet organizational and end-user requirements. Testing groups are typically comprised of technicians and end users who are responsible for identifying program defects or weaknesses during the testing process. Procedures should be in place to ensure programmers correct defects quickly and document all corrections. Moreover, correcting problems quickly increases efficiency by decreasing testers’ downtime. Primary testing includes acceptance testing, end-to-end testing, functional testing, integration testing, parallel testing, regression testing, stress testing, string testing, system testing, and unit testing (“Systems Development Life Cycle,” n.d.).

The implementation phase involves deploying approved applications to run the actual business. This phase includes training end users, installing the product, testing system and security parameters, and conducting post-implementation reviews. Post-implementation reviews should be conducted by management to validate the completion of project objectives. All personnel involved in the operational use of the product should be interviewed to identify and document any problems. New systems are often run in parallel with the old system until the accuracy and reliability of the new system can be verified (“Systems Development Life Cycle,” n.d.).

The maintenance phase involves the ongoing effort to constantly improve the product by making changes to the hardware, software, and documentation in order to support its operational effectiveness. Maintenance includes major modifications, routine changes, emergency changes, and software patches. All major modifications should be implemented by management using a well-structured process, such as an SDLC methodology (“Systems Development Life Cycle,” n.d.).

The SDLC methodology is the oldest methodology used for building information systems. It is a proven method but some would argue that the SDLC increases development time and cost. There are alternative approaches such as the Rapid Application Development (RAD) method which combines prototyping, Joint Application Development and CASE tools. RAD has some advantages over SDLC including reduced development cost, speed, and active user involvement (Post and Anderson, 2006). The maturity of an organization is a major determinate in implementing a methodology.

The CMM capability maturity model (Whitten, Bentley, & Dittman, 2004) is “A standardized framework for assessing the maturity level of an organization’s information systems development and management processes and products. It consists of five levels of maturity” (p. 84). In the CMM each level builds and expands on the level preceding it.

Most organizations start at Level 1. At this level projects don’t follow a consistent process. They may be unpredictable and tumultuous. Each team follows its own methods without regard for other teams. Projects typically encounter crises, are over budget, and behind schedule. Documentation is inconsistent which creates problems for anyone trying to manage the system (Whitten, Bentley, & Dittman, 2004).

In Level 2 the focus is on project management. Project management procedures are established to track project functionality, schedules, and cost. The system development process may vary from project to project but a process is always followed. Level 2 develops the foundation for the standardization that occurs in Level 3 (Whitten, Bentley, & Dittman, 2004).

Level 3 develops the system development process into a standard. All projects use the standard process to develop and maintain information systems and software. Consistently using standards will result in high-quality documentation and deliverables. The process is repeatable, stable, and predictable (Whitten, Bentley, & Dittman, 2004).

Measurable goals are set for quality and productivity in Level 4. The measures are collected routinely and stored in a database. This data is used to improve project management. Whenever a project encounters a problem, the process can be adjusted based on predictable and measurable impacts (Whitten, Bentley, & Dittman, 2004).

Level 5 consists of continually monitoring and improving based on the measures and data analysis that was developed in Level 4. Technology is changed as needed and the process itself can be adjusted to meet requirements. Lessons learned are shared across the organization with emphasis on eliminating inefficiencies while sustaining quality (Whitten, Bentley, & Dittman, 2004).

The CMM shows that organizational maturity is essential for development of processes and products. It follows that organizational maturity would be essential to any SDLC model. Using the two models together can develop standardization within an organization that will stimulate growth, increase operational efficiency, allow effective management, and ensure quality. Usually a few models are combined into a hybrid methodology to remain versatile and make the best fit for the project (“SDLC Resources from MKS,” n.d.).

References

(2000). Systems development life cycle from FOLDOC. Retrieved December 3, 2008, from Foldoc Web site: http://foldoc.org/foldoc.cgi?Systems+Development

+Life+Cycle

(2002, May 14). Quick study: systems development life cycle. Retrieved December 1, 2008, from http://www.computerworld.com/developmenttopics/development/

story/0,10801,71151,00.html

(2008). Systems development life cycle (SDLC) resources from MKS. Retrieved December 1, 2008, from http://www.mks.com/sdlc

(n.d.). Systems development life cycle. Retrieved December 1, 2008, from Federal Financial Institutions Examination Council : http://www.ffiec.gov/ffiecinfobase/booklets/d_a/08.html

Post, G., & Anderson, D. (2006). New York, NY: McGraw-Hill Companies, Inc.

Whitten, J. L., Bentley, L. D., & Dittman, K. C. (2004). New York, NY: McGraw-Hill Companies, Inc.

]]> http://timsteiner.wordpress.com/2009/01/06/systems-development-lifecycle-sdlc/feed/ 0 timsteiner http://timsteiner.wordpress.com/2008/09/11/cisco-ccie-project-part-3-configure-eompls-pseudowire/ http://timsteiner.wordpress.com/2008/09/11/cisco-ccie-project-part-3-configure-eompls-pseudowire/#comments Thu, 11 Sep 2008 23:37:01 +0000 timsteiner http://timsteiner.wordpress.com/?p=141 ]]> Cisco EoMPLS Pseudowire configuration

This document provides step-by-step instructions for setting up MPLS forwarding on an IP network.

Prerequisites

See Cisco CCIE Project Part 1- Configure the ATM Switched Virtual Circuit (SVC)

See Cisco CCIE Project Part 2 – Configure OSPF over ATM

See Cisco CCIE Project Part 3 – Configure MPLS Forwarding

Procedure

1. Complete all tasks in Cisco ATM lab configuration
2. Complete all tasks in Cisco routing OSPF over ATM configuration
3. Complete all tasks in Cisco MPLS Forwarding

1. Power on devices

1. Connect to Cisco 7200A via console cable

7200A#

conf t

pseudowire-class atom

encap mpls

7200B#

conf t

pseudowire-class atom

encap mpls

7200A#

conf t

int fa 2/0.1

encap dot1q 100

xconnect 10.10.10.101 123 pw-class atom

7200B#

conf t

int fa 2/0.1

encap dot1q 200

xconnect 10.10.10.102 123 pw-class atom

Verify

Issue command “show mpls l2transport vc” on both routers to ensure the layer 2 tunnel exists and make sure the status is up.

]]> http://timsteiner.wordpress.com/2008/09/11/cisco-ccie-project-part-3-configure-eompls-pseudowire/feed/ 0 timsteiner http://timsteiner.wordpress.com/2008/09/11/cisco-ccie-project-part-3-configure-mpls-forwarding/ http://timsteiner.wordpress.com/2008/09/11/cisco-ccie-project-part-3-configure-mpls-forwarding/#comments Thu, 11 Sep 2008 23:30:24 +0000 timsteiner http://timsteiner.wordpress.com/?p=137 ]]> Cisco Network Configuration for MPLS Forwarding

This document provides step-by-step instructions for setting up MPLS forwarding on an IP network.

Prerequisites

See Cisco CCIE Project Part 1- Configure the ATM Switched Virtual Circuit (SVC)

See Cisco CCIE Project Part 2 – Configure OSPF over ATM

Procedure

1. Complete all tasks in Cisco ATM lab configuration
2. Complete all tasks in Cisco routing OSPF over ATM configuration

1. Power on devices

1. Connect to Cisco 7200A via console cable

7200A#

conf t

mpls label protocol ldp

mpls ldp discovery targeted-hello accept

mpls ldp router-id Loopback0 force

!

Int loopback0

ip address 10.10.10.101 255.255.255.255

!

int fa 2/0

ip address 10.10.1.1

mpls ip

7200B#

conf t

mpls label protocol ldp

mpls ldp discovery targeted-hello accept

mpls ldp router-id Loopback0 force

!

Int loopback0

ip address 10.10.10.102 255.255.255.255

!

int fa 2/0

ip address 10.20.1.1

mpls ip

Verify

A message should pop-up stating that the LDP link is up. To verify this issue command “show mpls ldp neighbor.”

In part 1 of this project we set up an ATM VC and we were able to ping from one router to the other. Now we will set up OSPF routing so that we can share routes between the 2 7200 routers over the ATM link.

This document provides step-by-step instructions for setting up OSPF to connect over an ATM VC

Prerequisites

See Part 1 Configure the ATM Switched Virtual Circuit (SVC)

Procedure

1. Complete all tasks in Configure the ATM Switched Virtual Circuit (SVC)

1. Power on devices

1. Connect to Cisco 7200A via console cable

7200A#

conf t

interface fa2/0

ip address 10.10.1.1 255.255.255.0

no shut

!

router ospf 1

network 10.0.0.0 0.255.255.255 area 0

neighbor 10.1.1.2

*NOTE THE NEIGHBOR COMMAND MUST BE DONE MANUALLY FOR 7200A TO BE ABLE TO FIND AND ROUTE TO 7200B.

7200B#

conf t

interface fa2/0

ip address 10.20.1.1 255.255.255.0

no shut

!

router ospf 1

network 10.0.0.0 0.255.255.255 area 0

neighbor 10.1.1.1

Verify

Both routers should now list remote routes. This can be verified using the “show ip route” command. You should be able to ping 10.20.1.2 from 10.10.1.2, and be able to ping 10.10.1.2 from 10.20.1.2.

IP over ATM Network Diagram

This document provides step-by-step instructions for setting up an ATM switched virtual circuit (SVC) using Cisco static mapping. This configuration will allow the router of one end to ping the router of the other end over an ATM Virtual Circuit.

Requirements

· (2) console cables

· PC with serial connection

· (3) bidirectional multi-mode fiber cables

· (2) Cisco 7200 routers (with ATM module installed)

· (2) Cisco LightStream 1010 switches (with ATM module installed)

Network Diagram

See “ATM Network.vsd”

Procedure

1. Connect network devices as described in diagram.

Cisco 7200A => Cisco 1010A => Cisco 1010B => Cisco 7200B

1. Power on devices

1. Connect to Cisco 7200A via console cable

Router> en

Router# conf t

Router# hostname 7200A

7200A#

1. Connect to Cisco 7200B via console cable

Router> en

Router# conf t

Router# hostname 7200B

7200B#

1. Connect to Cisco 1010A via console cable

Switch> en

Switch# conf t

Switch# hostname 1010A

1010A#

1. Connect to Cisco 1010B via console cable

Switch> en

Switch# conf t

Switch# hostname 1010B

1010B#

Configure Static Mapping on Cisco 7200 router A

7200A#

conf t

interface ATM4/0

no ip address

no atm ilmi-keepalive

pvc 0/5 qsaal

!

pvc 0/16 ilmi

!

!

interface ATM4/0.1 multipoint

ip address 10.1.1.1 255.255.255.0

atm esi-address 111111111111.11

!

svc SVC1 nsap 47.00918100000000b06494ee01.222222222222.22

protocol ip 10.1.1.2

broadcast

encapsulation aal5snap

***PLEASE NOTE – the first part of the number after nsap is going to be different for you. This is unique for each router.

7200A# show atm ilmi-status

Interface : ATM4/0 Interface Type : Private UNI (User-side)

ILMI VCC : (0, 16) ILMI Keepalive : Disabled

ILMI State: UpAndNormal

Peer IP Addr: 10.118.1.166 Peer IF Name: ATM10/1/1

Peer MaxVPIbits: 8 Peer MaxVCIbits: 14

Active Prefix(s) :

47.009181000000001011bcbb01

End-System Registered Address(s) :

47.009181000000001011bcbb01.1111.1111.1111.11(Confirmed)

Configure Static Mapping on Cisco 7200 router B

7200B#

conf t

interface ATM3/0

no ip address

no atm ilmi-keepalive

pvc 0/16 ilmi

!

pvc 0/5 qsaal

!

!

interface ATM3/0.1 multipoint

ip address 10.1.1.2 255.255.255.0

no ip directed-broadcast

atm esi-address 222222222222.22

!

svc SVC1 nsap 47.009181000000001011bcbb01.111111111111.11

protocol ip 10.1.1.1

broadcast

encapsulation aal5snap

***PLEASE NOTE – the first part of the number after nsap is going to be different for you. This is unique for each router.

7200B# show atm ilmi-status

Interface : ATM3/0 Interface Type : Private UNI (User-side)

ILMI VCC : (0, 16) ILMI Keepalive : Disabled

ILMI State: UpAndNormal

Peer IP Addr: 0.0.0.0 Peer IF Name: ATM4/1/2

Peer MaxVPIbits: 8 Peer MaxVCIbits: 14

Active Prefix(s) :

47.0091.8100.0000.00b0.6494.ee01

End-System Registered Address(s) :

47.0091.8100.0000.00b0.6494.ee01.2222.2222.2222.22(Confirmed)

7200B# show atm map

Map list SVC1_ATM3/0.1 : PERMANENT

ip 10.1.1.1 maps to NSAP 4747.009181000000001011bcbb01.111111111111.11

, broadcast, connection up, VC 30, VPI 0, VCI 61, ATM3/0.1

7200B# show atm vc

VCD / Peak Avg/Min Burst

Interface Name VPI VCI Type Encaps Kbps Kbps Cells Sts

3/0 2 0 5 PVC SAAL 155000 UP

3/0 1 0 16 PVC ILMI 155000 UP

7200B# ping 10.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:

2d00h: ATMSIG: Called len 20

2d00h: ATMSIG: Calling len 20

2d00h: ATMSIG(ATM1/1/0 0,0 – 0001/00): (vcnum:0) build Setup msg,

Null(U0) state

2d00h: ATMSIG(ATM3/0 0,0 – 0001/00): (vcnum:0) API – from sig-client

ATM_OWNER_SMAP

2d00h: ATMSIG(ATM3/0 0,0 – 0001/00): (vcnum:0) Input event :

Req Setup in Null(U0)

2d00h: ATMSIG(ATM3/0 0,0 – 0001/00): (vcnum:0) Output Setup msg(XferAndTx),

Null(U0) state

2d00h: ATMSIG: Called Party Addr:

4747.009181000000001011bcbb01.111111111111.11

2d00h: ATMSIG: Calling Party Addr:

47.0091.8100.0000.00b0.6494.ee01.222222222222.22

2d00h: ATMSIG(ATM1/1/0 0,0 – 0001/00): (vcnum:0) Null(U0) -> Call Initiated(U1)

2d00h: E164 NOT Converted

2d00h: ATMSIG(ATM3/0 0,0 – 0001/00): (vcnum:0) Input event : Rcvd Call

Proceeding in Call Initiated(U1)

2d00h: ATMSIG(ATM3/0 0,37 – 0001/00): (vcnum:0) Call Initiated(U1)

-> Outgoing Call Proceeding(U3)

2d00h: ATMSIG(ATM3/0 0,37 – 0001/00): (vcnum:0) Input event : Rcvd Connect

in Outgoing Call Proceeding(U3)

2d00h: ATMSIG(ATM3/0 0,37 – 0001/00): (vcnum:36) Input event : Req Connect

Ack in Outgoing Call Proceeding(U3)

2d00h: ATMSIG(ATM3/0 0,37 – 0001/00): (vcnum:36) Output Connect Ack msg,

Outgoing Call Proceeding(U3) state

2d00h: ATMSIG(ATM3/0 0,37 – 0001/00): (vcnum:36) Outgoing Call Proceeding(U3)

-> Active(U10)

2d00h: ATMSIG(ATM3/0 0,37 – 0001/00): (vcnum:36) API – notifying Connect event

to client ATM3/0.1

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms

7200A#

***NOTE: THE PING SUCCESS RATE IS ONLY 80% THE FIRST TIME. THIS IS DUE TO THE INITIAL SETUP OF THE LINK.

Verify

A layer 3 connection now exists between 7200A and 7200B. You should be able to ping 10.1.1.2 from 7200A and be able to ping 10.1.1.1 from 7200B.

Disclaimer

Now I do not claim to be a CCIE, in fact I do not even have any Cisco certs. The following configuration has been tested to provide end-to-end layer 2 connectivity. I am aware that there may be other ways of setting this up. If you know of other better methods feel free to comment on this post.

Background info

I recently started a new job and made the mistake of including Cisco experience on my resume. Having never even finished my CCNA I am not what I would consider a Cisco expert but I am always up for a challenge. Well my first project at my new job was to set up 2 Cisco 7200 VXR routers and 2 Cisco 1010 lightStream Switches over ATM. Furthermore, this ATM link needs to be able to route IP traffic and there needs to a pseudowire that connects end-to-end and simulates an Ethernet LAN. So thats the plan. I spent the next day or two doing research and experimenting with router configs until I got something that works.

Here is basically how the devices are set up, each connected via ATM over multimode fiber.

Cisco 7200A => Cisco 1010A => Cisco 1010B => Cisco 7200B

This project will be broken down into 5 parts

1. CCIE Project Part 1- Configure the ATM Switched Virtual Circuit (SVC)

2. Cisco CCIE Project Part 2 – Configure OSPF over ATM

3. Cisco CCIE Project Part 3 – Configure MPLS Forwarding

4. Cisco CCIE Project Part 3 – Configure EoMPLS Pseudowire

5. Configure CE (Customer Edge) Devices

Glossary

ATM – Asyncronous Transfer Mode

OSPF – Open Shortest Path First

EoMPLS – Ethernet over MPLS

I did some research and think the best solution will be to purchase an EV-DO router. It would be worth the investment and save lots of time setting the network up. There are other options but if you are planning to use the Verizon Broadband connection long term it is a great investment.

Solution #1) EV-DO Routers

http://www.dlink.com/products/?pid=524

http://www.kyocera-wireless.com/kr1-router/

Solution #2) Share the Verizon connection with a Windows XP/Vista PC and a typical 802.11x wireless router

My friend had an issue where he had a Verizon card, but was only able to get signal in one part of the house. He asked me if there was any way to hook a wireless router so that he could use the Verizon broadband connection from anywhere in the house on his laptop. This is how it works.

This solution involves using a computer that will stay on all the time and route traffic into the verizon card.

1) Share the Verizon connection -> go to the properties of the Verizon connection -> under sharing select the check box that says “allow other network users to connect through this computers internet connection.” -> Select the home network connection to be “local area connection” (the connection you will plug the wireless router into) -> Under settings select all services check boxes (advanced users select only the ones you use)

2) Open the command prompt by clicking on START -> Run -> type in “cmd” and press enter

3) Type the following command into the command prompt “ipconfig/all”

4) Get out a paper and pencil and copy down the following information from your Verizon connection:

• default gateway =
• dns server 1= , dns server 2 =

5) Go to the properties of your local area connection -> Select Internet protocol (IP v4) -> Select properties -> input the default gateway and dns information into the corresponding field.

6) Connect to the internet through your Verizon card. Now plug in a wireless router (with default settings) to your LAN port. If the settings are configured correctly you should have access to the internet when connected wirelessly or wired to the router.