BECS Design Guidelines-3.15.3

BECS 3.15.
3 Design Guidelines
BECS 3.15.3 Design Guidelines
Document information
PF-DOC-BECS-3.15.3-Design_Guidelines. Published 2018-09-24.
Source ID: 370f1f644de9053a0990b794e7acbda11be7adec
Copyright and Legal notice

Copyright 2011-2018 PacketFront Software Solutions AB. All rights reserved.
BECS, SMT, HMT, BBE, program models, other software content and this documentation ("the Intellectual Property Rights") are protected by the
Swedish Copyright Act (Sw: Upphovsrättslagen) and, if applicable, the Swedish Patents Act (Sw: Patentlagen). All and any copying and distribution
of the Intellectual Property Rights, without authorization by PacketFront Software Solutions AB (hereinafter referred to as "PacketFront Software") is
prohibited. The prohibition includes every form of reproduction and distribution.
Every effort was made to ensure that the information in this document was complete and accurate at the time of printing. However, information is subject
to change without notice. PacketFront Software assumes no liability for damages incurred directly or indirectly from errors, omissions or discrepancies
between the software and this document.
BECS, SMT, HMT and BBE are trademarks of PacketFront Software AB.
All other trademarks, service marks and trade names are proprietary to their respective owner.
Purchasers, licensees and users accept and acknowledge that the products contain components (including components carrying certain firmware) and
combinations of components that constitute trade secrets protected by PacketFront Software or its partners. Purchasers, licensees and users warrant that
the delivered products will not be opened or dismantled, copied, altered or in any other way modified. Furthermore, purchasers, licensees and users agree
not to attempt to reverse engineer, disassemble, modify, translate, create derivative works, rent, lease, loan, or without written permission distribute or
sublicense the software, in whole or in part.
The products and its hardware, firmware and software, including technical data, may be subject to EU and U.S export control laws, including the U.S
Export Administration Act and its associated regulations and the International Traffic in Arms Regulations administered by the US Department of State,
and may be subject to export or import regulations in other countries. Purchasers and licensees agree to comply strictly with all such regulations and
acknowledges that it has the responsibility to obtain licenses to export, re-export, or import hardware, firmware and software.
Purchasers and licensees are not entitled to, and PacketFront Software is not in any event liable to pay, compensation for damages which delivered
products or software has caused to other property or to persons or any other consequential damages, including but not limited to loss of profit, loss of
production or any other indirect damages.
Table of Contents
Introduction ................................................................................................................................ 1
About this manual .............................................................................................................. 1
Related documentation ........................................................................................................ 1
BECS Overview ......................................................................................................................... 3
Common modules ............................................................................................................... 3
EMBECS .................................................................................................................... 3
IAMBR ...................................................................................................................... 4
Core modules ..................................................................................................................... 4
SM ............................................................................................................................. 4
NETLOG .................................................................................................................... 4
LM ............................................................................................................................. 4
EAPI .......................................................................................................................... 4
SETCL ....................................................................................................................... 4
MQ ............................................................................................................................ 5
CJM ........................................................................................................................... 5
Cell modules ...................................................................................................................... 5
CRE ........................................................................................................................... 5
EMIBOS .................................................................................................................... 5
DCE ........................................................................................................................... 5
EMI ........................................................................................................................... 5
Network Planning ....................................................................................................................... 7
OSPF ................................................................................................................................. 7
Address plan summarization ................................................................................................ 7
IPv4 resource .............................................................................................................. 7
IPv4 space .................................................................................................................. 8
Examples ............................................................................................................................ 8
Aggregating one network resource to different Distribution POP’s ................................. 8
Tree Thinking ........................................................................................................................... 17
Introduction of the configuration tree ................................................................................. 17
Weight .............................................................................................................................. 18
iBOS system configuration ................................................................................................ 19
Images Overview .............................................................................................................. 19
Recommended way of creating a configuration tree ............................................................ 20
Services .................................................................................................................................... 23
IP address planning ........................................................................................................... 23
Fallback space .................................................................................................................. 25
IP statistics ....................................................................................................................... 27
Generating statistics .................................................................................................. 27
Configuration ............................................................................................................ 27
Service statistics ................................................................................................................ 29
Operations ................................................................................................................................ 31
NAR ................................................................................................................................. 31
IBOS NAR-type script .............................................................................................. 31
IBOS NAR configuration .......................................................................................... 37
Generic NAR-type script ........................................................................................... 46
Generic NAR configuration ....................................................................................... 49
Good to know ........................................................................................................... 50
Data retrieval .................................................................................................................... 55
Prerequisites ............................................................................................................. 55
Data retrieval configuration ....................................................................................... 56
iii
Useful CLI commands .............................................................................................. 76
Database files on BECS server .................................................................................. 78
MQ forwarding configuration ............................................................................................ 78
Add a GDR parameter configuration .......................................................................... 78
Add a SDR subscription ............................................................................................ 80
Verify DCE configuration in CLI .............................................................................. 81
Verify MQ configuration in CLI ................................................................................ 83
Create a subscriber for MQ ....................................................................................... 83
Extract information ................................................................................................... 85
Free the disk space ................................................................................................... 86
Terminate the subscription ......................................................................................... 87
Backup ............................................................................................................................. 87
Appendix .................................................................................................................................. 89
Index ........................................................................................................................................ 95
iv
List of Figures
1. BECS system overview ........................................................................................................... 3
2. Configuration tree at the beginning .......................................................................................... 9
3. Add ancestor and child resources ........................................................................................... 10
4. Create interface loopback0 .................................................................................................... 11
5. Create and connect interfaces ................................................................................................ 12
6. Create resource on the link object .......................................................................................... 13
7. Create resource on interfaces ................................................................................................. 14
8. Resource tree in the CJM ...................................................................................................... 15
9. Configuration tree example .................................................................................................... 18
10. Images overview ................................................................................................................. 20
11. An example of scope configuration ...................................................................................... 24
12. An example of fallback scope configuration ......................................................................... 26
13. Sample IPv4 space subscription configuration ....................................................................... 28
14. An example of IP statistics graphs ....................................................................................... 29
15. Service attach sumary .......................................................................................................... 30
16. Tasks and triggers ............................................................................................................... 32
17. NAR Script ......................................................................................................................... 33
18. Platform .............................................................................................................................. 34
19. New element ....................................................................................................................... 35
20. Manual trigger configuration ................................................................................................ 36
21. NAR iBOS setup wizard ..................................................................................................... 37
22. Scenario .............................................................................................................................. 38
23. Remove uplink .................................................................................................................... 38
24. Add new element ................................................................................................................ 39
25. Logs of NAR script actions in SE-TCL ................................................................................ 39
26. Logs indicating snpa parameter is set ................................................................................... 40
27. New element created by NAR script .................................................................................... 40
28. Logs of NAR sript actions in SE-TCL .................................................................................. 41
29. Uplink mismatch on asr2-4k in topology view ...................................................................... 42
30. Swapped uplinks in topology view ....................................................................................... 42
32. Enable NAR script to disable invalid interfaces ..................................................................... 44
33. asr3-4k in topology view ..................................................................................................... 44
34. Disabled interface in the configuration tree ........................................................................... 45
35. asr3-5k in the topology view ............................................................................................... 46
37. NAR generic setup .............................................................................................................. 47
38. NAR generic setup - modify modules ................................................................................... 49
39. Logs of NAR script for module mismatch ............................................................................ 50
40. Logs of lock removing ........................................................................................................ 50
41. NAR script in file repository ............................................................................................... 51
42. System status: ..................................................................................................................... 52
43. LM CLI .............................................................................................................................. 52
44. Menu View->NAR… .......................................................................................................... 53
45. A sample of NAR window .................................................................................................. 53
46. Mark selected NAR(s) acknowledged ................................................................................... 54
47. Mark selected NAR(s) done ................................................................................................. 54
48. SDR CLOBs ....................................................................................................................... 55
49. Select service ...................................................................................................................... 56
50. Element root archive parameters .......................................................................................... 57
v
51. Interface archive parameters ................................................................................................ 58
52. IPv4 space parameters ......................................................................................................... 59
53. GDR configuraiton library ................................................................................................... 60
54. Start “GDR parameter configuration” script .......................................................................... 61
55. Select service ...................................................................................................................... 61
58. IPv4 space archive parameters ............................................................................................. 64
59. Select service ...................................................................................................................... 65
60. Service archive parameters .................................................................................................. 66
61. Start “SDR subscription configuration” script ....................................................................... 67
62. Select service ...................................................................................................................... 67
63. Element root statistics ......................................................................................................... 68
64. Interface statistics ................................................................................................................ 69
65. IPv4 space statistics ............................................................................................................ 69
66. Start “SDR parameter configuration” script ........................................................................... 70
67. Select service ...................................................................................................................... 70
68. Service statistics .................................................................................................................. 71
69. GDR SDR configuration in the configuration tree ................................................................. 71
70. Element properties .............................................................................................................. 72
71. Start the “statistics toggle” script ......................................................................................... 72
72. Statistics toggle ................................................................................................................... 73
73. RDR information example ................................................................................................... 73
74. iBOS system load ............................................................................................................... 74
75. Start the statistics window ................................................................................................... 74
76. An example of searching result for statistics information ....................................................... 75
77. An example of run-time graphing statistics information ......................................................... 76
80. Element root statistics ......................................................................................................... 80
81. Interface statistics ................................................................................................................ 81
82. Example output of the command “show object” .................................................................... 82
83. DCE show archive class ...................................................................................................... 82
84. MQ show sources detailed ................................................................................................... 83
85. Logs of IAMBR .................................................................................................................. 85
86. MQ show sources detailed ................................................................................................... 85
vi
List of Tables
1. The parent-child relationship ................................................................................................... 7
vii
viii
List of Examples
1. The configuration tree structure ............................................................................................. 23
2. Sample output of command show nar inmem ......................................................................... 54
3. Sample output of command show nar scripts .......................................................................... 54
4. Output from DCE CLIs for a service attach that is enabled for gathering statistics ...................... 77
5. Output from DCE CLIs for a service attach that is enabled for gathering statistics ...................... 77
6. Output from ASR CLIs with GDR enabled ............................................................................ 77
7. Output on BECS server ......................................................................................................... 78
8. Set the library path permanently ............................................................................................ 84
9. Get “mqctl” options .............................................................................................................. 84
10. Create an MQ subscriber ..................................................................................................... 84
11. Reading the subscription ...................................................................................................... 86
12. Subscription data ................................................................................................................. 86
13. Delete data .......................................................................................................................... 86
ix
x
Introduction
BECS™ Network Orchestrator is a centralized control and provisioning software for network devices
from different manufacturers in the network. This manual is geared towards helping network engineers
to build a broadband network using BECS.
About this manual

