XORP Router Manager Process (rtrmgr) Version 1.8-CT
Contents
1. show interfaces and show vif The show interfaces command takes one mandatory parameter whose value must be the name of one of the configuration tree nodes taken from the variable name wildcard expansion interfaces interface 23 Thus if the router had config tree nodes called interfaces interface x10 and interfaces interface x11 then the value of the mandatory parameter must be either x10 or x11 Additional optional parameters might be brief detail or extensive the set of allowed optional parameters is specified by the Sopt parameter commands The Scommand command indicates the program or script and its arguments to be executed to im plement this operational command the script should return human readable output preceded by a MIME content type indicating whether the text is structured or not If the command specification contains any positional arguments e g 0 1 2 they are resolved by substituting them with the particular substring from the typed command line command 0 is substituted with the complete string from the command line 1 is substituted with the first token from the command line 2 is substituted with the second token from the command line The resolved positional arguments along with the remaining arguments if any are passed to the executable command For example if the user types show interfaces xl0 the xorpsh might invoke the show_interface command using the Unix comma2. Most of the nodes are annotated with commands to be run when the value of the node changes in the configuration tree when a new instance of the node is created or an instance of the node is deleted in the configuration tree or to get the current value of a node from the running processes providing the functionality Note that for verification purpuse all variable names must refer to valid nodes in the template tree Hence the template tree may contain dummy nodes that shoudn t be used for configuration purpose For example the internal variable TID that can be used to store the transient transaction ID should be specified as interfaces Smodinfo TID Screate 2 1 Template Tree Node Types The following types are currently supported for template tree nodes u32 Unsigned 32 bit integer u32range A range of unsigned 32 bit integers defined by an upper and lower inclusive boundary Boundaries are separated by two dots e g 1234 5678 If upper and lower boundaries are equal it is sufficient to specify only a single value e g 1234 132 Signed 32 bit integer bool Boolean valid values are true and false toggle Similar to boolean but requires a default value Display of the config tree node is suppressed if the value is the default ipv4 An IPv4 address in dotted decimal format ipv4net An IPv4 address and prefix length in the conventional format E g 1 2 3 4 24 ipv4range A range of IPv4 addresses def
3. XRL directory to be used to generate stub code in the XORP processes this forms the definitive version of a particular XRL Checking against this version detects if a template file has somehow become out of sync with the router s codebase Doing this check at startup prevents subtle run time errors later The rtrmgr will exit if a mismatch is discovered The rtrmgr then reads the router configuration file All the configuration options in the config file must correspond to configurable functionality as described by the template files As it reads the config file the rtrmgr stores the intended configuration in its configuration tree At this point the nodes in the configuration tree are annotated as not existing that is this part of the configuration has not yet been communicated to the process that will implement the functionality The rtrmgr next traverses the configuration tree to discover the list of processes that need to be started to provide the required functionality Typically not all the available software on the router will be needed for a specific configuration The rtrmgr traverses the template tree again to discover an order for starting the required processes that satisfies all their dependencies The rtrmgr starts the first process in the list of processes to be started If no error occurs the rtrmgr traverses the configuration tree to build the list of commands that need to be executed to configure the proce
4. and if it is not specified then it is expected that the process will transition on its own to the PROC_READY state smodinfo shutdown_method method argument The shutdown_method subcommand takes two or more additional parameters that are used to specify the mechanism to be used to gracefully shutdown the module The only methods current supported are xr1 which takes an XRL specification as an argument and program which takes an executable program as an argument If the process does not then transition to PROC_SHUTDOWN state the rtrmgr will then kill the process 2 2 2 The mandatory Command Smandatory is used to specify the list of nodes or variables that must be configured in the user config uration file or that must have a default value This command can appear multiple times anywhere in the template tree If it appears multiple times within the same template node then all listed nodes are manda tory However note that it cannot be used to specify a multi value node such as S interfaces interface vif address 2 2 3 The 3create Command create is used to create a new instance of an interior node in the configuration tree e The first parameter indicates the form of action to take to perform this action typically it is xr1 which indicates an XRL should be called To execute an external program instead the action should be program e If the action is xr1 then the second parameter specifies the XRL to call to create the new
5. it The syntax is sdeprecated String with reason If the XORP startup configuration contains a statement that uses a deprecated node in the template the rtrmgr prints an error with the string with the reason and exits If however a third party user program e g other than xorpsh sends to the rtrmgr configuration that contains a deprecated statement the rtrmgr returns an error to xorpsh and the error message will contain the string with the reason 2 2 15 The Zuser hidden Command The Suser hidden command can be used to hide a template tree node and the subtree below it from the user Such node or a subtree can be used by the rtrmgr itself for internal purpose only and is not visible to the user e g via xorpsh or when saving the configuration to a file The syntax is Suser hidden String with reason However if the XORP startup configuration contains a statement that uses an user hidden node the rtrmgr will accept the configuration Similarly if a third party user program e g other than xorpsh sends 14 to the rtrmgr configuration that contains an user hidden statement the rtrmgr would accept that statement This is an experimental feature may become permanent or may be disabled in the future 2 2 16 The read only Command The read only command can be used to specify a template tree node as read only The syntax is Sread only String with reason or Sread only Only a leaf node that contains a val
6. start_commit lt method gt e Smodinfo end commit lt method gt e modinfo statusmethod lt method gt e Smodinfo startup_method lt method gt e Smodinfo shutdown_method lt method gt are used to specify the mechanism to be call before any configuration change of a module the mecha nism to discover the status of a module and so on Template tree commands suchas Screate sactivate and set are used to specify the actions that need to be performed when the router configuration is created or modified This section provides a complete listing of all the template tree actions that the rtrmgr supports 2 3 1 Template Tree xr1 Action The xrl command action specifies the XRL to be executed The XRL and its arguments must be inside quotes and it may contains variables that will be substituted with the particular values at execution time For example if the template tree held the following bgp id sset xrl S bgp targetname bgp 0 2 set_bgp_id id ipv4 S Then when we set the value of bgp id first the rtrmgr will substitute bgp targetname with the particular value of that variable and with the value of bgp id After the substitution it will call XRL bgp 0 2 set_bgp_id with argument id ipv4 set to the value of bgp id We could use xr1 actions to get the value of a particular variable store the value inside the rtrmgr and then use that value by other actions For example if the template tree held t
7. to ensure that only the permitted combinations are allowed 2 2 12 The allow range Command The 3allow range command restricts the range of values an integer configuration item may take The syntax is Sallow range varName lowValue highValue help help string 13 where the first parameter varName gives the name of the variable to be restricted This is typically The JowValue and highVal parameters specify the lower and upper bound of the allowed range of values The help is a mandatory keyword and is followed by the help string The help string is used for command line completion purpose An example of use appears in the interface address prefix specification address ipv4 prefix length u32 address ipv4 prefix length S allow range 1 32 Shelp The prefix length Seta XEL Tosa sgets XEL 44 F If there is more than one allow range command restricting the value of a variable then the assigned value must belong to any of the specified ranges 2 2 13 The help Command The help command specifies the CLI configuration mode help string The syntax is help short long Help string where the first parameter short or long specifies whether this is the short version or the long version of the help and the second parameter is the help string itself 2 2 14 The sdeprecated Command The deprecated command can be used to deprecate a template tree node and the subtree below
8. XORP Router Manager Process rtrmgr Version 1 8 CT XORP Inc and individual contributors http www candelatech com xorp ct xorp users xorp org 1 Introduction June 1 2010 This document provides a high level technical overview of the Router Manager rtrmgr code structure intended to aid anyone needing to understand or modify the software It is not a user manual The XORP software base consists of a number of routing protocols BGP OSPF PIM SM etc a Routing Information Base RIB process a Forwarding Engine Abstraction FEA process and a forwarding path Other management monitoring or application processes may also supplement this set Figure 1 illustrates these processes and their principle communication channels Management Processes IPC router finder manager CLI SNMP BGP4 N PIM SM RIP IGMP MLD aa Multicast Routing IS IS FEA Unicast Routing Forwarding Engine RIB routing information base FEA forwarding engine abstraction 3 lick Eleme ra Figure 1 Overview of XORP processes For research purposes these processes may be started manually or from scripts so long as the depen dencies between then are satisfied But when using XORP in a more operational environment the network manager typically does not wish to see the software
9. a tree with three types of nodes e Structural nodes such as protocol and ospf that exist merely to provide scope e Named interior nodes such as area and interface where there can be multiple in stances of the node Symbol indicates that a name is required in the case of area the fragment above specifies that the name must be an IPv4 address e Leaf nodes such as flood_rate and hello interval These nodes are also typed and may op tionally specify a default value In the example above hello interval is of type u32 unsigned 32 bit integer and takes the default value of 30 Thus the template tree created from this template file would look like ROOT protocols ospf router id mospf flood_rate area stub interface disable hello interval dead interval The same node may occur multiple times in the template file This might happen because the node can take more than one type for example it might have an IPv4 or an IPv6 address or it might happen because the second definition adds information to the existing definition 4 In addition to specifying the configurable options the template file should also specify what the rtrmgr should do when an option is modified These commands annotating the template file begin with a 3 Thus the template file above might also contain the following a
10. alue of a leaf node in the configuration tree The value will return to its default value if a default value is specified e The first parameter indicates the form of action to take to perform this action typically it is xr1 which indicates an XRL should be called To execute an external program instead the action should be program e If the action is xr1 then the second parameter specifies the XRL to call to unset the value of config uration tree instance of this template tree node e If the action is program then the second parameter specifies the program to execute to unset the value of configuration tree instance of this template tree node 2 2 10 The sget Command get is called to get the value of a leaf node in the configuration tree Normally the rtrmgr will know the value if there is no external means to change the value but the get command provides a way for the rtrmgr to re sync if the value has changed e The first parameter indicates the form of action to take to perform this action typically it is xr1 which indicates an XRL should be called To execute an external program instead the action should be program 12 e If the action is xr1 then the second parameter specifies the XRL to call to get the value of configu ration tree instance of this template tree node e If the action is program then the second parameter specifies the program to execute to get the value of configuration tree instance of this template tr
11. ate files are intended to be written by software developers whereas configuration files are intended to be written by network managers Hence the syntax of configuration files is simpler and more intuitive but less powerful However both specify the same sort of tree structure and the nodes in the configuration tree must correspond to the nodes in the template tree An example fragment of a configuration file might be protocols ospf router id 1 2 3 4 mospf area 1 2 3 27 stub interface fxpl hello interval 10 interface fxp2 Note that unlike in the template tree semicolons are not needed in the configuration tree and that line breaks are significant The example fragment of a configuration file above will construct the following configuration tree from the template tree example given earlier ROOT protocols ospf router id 1 2 3 4 mospf true area 1 2 3 27 stub true interface fxp1 hello interval 10 dead inteval 90 interface fxp2 hello interval 30 dead interval 90 Note that configuration tree nodes have been created for dead interval and in the case of fxp1 for he llo interval even though this was not mentioned in the configuration file This is because the template tree contains a default value for this leaf node Also in case of configuring a boolean variable e g of type bool or toggle such as mospf typi
12. ble program as an argument smodinfo end_commit method argument The end_commit subcommand takes two or more additional parameters that are used to specify the mechanism to be called to complete any change to the configuration of the module The only methods currently supported are xr1 which takes an XRL specification as an argument and program which takes an executable program as an argument Both start_commit and end_commit are optional They provide a way to make batch changes to a module configuration as an atomic operation smodinfo status_method method argument The st atus_method subcommand takes two or more additional parameters that are used to specify the mechanism to be used to discover the status of the module The only methods current supported are xrl which takes an XRL specification as an argument and program which takes an executable program as an argument smodinfo startup_method method argument The startup_method subcommand takes two or more additional parameters that are used to spec ify the mechanism to be used to gracefully startup the module The only methods current supported are xrl which takes an XRL specification as an argument and program which takes an executable program as an argument Before the st artup_met hod subcommand is called it is expected that the process is in PROC_STARTUP state after the subcommand is called the process should transition to the PROC_READY state Note that this subcommand is optional
13. cess to certain events The rtrmgr exports the following XRLs that may be called by xorpsh register_client This XRL is used by a xorpsh instance to register with the rtrmgr In response the rtrmgr provides the name of a file containing a nonce the xorpsh must read this file and return the contents to the rtrmgr to authenticate the user authenticate_client Xorpsh uses this to complete the authentication process get_running_config Xorpsh uses this to request the current running configuration from the rtrmgr The response is text in the same syntax as the rtrmgr configuration file that provides the rtrmgr s view of the configuration enter_config_mode A xorpsh process must be in configuration mode to submit configuration changes to the rtrmgr This XRL requests that the rtrmgr allows the xorpsh to enter configuration mode Not all users have permission to enter configuration mode and it is also possible that a request may be refused because the configuration is locked Unfortunately the router manager is not simple as we would like 21 get_config_users Xorpsh uses this to request the list of users who are currently in configuration mode apply_config_change Xorpsh uses this to submit a request to change the running configuration of the router to the rtrmgr The change consists of a set of differences from the current running configuration lock_config Xorpsh uses this to request an exclusive lock on configuration chang
14. configura tion tree instance of this template tree node e If the action is program then the second parameter specifies the program to execute to create the new configuration tree instance of this template tree node Note that if a node has no create command then the set command if exists for that node is used instead see below 2 2 4 The Zactivate Command activate is used to activate a new instance of an interior node in the configuration tree It is typi cally paired with Screate the create command is executed before the relevant configuration of the node s children has been performed whereas activate is executed after the node s children have been configured A particular interior node might have either create activate or both e The first parameter indicates the form of action to take to perform this action typically it is xr1 which indicates an XRL should be called To execute an external program instead the action should be program e If the action is xr1 then the second parameter specifies the XRL to call to activate the new configu ration tree instance of this template tree node e If the action is program then the second parameter specifies the program to execute to activate the new configuration tree instance of this template tree node For example if the template tree held the following address ipv4 Screate xrl XRLI Sactivate xrl XRL2 netmask ipv4 Sset xrl XRL3 Then when an instanc
15. e new_config_user Rtrmgr uses this XRL to inform all xorpsh instances that are in config mode than another user has entered config mode config_change_done When a xorpsh instance submits a request to the rtrmgr to change the running config or to load a con fig from a file the rtrmgr may have to perform a large number or XRL calls to implement the config 22 change Due to the single threaded nature of XORP processes the rtrmgr cannot do this while re maining in the appl y_config_change XRL so it only performs local checks on the sanity of the request before returning success or failure the configuration will not have actually been changed at that point When the rtrmgr finishes making the change or when failure occurs part way through mak ing the change the rtrmgr will call config change_done on the xorpsh instance that requested the change to inform it of the success or failure config_changed When multiple xorpsh processes are connected to the rtrmgr and one of them submits a successful change to the configuration the differences in the configuration will then be communicated to the other xorpsh instances to keep their version of the configuration in sync with the rtrmgr s version 4 1 Operational Commands and xorpsh Up to this point we have been dealing with changes to the router configuration Indeed this is the role of the rtrmgr process However a router s command line interface is not only used to change or query the
16. e fxpl vif fxpl address 10 0 0 1 15 interface dcO vif dcO address 10 0 1 1 interface fxp0 vif fxp0 address 10 0 2 1 The ordering of the interface sections here is arbitrary in the order they were entered by the user In many cases this is what is desired but in some cases such as firewall rules this is not desired and the order command provides a way to enforce an ordering For example a simple firewall not the actual XORP firewall might use a template such as firewall interface txt rule u32 Sorder sorted numeric permit txt deny txt Thus some configured firewall rules might be firewall interface fxp0O rule 100 permit net 10 0 0 0 24 rule 300 deny all The ordering here is now dictated by rule number in accordance with the tt order command If a new rule 200 was subsequently inserted it would always be displayed and configured after rule 100 and before rule 300 The available parameters for the order command are e unsorted the default ordered in the order of entry 16 e sorted numeric sorted in increasing numeric interger order e sorted alphabetic sorted in increasing alphabetic order Note that if sorted numeric is applied toa t xt field the sort order for non numeric values is undefined but numeric values will be sorted correctly 2 3 Template Tree Command Actions Template tree commands such as e Smodinfo
17. e of address and netmask are created and configured the execution order of the XRLs will be XRL XRL3 XRL2 2 2 5 The Supdate Command Supdate is used to update an existing instance of a node in the configuration tree It is typically paired with Sactivate the activate command is executed after the node s children have been configured for very first time e g on startup whereas update is executed if some of the node s children have been modified e g via xorpsh e The first parameter indicates the form of action to take to perform this action typically it is xr1 which indicates an XRL should be called To execute an external program instead the action should be program e If the action is xr1 then the second parameter specifies the XRL to call to update the configuration tree instance of this template tree node e If the action is program then the second parameter specifies the program to execute to update the configuration tree instance of this template tree node Note that if the value of a node is modified only the closest update command up in the hierarchy is executed For example if the template tree held the following 10 address ipv4 Screate xrl XRLI Sactivate xrl XRL2 Supdate xrl XRL3 netmask ipv4 Supdate xrl XRI4 disable bool Sset broadcast ipv4 Sseti Then when the value of disable is modified only XRL4 will be called If the value of broadcast is modified then XRL3
18. ecute to delete the configuration tree instance of this template tree node 11 If a node that is deleted does not have a delete command then the delete commands of its children are called instead This rule is applied recursively for each child that does not have a delete command For example lets say A is a parent of B1 and B2 and B1 is a parent of C1 Also lets say that only B2 and Cl have delete methods If we delete A then both B2 s and Cl s delete methods are invoked If however B1 also has a sdelete method then deleting A will invoke only B1 and B2 s delete methods 2 2 8 The 3set Command set is called to set the value of a leaf node in the configuration tree e The first parameter indicates the form of action to take to perform this action typically it is xr1 which indicates an XRL should be called To execute an external program instead the action should be program e If the action is xr1 then the second parameter specifies the XRL to call to set the value of configura tion tree instance of this template tree node e If the action is program then the second parameter specifies the program to execute to set the value of configuration tree instance of this template tree node Note that when a new instance of a node in the configuration tree is created if that node has no create command then the set command if exists for that node is used instead 2 2 9 The Sunset Command Sunset is called to unset the v
19. ee node 2 2 11 The allow Command The allow command provides a way to restrict the value of certain nodes to specific values e The first parameter gives the name of the variable to be restricted e The second parameter is a possible allowed value for this variable e The third parameter must be the help keyword e The fourth parameter is the help string for this value If there is more than one possible values each of them should be specified by a separate tallow command For example a node might specify an address family which is intended to be one of inet or inet6 The type of the node is txt which would allow any value so the allow command might allow the rtrmgr to restrict the legal values without having to communicate with the process providing this functionality A more subtle use might be to allow certain nodes to exist only if a parent node was of a certain value For example family txt Sallow inet Shelp IPv4 address family Sallow inet6 Shelp IPv6 address family address ipv4 Sallow S family inet Shelp IPv4 address family broadcast ipv4 address ipv Sallow S family inet6 Shelp IPv6 address family In this case there are two different typed versions of the address node once for Pv4 and one for IPv6 Only one of them has a leaf node called broadcast The allow command permits the rtrmgr to do type checking
20. es Typically this is done just prior to submitting a set of changes unlock _config Unlocks the rtrmgr configuration that was locked by a previous call to Llock_config lock_node Xorpsh uses this to request a lock on configuration changes to a specific config tree node Usually this will be called because the user has made local changes to the config but not yet committed them and wishes to prevent another user making changes that conflict Locking is no substitute for human to human configuration but it can alert users to potential problems Note node locking is not implemented yet unlock_node Xorpsh uses this to request a lock on a config tree node be removed save_config Xorpsh uses this to request the configuration be saved to a file The actual save is performed by the rtrmgr rather than by xorpsh but the resulting file will be owned by the user running this instance of xorpsh and the file cannot overwrite files that this user would not otherwise be able to overwrite load_config Xorpsh uses this to request the rtrmgr reloads the router configuration from the named file The file must be readable by the user running this instance of xorpsh and the user must be in configuration mode when the request is made leave_config_mode Xorpsh uses this to inform rtrmgr that it is no longer in configuration mode Each xorpsh process exports the following XRLs that the rtrmgr can use to asynchronously communicate with the xorpsh instanc
21. he following interface Ssmodinfo start_commit xrl S interface targetname ifmgr 0 1 start_transaction gt tid u32 S interface TID Smodinfo end_commit xrl S interface targetname ifmgr 0 1 commit_transaction tid u32 S interface TID 17 TID Screate interface txt create xrl S interface targetname ifmgr 0 1 create_interface tid u32 S interface TID amp ifname txt Then whenever the interface configuration is changed the start_commit and end_commit XRLs will be call before and after performing any change to the configuration of the module The start_commit XRL will return the transaction ID tid of type u32 The rtrmgr will store that value internally in the S interface TID local variable note that this variable should be declared as a leaf node without type Then this value can be used by other actions such as the Screate and the end_commit XRL actions in the above example 2 3 2 Template Tree program Action The xrl command action specifies the external program to be executed The program and its arguments must be inside quotes and it may contains variables that will be substituted with the particular values at execution time For example if the template tree held the following foo set program bin echo n S gt gt tmp file txt Then when we set the value of foo first the rtrmgr will substitute with the value of foo After the substitution i
22. ined by an upper and lower inclusive boundary IPv4 addresses are specified in dotted decimal format delimited by two dots e g 1 2 3 4 5 6 7 8 If upper and lower boundaries are equal it is sufficient to specify only a single value e g 1 2 3 4 ipv6 An IPv6 address in the canonical colon separated human readable format ipv6net An IPv6 address and prefix in the conventional format E g fe80 1 64 ipv6range A range of IPv6 addresses defined by an upper and lower inclusive boundary IPv6 addresses are speci fied in colon separated format and are delimited by two dots e g fe80 1234 fe80 5678 If upper and lower boundaries are equal it is sufficient to specify only a single value e g fe80 1234 macaddr An MAC address in the conventional colon separated hex format E g 00 c0 4 68 8c 58 com32 Unsigned 32 bit integer representing a BGP community tag It can be specified either in a colon separated format using two 16 bit integers e g 65001 1 or as a single 32 bit unsigned integer It is likely that additional types will be added in the future as they are found to be needed 2 2 Template Tree Commands This section provides a complete listing of all the template tree commands that the rtrmgr supports 2 2 1 The modinfo Command The sub commands to the 3modinfo command are Smodinfo provides ModuleName The provides subcommand takes one additional parameter which gives the name of the module providing the functionali
23. mandatory annotation contains the list of nodes or variables that must be configured in the user configuration file or that must have a default value In the above example this applies to variables targetname and router id The protocols ospf targetname node carries an annotation to specify the existence of vari able name targetname that can be used to specify the XRL target name of an OSPF instance The specific value of t argetname can be configured elsewhere The protocols ospf router id node carries annotations to set the value of the router ID in the ospf process and to get the value back The set command is set xrl S ospf targetname ospf 0 1 set_router_id id u32 This specifies that to set this value the rtrmgr must call the specified XRL In this case it specifies a variable expansion of variables ospf targetname and All variables take the form The variable ospf targetname means the value of node protocols ospf targetname The variable means the value of the current node Hence if the targetname is set in the configuration tree to or had a default value in the template tree of ospf and the router ID node in the configuration tree had the value 1 2 3 4 then the XRL to call would be ospf ospf 0 1 set_router_id id u32 1 2 3 4 The set command only applies to leaf nodes that have values and only if the value is allowed to be changed For example n
24. nd line path to show_interfaces i x10 The pathname to a command must be relative to the root of the XORP tree The ordering in computing the root of the tree is a the shell environment XORP_ROOT if exists b the parent directory the xorpsh is run from only if it contains the etc templates and the xrl targets directories c the XORP_ROOT value as defined in config h currently this is the installation directory and defaults to usr local xorp The command module indicates that this operational command should only be available through the CLI when the router configuration has required that the named module has been started If the smodule command is missing then this operational command is always enabled The command he1lp is used to specify the CLI help for each CLI command or the optional parameters It must be on the same line as the command or the Sopt_parameter commands If the argument after the She 1p command is in quotes then it contains the help string itself Otherwise the argument is the name of the tag that contains the help string The command t ag is used to specify the help string associated with each tag For example statement Scommand path to show_vif i 3 Shelp HELP Stag HELP Show vif information is equvalent with Scommand path to show_vif i 3 Shelp Show vif information Note currently there is no security mechanism restricting access to operational mode commands beyond the re
25. ng the variable name itself e g mospf is equivalent to assigning it value of true e g mospf true 20 4 Command Line Interface xorpsh The rtrmgr process is the core of a XORP router it starts and stops processes and keeps track of the configuration To do its task it must run as root whereas most other XORP processes don t need privileged operation and so can be sandboxed This makes the rtrmgr process the single most critical point from a security point of view Thus we would like the rtrmgr to be as simple as possible and to isolate it from possibly hostile input as far as is reasonable For these reasons we do not build a command line interface directly into the rtrmgr but instead use an external process called xorpsh to interact with the user while limiting the rtrmgr s interaction with xorpsh to simple authentication mechanisms and exchanges of configuration tree data Thus the command line interface architecture looks like xorpsh processes running from unprivileged user accounts Constrained CLI lt gt xorpsh ee interaction with xorpsh e A rmgr users m process XRLs for lt gt xorpsh figuration RIB BGP OSPF PIM SM FEA The interface between the rtrmgr and a xorpsh instance consists of XRLs that the xorpsh may call to query or configure rtrmgr and a few XRLs that the rtrmgr may asynchronously call to alert the xorpsh pro
26. nnotated version of the template tree protocols ospf smodinfo provides ospf Smodinfo depends rib smodinfo path ospfd xorp ospfd smodinfo default_targetname ospf Smandatory targetname router id targetname Sset router id sset xrl S ospf targetname ospf 0 1 set_router_id id u32 S sget xrl S ospf targetname ospf 0 1 get_router_id gt id u32 area Screate xrl S ospf targetname ospf 0 1 add_or_configure_area area_id u32 S sdelete xrl S ospf targetname ospf 0 1 delete_area area_id u32 S area mospf Sset xrl S ospf targetname ospf 0 1 set_mospf enabled bool sdelete xrl ospf targetname ospf 0 1 set_mospf enabled bool S DEFAULT get xrl S ospf targetname ospf 0 1 get_mospf gt enabled bool The first four annotations apply to the protocols ospf node and specify the omodinfo command which provides information about the module providing this functionality In this case they specify the following e This functionality is provided by the module called ospf e This module depends on the module called rib e The program in osp d xorp ospfd should be run run to provide this module e XRL target name ospf should be used by default when validating an XRL specification that uses a variable inside the ospf module e g ospf targetname to specify the XRL target The
27. ode protocols ospf router id has set command because its value can be changed On contrary node protocols ospf area does not have set command because it defines a node that can have multiple instances Each instance has a value when the instance is created but that value cannot be changed later Internal nodes would typically use the create command to create a new instance of the node as shown with the protocols ospf area node In the example above the screate command involves two variable expansions area and stub The form area means this area and so in this case it is directly equivalent to meaning this node The variable stub means the value of the leaf node called stub that is a child node of this node Default template value of a variable can be specified by the keyword DEFAULT For example DEFAULT or DEFAULT would refer to the default template value of this node while foo bar DEFAULT would refer to the default template value of node foo bar Thus the template tree specifies the following information e The nodes of the tree specify all the configuration options possible on the router e Some of the nodes are annotated with information to indicate which software to run to provide the functionality rooted at that node to indicate which other modules this software depends on being running and to provide additional information about this module e
28. router configuration but also to learn about the dynamic state of the router such as link utilization or routes learned by a routing protocol To keep it as simple and robust as possible the rtrmgr is not involved in these operational mode commands Instead these commands are executed directly by a xorpsh process itself To avoid the xorpsh implementation needing in built knowledge of router commands the information about operational mode commands is loaded from another set of template files A simple example might be show interfaces interfaces interface Scommand path to show_interfaces i 3 Shelp HELP Smodule fea Sopt_parameter brief Shelp BRIEF Sopt_parameter detail thelp DETAIL Sopt_parameter extensive Shelp EXTENSIVE HELP Show network interface information BRIEF Show brief network interface information tag DETAIL Show detailed network interface information tag EXTENSIVE Show extensive network interface information o ct ct Y o Q Q A oP show vif interfaces interface vif x Scommand path to show_vif i 3 Shelp Show vif information Smodule fea Sopt_parameter brief Shelp Show brief vif information Sopt_parameter detail Shelp DETAIL Sopt_parameter extensive Shelp EXTENSIVE Stag DETAIL Show detailed vif information Stag EXTENSIVE Show extensive vif information This template file defines two operational mode commands
29. ss just started A command can be either an XRL or an external program These commands are then called one after another with the successful completion of one command triggering the calling of the next The commands are ordered according to the command semantics e g see below the description of commands create activate etc If the semantics of the commands do not specify the ordering then the commands follow the order they are defined in the rtrmgr template files Some processes may require calling a transaction start command before configuration and a transaction complete command after configuration the rtrmgr can do this if required 8 If no error occurred during configuration the next process is started and configured and so forth until all the required processes are started and configured 9 At this point the router is up and running The rtrmgr will now allow connections from the xorpsh process to allow interactive operation 2 Template Files The router manager reads a directory of template files to discover the configuration options that the router supports A fragment of such a configuration file might look like protocols ospf router id ipv4 mospf toggle false flood_rate 132 area ipv4 stub toggle false interface txt disable toggle false hello interval u32 30 dead interval u32 95 This defines a subset of the configuration options for OSPF The configuration options form
30. strictions imposed by Unix file permissions This is not intended to be the long term situation A Modification History e December 11 2002 Initial version 0 1 completed e March 10 2003 Updated to match XORP release 0 2 No significant changes Only text plain is currently supported 24 June 9 2003 Updated to match XORP release 0 3 No significant changes August 28 2003 Updated to match XORP release 0 4 Added information about computing the root of the XORP tree November 6 2003 Updated to match XORP release 0 5 No changes July 8 2004 Updated to match XORP release 1 0 Added information about new template keywords Miscellaneous cleanup January 27 2005 Removed MFEA MRIB related text because the MFEA does not deal with the MRIB information anymore April 13 2005 Updated to match XORP release 1 1 Added information about new template key words Miscellaneous cleanup March 8 2006 Updated to match XORP release 1 2 Miscellaneous changes August 2 2006 Updated to match XORP release 1 3 Miscellaneous cleanup March 20 2007 Updated to match XORP release 1 4 No changes July 22 2008 Updated to match XORP release 1 5 No changes 25
31. structure but rather would like to interact with the router as a whole Minimally this consists of a configuration file for router startup and a command line interface to interact with the router during operation The rtrmgr process provides this unified view of the router The rtrmgr is normally the only process explicitly started at router startup The rtrmgr process includes a built in XRL finder so no external finder process is required The following sequence of actions then occurs 1 The rtrmgr reads all the template files in the router s template directory Typically there is one tem plate file per XORP process that might be needed A template file describes the functionality that is provided by the corresponding process in terms of all of the configuration parameters that may be set It also describes the dependencies that need to be satisfied before the process can be started After reading the template files the rtrmgr knows all the configuration parameters currently supportable on this router and it stores this information in its template tree After all template files are read the template tree is checked for errors e g invalid variable names etc The rtrmgr will exit if there is an error The rtrmgr next reads the contents of the XRL directory to discover all the XRLs that are supported by the processes on this router These XRLs are then checked against the XRLs in the template tree As it is normal for the XRLs in the
32. t will call program bin echo with argument n and the value of foo The result of this command will be appended to file tmp file txt We could use program actions to store the stdout and stderr output of a command inside the rtrmgr and then use those values by other actions For example if the template tree held the following rtrmgr CONFIG Screate CONFIG STDERR Screate load Screate 18 Sset program bin cat gt stdout S rtrmgr CONFIG amp stderr S rt rmgr CONFIG_STDERR save Screate sset program bin echo n S rtrmgr CONFIG gt S Then whenever we change the value of variable load the external program bin cat will be exe cuted with the value of that variable as its argument The rtrmgr will store the stdout and stderr output of that program internally inside local variables rt rmgr CONFIG and rtrmgr CONFIG_STDERR respectively note that those variables should be declared as leaf nodes either with or without type Then those values can be used by other actions such as the Sset action for the save node in the above example 19 3 The Configuration File Whereas the template files inform the rtrmgr as the possible configuration of the router the configuration file provides the specific startup configuration to be used by this specific router The syntax is similar to but not the same as that of template files the differences are intentional templ
33. ty rooted at this node smodinfo depends list of modules The depends subcommand takes at least one additional parameter giving a list of the other modules that must be running and configured before this module may be started smodinfo path ProgramPath The path subcommand takes one additional parameter giving the pathname of the software to be run to provide this functionality The pathname may be absolute or relative to the root of the XORP tree The ordering in computing the root of the tree is a the shell environment XORP_ROOT if exists b the parent directory the rtrmgr is run from only if it contains the etc templates and the xrl targets directories c the XORP_ROOT value as defined in config h currently this is the installation directory and defaults to usr local xorp smodinfo default_targetname TargetName The default_targetname subcommand takes one additional parameter giving the value of the XRL target name that should be used by default when validating an XRL specification e g if the specification uses a variable inside that module to specify the XRL target name smodinfo start commit method argument The start_commit subcommand takes two or more additional parameters that are used to specify the mechanism to be call before performing any change to the configuration of the module The only methods currently supported are xr1 which takes an XRL specification as an argument and program which takes an executa
34. ue can be marked as read only If a node is marked as a read only then its value cannot be changed from the default template value For example a read only node could be part of the startup configuration but if its value is different from the default template value the rtrmgr will reject the configuration Note that by definition a read only node is also permanent see Section 2 2 17 it cannot be deleted directly but it will be removed if its parent is deleted 2 2 17 The spermanent Command The permanent command can be used to specify a template tree node as a permanent node that cannot be deleted The syntax is Spermanent String with reason or Spermanent If a node is marked as permanent the node itself cannot be deleted directly However deleting the parent node will delete the permanent node as well Also adding or deleting children of a permanent node is allowed If a permanent node never should be deleted then all its ancestors should be marked as permanent 2 2 18 The order Command The order command provides a way to specify the ordering of multiple nodes of the same type in the configuration For example if no ordering is specified in the template file such as with interfaces interfaces interface txt Then this template would allow the configuration for each interface to be displayed and configured in the order they were entered For example the configuration might be interfaces interfac
35. will be called 2 2 6 The 31ist Command list is called to obtain a list of all the configuration tree instances of a particular template tree node For example a particular template tree node might represent the interfaces on a router The configuration tree would then contain an instance of this node for each interface currently configured The list command on this node would then return the list of interfaces e The first parameter indicates the form of action to take to perform this action typically it is xr1 which indicates an XRL should be called To execute an external program instead the action should be program e If the action is xr1 then the second parameter specifies the XRL to call to return the list e If the action is program then the second parameter specifies the program to execute to return the list 2 2 7 The delete Command delete is called to delete a configuration tree node and all its children A node that has a create or activate command should also have a delete command e The first parameter indicates the form of action to take to perform this action typically it is xr1 which indicates an XRL should be called To execute an external program instead the action should be program e If the action is xr1 then the second parameter specifies the XRL to call to delete the configuration tree instance of this template tree node e If the action is program then the second parameter specifies the program to ex
Download Pdf Manuals
Related Search