Management Interface. [COMMENT28] ALLTEL Financial and Client will establish a joint data processing steering committee to facilitate long-term planning and to provide for a periodic review of Client's data processing priorities, objectives, and accomplishments. Such committee will be comprised of designated members of Client's executive management and shall meet monthly. ALLTEL Financial's Account Executive will be a non-voting member of such committee. The steering committee will develop and adopt a long-term strategic plan and a rolling twelve-month business plan for data processing. ALLTEL Financial will assist the committee in evaluating its plans and the implementation thereof through an annual review presented to the committee and to the board of directors of Client, and through more frequent call programs and surveys. An initial organization meeting of the steering committee and the user committee described in Section 6.2 will be held within thirty (30) days of the Effective Date of this contract.
Management Interface. To interact with a XORP router using the command line interface (CLI), the user runs the XORP command shell “xorpsh”. This allows configuration of the router and monitoring of the router state. The user interface style is loosely modeled on that of a Juniper router. XORP Resource Locators are the XORP projects preferred means for inter-process communication. An XRL Target is defined as something that XRL requests can be directed to in order to be executed. Multiple XRL targets can exist within a single process, though there will typically be one target per process. Each XRL Target has an associated name and a set of IPC mechanisms that it supports. At start-up each target registers its name and IPC mechanisms with the Finder, so other processes are able to direct requests to it. An XRL Interface is defined to be a set of related methods that an XRL Target would implement. Each XRL Interface is uniquely identified by a name and version number. An XRL Target will nearly always implement multiple interfaces and potentially multiple versions of particular interface. For instance, every XRL Target could implement a process information interface that would return information about the process hosting the target. Each XRL Target will implement interfaces specific to their field of operation: a routing process would implement the “routing process interface” so that the RIB process can make identity-agnostic XRL calls for tasks like redistributing a route to another routing protocol. An XRL Interface Client is defined to be a process that accesses a particular XRL Interface. Example XRL Targets and clients: OSPF, RIB, and CLI. OSPF and RIB processes are XRL targets. OSPF supports XRL interfaces “OSPF Configuration/1.0” and “Routing Protocol/1.0”: the CLI is a client of the “OSPF Configuration/1.0” interface and the RIB a client of the “Routing Protocol/1.0” interface. RIB supports XRL interface “Routing Information Base/1.0”: the OSPF is a client of that interface. The XRL Interface and XRL Target specifications are used to generate code that takes some of the tedium out of writing XRL related code. Two scripts are written: clnt-gen and tgt-gen that generate C++ header files and libraries and also produce a list of XRL’s for each XRL Target. XORP supports Forwarding Engine Abstraction (FEA) whose main purpose is to provide a stable API to the forwarding Engine. In terms of Xorp intrinsic engine this is performed via XRL interfaces. FEA functionality includes Interf...
Management Interface. You Clients can use the command-line client birdc to talk with a running BIRD. Communication is done using a bird.ctl UNIX domain socket (unless changed with the -s option given to both the server and the client). The commands can perform simple actions such as enabling/disabling of protocols, telling BIRD to show various information, telling it to show routing table filtered by filter, or asking BIRD to reconfigure. Press ? at any time to get online help. Option -v can be passed to the client, to make it dump numeric return codes along with the messages. You do not necessarily need to use birdc to talk to BIRD, your own applications could do that, too -- the format of communication between BIRD and birdc is stable. Configuration of BIRD is complex, yet straightforward. There are three modules taking care of the configuration: config manager (which takes care of storage of the config information and controls switching between configs), lexical analyzer and parser. The configuration manager stores each config as a config structure accompanied by a linear pool from which all information associated with the config and pointed to by the config structure is allocated. There can exist up to four different configurations at one time: an active one (pointed to by config), configuration it is just switching from (old_config), one queued for the next reconfiguration (future_config; if it's non-NULL and the user wants to reconfigure once again, it is only needed to just free the previous queued config and replace it with the new one) and finally a config being parsed (new_config). Loading of new configuration is very simple: just call config_alloc() to get a new config structure, then use config_parse() to parse a configuration file and fill all fields of the structure and finally ask the config manager to switch to the new config by calling config_commit(). CLI commands are parsed in a very similar way -- there is also a stripped-down config structure associated with them and they are lex-ed and parsed by the same functions, only a special fake token is prepended before the command text to make the parser recognize only the rules corresponding to CLI commands. The lexical analyzer used for configuration files and CLI commands is generated using the flex tool accompanied by a couple of functions maintaining the hash tables containing information about symbols and keywords. Each symbol is represented by a symbol structure containing name of the symbol, its lexical sco...
Management Interface. The Vyatta CLI is the main user interface to interact with Vyatta. To access the command-line interface (CLI), log on to the Vyatta system, either directly through the console port, or remotely using an SSH or Telnet session. • From the router’s console. • Remotely, using SSH or Telnet. The CLI of the Vyatta system includes two kinds of commands: • Vyatta-specific commands for operating and configuring the Vyatta system. • Commands provided by the operating system shell in which the Vyatta CLI operates. The commands you can execute depend on your user role. However, any command to execute can be run from within the Vyatta CLI. There are two command modes in the Vyatta CLI: operational mode and configuration mode. • Operational mode provides access to operational commands for showing and clearing information and enabling or disabling debugging, as well as commands for configuring terminal settings, loading and saving configuration, and restarting the system. • Configuration provides access to commands for creating, modifying, deleting, committing and showing configuration information, as well as commands for navigating through the configuration hierarchy.
Management Interface