These guidelines are designed to assist you in network design and BECS configuration to provide the
best performance for BECS in your broadband network.
The reader is expected to have expert knowledge of networking, and it is recommended to be familiar
with the PacketFront Software products, both software and hardware, being used with BECS in the
network.
This manual describes the following:
• BECS Overview
• Network Planning
• Tree Thinking
• Services
• Operations
After reading this manual, you will be able to build a network running a standalone BECS with one
attached cell, as well as being able to manage basic services.
Related documentation
Other BECS product manuals are:
• BECS GUI User Guide
• BECS System Administrator Guide
• BECS Network Adminstrator Guide
• BECS Module Command Reference
• BECS Service Deployment Guide
• BECS Troubleshooting Guide
For more information, send an email to info@pfsw.com.
1
2
BECS Overview
Common modules
The BECS system consists of a number of different software modules that each serve a specific purpose.
The modular design of BECS allows parts of the system to be distributed to separate physical servers.
This adds scalability and redundancy to the system. The following picture shows an overview of the
software modules in the BECS system.
Figure 1. BECS system overview
EMBECS
For software and hardware, there are specific network element manager modules. The element manager
for BECS modules is EMBECS.
EMBECS is responsible for starting up all other BECS modules in the system and to monitor how they
are running.
EMBECS is required on both the Core and the Cell servers.
3
IAMBR
The Inter-Application Message Broker Router (IAMBR) is a message bus that allows BECS modules
to communicate with each other. IAMBR is also used by the HA-link protocol that verifies server
status in high-availability deployments. IAMBR uses the Shortest-Path Algorithm to set up the best
communication path between the system modules. This allows some degree of additional fault tolerance
between the system modules. IAMBR is PacketFront Software proprietary.
IAMBR modules are required on the Core and the Cell servers.
Core modules
The BECS core consists of a set of modules that serve the general BECS system. The core modules are
typically located on the central server.
Interaction with external applications such as the BECS GUI and SMT or similar subscriber management
tools are important for these modules. The central server operating the core modules is typically located
in the network operators main data center.
SM
The System Manager (SM) maintains the central file repository for iBOS system images. Any core files
recieved from the network are uploaded to the system manager. The system manager also contains scripts
that are used for the BECS GUI wizards and for the Network Action Request handling.
NETLOG
The NETLOG module stores the address history log and other log information related to the assignment
of IP addresses to subscribers in the network. The NETLOG is important for subscriber traceability and
for handling abuse, as well as being a means for keeping track of service activation and deactivation
per subscriber.
LM
The Log Manager (LM) holds the BECS system log. This log information is related to the operation of
the BECS system and contains information about important system events including network element
related actions. The LM is also the recipient of Network Action Request (NAR) messages and it can
trigger automated scripts in the ScriptEngine that have been designed to handle such events. The LM
stores recieved system logs in a database. Database files are rotated regularly for backup purposes.
EAPI
The External Application Interface (EAPI) publishes function calls that access BECS data directly. The
BECS GUI interface and the Mediation Point use the EAPI for communication with BECS. Domain
connections to the MP are configured here.
SETCL
The Script Engine TCL (SETCL) is a module for automated script execution. During normal operation,
situations may occur where BECS requires external logic to resolve the situation. An example might
be when an unknown network element attempts to contact BECS. The element may be part of normal
deployment and an automated script can create the necessary objects in the database when the element
connects. The ScriptEngine also provides the framework for BECS Wizards to assist in the management
of the network through the BECS GUI.
4
BECS Overview
MQ
The Message Queue module (MQ) is used by external applications to subscribe to data generated
from within the BECS system or connected elements, such as object modifications, client start/stop,
IGMP events, etc. Different formats for exporting BECS data are supported and these formats are also
configured in this module.
CJM
The Configuration Job Manager (CJM) holds the configuration tree that describes the services available
to subscribers, where in the network subscribers are present and which services they subscribe to. In
addition the configuration tree contains network topology information including the configuration of
network elements. The CJM maintains the configuration tree and any changes to the tree from external
applications are parsed by the CJM before it is deployed into the Cell Configuration Rendering Engine.
Cell modules
Cells consists of a number of modules that handle a certain part of the network topology. In a large
network, the cell may be separated from the core server and deployed into the network. The servers that
run a BECS cell is typically located at a distribution POP in the network closer to the part of the network
managed by the cell.
CRE
The Configuration Rendering Engine (CRE) module has a local copy of the configuration tree for that
part of the network that its cell cover. The CRE assembles objects from the configuration tree to form the
final configuration to be deployed into network elements. This process concatenates configuration line
objects and parameters, allocates IP addresses, and resolves any configuration preprocessor conditions,
and forms the final network element configuration that is then passed on to the ElementManager.
This means that the CRE only gathers the configuration information but does not understand the meaning
of the configuration.
EMIBOS
For software and hardware, there are specific network element manager modules. iBOS is Waystream’s
intelligent broadband operating system that runs on the ASR hardware platform. The element manager
for configuration of hardware modules is called EMIBOS.
EMIBOS receives configuration from the CRE and verifies that all configuration statements are accurate
and valid for the version of iBOS in which it is run. Network elements connect to the EMIBOS module
with the Waystream proprietary CSAR protocol and receive their configuration through that connection.
DCE
The Data Collection Engine module (DCE) is used for data retrieval from network elements. This is
done on the Core by the Master DCE (MDCE) and by the DCE on each cell.
EMI
For software and hardware, there are specific network element manager modules. In BECS, the element
manager instance for configuration of a hardware module is called an EMI.
The EMI receives configuration from the CRE and verifies that all configuration statements are accurate
and valid for the version of OS for which it is running. Network elements connect to the EMI module
and receive their configuration from BECS using the EMI.
5
6
Network Planning
Before you start to define your services in BECS, it is important to plan your BECS network. The
following topics are discussed in this chapter:
• "OSPF"
• "Address plan summarization"
OSPF
This manual only focuses on non-HA BECS design, therefore OSPF configuration is discarded
intentionally. If you are planning HA installation of BECS, consult PS for more information on this topic.
Address plan summarization

BECS use two object types to manage IP addresses in the configuration, the IPv4 resource and the IPv4
space. The Configuration Job Manager (CJM) is responsible for managing the IPv4 resource, and does
this with a resource tree that exists in parallel with the configuration tree. This section exemplifies in
detail how to configure IP addressing with these two objects.
IPv4 resource
IPv4 resource objects provide a manageable IP address plan, with the possibility to aggregate addresses
in a tree structure. To do this the CJM has a resource tree parallel to the configuration tree, and it always
begins with the resource “root pool” 0.0.0.0/0.
Resources that are defined directly under the root pool (0.0.0.0/0) are called ancestor resources. They
are the largest aggregations of a number of child resources. Resources named Free are also located under
the root pool and aggregated to as large subnets as possible.
Resources can be allocated from other resources, then they enter a parent-child relationship, see Table 1,
“The parent-child relationship”. The resources allocated from other resources can be child resources or
sub-resources, with the difference of levels.
Child resources must be located at least one level below the resource it originates from. Following
objects count as “levels”: Node, Element, Element Module, Parameter Object, IPv4 Space, and Interface.
The size of the child resource can be equal or smaller than its parent resource.
Sub-resources are not bound to the configuration tree hierarchy, as “normal” resources are. They can be
created at the same level as the parent resource. A sub-resource can be created out of “normal” resources
as well as other sub-resources. Sub-resources cannot be ancestor resources, they must have a parent.
Table 1. The parent-child relationship

Parent Child
resource level
ancestor resources = root child resources
7
Parent Child
sub-resources
child resources <= parent — 1 child resources
sub-resources
sub-resources <= parent child resources
sub-resources
Based upon the defined IP address and prefix length, each IPv4 resource object can generate four
configuration parameters on its parent in the configuration tree: $network, $gateway, $prefixlen, and
$ipaddress.
IPv4 space
The IPv4 Space is an object that houses any number of IPv4 resources to be used for dynamic address
allocation.
The IPv4 Space work as a “client database”. Each IPv4 Space holds records of all its IPv4 resources
and clients, such as
• which address is used on which port for which MAC address
• which gateway that the client should have
• if client addresses on the ASR should be aggregated in OSPF
It is also possible to exclude addresses that normally could be allocated.
To cater for these new requirements three additional parameters are generated: $gateway,
$aggregateprefixlen, and $excluded.
Examples
Each example is followed by a detailed walkthrough of how the resource is processed in BECS.
Aggregating one network resource to different Distribution POP’s
In BECS, the problem is that one resource option is available regardless of using wizards or not. At the
same time we want to be able to aggregate these networks in OSPF both on the core routers and in the
distribution layer.
The following procedure shows how to allocate one resource for all link interfaces and one resource for
all loopbacks in a network.
The procedure is based on the assumption that the configuration tree has already been established. Core
routers are present for illustration purpose.
8
Network Planning
Figure 2. Configuration tree at the beginning
The following procedure is described:
• “Add resources”
• “Create loopback0 interface with resource”
• “Create interfaces and link objects”
• “Create resource on the link object”
• “Create resource on interfaces”
Add resources
1. Add two ancestor resources in a library under the node Core, one is “links” and one is “loopbacks”.
For information on how to add an IPv4 resource, refer to BECS GUI User’s Guide.
2. Allocate the “child resources” from these resources, and distribute in the configuration tree according
to the intended OSPF-aggregation design. Adding “child resource” is similar to add parent resource.
In IP resource properties window, select the corresponding parent resource name in Name combobox
and define “child resource” prefix length.
9
Figure 3. Add ancestor and child resources
Create loopback0 interface with resource
1. Add an interface named “loopback0” to element ASR2-1 under node Access_2. For information on
how to add an interface, refer to BECS GUI User Guide.
10
Network Planning
Figure 4. Create interface loopback0
2. To add IPv4 resource to the new interface loopback0, right-click interface loopback0, select Add,
and then click IPv4 resource.
The CJM creates a child /32 child resource from the closest available resource. To verify the netmask
is /32, select the “links” resource from the drop-down menu Name in the Properties tab.
Create interfaces and link objects
1. Add interface “uplink_1” on Distribution_Router_2.
2. Add interface “gigabitethernet1” on ASR2-1.
3. Connect these two interfaces. A link object is created automatically when these two interfaces are
connected.
For information on how to connect two interfaces, refer to BECS GUI User Guide. A quick way of
connecting these two interfaces is described as below:
11
a. In topology view, hold down the right mouse button, drag-and-drop from Distribution_Router_2 to
Access_2.
b. Define the interface used for connection on each node.
Figure 5. Create and connect interfaces
Create resource on the link object
1. Right-click the link between Distribution_Router_2 and Access_2.
2. Select Add, then click IPv4 Resource.
3. Select the “links” resource from the drop-down menu Name in the Properties tab, and set netmask
to /30. DO NOT specify address. BECS chooses the “lowest” resource it can find, which in this case
would be the first /30 from the resource under Access_2, and the child resource should have address
10.0.1.192/30.
12
Network Planning
Figure 6. Create resource on the link object
Create resource on interfaces
1. Right-click one of the two interfaces connected to the link object.
2. Select Add, then click IPv4 Resource. The only option in the drop-down menu should be the link
resource, and the prefix should be fixed to 32.
Repeat the above steps for the other interface. Both interfaces should get the two available /32 child
resources from the link object: 10.0.1.193/32 and 10.0.1.194/32.
13
Figure 7. Create resource on interfaces
Note
When adding a resource to an interface connected to a link object, the parent resource MUST
reside on the link object, and the netmask MUST be /32.
This is because a child resource created from a parent is located on a link that has the flag
“useparentmask” set. Objects with this flag inherit the values of the parameters “network” and
“prefixlen” from its parent.
Good to know
This section highlights the prons and cons in the previous example.
Resource tree vs. configuration tree
A thing that could be confusing is the fact that the child resource (10.0.1.193/32) on the distribution router
is located higher than its parents parent (10.0.1.192/26). This is because the resource tree is separated
from the configuration tree. From a resource tree’s point of view, the resources are in correct order.
14
Network Planning
Below is a view of the resource tree in the CJM where we can clearly see the Parent-Child relations. You
can also see which addresses are free and which are used, and where the used addresses are located.
Figure 8. Resource tree in the CJM
The link object
Since the link object can be located in more than one level (Node, Element, Interface), as shown in the
example, it can be exposed to the same resource but at different levels. To handle this the following rules
apply to the resource allocation:
• When connected to interfaces in the same branch the “lowest” resource found will be used
• When connected to interfaces in different branches the first common resource for the two branches.
In the example, this would be impossible since the first common resource is the 10.0.1.0/24 resource,
and that is fully allocated by its two /25 child resources.
15
16
Tree Thinking
This chapter provides guidance on creating the configuration tree in BECS. Before you start to configure
BECS with the details, there are numbers of important parts to understand about the overall philosophy
of how BECS3 configuration works regarding the configuration tree, and this section is trying to explain
that as easily as possible.
Introduction of the configuration tree

