The Traffic Mapping Configuration Attribute Information Technology Essay

1808 words (7 pages) Essay

1st Jan 1970 Information Technology Reference this

Disclaimer: This work has been submitted by a university student. This is not an example of the work produced by our Essay Writing Service. You can view samples of our professional work here.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UKEssays.com.

The rapid growth of todays enterprise network has made the networking environment very complex. This has resulted to difficulty in the maintenance and troubleshooting of networks and has increased the need for specialized networking tools for analysis of complex communication networks.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!

Find out more

OPNET Modeller enables one to create a hypothetical network consisting of relevant protocols. Switches, Routers, web servers and almost everything set up in real network can be duplicated in an OPNET Modeller virtual network. Any virtual network can be manipulated in several ways by adding or removing routers and web servers, altering protocols etc. The effects of diverse alterations and configurations in different scenarios can be quantifiably and usefully examined and analyzed. The figure 3 below shows the functionality and characteristics of OPNET simulation tool. OPNET has three categories: a) hierarchical model building, b) Running Simulations and c) Analyzing results (Mohd and Abdullah, 2008). The academic version of OPNET IT Guru software was utilized to test the network model created in this paper.

Fig 3.0 Functionality and Characteristics of OPNET Architecture

(Source: Mohd & Abdullah., 2008)

3.1 TEST MODEL DEVELOPEMENT

The network topology used in this paper was designed to emulate, as nearly as possible, a real enterprise network. OPNET Modeller 15 was used for the simulation using OPNET MPLS models obtainable in the OPNET Model Library. The main aim of the model testing was to specifically investigate to what extent, if any, IPSec VPN network would impact on an existing MPLS enterprise network. In order to achieve this, a network with the following components was prototyped. All the links were connected with PPP_DS1 link. The core network consists of three LSRs. The LERs and LSRs are MPLS enabled and have been configured in such a way that switching algorithms and label mapping are enabled only when LSPs are defined. If LSPs are not defined, the routers will us the routes advertised by dynamic routing protocol running on the interfaces of the routers. In terms of result, the following metrics will be used for comparison and analysis purpose:

Delay (sec) represents end-to-end delay which is the summation of all delays.

Utilization represents percentage of the consumption of an available channel bandwidth where a value of 100.0 would indicate full usage.

The methodology used in setting up the network can be found in appendix 1. In Scenario 1, the network does not have any LSPs meaning that there was no MPLS-TE. The goal was to obtain a baseline results. In scenario 2, the baseline topology was duplicated and MPLS-TE was configured in the network. IPSec was then deployed with in Scenario 3. In the final scenario, the heavy servers where changed to light servers to really make comparison of the effect of heavy load the network.

3.1.1. Basic Components for the implementation of the Scenario

The basic components used for the implementation of the network mentioned above are listed in the table below (see Table.3).

Component

Palette

Application Configuration

Internet_toolbox

Profile Configuration

Internet_toolbox

Ethernet2_Slip8_LER

MPLS object Palette

PPP_DS3

MPLS object Pallete

Ethernet2_Slip8_LSR

MPLS object Pallete

MPLS_E-LSP_DYNAMIC

MPLS object Pallete

PPP_DS1

MPLS object Pallete

PPP_Servers_adv

MPLS object Pallete

MPLS Configuration

MPLS object Palette

Table: Components of the network

The figure below shows the network created with the components. The edge network on the source and destination consist of an LER connected to the core. The core network consists of five LSRs connected using PPP_DS3 links. The links used between the LERs to the workstation and servers are PPP_DS1 links.

Fig: Baseline Network Topology

All the routers (LSRs and LERs) in the baseline topology are MPLS enabled but are configured in such a way that label mapping and switching algorithms are only enabled when LSPs are defined. The Database application was configured on workstation 1, FTP application on workstation 2 and Web & Email application on workstation 3 to drive the network performance simulation.

3.2 MODELLING MPLS IN A NETWORK

The configuration of MPLS in a network has three steps. This process must be carried out before one can run a simulation using MPLS.

LSPs must be created in the network

FEC and traffic trunks must be created in the MPLS configuration Object

LERs must be configured to direct packets into the appropriate LSPs.

3.2.1 MODEL ATTRIBUTES

The global MPLS attributes used to configure to configure this MPLS parameters are grouped in the MPLS configuration object.

Creating LSPs

