Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

No index entries found.

Network Reports

Demand Reports


Demand Path & Diversity Report


The Demand Path & Diversity Report lists all user demand requirements in the network, with demand ID, origination, destination, bandwidth, type, priority, preempt priority, path routing, and distance metrics. The output file that is written to the output directory is called “PATHRPT.runcode”.

Figure 179: The Path and Diversity Report in a Frame Relay Network

The Path and Diversity Report in a Frame Relay Network

Field

Description

FlowID/PVCID

The ID of the demand. (Column name varies with hardware modules.)

From_Node_Name

The full name of the origination node of the demand.

From_Domain/From_Area

The domain at which the demand originates, if any.

From_Node#

The ID of the origination node of the demand.

From_Country

The country in which the origination node resides.

Card

The name of the card which the demand is connected to; the card slot position that the demand/flow uses.

Port

The port number of the card which the demand is connected to; the port associated with the card the demand/flow uses

To_Node_Name

The full name of the destination node of the demand.

To_Domain/To_Area

The domain at which the demand is destined for, if any.

To_Node#

The ID of the destination node of the demand.

To_Country

The country in which the destination node resides.

Card

The name of the card which the demand is connected to; the card slot position that the demand/flow uses

Port

The port number of the card which the demand is connected to; the port associated with the card the demand/flow uses

Bandwidth

The amount of bandwidth allocated to the selected demand.

Type

The type of the demand, whether it is a data demand (R) or voice demand (V), and the direction of the demand (A-Z, Z-A).

Terrestrial

The demand's preference for terrestrial media. Valid entries include: Don't Care, Required, Prefer, Prefer Not, and Avoid. Note that this parameter is used in route biasing and may not actually reflect true media characteristics.

Fiber

The demand's preference for fiber media. Valid entries include: Don't Care, Required, Prefer, Prefer Not, and Avoid. Note that this parameter is used in route biasing and may not actually reflect true media characteristics.

Encrypted

The demand's preference for encryption media. Valid entries include: Don't Care, Required, Prefer, Prefer Not, and Avoid. Note that this parameter is used in route biasing and may not actually reflect true media characteristics.

Pri, PrePri

The priority field of the demand specification consists of two numbers separated by a comma (,), or a forward-slash (/). The first number defines the call priority of the demand, and the second number the preempt priority of the demand. The preempt priority should be at the same or lower priority as the call priority of the demand. It is assumed that this demand can bump any of the demand with call priority lower than the preempt priority.

Actual_Path

The current path (routing) of the demand.

Route_Cost

This field displays the sum of the metrics (administrative weights) of the links that the demand traverses. For asymmetric demands, two separate rows are used to show the metric, one for each direction. Note that the default metric of a link depends upon the routing method set in the Tools > Options > Design window, Design>Path Placement options pane.

Delay

When the program performs path placement and is trying to find the best route for a call, delay metrics are examined to determine the desirability/undesirability of a link. Two delay metrics are supported, one for each direction of the trunk. If asymmetric delay metrics are not supported by the hardware, the second delay is marked as '-'. If a delay metric is not defined for a trunk, a default delay is calculated based on propagation delay and serialization delay.

Geo_Dist(Mile)

Specifies the sum of the actual mileage distance of links in the current path.

#Hop

Specifies the total number of hops of the current path.

OnPrefRt/Path_Violation

Specifies if the demand could not be routed on the specified path.

Media_Error

Specifies if the demand could not be routed on the specified media (terrestrial, fiber, encrypted).

Comment

Any user-specified comments.

DivLevel/DivGroup

Group name for demands that are to be diverse from each other.


CoS Demands Report


The CoS Demands Report provides information on interface load and queueing delays for the demands of the selected CoS class in the network. See the Router Feature Guide For NPAT and IP/MPLSView for details on the Class of Service feature.

The output file that is written to the output directory is called “DEMANDCOS.runcode”.

Figure 180: The CoS Demands Report

The CoS Demands Report
  • Normal or Peak: Normal traffic means the network does not experience any failure/outages. Peak means that failure simulation reports are going to be used.
  • CoS Classes: Select all or one specific class of traffic. Reports can be issued for all classes of traffic or for a particular one (for example, the priority class).
  • Period: Select planned, worst, all, or a specific time period (from traffic load files). Planned means the report is generated using the interface load calculated based on the demand file values. Worst means that the report is generated using the interface load calculated based on the worst traffic load.

Field

Description

DemandName

The name of the demand.

NodeA

The originating node of the demand.

NodeZ

The terminating node of the demand.

BW

The bandwidth of the demand.

Type

The type of the demand, whether it is a data demand (R) or voice demand (V), and the direction of the demand (A-Z, Z-A).

Policy Class

The policy class to which the demand belongs.

Dir

The direction of the demand: A2Z, Z2A.

PropDelay(ms)

The sum of node delay and link propagation delay for nodes and links in the path. Delay at the first node is not included.

#Hop

Specifies the total number of hops of the current path.

CodecPktDelay

Specifies the Codec Packet Delay

Planned Load

The bandwidth defined in the demand’s bandwidth field. The amount of bandwidth planned for this demand.

Planned QDelay(ms)

The queueing delay based on the planned load and CoS policies.

Planned DropBW

The planned drop bandwidth for this demand

Planned Jitter

The jitter as defined by the standard deviation of the total path delay.

Worst Load

The highest bandwidth among the load in all the traffic periods.

Worst QDelay

The highest queueing delay value among all the traffic periods.

Worst DropBW

The highest dropped bandwidth among all the traffic periods.

1, 2, ... Load

The bandwidth of the demand in the specified time period.

1, 2, ... QDelay

The queueing delay in the specified time period.

1, 2, ... DropBW

The dropped bandwidth in the specified time period.


Demand Route Cost Report


The Demand Route Cost Report provides cost information for each demand based on the demand’s route. Each entry is a demand in the network. The report specifies details of each demand, its total cost, and the breakdown of the cost by each link that it passes through.

The output file that is written to the output directory is called “CKTCOST_RT.runcode”.

Figure 181: The Demand Route Cost Report