The configuration tree is a management tool with which you can control when and how services and
parameters are deployed to objects around the network. Learning where in the tree to place objects for
optimal performance is an essential part of successful network management through BECS.
The tree structure in BECS works as an analogue of the real network, which is basically one large
aggregation of customer ports into one connection towards Internet, VoIP, or other services. In this way,
the tree structure gives you the ability to summarize routes, aggregate port configuration and so forth
towards the top in the network.
The basis for the tree structure is that you can have more significant and less significant objects in a
tree. If you have an object further out closer to the service attachment then that object is more significant
than the more general object closer to the root of the tree. This means that you can have overloading
of objects in the tree. It is possible to put a general object higher up in the tree and put a more specific
object further down in the tree.
It also means that you can place a certain object at a certain place in the tree, and the object will only
be available to the tree that is below that point.
For example in Figure 9, “Configuration tree example”, some services are only available in part of the
network where the ASRs exist below “Dist_1” (services are used here as an example, but it is equally
true for IP resources which you will see later in this document).
17
Figure 9. Configuration tree example
As you can see above, the global services defined at the root level are available in the entire network,
while the service defined below “Dist_1” is only available to elements placed below “Dist_1”.
Notice how the iBOS system parameters object placed under “Dist_2” changes the settings for the entire
network below “Dist_2”. While under the node “OSPF4”, the settings are changed once more for the
sub tree. This is what overloading is all about, you can have more general settings that effect a larger
part of the tree, and you can have more specific settings that only effect a smaller part of the tree.
Weight
In BEC3, the weight scheme is implemented to prioritize services and IP resources. The service with
higher weight will be applied before services with lower weight. This also applies to IP resources. For
example, if you have a fallback scope, you do not want addresses from this scope to be used before the
addresses of the “regular” scopes are used up.
The weight increments by 1000 for each level of the tree. Therefore, a good way to work with weights
is to use values below 1000 even for the highest prioritized services or IP resources.
Normally, you may want to prioritize your services in the following way:
18
Tree Thinking
• Internet service with low priority
• IP telephony service with higher priority
• IPTV service with the highest priority
This is primarily because you want the services with more specific settings regarding MAC addresses
and so on to be tested for service attachment first, so that the Set Top Box does not get the Internet
service and so on. The values you set on the different services can be anything, but reasonable room for
new services and weights should be taken into consideration. So something along the lines of:
Internet service: weight 100
IP telephony service: weight 200
IPTV service: weight 300
If you have other less significant services, you can put them between the Internet service and the IP
telephony service.
iBOS system configuration

The iBOS system configuration is automatically created by the script wizard Add->iBOS system
configuration.
This wizard should be run at the root level of the tree. Because this wizard will create a lot of objects
that are used by BECS to manage the iBOS system configuration, and they need only to exist at the
root level of the tree.
After you have created the iBOS system configuration at the root level, you can change the behaviour
of this configuration in different parts of the configuration tree by using the script wizard Add->iBOS
system parameters instead. This way you only place a parameter object on a certain level in the
configuration tree instead of creating a redundant copy of all the iBOS system configuration objects.
Notice in Figure 9, “Configuration tree example”, how the iBOS system configuration is created at the
root level, and an object of iBOS system parameters is created under “Dist_2” where the settings are
changed for some of the iBOS system configuration.
Images Overview
There can be many image deployment parameter objects in becs tree. A wizard can be used to show all
configured images for all element platforms for easy overview. Right-click any where in the BECS’s
tree and choose Show->Element image deployment to show the configured images table.
19
Figure 10. Images overview
One or several image deployment(s) can be de-configured by choose them and click Delete button.
Note
Deleting an image from the table here only means it is de-configured from the parameter object,
the image file itself is still in the BECS file repository. If all images are de-configured from one
parameter object, the parameter object will be deleted too from the BECS’s tree except user has
configured any other opaques on it.
Note
When upgrading elements image in a big network, to avoid whole network problem or to try out
the image, it should be done in steps. Each time a small part of network should be upgraded,
to achive this put an image deployment parameter object at the part to be upgraded. Node by
node, after all the leaf nodes are upgraded, the top level image deployment parameter object
can be updated last. Then "Image overview" wizard can be used to delete all the leaf parameter
objects very easily.
Recommended way of creating a configuration tree

When you build your configuration tree, keep in mind the following points:
• Plan your configuration tree in such structure: [city or company node]/Node/OSPF area/Ring/ASR
• If you are running only one cell, the cell should be placed under the City/company node, so that future
growth with an extra cell can be done without any need for moving cells in the configuration tree.
• iBOS system configuration should be placed in the root so that it is used throughout the entire
configuration tree. If you want to change iBOS version or other configurations on a particular ASR or
ring, you can add a parameter object or CLOB on the corresponding level by using the script wizard
Add->*iBOS system parameters*.
• The distribution router pair is placed on the node level.
20
Tree Thinking
• Place IP dynamic library and IP static library on each node.
• Place an IP library in the root which contains the top level address pools.
• Services are preferably placed on the root level to be available in the entire tree. A service located
under a certain node is available only to that node.
• The object close to the service attachment is more significant than the general object close to the root
of the tree. This is because a service is attached to a port at the furthest leaves in the tree, the rest of
the tree is there to make that service happen.
• Use Node objects. Node objects can be used to group objects in a certain logic, which can organize
and personalize your tree structure. The nodes correspond to different physical or logical parts of the
network. It is recommended to use nodes when creating the configuration tree, even if the network
is small. It is wise to think of future expansions already when doing the initial planning of how the
network will be reflected in the configuration tree. For detailed information on Node objects, refer
to BECS GUI User Guide.
• Use Library objects. Library objects are used to group objects of the same type, which makes your
configuration tree less clogged and less cluttered. You can even have Libraries inside Libraries. Unlike
Node objects, Library objects do not add new levels in the configuration tree when they are created. In
other words, objects in a library are located on the same level in the tree as the library object itself. For
example, if you organize many services from the same service provider. You can create a Library for
the service provider, and under that Library create nested Library for individual service. For detailed
information on Library objects, refer to BECS GUI User Guide.
• Normally, CLOBs should be placed high up at the root of the tree because CLOBs cannot be
overloaded. If you have conflicting configuration rows in two CLOBs, a service cannot decide which
row to use.
• Configurations such as IPv4 resources and parameters can be added at all levels, giving impact at
different parts of the tree.
• To make a service work, make sure you have three things defined in your configuration tree:
• A service definition
• An assigned IP resource (an IPv4 space is needed if the service is dynamic)
• A service attachment
BECS3 does not check the consistency of these three things in the configuration tree. However, at
runtime, for example, when a DHCP Discovery is received, BECS tries to combine these three things
into one working service.
The benefits of creating a tree like this are several:
• Having a cell-level in the tree makes it easy to add another cell, and if necessary move objects from
the old cell branch to the new.
• Having the distribution node level makes the tree more like the physical network, hence, giving the
tree a structure that is easier to follow.
• Having the OSPF area level is essential for route summarization.
• The separate nodes for rings again makes the tree more like the physical network.
21
22
Services
This chapter describes the services in BECS that are of interest for service providers. The following
topics are covered in this chapter:
• "IP address planning"
• "Fallback space"
• "IP statistics"
• "Service statistics"
IP address planning
In BECS3, the configuration tree structure makes it possible to place IP resources for dynamic and static
services on different levels in the configuration tree, which makes it possible to choose where you want
to place summarizations in the network. This means that you can make summarizations on different
levels in the network for different services.
The two extreme examples are
• If you have a service that are used by a lot of clients, you would like to put the IP resources/spaces
far out in the tree on OSPF level to avoid a lot of unnecessary routes in the core. In this way you can
make summarizations in the distribution routers and avoid a lot of routes in the core.
• If you have a service in the network that is used by a few clients, splitting the IP resources/spaces into
subnets and making summarizations in the distribution or core routers would be a lot of work for little
gain. Because there are few clients, you can only get few extra routes in the core.
If you choose to create a tree structure like the one recommended in “Recommended way of creating a
configuration tree” , you may have a tree structure like: [city or company node]/Node/OSPF area/Ring/
ASR.
Example 1. The configuration tree structure

Acme/Node1/OSPF20/Ring1/ASR1
This means that you can place the IP resource on any of the node levels and choose on which level in
your network to place the summarizations.
Placing the IP resources/spaces on the OSPF node level means that you can put the summarizations in
the distribution routers on the OSPF level. If you choose to put the summarization on the distribution
router level (this specific IP subnet is used in several OSPF areas), you can place the resource on the
node level which is corresponding to the distribution router level.
The configuration tree structure gives you the opportunity to choose the granularity of the
summarizations you perform in the tree.
23
Figure 11. An example of scope configuration
Notice how the “ACME_internet” space is placed on the OSPF level to be able to summarize on the
OSPF level. While the “ACME_VoIP” space which in this case has fewer clients is instead placed on
the node level. This is the same level as where the distribution router is placed, which means that you
can summarize on distribution router level instead of the OSPF level.
Note
In a distributed BECS system, IPv4 spaces, which are used for dynamic services, must not
be placed above the cell attach objects in the configuration tree. Sharing the same IPv4 space
between two cells is not supported, and will result in that both cells will assign the same IP
addresses to clients.
24
Services
Fallback space
In BECS 3, the configuration tree structure is a fully generic tree structure with levels and higher and
lower priority. Thus, you can use this hierarchy not only for parameter objects but also for the IP
addressing of services. The most common usage of this is called “fallback space”, which is a way to
avoid totally running out of IP addresses in a DHCP space.
At normal operation, the IP addresses are allocated from the space that is furthest out in the tree and
closest to the service attachments. In this case on the OSPF level. When the entirety of this space is
used up, BECS3 will stop handing out IP addresses and wait for manual intervention, e.g. add more IP
resources to the space.
If you have created a “fallback space”, BECS will still try to use the normal space on the OSPF level,
but it will realize that this space does not have any available IP addresses and will then look further up
in the tree for another suitable space. In the example below, the “fallback space” is created on the node
level in parallel with the previous ACME_VoIP space.
25
Figure 12. An example of fallback scope configuration
This way BECS can continue to hand out IP addresses before the administrator is manually going to add
more subnets to the normal space on the OSPF level. The only difference is that the summarization of
the addresses in the fallback space is not as good as it is for the normal space, since the normal space
is further down in the tree on the OSPF level.
Having a “fallback space” is a good way to get some headroom in the event of a DHCP space gets
full. The result is that you will not completely run out of addresses for a service, instead you will get
some less optimal addresses (with regard to summarizations). The important thing is that clients will
not experience any disturbance in the service during the time it takes to get more IP addresses from the
service provider and to add them to the network.
26
Services
IP statistics
BECS statistics provides the ability to monitor the usage of available IPv4 addresses in the networks.
BECS keep track of the number of free and allocated addresses, and make the data available through
the SDR framework. The SDR framework stores the data and offers some basic processing capabilities,
such as minimum and maximum value tracking, and running averages. Users can view data as graphs in
BECS GUI, or export it through the MQ module for processing by external software.
Generating statistics
Statistics are generated for IPv4 space objects. For each object, a hierarchy of cnames are generated:
ipv4
a.b.c.d/n
used Addresses allocated to clients or
administratively excluded
blocked Addresses allocated to elements
(this includes the *used* number)
free Addresses free for allocation
summary The same numbers as above,
summarized for the entire space
If “used” is a lot smaller than “blocked”, that indicates an address space fragmentation problem.
Configuration
To generate statistics for one or more IPv4 spaces, the following tasks are required:
1. Add GDR configuration using Add->GDR configuration, and Add->GDR parameter