OPNET modeller supports static and dynamic LSPs using strict and loose path objects in the OPNET. MPLS_E-LSP_DYNAMIC was used to create the LSP manually. To do this, the ingress and egress LERs of the LSP were specified. Starting from the ingress LER, the required intermediate routers for the LSP path were selected which terminated at the egress LER. This method marks that selected routers or link that must be used when routing packets in an LSP. When LSPs are defined newly, details of the LSP need to be updated in the modeller using “Protocols>MPLS>Update LSP Details”. However, the ingress LER looks for an alternate route to if the link or node marked as strict fails using backup LSP, if one exist. The figure below shows the two dynamic LSP, representing LER1ƒ LER2. The coloured lines show the MPLS data path created by label management protocols and they are LER1->LSR3->LSR4->LER2 and LER1->LSR2->LER2.

Find out how UKEssays.com can help you!

Our academic experts are ready and waiting to assist with any writing project you may have. From simple essay plans, through to full dissertations, you can guarantee we have a service perfectly matched to your needs.

View our services

Defining FEC profiles

Both FECs and traffic trunks in a network are defined in MPLS configuration object. FECs help to classify and group packets. This makes it possible for all packets in a group to be forwarded the same way. For any packet to qualify for a particular FEC, the IP header fields must meet the condition of at least one row of the FEC. The following IP header fields: ToS, Protocol, Source Address Range, Destination Address Range, Source Port, and Destination can all be used to define FEC. Right click on MPLS configuration object ƒ  Edit attributes ƒ  FEC specification. Two FECs were defined in the topology. Figure below shows the attribute sequence for defining an FEC.

Fig: Specifying FEC Attributes

Creating Traffic Trunks

Traffic trunk specifies out-of -profile actions and traffic classes for traffic trunks in the network. It helps to capture traffic characteristics such as average rate, peak rate and average burst rate size. At least one traffic trunk is required for the MPLS model to handle traffic. Two trunks where created in the MPLS configuration object as shown in figure below

Fig Traffic Trunk Profiles

EXP<--> Drop Precedence and EXP<-->PHB

The attributes states how EXP bits in the MPLS shim header are translated into diffserv information at each LSR. The default setting was used.

3.2.2 ROUTER ATTRIBUTES

The router specific MPLS attributes configured are grouped in the MPLS parameters attribute on each LER router.

Traffic Mapping Configuration Attribute

This indicates bindings between FECs and LSPs. Each row of the table specifies a distinct traffic engineering binding. Each of the traffic engineering binding specifies the traffic trunk, FEC and LSP applied to the label of incoming packets. The following order takes place when an unlabelled packet enters the ingress LER to establish the correct label for the packet.

The Traffic engineering binding is chosen based on the packet FEC and incoming interface

The packed is assessed to make sure that the traffic characteristics match to those specified for traffic engineering binding’s traffic trunk.

The packet is then labelled and sent across the primary LSP specified for the traffic engineering binding.

3.3 SIMULATION OF MPLS NETWORK

The figure below shows the three different simulation options in Modeller.

Figure: Simulation Options in Modeller

Included in with the University licence is the DES option and it provides a high-fidelity result for studies requiring per packet simulation analysis. DES supports hybrid simulation which can model analytical and discrete traffic providing detailed results for targeted traffic flows enabling greater runtime if fine tuned. The simulation was set to run for 1 hr after setting the following IP Global Attribute parameters in the DES.

CONFIGURING IPSEC IN THE NETWORK

Security Association between the two LERs were conducted and transport mode was used because the security is site-to-site. The parameters of SA called Phase 1 IKE SA were set. The proposals made during this phase appear in IKE Proposals under OPNET Modeller. The purpose was for authentication and the exchange of secret keys. Only one proposal was configured for the purpose of simplicity. The global properties that will act on all proposals were first configured. For the authentication algorithms, MD5 was chosen because it requires fewer resources than SHA-1. The authentication method to be applied to the SA was indicated. 3DES was chosen for encryption algorithm to be used in this first phase to generate secret key through the Diffie-Hellman (DH).

The policy implemented during the first stage was specified in the second step. Aggressive mode was chosen from the “IKE Policies” attribute. The name of the proposal on which this policy will work, and the authentication method to be exchanged in the first phase were indicated.

In terms of results analysis, we will focus on the throughput (in bits/sec) collected at the outgoing interfaces to the various destinations from the egress LER. Various other metrics that can also be analyzed for the above network include application response time, number of TCP retransmissions, traffic dropped in the core of the network due to congestions, etc.

B Performance Metrics

We use the following metrics for comparison and

analysis purpose:

_ Delay (sec) represents end-to-end delay. It is the

summation of all delays discussed in previous

section.