The Demand Route Cost Report
##############################################################
# COST REPORT FOR DEMANDS File=CKTCOST_RT.x
##############################################################
##
# Currency= DL(American Dollar), DistUnit=mile
Ratedir = /u/wandl/db/rates/default
# Calculation Method: utilization cost according to demand routes
# i.e. Demand cost = Sum of (bandwidth/link_cap)*(link cost)
# for links in the path
#

Equal Cost Multi-Path Report


The Equal Cost Multi-Path Report displays all the equal cost multiple-paths in the network. It lists each set of equal cost paths, displaying the originating and destinating nodes, and the hop-by-hop paths. See the Router Feature Guide For NPAT and IP/MPLSView for details on the ECMP feature. The output file that is written to the output directory is called “EQPATHRPT.runcode”.

Figure 182: The Equal Cost Multi-Path Report

The Equal Cost Multi-Path Report

Note: ECMP paths are calculated based on IGP routing, but the actual path placement will also take into consideration MPLS Traffic Engineering Tunnels.

* Notations:
* & : Same site
* - : Intra-LATA or Intra-Country
* -- : Inter-LATA or Inter-Country
* = : Intra-LATA or Intra-Country, Second vendor or linktype
* == : Inter-LATA or Inter-Country, Second vendor or linktype.
* @ : Intra-LATA or Intra-Country, Inter-domain
* @@ : Inter-LATA or Inter-country, Inter-domain
* -*- : Link missing or not enough bandwidth

Link Reports


Planned Link Utilization Report


The Planned Utilization Report lists comprehensive link and bandwidth information for the network. The output file that is written to the output directory is called “LKUTIL.runcode”.

Figure 183: The Planned Link Utilization Report, LKUTIL

The Planned Link Utilization Report, LKUTIL

Field

Description

Linkname

The name of the link.

dir

The direction of the link.

Anode

The origination node of the link.

Znode

The destination node of the link.

Type

The type of trunk being used. The trunk type is subsequently used in determining link pricing and bandwidth availability.

TrunkBw

The total bandwidth of the link from nodes A to Z. This is also the sum of the AvailBW, UsedBW and Ovhd values.

AvailBW

The available amount of unutilized bandwidth between nodes A and Z.

UsedBW

The amount of bandwidth actually used by the demand requirements between nodes A and Z.

Ovhd

The amount of reserved bandwidth for overhead. (TotalBw = AvailBw + UsedBw + Ovhd)

UtilPct

The utilization of this link calculated by (UsedBW+Ovhd)/TotalBW.

nDemand/ncall

The number of demands routed on or through the link.


Planned Physical Interface Utilization


The Planned Physical Interface Utilization Report provides utilization statistics for each physical interface in the network. The output file that is written to the output directory is called “PHYUTIL.runcode”.

Figure 184: Planned Physical Interface Utilization

Planned Physical Interface Utilization

Demand Traffic Versus Interface Traffic


The Demand Traffic vs Interface Traffic report merges together the Measured Link Utilization and the Interface Traffic reports and compares them.

In Layer 3, the Compared Link Utilization report is used to compare the link utilizations computed from the traffic load versus that computed from the interface traffic. For each of the 24 periods, the difference between the link utilization computed from the interface traffic and from the traffic load is calculated and displayed in the Diff (intf - Demand) columns for each period and for the worst period and the average of the periods.

In Layer 2, the Compared Link Utilization report is used to compare the link utilizations computed from the tunnel traffic load versus that computed from the interface traffic.

Figure 185: Compared Link Utilization Report

Compared Link Utilization Report

CoS Links Report


The CoS Links Report provides information on interface load and queueing delays for links of the selected CoS class(es). See the Router Feature Guide For NPAT and IP/MPLSView for details on this feature. The output file that is written to the output directory is called “LINKCOS.runcode”.

Figure 186: The CoS Links Report

The CoS Links Report
  • Normal or Peak: Normal traffic means the network does not experience any failure/outages. Peak means that failure simulation reports are going to be used.
  • CoS Classes: Select all or one specific class of traffic. Reports can be issued for all Classes of Traffic or for a particular one (for example, the Priority class)
  • Period: Select planned, worst, all, or a specific time period (from interface load files). Planned means the report is generated using the interface load calculated based on the demand file values. Worst means that the report is generated using the interface load calculated based on the worst traffic load.

Field

Description

LinkName

The name of the link.

TrunkType

The type of the link, for example, OC3 or STM1

Bandwidth

The bandwidth of the link.

Node

One of the link’s endpoints. This specifies the direction of traffic described in this row.

Interface

The interface on the node that the link is connected to.

Policy Name

The CoS policy specified for the link.

Policy-Class

The CoS class of traffic.

Policy Bandwidth

Bandwidth reserved for the policy class.

PIR

The Peak Information Rate

Class

The class name used in demands' CoS definition.

Match

The "IP precedence" or "MPLS EXP bits" used as matching conditions for the specified class.

PropDelay

The propagation delay on the link.

Planned Load

The amount of bandwidth planned for demands on the link.

Planned Util

Percentage of the trunk bandwidth that is used.

Planned PolicyUtil

Percentage of the bandwidth reserved for the policy class that is used.

Planned QDelay(ms)

The queueing delay on the link.

Planned DropBW

The dropped bandwidth planned on this link.

Planned Jitter

The standard deviation of the total path delay.

Worst Load

The highest bandwidth among the load in all the traffic periods.

Worst QDelay

The highest queueing delay value among all the traffic periods.

Worst DropBW

The highest dropped bandwidth among all the traffic periods.

1, 2, ... Load

The load of the link in the specified time period.

1, 2, ... QDelay

The queueing delay in the specified time period.

1, 2, ... DropBW

The dropped bandwidth in the specified time period.


Link Cost Report


The Link Cost Report provides detailed link pricing information. Each link in the network is listed by its source and destination nodes, Vendor, Type, Monthly Cost, and Non-Recurring Charge. Link grouping is done by LEC and IXC vendor.

The output file that is written to the output directory is called “LKCOST.runcode”.

Figure 187: The Link Cost Report

The Link Cost Report
******************************************************************
*
* Backbone Link Configuration and Pricing Report -- runcode=x
*
******************************************************************
*
Remark 1: vendor/cost marked with * are default specified in usercost file
Remark 2: vendor/cost marked with # are default specified in bblink file
Remark 3: cost marked with @ are calculated from usercountrycost file
Remark 4: cost marked with ^ are estimated from default specified in usercost
file