configuration wizards. The GDR configuration automatically generate a CLOB to store the generated
statistics. For detailed information on how to add GDR configuration, see “Data retrieval”.
2. Set the statistics flag for the IPv4 space object by selecting Statistics in the Properties window of the
object, or by using the the script wizard Assistant->Statistics toggle.
3. Configure a subscription for the IPv4 space using Add->SDR subscription configuration. For more
information on the SDR subscription configuration, see “Add a SDR subscription”. Configure the
subscription according to the statistics data required in the wizard.
27
Figure 13. Sample IPv4 space subscription configuration
28
Services
Figure 14. An example of IP statistics graphs
Service statistics
There is a wizard prepared to see the services deployed in the network and statistics on number of
mappings. This wizard can be run on any level in the network providing useful data on number of service
mappings in total as well as for a specific area or cell.
To run the service attach summary wizard, right-click on the level of the network to analyze and choose
Show->Service attach summary. This will give you a window showing data for the part of the network
that is being analyzed.
• The left pane shows the total number of service attaches and interfaces.
• On the right there are three sections.
• The top one shows a summary of all service attached, divided by the services mapped.
• The middle one shows the number of service attaches per namespace (typically service provider).
29
• The bottom one shows the interfaces grouped by the interface roles.
Figure 15. Service attach sumary
For other statistics you can also use the wizard to show clients and object count from different parts
of the tree.
30
Operations
This chapter explores useful functionalities in operations for the Service Provider and the Network
Operator. The following topics are included:
• “NAR”
• “Data retrieval”
• “MQ forwarding configuration”
• “Backup”
NAR
Network Action Requests (NAR) are generated by BECS system modules as a result of an exceptional
event. Examples of such events are:
• Out of vital system resource
• An IPv4 address space has reached an upper threshold of usage.
• Unknown network element
• A network element that is not defined in the database has made contact with BECS.
• Disk space level critical
• The disk space usage on a system server has reached a critical level.
NAR events are either handled automatically by a script or manually by a system or network
administrator. The script engine offers the interface for automatic NAR event handling.
When a NAR event occurs, the NAR is sent as a message to the system log manager (LM). Each NAR
event has a configured action to apply. NARs are stored in LM so operators can view and act on them
in BECS GUI. But it is also possible for NARs to be handled automatically by a script.
Scripts that handle NAR events are stored with the script engine. When the event occurs, the log manager
signals the script engine to launch the configured script. For each NAR event there is a set of parameters
that is provided as arguments to the script.
NAR setup wizard is used to configure how to handle the NAR in the NAR script. BECS uses different
NAR-type script for iBOS element, generic elements and CPE element. Generic elements can be any
element type, e.g. Actualizer based element manager type.
IBOS NAR-type script

Scripts defined with the type “nar” are used by BECS exclusively for handling NARs. In the file
repository, the files can be seen:
• naribossetup.tcl (NAR setup wizard)
• NAR_IBOS.tcl (NAR script)
31
NAR iBOS setup wizard (naribossetup.tcl)
The NAR setup wizard configures how NARs are handled by the NAR script “NAR_IBOS.tcl”. The
following configurations are included in the NAR setup wizard:
• tasks, e.g. create/modify SNPA, correct uplink and create new element, modify element modules
• triggers, e.g. use default or manually defined triggers
• script, e.g. enable/disable script execution
• running time, e.g. define interval before NAR status is changed to “Done”
The NAR setup wizard is triggered in BECS GUI. An object “NAR iBOS setup” is created on a specific
level in the configuration tree. Typical configuration is one “NAR iBOS setup” at cell level and one at
dist/ASR element level. It is recommended to have dist routers (unmanaged element) at the same level
as ASR elements. Thus, a “NAR iBOS setup” can cover the entire ring.
The following procedures should be followed when using NAR setup wizard:
1. Right-click a node object where you want to configure NARs, on the right-click menu, select Add-
>NAR->NAR iBOS setup.
2. Configure tasks and triggers.
Figure 16. Tasks and triggers
Task Description
Create SNPA for unknown Allow NAR scripts to set SNPA parameter (only if not set) on
element elements
Modify incorrect SNPA Allow NAR scripts to modify SNPA parameter on elements
32
Operations
Task Description
Correct up link mismatch Allow NAR scripts to switch uplink ports
Create new element Allow NAR scripts to create elements
Modify element modules Allow NAR scripts to modify module type on iBOS chassis
element
Set old FQPN as Endpoint ID Allow NAR script set the old FQPN as Endpoint ID when
(Don’t use for BBE) platform change
Set media 100-auto when When replacing platform from ASR4k/5k to ASR6k, allow NAR
replacing platform to ASR6k script configure customer interfaces with media parameters for
auto-negotiation with max 100 mbit/s for backward compatible
Trigger Description
Use default triggers All iBOS_NAR messages are handle by scripts
Set triggers manually Manually select which NAR message are handled by scripts
a. If you select Create SNPA for unknown element or Modify incorrect SNPA,
the following wizard appears:
Figure 17. NAR Script
Enable NAR scripts continue execution after reading NAR iBOS setup
Disable NAR scripts exit after reading NAR iBOS setup
Suppress time Delay time until next NAR message is processed by scripts
b. If you select Correct uplink mismatch or Create new element, the following wizard
appears:
33
Figure 18. Platform
Default platform for element This value is set as parameter “platform” on element object. If
object an element has been created before, the NAR message will use
the existing parameters of the platform.
Resources Select from which resources NAR script can allocate
Role Select roles on uplink port, loopback interface, and customer
port set by NAR script when creating elements
OSPF configuration Define OSPF Area, OSPF Hello interval, and OSPF Dead
interval when creating links and loopback interfaces
34
Operations
Figure 19. New element
Where to create new elements Select where the new element is created in the configuration
tree
E-mail notify Select Send E-mail checkbox to enable e-mail notify when a
new element is created. Specify the e-mail in the textbox E-
mail address
Create link and resource Allow NAR script to create link and resource objects
Create loopback0 on new Tell NAR script to create the interface 'loopback0' on the new
element element
Set X and Y position on Tell NAR script to calculate X and Y position relative to the
objects parent object for link and element objects
Delete invalid interface(s) after Tell NAR script to delete invalid interfaces after replacing an
replacing element element. For example, ethernet0 will be deleted if an ASR4000
is replaced with an ASR5000.
Generate debug message Tell NAR script output debug log message
c. If you select Set triggers manually the following wizard appears:
35
Figure 20. Manual trigger configuration
IBOS NAR script (NAR_IBOS.tcl)
NAR scriptes modify the BECS database according to NAR event and NAR iBOS setup. When the relay
interface is found in the BECS database, it scans the configuration tree upwards from the relay interface
to find the nearest NAR iBOS setup.
NAR scripts are not executed by the user, they are automatically executed for all NARs named IBOS_*
. The following NAR events are supported in the NAR script “NAR_IBOS.tcl”:
IBOS_BOOTP_ERR_UPLINK_RELAY
IBOS_BOOTP_UNKNOWN_ELEMENT
IBOS_BOOTP_UNKNOWN_UPLINK_RELAY
IBOS_BOOTP_UNKNOWN_UPLINK_EXTERNAL_RELAY
IBOS_BOOTP_UNKNOWN_UPLINK_LIMITED_RELAY
IBOS_CSAR_UNKNOWN_ELEMENT
IBOS_MODEL_MISMATCH
IBOS_ELEMENT_MISMATCH_PLATFORM
IBOS_ELEMENT_MISSING_PLATFORM_LOCAL
IBOS_MODULE_UNKNOWN
IBOS_MODULE_MISMATCH
IBOS_MODULE_MISSING
The following features are supported by NAR scripts:
• Create elements (ASR4000, ASR5000 and ASR10000)
• Create/attach links and resources
• Set SNPA on elements
• Modify SNPA on elements
• Replace element (ASR4000 -> ASR5000, ASR5000 -> ASR4000)
36
Operations
• Invalid interfaces will be disabled or deleted depending on configuration in NAR iBOS setup
• Replace model 8/16/24 port (ASR4000 ->ASR5000, ASR5000 ->ASR4000)
• Correct uplink mismatch
• Create module on chassis element slot (MPC480-SE)
• Replace module on chassis element slot (MPC480-SE)
The actions require an ASR that has been powered on or restarted.
IBOS NAR configuration