_ Throughput (pps) represents the total number of

packets forwarded to higher layers per second.

_ Utilization represents percentage of the

consumption of an available channel bandwidth

where a value of 100.0 would indicate full usage.

The rapid growth of todays enterprise network has made the networking environment very complex. This has resulted to difficulty in the maintenance and troubleshooting of networks and has increased the need for specialized networking tools for analysis of complex communication networks.

OPNET Modeller enables one to create a hypothetical network consisting of relevant protocols. Switches, Routers, web servers and almost everything set up in real network can be duplicated in an OPNET Modeller virtual network. Any virtual network can be manipulated in several ways by adding or removing routers and web servers, altering protocols etc. The effects of diverse alterations and configurations in different scenarios can be quantifiably and usefully examined and analyzed. The figure 3 below shows the functionality and characteristics of OPNET simulation tool. OPNET has three categories: a) hierarchical model building, b) Running Simulations and c) Analyzing results (Mohd and Abdullah, 2008). The academic version of OPNET IT Guru software was utilized to test the network model created in this paper.

Fig 3.0 Functionality and Characteristics of OPNET Architecture

(Source: Mohd & Abdullah., 2008)

3.1 TEST MODEL DEVELOPEMENT

The network topology used in this paper was designed to emulate, as nearly as possible, a real enterprise network. OPNET Modeller 15 was used for the simulation using OPNET MPLS models obtainable in the OPNET Model Library. The main aim of the model testing was to specifically investigate to what extent, if any, IPSec VPN network would impact on an existing MPLS enterprise network. In order to achieve this, a network with the following components was prototyped. All the links were connected with PPP_DS1 link. The core network consists of three LSRs. The LERs and LSRs are MPLS enabled and have been configured in such a way that switching algorithms and label mapping are enabled only when LSPs are defined. If LSPs are not defined, the routers will us the routes advertised by dynamic routing protocol running on the interfaces of the routers. In terms of result, the following metrics will be used for comparison and analysis purpose:

Delay (sec) represents end-to-end delay which is the summation of all delays.

Utilization represents percentage of the consumption of an available channel bandwidth where a value of 100.0 would indicate full usage.

The methodology used in setting up the network can be found in appendix 1. In Scenario 1, the network does not have any LSPs meaning that there was no MPLS-TE. The goal was to obtain a baseline results. In scenario 2, the baseline topology was duplicated and MPLS-TE was configured in the network. IPSec was then deployed with in Scenario 3. In the final scenario, the heavy servers where changed to light servers to really make comparison of the effect of heavy load the network.

3.1.1. Basic Components for the implementation of the Scenario

The basic components used for the implementation of the network mentioned above are listed in the table below (see Table.3).

Component

Palette

Application Configuration

Internet_toolbox

Profile Configuration

Internet_toolbox

Ethernet2_Slip8_LER

MPLS object Palette

PPP_DS3

MPLS object Pallete

Ethernet2_Slip8_LSR

MPLS object Pallete

MPLS_E-LSP_DYNAMIC

MPLS object Pallete

PPP_DS1

MPLS object Pallete

PPP_Servers_adv

MPLS object Pallete

MPLS Configuration

MPLS object Palette

Table: Components of the network

The figure below shows the network created with the components. The edge network on the source and destination consist of an LER connected to the core. The core network consists of five LSRs connected using PPP_DS3 links. The links used between the LERs to the workstation and servers are PPP_DS1 links.

Fig: Baseline Network Topology

All the routers (LSRs and LERs) in the baseline topology are MPLS enabled but are configured in such a way that label mapping and switching algorithms are only enabled when LSPs are defined. The Database application was configured on workstation 1, FTP application on workstation 2 and Web & Email application on workstation 3 to drive the network performance simulation.

3.2 MODELLING MPLS IN A NETWORK

The configuration of MPLS in a network has three steps. This process must be carried out before one can run a simulation using MPLS.

LSPs must be created in the network

FEC and traffic trunks must be created in the MPLS configuration Object

LERs must be configured to direct packets into the appropriate LSPs.

3.2.1 MODEL ATTRIBUTES

The global MPLS attributes used to configure to configure this MPLS parameters are grouped in the MPLS configuration object.

Creating LSPs

