Home | Business News | Browse by Publication | X | XML Journal

Managing Juniper Networks'' routers using XML: an XMN-based RPC mechanism. (Enterprise Solutions).

Article Excerpt
XML is the ideal platform for network management. XML's self-describing, text-based syntax is able to encapsulate the complex, hierarchical, and volatile configuration of any networked device. Controlling a network full of devices with proprietary and constantly evolving configuration syntax requires a Herculean effort. XML and XML Schemas help by providing a canonical representation and description of each device's configuration data and model. Even better, the vast and growing array of XML tools makes it even simpler and more intuitive to work with any XML document.

To leverage these in-herent strengths, Juniper Networks implements an XML-based RPC mechanism with which all of Juniper's M- and T-series routers can be queried, configured and managed. An idea this powerful deserves its own acronym: XNM (XML Network Management).

Quick Tour

Clients send requests encoded within elements and receive replies within matching elements. It's this simple:



This interaction is shown in Figure 1.

[FIGURE 1 OMITTED]

Similarly, loading XML-encoded configuration is performed with the element. The server responds--assuming no error has occurred--with an empty tag, indicating success.

Supplying additional tags within the tag allows a configuration subset to be retrieved. For example, the policy-options statement below the configuration root contains a set of routing policies that our client can request:



This will retrieve all configured policy statements.

Configuration subsets can be configured on the device in a similar manner. Any configuration snippet supplied within the element will be configured on the router. Supplying various attributes determines whether the configuration snippet should be created, updated, or deleted, as we'll see later. Success is indicated when the server responds with an empty tag.

JUNOS and XNM

The XNM server software contains several features that make using the XNM API both flexible and robust. Using a "commit-based" configuration model, a client writes configuration data to a "candidate" configuration. A client configuring a router works on a shared or private candidate configuration. Once the configuring is done, a "commit" operation must be issued to transfer the candidate configuration to the router's running configuration. By default, the candidate configuration is shared with anyone who happens to be configuring the router at any given instant.

When the router is configured remotely, it would be nice to lock everyone out of configuration mode except yourself. To accomplish this your client may "lock" the candidate configuration database, ensuring exclusive access only to you. Once your client has exclusive access to the candidate configuration, you can safely alter it without fear of conflicts with other API clients or CLI users. The relationship between the candidate and running configurations can be seen in Figure 2; Figure 3 shows the client accessing the candidate configuration simultaneously. Had any one of the three clients locked the candidate configuration, only...

View this article FREE - Now for a Limited Time, try Goliath Business News
Free for 3 Days!