Three examples of NAR configurations are presented in this section.
• “Adding an element”
• “Swapping uplink”
• “Replacing element”
Before you start the following examples, make sure you select all the following checkboxes of Task in
the “NAR iBOS setup” wizard.
Figure 21. NAR iBOS setup wizard
Adding an element
You can add an element in the network either using wizard Add->PacketFront ASR, or using NAR
script. Different actions are performed by NAR script in these two cases.
37
Adding an element using wizard “Add->PacketFront ASR”
In the following scenario, if you want to add an element between “asr2-4k” and “x450-2” using wizard
Add->PacketFront ASR, the NAR script can set the SNPA parameter automatically. In this case, you
do not need to manually configure the SNPA parameter youself.
Figure 22. Scenario
1. Physically remove the link between the ASR “asr2-4k” and the distribution router “x450-2”, and
connect an ASR to them while keeping the new ASR powered off.
2. In the topology view, disconnect “gig1.asr2-4k” from the link.
Figure 23. Remove uplink
3. In BECS GUI, add an element called “asr3-5k” between “X450-2” and “asr2-4k” using wizard Add-
>*PacketFront ASR*. For detailed information on how to add an ASR using the wiard, refer to BECS
GUI User’s Guide.
38
Operations
Figure 24. Add new element
4. Turn on the new element. Then LM triggers the NAR script.
5. NAR script scans BECS DB for the relay interface and the NAR iBOS setup from the relay interface
level.
6. NAR script scans the configuration tree upwards to find the OID for the relay/boot element and the
link.
7. NAR script sets the SNPA parameter on the new element.
Note
Actions taken by NAR script are logged in LM and visable in BECS GUI, see example in
following figure.
Figure 25. Logs of NAR script actions in SE-TCL
If SNPA parameter is set on the boot element object, a warning is given, otherwise SNPA parameter
is set on the element object.
39
Figure 26. Logs indicating snpa parameter is set
Adding an element using NAR script
In the previouse scenario, see Figure 22, “Scenario”, you can add element “asr3-5k” using the NAR
script instead of using wizard Add->*PacketFront ASR*. The NAR script can creates the new element
and related links automatically in the topology view in BECS GUI.
1. Physically remove the link between the ASR “asr2-4k” and the distribution router “x450-2”, and
connect an ASR to them while keeping the new ASR powered off.
2. In the topology view, disconnect “gig1.asr2-4k” from the link, see Figure 23, “Remove uplink”.
3. Turn on the new element. Then LM triggers the NAR script.
4. NAR script scans BECS DB for the relay interface and the NAR iBOS setup from the relay interface
level.
link.
6. NAR script creates the new element and links to “x450-2” and “asr2-4k”, see Figure 27, “New
element created by NAR script”. The initial name on the new element is in the format of “asr-
aaaabbbbccccdddd”, where aaaabbbbccccdddd is the SNPA value on the element.
Figure 27. New element created by NAR script
7. In the topology view, move the element and rename it to “asr3-5k”.
40
Operations
Figure 28. Logs of NAR sript actions in SE-TCL
To see complete logs of NAR script actions in this example, refer to “logs” in Appendix.
Modify an element module
For the chassis based iBOS element, if there is an unknown or mismatched module, to let the NAR script
correct the module automatically, select the checkbox of Task “Modify element modules"" in the``NAR
generic setup” wizard. For detailed information, see the example - “Modify an element module”.
Swapping uplink
If there is an uplink mismatch between the physical network topology and the BECS DB, the NAR script
can automatically correct the uplink mismatch according to the physical network topology.
1. In the following figure, element “asr2-4k” is down with uplink mismatch according to BECS DB.
In the physical network topology, “gig1.asr2-4k” is connected to “gig2.asr3-5k”; but BECS DB says
that “gig2.asr2-4k” is connected to “gig2.asr3-5k”, which is reflected in the current topology view.
41
Figure 29. Uplink mismatch on asr2-4k in topology view
2. Turn on the element “asr2-4k”. Then LM triggers the NAR script.
3. NAR script scans BECS DB for the relay interface and the NAR iBOS setup from interface level.
link.
5. NAR script swaps uplinks “gig1.asr2-4k” and “gig2.asr2-4k”, and modifies BECS DB so that
“gig1.asr2-4k” is connected to “gig2.asr3-5k”, see the following figure.
Figure 30. Swapped uplinks in topology view
42
Operations
To see complete logs of NAR script actions in this example, refer to “logs” in Appendix.
Replacing element
In case that an element is down in the network, or for some other reasons, you want to replace an
element with another one, the NAR script can automatically make the changes, for example, set the
SNPA parameter, add missing ports and disable invalid interfaces. To enable NAR script disable invalid
interfaces, you must select the checkbox Delete invalid interface(s) after replacing element in the
wizard “NAR iBOS setup”, see Figure 32, “Enable NAR script to disable invalid interfaces”.
43
Figure 32. Enable NAR script to disable invalid interfaces
1. In the following figure, physically disconnect “asr3-4k” (an 16-port ASR4000) from the network.
Figure 33. asr3-4k in topology view
2. As BECS does not automatically detect the new ASR, you must manually remove the SNPA
parameter by double-clicking the element, remove the SNPA value from Element SNPA in the Script
wizard window, or right-clicking the element, remove the SNPA value on the Parameters tab in
the Properties window.
3. Physically connect an ASR5000 in the network, and turn on the element. Then LM triggers the NAR
script.
44
Operations
4. NAR script scans BECS DB for the relay interface and the NAR iBOS setup from interface level.
link.
6. NAR script sets SNPA parameter on the element, adds missing ports and disables interface
“ethernet0”.
Note
An ASR5000 does not have a physical interface “ethernet0”. However, as the element “asr3-4k”
is replaced by an ASR5000, the NAR script does not remove the invalid interface “ethernet0”.
The interface “ethernet0” is disabled as you can see in the configuration tree in Figure 34,
“Disabled interface in the configuration tree”.
Figure 34. Disabled interface in the configuration tree
45
Figure 35. asr3-5k in the topology view
Note
The NAR script does not change the element name for you. In the example shown in Figure 35,
“asr3-5k in the topology view”, the element name is changed to “asr3-5k” manually in the
element Properties window.
Generic NAR-type script

In the file repository, the “nar” type files for handling NARs for generic element are called generic NAR-
type script. They are:
• nargenericsetup.tcl (NAR generic setup wizard)
• nar_bootp_unknown_element.tcl nar_modules.tcl nar_ssh_fingerprint.tcl (NAR script)
NAR Generic setup wizard (nargenericsetup.tcl)
The NAR generic setup wizard configures how NARs for generic element are handled by the generic
NAR scripts. The following configurations are included in the NAR generic setup wizard:
46
Operations
• tasks, e.g. create/modify SNPA, modify element modules for generic element, clear fingerprint.
• EM type(s), e.g. ios for Cisco element, junos for Juniper element, that perform the tasks.
To get the typical configuration for NAR setup, see section “NAR iBOS setup wizard”.
The following procedures should be followed when using NAR setup wizard:
1. Right-click a node object where you want to configure NARs, on the right-click menu, select Add-
>NAR->NAR Generic setup.
2. Configure tasks and EM type(s) that perform the configured tasks.
Figure 37. NAR generic setup
Task Description
Create SNPA for unknown Allow NAR scripts to set SNPA parameter (only if not set) on
element elements
Modify incorrect SNPA Allow NAR scripts to modify SNPA parameter on elements
Clear fingerprint when modify Allow NAR scripts to clear the finger print parameter on elements
incorrect SNPA when SNPA is modified
Modify element modules Allow NAR scripts to modify module type on chassis element
Field Description
Take care of NAR(s) for EM The EM type that is added into to the “EM type” list will perform
type the tasks that selected by NAR scripts accordingly when NAR is
received.
47
Generic NAR scripts
Generic NAR scripts handle NAR event for generic element types that is configured by generic NAR
setup. To understand more on NAR scripts, see section “IBOS NAR script”.
BECS uses different generic NAR scripts to handle different NAR:
• nar_bootp_unknown_element.tcl
• nar_modules.tcl
• nar_ssh_fingerprint.tcl
nar_bootp_unknown_element.tcl
“nar_bootp_unknown_element.tcl” handles the following NAR events:

<EM_TYPE>_BOOTP_UNKNOWN_ELEMENT
<EM_TYPE> is any element type that added from Generic NAR setup wizard.
The following features are supported in the NAR script “nar_bootp_unknown_element.tcl”:
• Set SNPA on elements
• Modify SNPA on elements
• Clear fingerprint on element when SNPA is changed
The actions require an element that has been powered on or restarted.
nar_modules.tcl
“nar_modules.tcl” handles the following NAR events:

<EM_TYPE>_MODULE_MISMATCH
<EM_TYPE>_MODULE_MISSING
<EM_TYPE>_MODULE_UNKNOWN
The following features are supported in the NAR script ‘nar_modules.tcl’':
• Create module on chassis element slot
• Replace module on chassis element slot
The actions require an element that has been powered on or restarted and module is on in the element slot.
Note
The management module can’t be replaced by NAR script.
nar_ssh_fingerprint.tcl
“nar_ssh_fingerprint.tcl” handles the following NAR events:

<EM_TYPE>_SSH_UNKNOWN_FINGERPRINT
48
Operations
The following feature is supported in the NAR script ‘nar_ssh_fingerprint.tcl’':
• Set fingerprint on element
The actions require an element that has been powered on or restarted.
Generic NAR configuration

An example of NAR configurations are presented in this section.
• “Modify an element module”
This example is based on the product kit EM-IOS which is element manager for managing Cisco element.
Before you start the following example, make sure you select the checkbox of Task “Modify element
modules"" and add ``ios"" to the EM type list in the``NAR generic setup” wizard.
Figure 38. NAR generic setup - modify modules
Modify an element module
You can add an Cisco 4500e in the network using element wizard Add->Managed element. For detailed
information on how to add an element using the wizard, refer to BECS GUI User’s Guide.
On the “Select slot/module configuration” page in the wizard, you can either select “Enable” or “Inherit
from tree” to allow NAR to modify modules. The select here will overwrite the NAR setting in the NAR
generic setup. Also select the modules for each slot but leave one module is mismatched with the real
module in the element slot.
After EM connected to element, the logs on executing NAR script for NAR
IOS_MODULE_MISMATCH can be find from GUI.
49
Figure 39. Logs of NAR script for module mismatch
When EM found there was module mismatch, it adds ModueleError lock to the element. This will make
EM stop to configure the element. After NAR script executed. The mismatched module will be modified
with correct module type.
Figure 40. Logs of lock removing
Good to know
When you configure NAR in BECS, the information introduced in this section is helpful to ensure the
best performance of BECS.
Time-consuming task
Including the default suppress time (2 seconds), it can take NAR script at least 3 seconds to set the SNPA
parameter on an element, depending on the current load on BECS core server.
Note
The suppress time can be configured according to your preference in the script wizard “NAR
iBOS setup”.
In a ring topology, if you want NAR script to set the SNPA parameter on hundreds of elements, it takes
a large amount of time to complete. For example, setting SNPA parameters on 200 elements at one
time can take at least 10 minutes to complete, excluding time for element boot, routing distribution and
configuration provisioning from EMIBOS.
The fact that this configuration is time-consuming is not a drawback in NAR implementation or BECS
system. This is a natural behavior of the network configuration. In a ring topology, a set of elements
are connected with point-to-point link, configurations are performed on elements one by one. On a
small network with under five elements, the configuration only takes less than a minute. However,
configuration time accumulates on a large network. You should be aware of this fact when configuring
large network.
Preventing NAR scripts being executed during BECS start-up
During BECS start-up, unnecessary NARs can be generated due to the fact that EM-iBOS is not fully
synchronized with CJM/CRE. To prevent NAR script being executed during this time, follow this
procedure:
1. Remove the NAR script “NAR_IBOS.tcl” from the file repository. You can open the file repository
by clicking View->File repository…
50
Operations
Figure 41. NAR script in file repository
2. Remove unnecessary NAR messages (IBOS_* in this case) either in the NAR window in BECS GUI
or using command clear nar in LM. This must be done before re-installing NAR script.
Note
The command clear nar deletes all NAR messages, you will lose all the history of NAR
messages. However, new NAR messages will be generated if there is something wrong
after executing clear nar. Make sure you are aware of the consequences before using this
command.
• You can open the NAR window by clicking View->NAR, then manually delete the NAR messages
generated by iBOS one by one, see the figure below. For detailed information on how to delete
NAR messages, see section “Check NAR messages in BECS GUI”
• You can open LM by clicking View->System status, then double-click LOGMANAGER, see
Figure 42, “System status:”. In the LM CLI window, write command clear nar, then press Enter,
see Figure 43, “LM CLI”.
51
Figure 42. System status:
Figure 43. LM CLI
3. Re-install the NAR script after BECS start-up.
Using NAR messages for troubleshooting
NAR messages are useful when troubleshooting the network elements. This chapter describes how NAR
messages can be used for troubleshooting. NAR messages are generated by modules in BECS when one
of the following exceptional events occurs:
• Unknown iBOS element
• Unknown uplink or uplink mismatch
• Out of resourses
• Low diskspace on BECS server
52
Operations
• HA state
All NAR messages are stored in a local database (roots/logman/logmanager.db.nars) by

Log Manager (LM).
Check NAR messages in BECS GUI
NAR messages can be viewed using menu View->*NAR…* in BECS GUI.
Figure 44. Menu View->NAR…
Figure 45. A sample of NAR window
To delete a NAR message, status must first be set to “acknowledged”, and then set status to “Done”.
53
Figure 46. Mark selected NAR(s) acknowledged
Figure 47. Mark selected NAR(s) done
Check NAR messages in LM
NAR messages can be viewed using command show nar inmem in LM. You can open LM by clicking
View->System status, then double-click LOGMANAGER.
Example 2. Sample output of command show nar inmem

LM> show nar inmem
Class Type Key Status
-------------------------------------------------------------------------------
ELEMENT IBOS_BOOTP_UNKNOWN_ELEMENT 0008.ae50.04a0 New
235 received, first Fri Nov 16 12:35:06 2007, last Fri Nov 16 12:44:51 2007
Message:
"A BOOTREQUEST was received from an unknown element "0008.ae50.04a0" running
version ibos-asr5k-3.11.0-ED-R"
HA ACTIVE lasse New
1 received, first Fri Nov 16 10:16:09 2007, last Fri Nov 16 10:16:09
2007
Message:
"Cell lasse, node primary active"
ELEMENT IBOS_CSAR_UNKNOWN_ELEMENT 0008.ae50.04a0 New
30 received, first Fri Nov 16 10:00:40 2007, last Fri Nov 16 10:01:38 2007
Message:
"A CSAR connection was established by an unknown element "0008.ae50.04a0"
(address 10.89.1.14) running version ibos-asr5k-3.11.0-ED-R"
By default there are no NAR scripts associated with any NARs. Use the command show nar scripts in
LM to see which NAR scripts that are installed in the system.
Example 3. Sample output of command show nar scripts

LM> show nar scripts
No scripts registered
In the LM, there are some NAR related commands:
• show nar scripts
• show nar active
• show nar inmem
54
Operations
• show nar locks
• clear nar
For more information on these commands, refer to section “Log Manager” in Network Administrator
Guide.
Data retrieval
This section introduces what configurations need to be perfomed in BECS GUI to configure data retieval
in BECS system.
Prerequisites
Make sure the following tasks are fulfilled before you start the configuration. Create CLOBs for Statistics
Data Retrieval (SDR) configuration using the correct version of script iBOS system configration
(ibos_sys_conf). Regenerate the CLOBs for iBOS system configration, if you do not have the following
CLOBs available in the BECS GUI:
• SDR interface configuration
• SDR root configuration
• SDR service configuration
Figure 48. SDR CLOBs
• Make sure that the ASR is running a version of iBOS that supports Generic Data Retrieval (GDR),
version 3.7.x and above.
• Define the SDR and the Message Queue (MQ) parameters for the whole network, or inherit the
information from the tree.
Scripts to use when configuring GDR:
• Add->GDR->GDR configuration
• Add->GDR->GDR parameter configuration
• Add->GDR->SDR configuration
55
• Assistants->Statistics toggle
Data retrieval configuration
Examples provided in this section are different instances of data retrieval configuration. The following
examples are given:
• “Adding the GDR configuraiton under the root node”
• “Adding the GDR parameter configuration to a branch of the network”
• “Adding the GDR parameter configuration for a service”
• “Adding the SDR subscription configuration for a service”
• “Enabling statistics on an object”
Adding the GDR configuraiton under the root node
1. Right-click the root node, in the shortcut menu, select Add->GDR->GDR configuration.
2. Click Next on the first window. This window provides basic description on the GDR configuration.
3. Click Next on the second window. This window informs you that common GDR objects are created.
4. On the third window, choose service “ibos_sys_conf”, then click Next.
Figure 49. Select service
5. Define parameters for SDR.
56
Operations
Figure 50. Element root archive parameters
Click Next.
57
Figure 51. Interface archive parameters
Click Next.
58
Operations
Figure 52. IPv4 space parameters
Click Create.
If you choose Inherit from tree, the GDR needs to be enabled at another point in the configuration
tree.
If you choose Enable or Disable, the parameters are defined on a global level for the network. For
detailed information on parameters, see “Parameter discussion”.
In the example above, all information needs to be enabled at another point in the tree, not under the
root node. You need to add the GDR configuration under the root node in order to get the CLOBs
generated.
The script includes two pages of configuration:
• Element root statistics: environment and system load
• Interface statistics: any interface related info including ADSL
After doing verify and commit for running script GDR configuration on the root node, a library called
GDR configuration has been created. In the library, a parameter object GDR parameters and CLOBs are
generated to make the SDR and RDR function.
59
Figure 53. GDR configuraiton library
Parameter discussion
Defining parameters in specific objects of the configuration tree gives more control over where the GDR
runs. To be used correctly, and avoid overloading the system, it is important to understand the different
parameter settings that are possible and how they affect DCE and other components. The default values
of 900 seconds (15 minutes) record interval, record count of 1344, and write-back value of 5, are chosen
to avoid overloading the system and disk, and to keep statistics values available for searching for 14 days.
In some cases, for example when trouble shooting a specific problem, it may be feasible to use a shorter
record interval for a short period of time. This can be done by adding a temporary GDR parameter object
at a low level in the configuration tree, and set it to use a short record interval. It is not recommended
to use a short interval throughout the whole system, since this will put higher load on iBOS, EMIBOS,
DCE, IAMBR as well as disk I/O.
If the user want data to be stored for longer time than 14 days, the record count may be increased.
Increasing the record count will not increase the load, but the DCE archive will use up more disk space.
The record write-back value is used to decrease the disk I/O and space usage. This setting is the number
of statistics values configured to go to archiving, that are kept only in DCE memory before the values are
written to disk. The default setting means that data will be written to disk every 900 * 5 = 4500 seconds
(75 minutes). The data from all ASRs don’t come in on set times, so data will be written to disk more
often than this in total, but for a single statistics value it’s every 75 minutes.
In a HA set up, DCE only sends data to the other side when they are written to disk, also to decrease
load on network and module communication. However, this means that when the currently active BECS
server is stopped, DCE will lose all data that is only stored in its memory, a maximum of the write-back
number of values for each statistics value. If it is very important that data is always synchronised, the
write-back setting should be set to 1. Note however, that this will increase disk I/O, disk space usage,
DCE load and network load between the two HA machines.
The amount of increase in all cases largely depends on the number of counters configured in the system.
Adding the GDR parameter configuration to a branch of the network
1. Right-click an object in the configuration tree where you want to enable GDR, in the shortcut menu,
select Add->GDR->GDR parameter configuration.
60
Operations
Figure 54. Start “GDR parameter configuration” script
2. Choose service “ibos_sys_conf”, then click Next.
61
Click Next.
62
Operations
Click Next.
63
Figure 58. IPv4 space archive parameters
Click Create.
4. Select Verify in the menu bar.
5. Select Commit in the menu bar.
Adding the GDR parameter configuration for a service
You can configure GDR on services you want to gather statistics for. If you want to gather statistics
for several services, each of the services needs to have GDR configuration and SDR subscription
configuration. Typically, customer services include Internet service, IPTV service and so forth. An
Internet service is being exemplified as follow.
1. Right-click an object in the configuration tree where you want to enable GDR, in the shortcut menu,
select Add->GDR->GDR parameter configuration.
2. Choose service (Internet:lab_isp in this example), then click Next.
64
Operations
65
Figure 60. Service archive parameters
Click Create.
Adding the SDR subscription configuration for a service
You can configure SDR on services you want to gather statistics for. Before this is done, no archiving is
made of the statistics - here you actually configure what you want to gather in your statistics databases.
Adding the SDR subscription configuration for the “ibos_sys_conf” service allows you to gather
statistics for element root statistics, such as environment variables and system load related counters.
Adding the SDR subscription configuration for any other services allows you to gather statistics for the
service attaches for the specific service (Internet:lab_isp in example below).
1. Right-click an object in the configuration tree where you want to enable SDR, in the shortcut menu,
select Add->GDR->SDR subscription configuration.
66
Operations
Figure 61. Start “SDR subscription configuration” script
2. Choose service “ibos_sys_conf”.
Click Next.
3. Define statistics subscription and archiving configuration.
67
Figure 63. Element root statistics
Click Add. You can add more statistics subscription and archiving configuration if you want. Click
Next to continue the wizard.
68
Operations
Figure 64. Interface statistics
Next to continue the wizard.
Figure 65. IPv4 space statistics
Create to close the script wizard for SDR subscription configuration.
69
4. Right-click the same object in the configuration tree, in the shortcut menu, select Add->GDR->SDR
subscription configuration.
Figure 66. Start “SDR parameter configuration” script
5. Choose service (Ethernet_Service in this example).
Click Next.
6. Define statistics subscription and archiving configuration.
70
Operations
Figure 68. Service statistics
Create to close the script wizard for SDR subscription configuration.
Now, you should see the GDR SDR configuration in the configuration tree as follow:
Figure 69. GDR SDR configuration in the configuration tree
Enabling statistics on an object
You can enable statistics on an object that you want to gather statistics for. This is done either by manually
checking the Statistics check-box in the properties window, or by using the Statistics toggle script
in scale. You can check in the DCE CLI that the objects are statistics enabled. CLI command show
objects can show you all objects that are known by DCE.
Enabling statistics in the properties window
1. Right-click an element object, and then click Properties.
71
2. In the Properties window, select the Statistics checkbox.
Figure 70. Element properties
Enabling statistics using script
1. Right-click an object, select Assistants, and then click Statistics toggle.
Figure 71. Start the “statistics toggle” script
2. Select the object type(s) you want to activate statistics for
72
Operations
Figure 72. Statistics toggle
Viewing real-time data retrieval
By adding the GDR configuration under the root node without enabling anything also gives the
possibility to use the Real-time Data Retrieval (RDR) scripts in the system. These scripts are found in
the Show menu. RDR polls the ASR for information instantly, and does not store it anywhere.
Example of RDR information found in the system:
Figure 73. RDR information example
73
Figure 74. iBOS system load
Viewing statistical data
It is possible to view the statistical data in two ways:
• in a database file in BECS system to see gathered statistics information. You can open the statistics
window by right-clicking a specific object, or clicking Statistics on the Find menu.
Figure 75. Start the statistics window
74
Operations
Figure 76. An example of searching result for statistics information
• in BECS GUI to see run-time graphing statistics information. You can start the run-time graphing by
clicking the icon in the toolbar, or clicking Graphs in the View menu.
75
Figure 77. An example of run-time graphing statistics information
To get fast responses, use a short archiving interval when setting up SDR. Be patient if you have used
the default values, it takes time to get the values into the database file.
Useful CLI commands
In DCE
show object
To see which objects have statistics enabled
show object <oid> detailed
To see information about what is configured for a specific object.
76
Operations
Example 4. Output from DCE CLIs for a service attach that is enabled for
gathering statistics
DCE> show object 5485 detailed
Object name: Internet
Object ID: 5485
Statistics ID: 5485
Archives:
Cname regexp: service->lab_isp-Internet->.*
SDRIDs: 844,843,842,841,840,839,838,837,836,835,834,826,827,828,829
Storage IDs: 2
Config:
5420:4: archive service->lab_isp-Internet->.* storage
10 1344 write-back 5 mix-function average
MQ Forwarding:
In CRE
show object <oid> dce
To see the configuration for DCE-objects.
Example 5. Output from DCE CLIs for a service attach that is enabled for
gathering statistics
CRE> show object 5485 dce
object: service attach "Internet"[5485]
parent: interface fastethernet4, role: "customer.running"[3799]
statistics: Enabled
weight: Configured: 0, computed: 4000
namespace: "lab_isp"
servicename: "Internet"
dce: Object status for DCE: <open> <up>
dce: DCE configuration follows
"" open Remote:1 <act>