Special characters (such as #, *, @, ^) appended to a vendor or cost value is used to indicate how the pricing was calculated. For example, a vendor or cost value marked with a '#' means that default values specified in the bblink file were used. Press the Exp button in the report window for an explanation.

If the report is saved in CSV format or is viewed through the IP/MPLSView client, there are question marks ('??') in the Monthly and NRC columns indicating that pricing for this link cannot be determined. This usually occurs if the service type is not supported in the tariff database. In this case, you can:

  • Specify the desired link cost directly in the bblink file, or
  • Use the usercost file to define the default vendor and cost for various service types between particular node pairs. More detailed information on this file can be found in the File Format Reference For NPAT and IP/MPLSView.
  • Use the custrate file to create pricing tables between defined classes of nodes. Note that this the custrate feature is an unbundled add-on feature.

Field

Description

Linkname

Identifier of the link

CntryA/NXX

The NPA/NXX location of where the link originates.

NodeA

The name of the node where the link originates.

CardA

Any information regarding the card found at the origin node of the link.

InterfaceA

The name of the interface at the orign node of the link.

CntryZ/NXX

The NPA/NXX location of the destination of the link.

NodeZ

The name of the destination node where the link terminates.

CardZ

Any information regarding the card found at the destination node of the link.

InterfaceZ

The name of the interface at the destination node of the link.

Vendor

The vendor associated with this link. Possible values for vendors include those that are specific to a certain country or region, and are listed in the tariff database. If a vendor is not specified, this value is set to the default value DEF.

#

The number of links from node A to node Z.

Type

The type of link being used. The link type is used in determining link pricing and bandwidth availability.

Monthly

Link/circuit cost expressed a a monthly billed amount.

NRC

Non-Recurring Charge also known as installation charge.

Dist (mile)

The distance between the two nodes (in miles).

AdminDist

The administrative weight or distance of the link. AdminDistA for A-Z direction; AdminDistZ for Z-A direction.

Delay

The delay of the link in each direction. DelayA=delay for A-Z; DelayZ=delay for Z-A.

CLASS

The custom rate class that the nodes belong to. CLASSA=class for node A; CLASSZ=class for node Z.

SITE

The site that the nodes belong to. SITEA=site for node A; SITEZ=site for node Z.

HWTYPE

The hardware type of the nodes. HWTYPEA=hw type for node A; HWTYPEZ=hw type for node Z.


RSVP Bandwidth Allocation Report


The RSVP Bandwidth Allocation Report displays detailed link partition information for each link in the network. This report displays the same detailed information in the capacity tab menu of the Links window found in the Network menu.

The output file that is written to the output directory is called “LKPART.runcode”.

Figure 188: The Link Partition Report in a Router Network

The Link Partition Report in a Router Network

Measured Link Utilization Report


The Measured Link Utilization report displays the computed link utilization based on the routed traffic load in the network. For live network models, this report can be viewed after opening the live network and switching to Offline mode.

In Layer 3, the traffic load could be either the measured end-to-end traffic load, which can be read in as a trafficload file in the Load Network Files window, or the end-to-end demands. If a trafficload file is read in, then up to 24 periods of traffic data could be available. For each period, load and utilization information are displayed in two columns. Worst and average statistics are also shown (for example, Average Load and Average Util columns).

In Layer 2, the link utilization is based on the tunnel traffic load in the network. The tunnel traffic load can be read in as a t_trafficload file in the Load Network Files window.

Figure 189: Measured Link Utilization Report

Measured Link Utilization Report

Interface Traffic Reports

The Interface Traffic Reports detail the measured traffic on each link over a set of time periods, if data is provided. In order to access these reports, traffic should have first been collected (either using the offline traffic collection features in IP/MPLSView or other traffic sources) and imported into the software using the offline traffic import feature. For more on Offline Traffic Import, see the Router Feature Guide For NPAT and IP/MPLSView.

Processed interface traffic data is saved in a file that is referenced by the specification file in the lines, “interfaceLoad_out” (egress traffic) and “interfaceLoad_in” (ingress traffic). The Interface Traffic Report, AS Traffic Report and Inter-AS Traffic Report are derived from these files. Up to 24 periods of traffic data could be available. For each period, load and utilization information are displayed in two columns. Worst and average statistics are also shown (for example, Average Load and Average Util columns). The report is the same in Layer 3 as in Layer 2.

Note: If the outgoing traffic measurements cannot be found (going out from Node A to Node B) in the egress traffic file, then IP/MPLSView will use the numbers from the ingress traffic file (going into Node B from Node A) if available.

Figure 190: Interface Traffic Report

Interface Traffic Report

Interface Traffic Report


The Interface Traffic Report is generated when you perform an offline traffic import.

Field

Description

LinkName

The name of the link.

NodeA/Z

The source (A) and destination (Z) endpoints of the link.

InterfaceA/Z

The originating (A) and terminating (Z) interfaces on Node A and Z respectively.

Bandwidth

The total bandwidth of the link.

Trunk Type

The link type (for example, T1, OC3, ATM10M)

Worst Load

The worst load experienced over all time periods.*

Worst Util

The link utilization correlating to the Worst Load.

Average Load

The average of the loads experienced over all time periods.*

Average Util

The link utilization correlating to the Average Load.

period1...n

The load experienced during period1, period2, ... periodn.*

Util(%)

The link utilization correlating to the load measured each period. There should be a “Util(%)” column immediately after each “period” column.

To determine the units (for example, Kbps), press the Explanation button at the top of the report.


AS Traffic Report


The Autonomous System (AS) Traffic Report details the traffic measured over links whose endpoints are located in two different ASs.

Field

Description

AS1

The AS number of the source AS for the link.

nodeID1

The node ID of the source node of the link.

interface1

The link interface at the source node.

AS2

The AS number of the destination AS for the link.

nodeID2

The node ID of the destination node of the link.

interface2

The link interface at the destination node.

bandwidth

The bandwidth of the link.

Average-in

The average incoming traffic measured on the link in the AS2->AS1 direction.

Average-out

The average outgoing traffic measured on the link in the AS1->AS2 direction.


Inter-AS Traffic Report


The Inter-AS Traffic Report details the aggregated average traffic measured on all links between two different Autonomous Systems (AS).

Field

Description

AS1

The AS number of the source AS.

AS2

The AS number of the destination AS.

AS1 Name

The AS name corresponding to AS1. By default, the AS names are derived from the file, $WANDL_HOME/db/misc/ASNames.

AS2 Name

The AS name corresponding to AS2.

Total BW

The Total Bandwidth of all links between these two ASs.

Average-in

The average traffic load measured on all links between AS1 and AS2 in the AS2->AS1 direction.

Average-out

The average traffic load measured on all links between AS1 and AS2 in the AS1->AS2 direction.


Inbound/Outbound Network Traffic


This report displays an aggregate outbound and aggregate inbound value for each node, corresponding to the sum of traffic originating and terminating at a node respectively - but only on interfaces that do not correspond to any links in the network model (for example, customer-facing interfaces, PE-CE interfaces when CE configuration files are missing from the network model). This information is derived from the measured traffic on the interfaces (interface “egress” and “ingress” traffic files in the File > Load Network Files window).

One purpose for this file is for use in the Traffic Matrix tool, as described in the Router Feature Guide For NPAT and IP/MPLSView.

Figure 191: Inbound/Outbound Network Traffic

Inbound/Outbound Network Traffic

Group Reports

This set of group reports in the Report Manager displays information about groups in the network model. This information includes link and demand summaries and details within and between groups. When you have categorized nodes into groups, these reports show the amount of links and traffic that exists within a certain group or between two different groups. After a failure simulation run, you can also choose to view network group information in peak conditions.

These reports can be generated in Layer 2 of an IP/MPLS network regarding tunnel information between groups, as well as in an ATM network containing PNNI groups. To view information between PNNI groups, select this option in the Group Type selection box.


Group Demand Summary by Group Pair Report


Figure 192: Group Demand Summary Report

Group Demand Summary Report

The output file that is written to the output directory is called “GROUPDEMANDSUMMARY.runcode”.

  • Normal, Peak: Select Normal to display network information under normal conditions. After having run a failure simulation, selecting “Peak” will show peak utilization information.
  • Group Type: The default selection is user-defined groups. If this network contains PNNI groups, then the selection box will also allow you to choose PNNI groups for viewing.
  • Period: Based on the traffic load file, the report can display traffic load information in the selected time period(s).

Field

Description

Group A, Z

This row contains summarized information for demands that originate at group A and terminate at group Z.

# Demand

The total number of requested demands (placed and unplaced) from group A to group Z.

BW

The sum of the demands’ bandwidth.

WorstLd

The sum of the traffic load for these demands in the worst case out of all the time periods. (Data taken from traffic load file.)

WorstLd/BW

The ratio of worst load and the sum of the demands’ bandwidth.

P_01, P_02, ...

The sum of the traffic load for these demands in period 1 (P_01), period 2 (P_02), etc. (Data taken from traffic load file.)


Group Demand Detail by Group Detail Report


The output file that is written to the output directory is called GROUPDEMANDDETAIL.runcode.

  • Normal, Peak: Select Normal to display network information under normal conditions. After having run a failure simulation, select Peak to show peak utilization information.
  • Group Type: The default selection is user-defined groups. If this network contains PNNI groups, then the selection box also allows you to choose PNNI groups for viewing.
  • Period: Based on the traffic load file, the report can display traffic load information in the selected time period(s).

Field

Description

Node A, Z

This row describes a demand that originates at node A and terminates at node Z.

Group A, Z

Group A is the group in which node A resides. Group Z is the group in which node Z resides.

BW

The bandwidth of the demand.

WorstLd

The worst load of this demand out of all the time periods. (Data taken from traffic load file.)

WorstLd/BW

The ratio of worst load and the bandwidth of the demand.

P_01, P_02, ...

The load of this demand from node A to node Z in period 1 (P_01), period 2 (P_02), etc. (Data taken from traffic load file.)


Group Demand Traffic on Link Summary Report


The output file that is written to the output directory is called “GROUPLINKSUMMARY.runcode”.

Figure 193: Group Demand Traffic on Link Summary Report

Group Demand Traffic on Link Summary Report
  • Normal, Peak: Select Normal to display network information under normal conditions. After having run a failure simulation, select Peak to display peak utilization information.
  • Group Type: The default selection is user-defined groups. If this network contains PNNI groups, then the selection box also allows you to choose PNNI groups for viewing.
  • Period: Based on the traffic load file, the report can display traffic load information in the selected time period(s).

Field

Description

Group A, Z

This row contains summarized information for links in the network whose first endpoint is in group A and other is in group Z.

TotalBW

The sum of the bandwidth of links between group A and group Z.

ProvBW

The sum of the amount of bandwidth in the links planned for demands that are routed on or pass through the links.

# Link

The number of links between group A and group Z.

# Calls

The number of demands routed on or through the links between group A and group Z.

WorstLd

The sum of the links’ traffic load in the worst case out of all the time periods. (Data taken from traffic load file.)

WorstLd/TotalBW

The ratio of worst load and sum of the bandwidth of the links.

P_01, P_02, ...

The sum of the links’ traffic load in period 1 (P_01), period 2 (P_02), etc. (Data taken from traffic load file.)


Group Demand Traffic on Link Detail Report


The output file that is written to the output directory is called “GROUPLINKDETAIL.runcode”.

  • Normal, Peak: Select Normal to display network information under normal conditions. After having run a failure simulation, select Peak to displaypeak utilization information.
  • Group Type: The default selection is user-defined groups. If this network contains PNNI groups, then the selection box will also allow you to choose PNNI groups for viewing.
  • Period: Based on the traffic load file, the report can display traffic load information in the selected time period(s).

Field

Description

Node A, Z

This row describes a link in the network whose endpoints are at node A and node Z.

Group A, Z

Group A is the group in which node A resides. Group Z is the group in which node Z resides.

TotalBW

The bandwidth of the link.

ProvBW

The amount of bandwidth in the link planned for demands that are routed on the link or pass through the link.

# Calls

The number of demands routed on or through the link.

Note: This can be verified by right-clicking on the link in the map and selecting View > Demands On/Thru Link.

WorstLd

The link’s traffic load in the worst case out of all the time periods. (Data taken from traffic load file.)

WorstLd/TotalBW

The ratio of worst load and the link’s bandwidth.

P_01, P_02, ...

The traffic load in the link in period 1 (P_01), period 2 (P_02), etc. (Data taken from traffic load file.)


Group Interface Load Summary Report


The output file that is written to the output directory is called “GROUPINTFSUMMARY.runcode”.

Note: To display interface load information in these reports, the interface load files must first be read into the network model.

Figure 194: Group Interface Summary Report

Group Interface Summary Report
  • Group Type: The default selection is user-defined groups. If this network contains PNNI groups, then the selection box will also allow you to choose PNNI groups for viewing.
  • Period: Based on the traffic load file, the report can display traffic load information in the selected time period(s).

Field

Description

Group A, Z

This row contains summarized information for traffic that originate at the interfaces of nodes that belong in group A and terminate at the interfaces of nodes that belong in group Z.

Group A is the group in which node A resides. Group Z is the group in which node Z resides.

Bandwidth

The sum of the bandwidth of links between group A and group Z.

WorstLoad

The interface traffic load of the links from group A to group Z in the worst case out of all the time periods. (Data taken from interface traffic load files.)

AverageLoad

The average interface load of the links from group A to group Z in all the time periods. (Data taken from interface traffic load files.)


Group Interface Load Detail Report


The output file that is written to the output directory is called “GROUPINTFDETAIL.runcode”.

Figure 195: Group Interface Detail Report

Group Interface Detail Report
  • Group Type: The default selection is user-defined groups. If this network contains PNNI groups, then the selection box will also allow you to choose PNNI groups for viewing.
  • Period: Based on the interface traffic load file, the report can display traffic load information in the selected time period(s).

Field

Description

LinkName

The name of a link whose end points are at node A and node Z. If the link does not have a link name, then it will appear as [nodeA]-[nodeZ].

Node A, Z

This row describes a link in the network whose endpoints are at node A and node Z.

Interface A, Z

This row gives interface A,Z that corresponds to node A,Z.

Group A,Z

The groups that nodes A and Z belong to, respectively.

Bandwidth

This corresponds to the bandwidth of interface A

Trunk Type

The link trunk type.

Worst Load

The interface load of the link from interface A to interface Z in the worst case out of all the time periods. (Data taken from interface load files.)

Average Load

The average interface load of the link from interface A to interface Z in all the time periods. (Data taken from interface load files.)


Group Demand Bandwidth Distribution Report


Like the VPN Reports, the Group Demand Bandwidth Distribution Report provides summarized traffic statistics. The output file is saved to the L3GROUPLOAD file. The source, destination, transit, and intra-group traffic is reported for each group, in terms of the number of demands and the bandwidth of those demands. Note that the source and destination traffic for a group do not include intra-group traffic.

Two additional columns #Transit(Max) and TransitBW(Max) may appear after running an exhaustive failure simulation script from Simulation>Scripts with the Generate Peak Group Transit Statistics checkbox selected or by setting CheckTransitDemandLimit=2 in the dparam file.

Figure 196: The Group Bandwidth Distribution Report

The Group Bandwidth Distribution Report

Field

Description

Group

The name of the group whose traffic load is being analyzed.

For nodes not belonging to any group, they are categorized together as “No Group”

VPN

The VPN, if any, whose traffic is being analyzed. For networks with multiple VPNs, select a specific owner under the Owner dropdownmenu to view only statistics for a particular VPN. Alternatively, select owner “All” to view a breakdown into statistics for each VPN. followed by the sum total.

  • If Total appears in this column, all traffic at this group is factored in, including traffic for each VPN and traffic not in any VPN.
  • Traffic that is not using any VPN is categorized under No VPN.

#Src(Inter)
SrcBW(Inter)

Total number of demands and bandwidth of demands that originate at this group and visit at least one other group.

Note: This category includes local inter-group traffic but not local intra-group traffic. For the total bandwidth originating at this group, add Src(Inter)+Local(Intra).

#Src(Placed)
SrcBW(Placed)

Number of routed demands and total bandwidth of routed demands that originate at this group and visit at least one other group. Unlike Src(Inter), Src(Placed) excludes unplaced demands.

#Dest(Inter)
DestBW(Inter)

Total number of demands and bandwidth of demands that terminate at this group and visit at least one other group

Note: This category includes local inter-group traffic but not local intra-group traffic. For the total bandwidth terminating at this group, add Dest(Inter)+Local(Intra).

#Dest(Placed)
DestBW(Placed)

Total number of routed demands and bandwidth of routed demands that terminate at this group after visiting at least one other group. Unlike Dest(Inter), Dest(Placed) excludes unplaced demands.

#Transit
TransitBW

Number of demands and total bandwidth of demands that pass through this group without originating or terminating at it

Note: If a demand transits through a group more than once, it is counted multiple times.

#Local
LocalBW

Total number of demands and bandwidth of demands that originate and terminate at the same group, subdivided below into Local(Intra) and Local(Inter).

#Local(Intra)
LocalBW (Intra)

Demands that originate and terminate at the same group which never go outside the group.

#Local(Inter)
LocalBW (Inter)

Demands that originate and terminate at the same group but transit through at least one other group. These demands are also counted under Src(Inter) and Dest(Inter).

#Transit(Max)
TransitBW(Max)

Max number and bandwidth of transit demands at this group during peak failure simulation

To view the details of the demands included in each category: Src(Inter), Dest(Inter), Transit, and Local(Inter), Local(Intra), access the text mode either from the command line using /u/wandl/bin/bbdsgn followed by the specification file path. Detailed info can be found under the menu item: 3. Network Information > 4.Path > 13.Group. Upon entering the group name, you can select which category of demands to view. For example, the following indicates the demands transiting through Group 1.

Enter group name: group1
Group Demands Menu (GROUP1):
1. ALL 2. Src (Inter) 3. Dest (Inter) 4. Transit
5. Local (Intra) 6. Local (Inter)
Select: 4
Demands Passing Through GROUP1:
* Bandwidth Unit = bit
Demand Node Node Bandwidth Type Pri/Pre path
flow10 ATL SDG 418017 R,A2Z 02,02 ATL--LAX--SDG
flow52 DEN SDG 402000 R,A2Z 02,02 DEN--SFO-SJC--LAX--SDG
flow78 NYC SDG 4801220 R,A2Z 02,02
NYC--PHI--WDC--ATL--LAX--SDG
flow82 PHI SDG 1216020 R,A2Z 02,02 PHI--WDC--ATL--LAX--SDG
flow88 SDG WDC 662011 R,A2Z 02,02 SDG--LAX--ATL--WDC
xflow10 SDG ATL 452011 R,A2Z 02,02 SDG--LAX--ATL
xflow52 SDG DEN 452011 R,A2Z 02,02 SDG--LAX--SJC-SFO--DEN
xflow78 SDG NYC 662011 R,A2Z 02,02
SDG--LAX--ATL--WDC--PHI--NYC
xflow82 SDG PHI 452011 R,A2Z 02,02 SDG--LAX--ATL--WDC--PHI
xflow88 WDC SDG 4689230 R,A2Z 02,02 WDC--ATL--LAX--SDG
--- 10 demands, Total bandwidth = 14.207M

Node Reports


Demand Traffic Per Node Report


The Demand Traffic Per Node Report contains summary traffic statistics for each node, including the amount of source, destination, and transit traffic reported either as a number of demands or as the combined bandwidth of those demands. Note that local demands (demands that originate and end at the same node) are not included in the source or destination traffic statistics.

The output file that is written to the output directory is called “SWITCHCONN.runcode”.

Figure 197: The Node Traffic Summary Report

The Node Traffic Summary Report

Field

Description

NodeName

The name of the node.

#Demand(Src)
DemandBW(Src)

Number of demands and total bandwidth of demands that originate at this node and terminate elsewhere (outgoing)

#Demand(Dest)
DemandBW(Dest)

Number of demands and total bandwidth of demands that terminate at this node and originate elsewhere (incoming)

#Demand(Total)
DemandBW(Total)

#Demand(Total)= #Demand(Src) + #Demand(Dest)
DemandBW(Total)=DemandBW(Src) + DemandBW(Dest)

#TransitDemand
TransitBW

Number of demands and total bandwidth of demands that pass through this node without originating or terminating at it

#TransitDmd(Max)
TransitBW(Max)

Max number and bandwidth of transit demands at this node during peak failure simulation

For ATM models, the headings for the report are shown in the following table.

Field

Description

NodeName

The name of the node.

#LocalDmd

The number of local demands at the node. Local demands are ones that originate and terminate at the node.

LocalBW

The bandwidth of local demands at the node.

#NonLocalDmd(Src)

The number of non-local demands that originate from the node.

NonLocalBW(Src)

The bandwidth of non-local demands that originate from the node.

#NonLocalDmd

Total number of non-local demands originating/terminating at the node.

NonLocalBW

Total bandwidth of non-local demands originating/terminating at the node. For asymmetric demands, the bandwidth of a demand is set to the larger value.

#TransitDmd

The number of transit demands at the node. Transit demands are ones that pass through the node, neither originating or terminating at the node.

#TransitDmd(Max)

The maximum number of transit demands at the node during peak failure simulation.

VPN Reports

The VPN Reports in the Report Manager display information about Layer3/Layer2 Kompella VPNs as well as Layer2 Martini VPNs.


Layer3/Layer2 Kompella Report


Field

Description

Node

The name of the node

VPN Name

The VPN name

VRF

The virtual routing and forwarding instance name

RD

The route distinguisher - used to determine which VPN a route belongs to

Route Target Export

Target VPN community that routes are exported to

Route Target Import

Target VPN community that routes are imported from

Protocols

The VPN protocol used

Interface

The interfaced used by the VPN

IP address

The VPN’s IP Address

Bandwidth

The allocated bandwidth


Layer2 Martini Report


Field

Description

VPNName

The name of the VPN

Node A, Z

The end points of the VPN and the nodes at which the circuits reside. Circuit A resides in node A, and circuit Z resides in node Z

VCID

The (unique) virtual circuit identifiers

circuit A, Z

The circuits at nodes A and Z that the VPN is connected to

Encapsulation ID

The interface encapsulation type

BW

The amount of bandwidth allocated to the VPN

Protocols Reports


Inter Area Load Distribution Report


The Inter Domain Load Distribution Report displays information on the load distribution between domains/areas in the network and is saved as “INTDOMLOAD.runcode”.

Demand Info: --- Total --- --- Placed --- - Not Placed - - Deactivated
- Area -> Area Count Bandwidth Count Bandwidth Count Bandwidth Count Bandwidth
AREA1 ->AREA0 10 4.864M 10 4.864M 0 0 0 0
AREA1 ->AREA3 15 3.712M 15 3.712M 0 0 0 0
AREA0 ->AREA1 10 4.864M 10 4.864M 0 0 0 0
AREA0 ->AREA3 20 1.280M 20 1.280M 0 0 0 0
AREA2 ->AREA1 24 32.544M 0 0 24 32.544M 0 0
AREA2 ->AREA0 16 21.696M 0 0 16 21.696M 0 0
AREA2 ->AREA3 8 10.848M 0 0 8 10.848M 0 0
AREA3 ->AREA1 12 2.176M 12 2.176M 0 0 0 0
AREA3 ->AREA0 20 1.280M 20 1.280M 0 0 0 0
-------------------------------------------------------------------------------
ALL ->ALL 135 83.264M 87 18.176M 48 65.088M 0 0
--- Inter-Domain Traffic from DOMAIN-EAST to DOMAIN-WEST
Demand1,DOMAIN_EAST,N1,,,XN1,US,DOMAIN_WEST,N2,,,XN2,US,
900000,"R,A2Z,CBR",Don't Care,Don't Care,Don't Care,"00,00",N1@@N2,684,25,no,no,
,

PVC Info: --- Total --- --- Placed --- - Not Placed - - Deactivated- Domain -> Domain Count Bandwidth Count Bandwidth Count Bandwidth Count Bandwidth DOMAIN-EAST->DOMAIN-WEST 1 900.000K 1 900.000K 0 0 0 0
--- Inter-Domain Traffic from DOMAIN-EAST to TEST
--- Inter-Domain Traffic from DOMAIN-WEST to NONE
--- Inter-Domain Traffic from DOMAIN-WEST to DOMAIN-EAST Demand1,DOMAIN_EAST,N1,,,XN1,US,DOMAIN_WEST,N2,,,XN2,US, 900000,"R,Z2A,CBR",Don't Care,Don't Care,Don't Care,"00,00",N1@@N2,684,25,no,no, ,
PVC Info: --- Total --- --- Placed --- - Not Placed - - Deactivated-Domain -> Domain Count Bandwidth Count Bandwidth Count Bandwidth Count Bandwidth DOMAIN-WEST->DOMAIN-EAST 1 900.000K 1 900.000K 0 0 0 0
--- Inter-Domain Traffic from DOMAIN-WEST to TEST Demand2,DOMAIN_WEST,N2,,,XN2,US,TEST,N3,,,XN3,US, 750000,"R,A2Z,CBR",Don't Care,Don't Care,Don't Care,"00,00",N2@@N3,684,21,no,no, ,
PVC Info: --- Total --- --- Placed --- - Not Placed - - Deactivated- Domain -> Domain Count Bandwidth Count Bandwidth Count Bandwidth Count Bandwidth DOMAIN-WEST->TEST 1 750.000K 1 750.000K 0 0 0 0

Field

Description

Count

The number of demands/PVCs between the two areas.

Bandwidth

The amount of bandwidth used by the demands/PVCs.

Total

All demands/PVCs between the two areas: placed + not placed + deactivated.

Placed

The demands/PVCs between the areas that are routed.

Not Placed

The demands/PVCs between the areas that are not routed.

Deactivated

The demands/PVCs between the areas that are not activated.


Inter Area Paths Report


The Inter Domain Paths Report displays information regarding paths between two user-specified areas/domains. The output file that is written to the output directory is called “INTDOMPATH.runcode”.

Field

Description

Count

The number of demands/PVCs between the two areas.

Bandwidth

The amount of bandwidth used by the demands/PVCs.

Total

All demands/PVCs between the two areas: placed + not placed + deactivated.

Placed

The demands/PVCs between the areas that are routed.

Not Placed

The demands/PVCs between the areas that are not routed.

Deactivated

The demands/PVCs between the areas that are not activated.


Area Pass Through Paths Report


The Area Pass Through Paths Report, or the Domain Pass Through Paths Report, generates information regarding demands passing through an area or domain in the network. This report is only available for networks defined with multiple areas or domains and demands to and from each domain. The output file that is written to the output directory is called “DOMPASSTHRU.runcode”.

Following is a sample text file of the Domain Pass Through Paths Report from an ATM network:

Demands passing through domain AREA0:
RN1N15,0.0.0.3,N1,,,XN1,US,0.0.0.1,N15,,,XN15,US, 768000,"R,BR1.0M,BM768K,BB200K,RT",Don't Care,Don't
Care,Don't Care,"02,02",N1-N10@@N17--N4--N7@@N8--N15,600,23,no,no, ,
RN1N15,0.0.0.3,N1,,,XN1,US,0.0.0.1,N15,,,XN15,US, 768000,"R,BR1.0M,BM768K,BB200K,RT",Don't Care,Don't
Care,Don't Care,"02,02",N1-N10@@N5--N6--N7@@N8--N15,600,22,no,no, ,
RN2N3,0.0.0.3,N2,,,XN2,US,0.0.0.1,N3,,,XN3,US, 512000,"R,Z2A,UBR+",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N17--N4@@N3,400,16,no,no, ,
RN2N3,0.0.0.3,N2,,,XN2,US,0.0.0.1,N3,,,XN3,US, 512000,"R,Z2A,UBR+",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N17--N4@@N3,400,16,no,no, ,
RN2N3,0.0.0.3,N2,,,XN2,US,0.0.0.1,N3,,,XN3,US, 512000,"R,Z2A,UBR+",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N17--N4@@N3,400,16,no,no, ,
RN2N13,0.0.0.3,N2,,,XN2,US,0.0.0.1,N13,,,XN13,US, 64000,"R,RT",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N11--N6@@N13,400,13,no,no, ,
RN2N13,0.0.0.3,N2,,,XN2,US,0.0.0.1,N13,,,XN13,US, 64000,"R,RT",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N11--N6@@N13,400,13,no,no, ,
RN2N13,0.0.0.3,N2,,,XN2,US,0.0.0.1,N13,,,XN13,US, 64000,"R,RT",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N11--N6@@N13,400,13,no,no, ,
RN2N13,0.0.0.3,N2,,,XN2,US,0.0.0.1,N13,,,XN13,US, 64000,"R,RT",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N11--N6@@N13,400,13,no,no, ,
RN2N13,0.0.0.3,N2,,,XN2,US,0.0.0.1,N13,,,XN13,US, 64000,"R,RT",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N11--N6@@N13,400,13,no,no, ,
RN2N13,0.0.0.3,N2,,,XN2,US,0.0.0.1,N13,,,XN13,US, 64000,"R,RT",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N5--N6@@N13,400,12,no,no, ,RN2N13,0.0.0.3,N2,,,XN2,US,0.0.0.1,N13,,,XN13,US, 64000,"R,RT",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N11--N6@@N13,400,13,no,no, ,
RN2N13,0.0.0.3,N2,,,XN2,US,0.0.0.1,N13,,,XN13,US, 64000,"R,RT",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N5--N6@@N13,400,12,no,no, ,
RN2N13,0.0.0.3,N2,,,XN2,US,0.0.0.1,N13,,,XN13,US, 64000,"R,RT",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N11--N6@@N13,400,13,no,no, ,
RN2N13,0.0.0.3,N2,,,XN2,US,0.0.0.1,N13,,,XN13,US, 64000,"R,RT",Don't Care,Don't Care,Don't
Care,"02,02",N2--N10@@N11--N6@@N13,400,13,no,no, ,
-- 15 PVC(s)(bw=3.712M) pass through domain AREA0

OSPF Area Summary Report


The Area Reports in the Report Manager display information about areas in the network model. This section includes a description of the OSPF area summary and detail reports, as well as the ABR border area report.

Figure 198: The OSPF Area Summary Report

The OSPF Area Summary Report

Field

Description

AS Number

The AS number of the area

OSPF Area

The name of the OSPF area

# of ABRs

The number of nodes that are defined as Area Border Routers (gateway routers)

# Internals

The number of routers in the OSPF area that aren’t defined as ABRs

# Routers

The total number of routers in the area (equivalent to # of ABRs + # Internals)

ASno_Area

A unique name created by concatenating the AS number and the area name


OSPF Area Detail Report


Figure 199: The OSPF Area Detail Report

The OSPF Area Detail Report

Field

Description

AS Number

The AS number of the OSPF area that the router is located in

OSPF Area

The name of the OSPF area that the router is located in

Router Name

The name of the router

Router IP

The router’s IP Address

ABR

Is this router defined as an Area Border Router


ABR Bordering Area Report


Field

Description

AS Number

The AS number of the area that the ABR is located in

ABR

The name of the ABR

Bordering Area(s)

A list of all the areas that the router is bordering

BGP Reports

When the client session is opened for the first time, the BGP Report should be checked to make sure that the network has no obvious BGP configuration errors. The output file that is written to the output directory is called “BGPRPT.runcode”.


BGP Integrity Check Report:


BGP statistics – This section shows:

  • The total number of BGP speakers in the network
  • The total number of neighbors
  • The total number of policies
  • The list of all ASs and the number of their BGP speakers
* BGP Integrity Check Report
******************************************************
-- 17 BGP speakers,89 neighbors,283 members,183 policies
-- 3 local AS:
ASno 222: 9 routers
ASno 111: 7 routers
ASno 555: 1 routers

Neighbor AS Specification Error Check Report


This section shows any errors about ASs that are not specified correctly. For example, router A declares that its neighbor, router B, is in AS1243, but router B is actually in AS4312.

* * * * * Neighbor AS Specification Error Check Report
AS Location Nbr_AS Nbr_IP_Addr Nbr-Location ValidAS Comments
111 X39 224 69.49.226.34 Q39 222
*** 1 AS specification errors

In the example, the Neighbor AS Specification Error Check Report shows that there is an error in the node (Location) X39.

The neighbor node(Nbr-Location) is Q39 and the neighbor AS (Nbr_AS) is 224, which should be 222 as shown in the ValidAS field.


Unbalanced BGP Neighbor Check Report


The BGP protocol requires that if router A declares router B to be its neighbor, then router B also has to declare that router A is its neighbor. If not, then an unbalanced neighbor occurs. This section reports any unbalanced neighbors between BGP speakers within the network.

* * * * * Unbalanced BGP Neighbor Check Report
# Unbalanced BGP Neighbor = 2
AS Location Nbr_AS Nbr-Location
111 S39 111 X39
111 W39 111 X39

The Unbalanced BGP Neighbor Check Report shows that there are two unbalanced neighbors. On the first record S39 declares that X39 is its neighbor but X39 does not declare that S39 is its neighbor. The second record shows a similar error.


IBGP Mesh Connectivity Check Report


All IBGP speakers within an AS have to be fully meshed, unless route reflectors or confederation are used. This section shows if any AS is not fully meshed.

A full mesh for both IPV4 and VPNV4 address families are checked.

* * * * *
IBGP Mesh Connectivity Check Report
AS222: #IPV4 IBGP neighbor=0. Check mesh definition for VPNV4 address family
AS 222: passed mesh connectivity checking
---- VPNV4 AS111: S39 is not defined as X39's neighbor
IPV4 VPNV4 AS111: W39 is not defined as X39's neighbor
AS111: 2 neighbor definition missing
AS333: IPV4, VPNV4, L2VPN IBGP neighbors are not defined
AS 555: passed mesh connectivity checking* * * * *
IBGP Mesh Connectivity Check Report
AS222: #IPV4 IBGP neighbor=0. Check mesh definition for VPNV4 address family
AS 222: passed mesh connectivity checking
---- VPNV4 AS111: S39 is not defined as X39's neighbor
IPV4 VPNV4 AS111: W39 is not defined as X39's neighbor
AS111: 2 neighbor definition missing
AS333: IPV4, VPNV4, L2VPN IBGP neighbors are not defined
AS 555: passed mesh connectivity checking

The IBGP Mesh Connectivity Check Report shows the following

  • AS222 is fully meshed for the VPNV4 address family but no IBGP neighbors exist for IPV4 address family.
  • AS111 is not fully meshed for IPV4 and VPNV4. For the VPNV4 address family, S39 and W39 are not defined as X39’s neighbors. For the IPV4 address family, W39 is not defined as X39’s neighbor.
  • AS555 passes the mesh connectivity check for both IPV4 and VPNV4.
  • AS333 is missing IBGP neighbors for the IPV4, VPNV4, and L2VPN address families.

IPV4/VPNV4/L2VPN Route Reflector Statistics


These three sections indicate the route reflector statistics, including number of route reflectors, number of route reflector clients, and hierarchical route reflector information. Route reflector clients with only one route reflector are listed as a warning that they do not have redundant route reflectors defined. The following is an example of the IPV4 route reflector statistics:

IPV4 Route Reflector Statistics: 200 BGP Speakers, 8 Route Reflectors, 100 Route
Reflector Clients
Redundant Route Reflectors are not defined at 2 RR Clients
1. WDC1, RR= PHI1
2. WDC2, RR= PHI1

#Route Reflector Hierarchy Level= 3
Top Level: 4RR(s)
1. NYC1,
2. NYC2,
3. BOS1,
4. BOS2,
Level 2: 3RR(s)
1. PHI1, RR= NYC1 NYC2
1. PHI2, RR= NYC1 NYC2
2. BOS3, RR= BOS1 BOS2
Level 3: 1RR(s)
1. TRE1, RR= PHI1 PHI2

VPNV4 and L2VPN route reflector statistics are similarly provided.

It is recommended that all errors reported in the BGP Report file get fixed before carrying on further analysis. One way to do it is to correct the errors on the configuration files and then run through getipconf again.

Modified: 2016-01-05