Orchestream's Service Activator is about creating applications on networks, with "applications" in this case defined as QoS, VPNs and other such things. In our testing, we clearly saw that Service Activator is the most mature product of the three, offering clear functionality and a versatile, object-oriented design that extends to its API. It makes no attempt to create a base configuration but rather expects the network to be configured and stable.
Service Activator configures QoS, MPLS (Multiprotocol Label Switching) IP VPNs, Juniper Networks' Circuit Cross Connects and access limiting through the manipulation of access lists. The product's architecture is object-based -- some basic object types include roles, access groups/user IDs, sites and per-hop behavior groups.
Devices, interfaces and virtual or subinterfaces are given roles within Service Activator. The devices are sorted at discovery time based on an editable text file that classifies devices and interfaces as having access, gateway or core roles. The classification can be overridden, however, either in the file or through a manual reclassification from within the GUI.
Service Activator accomplishes network configuration changes by using transactions. Whenever configurations are created, either by dragging and dropping within the GUI or via the command line, transactions are queued to perform the change. The transactions can then be run or saved and scheduled. This process requires a commit-and-verify process, so it's a transaction in the real sense of the word. All transactions are logged, and managers can back out one transaction at a time simply by deleting each transaction. None of the other products we tested came close to offering this level of control or ease of policy application.
Roles Playing
Roles are key to applying policy from within Service Activator. The default roles classify devices or interfaces as core, gateway or access devices. Policies are then applied to devices based on role. Although specific devices can have separate policies, it is obviously much easier to manage device and interface policies through reduced sets based on function. Service Activator is the only product of the three that uses this device-role method to determine where to apply policy.
Differentiating devices and interfaces is necessary because of the dual role a single switch or router can play: Any given device can be sitting either on a network boundary between service provider and customer or on a customer's network facing the service provider on one side and the internal network on the other. This capability was useful in our testing of MPLS VPN configurations because it let the provider's edge router have a different configuration on the customer-facing interface as opposed to core-network-facing interface.
Groups and accounts are pretty standard fare for controlling access. User accounts can be members of groups that have their access defined. In Service Activator, almost all objects can be owned by a user, with the owner able to delegate access to other members and/or groups. Not only did this capability let us set very granular restrictions on which devices users could access, we could also delegate control over specified objects to those users. This is the kind of granularity necessary for companies looking to support multitenancy, whereby the policy system will let end users access only their configurations and will support self-configuration. Service Activator does not, however, support access to external directories.
MPLS VPNs adhere to RFC 2547, and BGP (Border Gateway Protocol) routing had to be set up for Service Activator to be able to create the VPNs. However, Service Activator set up the BGP groups using the same policy settings on both Cisco 7200 and Juniper M5 devices. Once we understood how to use Service Activator (which wasn't very difficult), the work was in obtaining the right versions of IOS and getting our base OSPF and BGP routing running. This means Service Activator relies on having in place the appropriate router- and switch-code versions.
Smart Talker
Orchestream's offering shows its intelligence when changes are sent to the network. Not only does Service Activator check the syntax of commands before sending them, it checks to see if the interface will support the configuration properties assigned in the policy. This is possible because Orchestream predefines in Service Activator a given device's capabilities. However, properly using this feature calls for the intelligence of a network engineer. Why? Because to allow for decoupling of the policy rules and the devices to which the rules apply, the options that aren't applicable to a particular object can't be grayed out or unavailable. But once Service Activator fails in an attempt to apply a policy to a device, the Orchestream event system simply shows an error. Opening that error reveals the property page of the rule in question, but the product doesn't specifically indicate what property failed.
When setting ACLs (access-control lists) on Cisco devices, Service Activator checks to see what ACLs are set and avoids using those previously defined, even if they were set using another tool or by hand. This means you needn't worry about overlaying existing ACLs in a configuration, even if Service Activator didn't create them.
In fact, intelligence is evident throughout Service Activator's interface. Handy dandy right-click pop ups and context launches are everywhere, in stark contrast to Dorado Redcell Suite's GUI, which, even though it's Java, wasn't very functional in our tests.
Pricing for Service Activator is $72,000 per policy server and $12,000 per device driver family -- so all Cisco's device drivers are just $12,000. In addition, there is a per-interface cost, which in our pricing scenarios ran $195 per interface in quantities of 100, $175 in quantities of 1,000 and $120 in quantities of 10,000. This undoubtedly makes Orchestream the most expensive solution tested, but we say you get what you pay for, and this is one product worth the extra coin.
Each server can handle as many as 16 concurrent console sessions. All processes (server and proxy agents) run distributed, so the amount of hardware required is implementation-dependent. We ran our tests on a single Microsoft Windows NT box without any problems, but Orchestream says its customers generally run servers and proxy agents on separate Sun Solaris boxes and the GUI on Microsoft Windows NT or Windows 2000 PCs.
Orchestream says its future plans for Service Activator include adding more configuration applications, such as IPsec VPNs, and cultivating more third-party vendor integrations. While we were testing, Orchestream plans integration with InfoVista, allowing for the creation of configurations based on SLAs (service-level agreements). InfoVista creates the reports that audit and track the SLAs, while Orchestream creates the configurations to make the network compliant.
Service Activator 3.0. Available: Now. Orchestream, (703) 734-3706; fax (703) 734-3713. www.orchestream.com or info@orchestream.com
REPORTS
ANALYTICS
Follow 