Created: Thu Aug 16 17:33:36 2007
Last write: Thu Aug 16 18:08:44 2007
Last commit: Fri Aug 17 04:14:30 2007
Config: archive service->lab_isp-Internet->.* storage
10 1344 write-back 5 mix-function average [5420:4]
Render start: service attach "Internet"[5485]
On the ASR
show running-config context interface <name>
To see the configuration on a specific interface of an ASR.
Example 6. Output from ASR CLIs with GDR enabled

interface fastethernet4
description Customer interface
ip access-group cust-in in
ip strict-clients
arp proxy
ip dhcp csar
ip igmp access-group igmp-in
ip igmp downstream-map
pfdp passive
pfdp enable
sdr subscribe 5485 service->lab_isp-Internet interval
10
sdr subscribe 3799 ifcounters interval 10
sdr subscribe 3799 ifmedia interval 10
no snmp trap link-status-change
no shutdown
77
Database files on BECS server
Rotation of archive files is made when the file size is 64MB. A new archive file is then created with
a new filename.
The first slice (archive file) is called:

/opt/packetfront/becs3/roots/dce/archive/class_10_1344/0000000000000000
Example 7. Output on BECS server

bash-3.00# ls /opt/packetfront/becs3/roots/dce/archive/
class_10_1344
bash-3.00# ls -l /opt/packetfront/becs3/roots/dce/archive/class_10_1344/
total 992
-rw-r--r-- 1 pf root 494676 Aug 17 10:48 0000000000000000
MQ forwarding configuration
Data collected by GDR/SDR can be forwarded to MQ so that an external application can have access
to the statistics information. This section will walk you through the steps outlined previously to create
a GDR/SDR configuration for collecting interface statistics for ASR interfaces. The following events
are described:
• “Add a GDR parameter configuration”
• “Add a SDR subscription”
• “Verify DCE configuration in CLI”
• “Verify MQ configuration in CLI”
• “Create a subscriber for MQ”
• “Extract information”
• “Free the disk space”
• “Terminate the subscription”
Add a GDR parameter configuration

1. Right-click the node where your ASRs reside in, in the shortcut menu, select Add->GDR->GDR
parameter configuration.
2. Choose service “ibos_sys_conf”.
3. Configure the following parameters in the following two wizards:
a. Record store interval: 1 second (sample statistics gathered every second from asrs)
b. Record count interval: 1,209,600 seconds (this value means 2 weeks = seconds)
c. Record write back: 5 records (before writing data)
d. Mixing function: average
e. MQ forwarding minimum interval: 5 records before sending to MQ
78
Operations
79
Add a SDR subscription
1. Right-click the node where your ASRs reside in, in the shortcut menu, select Add->SDR subscription
configuration.
2. Choose the service “ibos_sys_conf”.
3. Add an Environment SDR with no MQ forwarding
Figure 80. Element root statistics
4. Add the interface statistics. Averge bit rate (this is the regexp each section will “filter” for) is
configured in this example. Then a queue is defined to send the data to. The name of the queue should
be descriptive such as “poc-asr1.interface.statistic”. Add the namespace if you are using one.
80
Operations
Figure 81. Interface statistics
5. Save (Verify and Commit) your configuration, and also make sure you turn on statistics for the objects
you want (Assistants->Statistics toggle wizard)
Verify DCE configuration in CLI
1. To open the the System status window, go to menu View->System status…, or click F5 in BECS
GUI.
2. To open the DCE CLI, double-click the DCE module in the System status window.
3. Issue command show object detailed in the DCE CLI. This will show you all the objects with
statistics turned on. In this example, we are interested in interface “gigabitethernet1” of poc-asr1,
which has an object id in BECS of 171. You can issue command show object <objectid> detailed
to see this particular interface.
81
Figure 82. Example output of the command “show object”
4. To see the files created when the GDR parameter is created, issue command show archive class file
detailed.
Figure 83. DCE show archive class
82
Operations
Note
There is a directory created on the BECS server that is of the name <sample rate> and <sample
period>. In this example we created a GDR with rate of 1 second and 1,209,600 seconds long,
so DCE created a class archive called “class_1_1209600”.
Output on the BECS server showing files created:

lls -lh /opt/packetfront/becs3/roots/dce/archive/class_1_1209600/ -rw-r--r--
1 pf root 17M Feb 21 13:57 0000000000000000
Verify MQ configuration in CLI

1. To open the the System status window, go to menu View->System status…, or click F5 in BECS
GUI.
2. To open the MQ CLI, double-click the MQ module in the System status window.
3. Issue command show sources detailed in the MQ CLI.
Figure 84. MQ show sources detailed
If you go back to Figure 82, “Example output of the command “show object””, you will see the name
of the message queue defined in the SDR Subscription earlier. The “quenched” message indicates that
MQ is telling the DCE that there are no active subscribers for the queue, so “quench” any messages.
Create a subscriber for MQ

To create a subscriber for MQ, you need to login to the BECS server. The following procedure should
be followed:
1. Set the library path
83
• If you want to set the library path for this particular session, use command
LD_LIBRARY_PATH=usr/lib:/usr/local/lib.
• If you want to set the library path permanently, add it to “.bash_profile” and re-login to the server.
Example 8. Set the library path permanently

root@lab.packetfront.com# cat .bash_profile
PS1="$LOGNAME@`hostname`# "
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
export PATH PS1
alias ll='ls -la'
export LD_LIBRARY_PATH=usr/lib:/usr/local/lib
2. Navigate to the BECS directory using command cd /opt/packetfront/becs3
3. Check “mqctl” options. This step shows you how to choose command options for mqctl. If you know
it already, go to the next step.
Example 9. Get “mqctl” options

root@poc-zone.seabin.packetfront.com# bin/mqctl
% Command (-c ..) missing
Commands:
start, stop, poll, send, list
Examples:
Read and drop 100 messages from subscription 5 every second
.. -c poll -s 5 -i 1 -r 100 -d 100
Just check queue size of subscription 5 every second
.. -c poll -s 5 -i 1
Create a subscription for 'foo.*' in namespace 'mingus',
output as unformatted text
.. -c start -q 'foo.*' -n mingus -t string
Create an exclusive subscription for 'toga.bears' in
root namespace (''), output just two vars as xml
.. -c start -q 'toga.bears' -t xml -f '$group $member'
Stop subscription 923 in namespace 'mingus'
.. -c stop -s 923 -n mingus
Get list of all subscription in namespace 'mingus'
.. -c list -n mingus
Note
mqctl is actually in /opt/packetfront/becs3/bin, however you want to be in the base directory

of BECS, not in bin. When issuing the command for mqctl, it will be bin/mqctl (see examples
below).
4. Create an MQ subscriber for the MQ source created earlier
Example 10. Create an MQ subscriber

root@lab.packetfront.com# bin/mqctl -c
start -q poc-asr1.interface.statistics -t string
MQCTL primary (pid 3725) started at Thu Feb 21 13:53:56 2008
connecting to /tmp/iambr
start: Connecting to EAPI...
IAMB Connection established
Connected to bus on 2eec.2f83.0100 as application 34
########################################################
start: messageQueueSubscriptionStart: subscriptionid=4, _txid=0
MQCTL primary (pid 3725) exited Thu Feb 21 13:53:56 2008
Note
The subscriber created has been given a unique ID (subscriptionid=4) that will be used later.
84
Operations
You can see also IAMBR NEIGHBOR log messages in BECS when you execute this.
Figure 85. Logs of IAMBR
If you go back to the MQ CLI and issue command show sources detailed again, you can see your
"subscriber" listed, as well as the files that have been generated. Note the Quenched status is also gone.
Figure 86. MQ show sources detailed
Output on the BECS server shows files created:
root@poc-zone.seabin.packetfront.com# ls -lh /opt/packetfront/becs3/roots/mq/sub4/

total 5634
-rwxr-xr-x 1 pf root 64M Feb 21 13:56 0000000000000000
-rw-r--r-- 1 pf root 155 Feb 21 13:53 mq.save
Extract information
Now you need to extract the actual information out of the file where MQ is saving data into.
You can use the "-c poll" option of the mqctl command, and then tell it what subscription to read, and
how many rows you want to see. In the following example it is reading the subscription created earlier,
and reading one line.
85
Example 11. Reading the subscription
poll -s 4 -r 1
poll: Connecting to EAPI...
########################################################
poll: messageQueueSubscriptionPoll: subscriptionid=4,
data={vstring="msg.ifcounters->rxavgbitrate=2120, sid=168,
oid=168", receivetime={seconds=1203623637,
microseconds=711084}, sourcetime={seconds=0, microseconds=0},
source="DCE-poc-primary", queue="poc-asr1.interface.statistics",
msgid="default.primary:47bdc6430000bb50",
seq=5169505938356353872, namespace="", subscriptionid=4},
data#=1, entries=1, queuesize=10745445,
outputtype="string", _txid=0
Now that you have a line of data, the actual statistic is the "data=" part, as well as the timestamp it was
created:
Example 12. Subscription data

data={vstring="msg.ifcounters->rxavgbitrate=2120,
sid=168, oid=168", receivetime={seconds=1203623637, microseconds=711084},
The "oid" is the OID of the interface in BECS, the seconds is the epoch timestamp on the Unix server.
You need some way to map the OID to an interface name that is meaningful in your application using
the data. To convert the timestamp to something more meaningful, run the following on Linux:
currentEpoch='1505481926'
date -d @${currentEpoch}
This can output a more friendly timestamp such as: "Fri Sep 15 15:25:26 CEST 2017".
You can embed that in your script if that is how you extract and format the data.
Free the disk space

If your application is reading/formatting the data and using it elsewhere, you want to delete the data after
it has been read. This will free up the disk space consumed by the MQ subscriber. To do this you add
the parameter -d <num rows> which is generally the same value as the read -r <number of rows>
Example 13. Delete data

poll -s 4 -r 1 -d 1
poll: Connecting to EAPI...
########################################################
poll: messageQueueSubscriptionPoll: subscriptionid=4,
data={vstring="msg.ifcounters->rxavgbitrate=2120, sid=168,
oid=168", receivetime={seconds=1203623637,
microseconds=711084}, sourcetime={seconds=0, microseconds=0},
source="DCE-poc-primary", queue="poc-asr1.interface.statistics",
msgid="default.primary:47bdc6430000bb50",
seq=5169505938356353872, namespace="", subscriptionid=4},
data#=1, entries=1, queuesize=47334650,
outputtype="string", _txid=0
This will delete the row you just read from the MQ subscriber file.
86
Operations
Terminate the subscription

If you no longer need to subscribe to the data, you need to issue a "stop" command via mqctl. This will
delete the subscription and delete the files that were generated when the subscriber was created:
stop -s 4
stop: Connecting to EAPI...
########################################################
stop: messageQueueSubscriptionStop: _txid=0
Make sure you stop/delete your MQ subscription when it is no longer needed. It will continue to use up
disk space if you do not, as opposed to the GDR/SDR which will overwrite the data once the threshold
set previously has been reached (that is two weeks in the scenario created previously).
Backup
Refer to section Backup in BECS System Administrator Guide.
87
88
Appendix
Complete logs of NAR script actions in example “Adding an element using wizard Add-
>PacketFront ASR”.
2007-11-28 12:59:16 SETCL NAR_IBOS.tcl Notice
NAR Done, suppress 10 seconds, NAR class='ELEMENT',
type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae50.04a0'
2007-11-28 12:59:15 SETCL NAR_IBOS.tcl Info Commit
jobs, NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae50.04a0'
Add resource to boot interface, object='/rootnode/Cell/Ring/asr-0008ae5004a0/gigabitethernet2',
NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY',
key='0008.ae50.04a0'
Connect link (79793) to boot interface, object='/rootnode/Cell/Ring/asr-0008ae5004a0/gigabitethernet2',
key='0008.ae50.04a0'
Add resource to relay interface, object='/rootnode/Cell/Ring/asr2-4k/gigabitethernet1', NAR
class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae50.04a0'
Add resource to relay interface link, oid=79793, NAR
class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY',
key='0008.ae50.04a0'
Connect link (79793) to relay interface, object='/rootnode/Cell/Ring/asr2-4k/gigabitethernet1',
key='0008.ae50.04a0'
Link created, oid=79793, NAR class='ELEMENT',
2007-11-28 12:59:15 SETCL NAR_IBOS.tcl Info Boot
interface, oid=79768, name='gigabitethernet2',
key='0008.ae50.04a0'
element, oid=79763, snpa='0008.ae50.04a0', object='/rootnode/Cell/Ring/asr-0008ae5004a0',
key='0008.ae50.04a0'
2007-11-28 12:59:15 SETCL NAR_IBOS.tcl Info Relay
element, oid=183, snpa='0008.ae10.1ee0', object='/rootnode/Cell/Ring/asr2-4k',
NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae50.04a0'
interface, role='uplink.running', NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY',
key='0008.ae50.04a0'
interface, oid=215, name='gigabitethernet1', NAR
key='0008.ae50.04a0'
2007-11-28 12:59:15 SETCL NAR_IBOS.tcl Info Use
NAR iBOS setup in '/rootnode/Cell/Ring',
key='0008.ae50.04a0'
NAR Ack, NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae50.04a0'
NAR Done, suppress 10 seconds, NAR class='JOB', type='IBOS_MODEL_MISMATCH', key='0008.ae50.04a0'
jobs, NAR class='JOB', type='IBOS_MODEL_MISMATCH',
key='0008.ae50.04a0'
Interface created, oid=79792, name='fastethernet24',
NAR class='JOB', type='IBOS_MODEL_MISMATCH',
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
89
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
90
Appendix

key='0008.ae50.04a0'
Interface created, oid=79768, name='gigabitethernet2',
key='0008.ae50.04a0'
Modify model parameter (ASR) to 'ASR5124', oid=79763,
object='/rootnode/Cell/Ring/asr-0008ae5004a0',
NAR class='JOB', type='IBOS_MODEL_MISMATCH', key='0008.ae50.04a0'
NAR class='JOB', type='IBOS_MODEL_MISMATCH', key='0008.ae50.04a0'
NAR Ack, NAR class='JOB', type='IBOS_MODEL_MISMATCH',
key='0008.ae50.04a0'
jobs, NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae50.04a0'
Boot interface not found, name='gigabitethernet2',
key='0008.ae50.04a0'
element, oid=79763, snpa='0008.ae50.04a0', object='/rootnode/Cell/Ring/asr-0008ae5004a0',
key='0008.ae50.04a0'
NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
key='0008.ae50.04a0'
NAR Ack, NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae50.04a0'
type='IBOS_BOOTP_UNKNOWN_ELEMENT', key='0008.ae50.04a0'
jobs, NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_ELEMENT',
key='0008.ae50.04a0'
Add resource to boot interface, object='/rootnode/Cell/Ring/asr-0008ae5004a0/gigabitethernet1',
NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_ELEMENT', key='0008.ae50.04a0'
Set role 'uplink.running' on boot interface, object='/rootnode/Cell/Ring/asr-0008ae5004a0/gigabitethernet1',
NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_ELEMENT',
key='0008.ae50.04a0'
Connect link (24387) to boot interface, object='/rootnode/Cell/Ring/asr-0008ae5004a0/gigabitethernet1',
Boot interface created, oid=79766, object='/rootnode/Cell/Ring/asr-0008ae5004a0/gigabitethernet1',
Interface loopback0 created, oid=79764, object='/rootnode/Cell/Ring/asr-0008ae5004a0/loopback0',
key='0008.ae50.04a0'
Boot element created, oid=79763, snpa='0008.ae50.04a0',
object='/rootnode/Cell/Ring/asr-0008ae5004a0',
Set platform parameter to 'asr5k' (using info from NAR message),
key='0008.ae50.04a0'
Boot element not found, snpa='0008.ae50.04a0', NAR
91
class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_ELEMENT',
key='0008.ae50.04a0'
interface link, oid=24387, NAR class='ELEMENT',
type='IBOS_BOOTP_UNKNOWN_ELEMENT', key='0008.ae50.04a0'
element, oid=23549, object='/rootnode/Cell/Ring/x450-2.lab.packetfront.com',
key='0008.ae50.04a0'
interface is unmanaged (role will not be evaluated), NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_ELEMENT',
key='0008.ae50.04a0'
interface, oid=23550, name='port12', NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_ELEMENT',
key='0008.ae50.04a0'
key='0008.ae50.04a0'
NAR Ack, NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_ELEMENT',
key='0008.ae50.04a0'
92
Appendix
Complete logs of NAR script actions in example “Swapping uplink”.

type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae10.1ee0'
jobs, NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae10.1ee0'
Add resource to boot interface, object='/rootnode/Cell/Ring/asr2-4k/gigabitethernet1',
NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae10.1ee0'
key='0008.ae10.1ee0'
element, oid=79515, snpa='0008.ae50.04a0', object='/rootnode/Cell/Ring/asr3-5k', NAR
class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae10.1ee0'
key='0008.ae10.1ee0'
key='0008.ae10.1ee0'
key='0008.ae10.1ee0'
NAR Ack, NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae10.1ee0'
jobs, NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae10.1ee0'
Add resource to boot interface, object='/rootnode/Cell/Ring/asr2-4k/gigabitethernet2',
Connect link (2457) to boot interface, object='/rootnode/Cell/Ring/asr2-4k/gigabitethernet2',
key='0008.ae10.1ee0'
key='0008.ae10.1ee0'
element, oid=137, snpa='0008.ae10.2200', object='/rootnode/Cell/Ring/asr1-4k',
key='0008.ae10.1ee0'
key='0008.ae10.1ee0'
key='0008.ae10.1ee0'
NAR Ack, NAR class='ELEMENT', type='IBOS_BOOTP_UNKNOWN_UPLINK_RELAY', key='0008.ae10.1ee0'
93
type='IBOS_BOOTP_ERR_UPLINK_RELAY', key='0008.ae10.1ee0'
jobs, NAR class='ELEMENT', type='IBOS_BOOTP_ERR_UPLINK_RELAY',
key='0008.ae10.1ee0'
Boot interface connected to relay link '/rootnode/Cell/Ring/asr2-4k/gigabitethernet1', NAR
class='ELEMENT', type='IBOS_BOOTP_ERR_UPLINK_RELAY', key='0008.ae10.1ee0'
DB boot interface detached '/rootnode/Cell/Ring/asr2-4k/gigabitethernet2',
NAR class='ELEMENT', type='IBOS_BOOTP_ERR_UPLINK_RELAY',
key='0008.ae10.1ee0'
Boot interface detached '/rootnode/Cell/Ring/asr2-4k/gigabitethernet1',
key='0008.ae10.1ee0'
2007-11-23 15:24:23 SETCL NAR_IBOS.tcl Info DB
boot element, oid=183, object='/rootnode/Cell/Ring/asr2-4k',
key='0008.ae10.1ee0'
2007-11-23 15:24:23 SETCL NAR_IBOS.tcl Info DB
boot interface, oid=223, name='gigabitethernet2',
key='0008.ae10.1ee0'
class='ELEMENT', type='IBOS_BOOTP_ERR_UPLINK_RELAY',
key='0008.ae10.1ee0'
key='0008.ae10.1ee0'
element, oid=79515, snpa='0008.ae50.04a0', object='/rootnode/Cell/Ring/asr3-5k', NAR
class='ELEMENT', type='IBOS_BOOTP_ERR_UPLINK_RELAY', key='0008.ae10.1ee0'
interface, role='uplink.running', NAR class='ELEMENT', type='IBOS_BOOTP_ERR_UPLINK_RELAY',
key='0008.ae10.1ee0'
key='0008.ae10.1ee0'
key='0008.ae10.1ee0'
NAR Ack, NAR class='ELEMENT', type='IBOS_BOOTP_ERR_UPLINK_RELAY',
key='0008.ae10.1ee0'
94
Index
A
About this manual, 1
B
BECS system overview, 3
C
Cell modules, 5
CJM, 5
Configuration Job Manager, 5
Configuration Rendering Engine, 5
Core modules, 4
CRE, 5
CSAR, 5
D
Data Collection Engine, 5
DCE, 5
E
EAPI, 4
element manager, 5
EM-iBOS, 5
EMBECS, 3
EMI, 5
EMIBOS, 5
External Application Interface, 4
I
IAMBR, 4
Inter-Application Message Broker Router, 4
L
LM, 4
Log Manager, 4
M
Message Queue, 5
MQ, 5
N
Netlog, 4
S
Script Engine TCL, 4
SETCL, 4
SM, 4
System Manager, 4
95
96

BECS Design Guidelines-3.15.3

Uploaded by

Copyright:

Available Formats

You might also like

BECS Design Guidelines-3.15.3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BECS Design Guidelines-3.15.3

Uploaded by

Copyright:

Available Formats

BECS 3.15.

Source ID: 370f1f644de9053a0990b794e7acbda11be7adec

Copyright and Legal notice

About this manual

This manual describes the following:

• BECS GUI User Guide

• BECS System Administrator Guide

• BECS Network Adminstrator Guide

• BECS Module Command Reference

• BECS Service Deployment Guide

• BECS Troubleshooting Guide

For more information, send an email to info@pfsw.com.

Figure 1. BECS system overview

EMBECS is required on both the Core and the Cell servers.

• "Address plan summarization"

Address plan summarization

Table 1. The parent-child relationship

• which address is used on which port for which MAC address

• which gateway that the client should have

• if client addresses on the ASR should be aggregated in OSPF

It is also possible to exclude addresses that normally could be allocated.

Aggregating one network resource to different Distribution POP’s

Figure 2. Configuration tree at the beginning

The following procedure is described:

• “Create loopback0 interface with resource”

• “Create interfaces and link objects”

• “Create resource on the link object”

• “Create resource on interfaces”

Create loopback0 interface with resource

Figure 4. Create interface loopback0

Create interfaces and link objects

1. Add interface “uplink_1” on Distribution_Router_2.

2. Add interface “gigabitethernet1” on ASR2-1.

b. Define the interface used for connection on each node.

Figure 5. Create and connect interfaces

Create resource on the link object

1. Right-click the link between Distribution_Router_2 and Access_2.

2. Select Add, then click IPv4 Resource.

Figure 6. Create resource on the link object

Create resource on interfaces

1. Right-click one of the two interfaces connected to the link object.

Resource tree vs. configuration tree

Figure 8. Resource tree in the CJM

The link object

Introduction of the configuration tree

• Internet service with low priority

• IP telephony service with higher priority

• IPTV service with the highest priority

Internet service: weight 100

IP telephony service: weight 200

IPTV service: weight 300

iBOS system configuration

Recommended way of creating a configuration tree

• The distribution router pair is placed on the node level.

• Place IP dynamic library and IP static library on each node.

• An assigned IP resource (an IPv4 space is needed if the service is dynamic)

The benefits of creating a tree like this are several:

• Having the OSPF area level is essential for route summarization.