OPNET modeller supports static and dynamic LSPs using strict and loose path objects in the OPNET. MPLS_E-LSP_DYNAMIC was used to create the LSP manually. To do this, the ingress and egress LERs of the LSP were specified. Starting from the ingress LER, the required intermediate routers for the LSP path were selected which terminated at the egress LER. This method marks that selected routers or link that must be used when routing packets in an LSP. When LSPs are defined newly, details of the LSP need to be updated in the modeller using “Protocols>MPLS>Update LSP Details”. However, the ingress LER looks for an alternate route to if the link or node marked as strict fails using backup LSP, if one exist. The figure below shows the two dynamic LSP, representing LER1ƒ LER2. The coloured lines show the MPLS data path created by label management protocols and they are LER1->LSR3->LSR4->LER2 and LER1->LSR2->LER2.

Defining FEC profiles

Both FECs and traffic trunks in a network are defined in MPLS configuration object. FECs help to classify and group packets. This makes it possible for all packets in a group to be forwarded the same way. For any packet to qualify for a particular FEC, the IP header fields must meet the condition of at least one row of the FEC. The following IP header fields: ToS, Protocol, Source Address Range, Destination Address Range, Source Port, and Destination can all be used to define FEC. Right click on MPLS configuration object ƒ  Edit attributes ƒ  FEC specification. Two FECs were defined in the topology. Figure below shows the attribute sequence for defining an FEC.

Fig: Specifying FEC Attributes

Creating Traffic Trunks

Traffic trunk specifies out-of -profile actions and traffic classes for traffic trunks in the network. It helps to capture traffic characteristics such as average rate, peak rate and average burst rate size. At least one traffic trunk is required for the MPLS model to handle traffic. Two trunks where created in the MPLS configuration object as shown in figure below

Fig Traffic Trunk Profiles

EXP<--> Drop Precedence and EXP<-->PHB

The attributes states how EXP bits in the MPLS shim header are translated into diffserv information at each LSR. The default setting was used.

3.2.2 ROUTER ATTRIBUTES

The router specific MPLS attributes configured are grouped in the MPLS parameters attribute on each LER router.

Traffic Mapping Configuration Attribute

This indicates bindings between FECs and LSPs. Each row of the table specifies a distinct traffic engineering binding. Each of the traffic engineering binding specifies the traffic trunk, FEC and LSP applied to the label of incoming packets. The following order takes place when an unlabelled packet enters the ingress LER to establish the correct label for the packet.

The Traffic engineering binding is chosen based on the packet FEC and incoming interface

The packed is assessed to make sure that the traffic characteristics match to those specified for traffic engineering binding’s traffic trunk.

The packet is then labelled and sent across the primary LSP specified for the traffic engineering binding.

3.3 SIMULATION OF MPLS NETWORK

The figure below shows the three different simulation options in Modeller.

Figure: Simulation Options in Modeller

Included in with the University licence is the DES option and it provides a high-fidelity result for studies requiring per packet simulation analysis. DES supports hybrid simulation which can model analytical and discrete traffic providing detailed results for targeted traffic flows enabling greater runtime if fine tuned. The simulation was set to run for 1 hr after setting the following IP Global Attribute parameters in the DES.

CONFIGURING IPSEC IN THE NETWORK

Security Association between the two LERs were conducted and transport mode was used because the security is site-to-site. The parameters of SA called Phase 1 IKE SA were set. The proposals made during this phase appear in IKE Proposals under OPNET Modeller. The purpose was for authentication and the exchange of secret keys. Only one proposal was configured for the purpose of simplicity. The global properties that will act on all proposals were first configured. For the authentication algorithms, MD5 was chosen because it requires fewer resources than SHA-1. The authentication method to be applied to the SA was indicated. 3DES was chosen for encryption algorithm to be used in this first phase to generate secret key through the Diffie-Hellman (DH).

The policy implemented during the first stage was specified in the second step. Aggressive mode was chosen from the “IKE Policies” attribute. The name of the proposal on which this policy will work, and the authentication method to be exchanged in the first phase were indicated.

In terms of results analysis, we will focus on the throughput (in bits/sec) collected at the outgoing interfaces to the various destinations from the egress LER. Various other metrics that can also be analyzed for the above network include application response time, number of TCP retransmissions, traffic dropped in the core of the network due to congestions, etc.

B Performance Metrics

We use the following metrics for comparison and

analysis purpose:

_ Delay (sec) represents end-to-end delay. It is the

summation of all delays discussed in previous

section.

_ Throughput (pps) represents the total number of

packets forwarded to higher layers per second.

_ Utilization represents percentage of the

consumption of an available channel bandwidth

where a value of 100.0 would indicate full usage.

Cite This Work

To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Related Services

View all

DMCA / Removal Request

If you are the original writer of this essay and no longer wish to have your work published on the UKDiss.com website then please: