Route Configuration

An SDK application has various options for adding routes using the CLI and SDK service daemon (libssd) library.

When you are using the MultiServices PIC, the routes you create direct traffic to a PIC interface and are known as service routes. You configure an IP address on the ms- interface, which translates into a route for that address, pointing to the PIC.

Basics about Routes

Whether you use libssd or not, you add routes to a routing instance, which is configurable and also exists by default. The routing instance is a collection of routing tables, interfaces, and routing protocol parameters. The set of interfaces belongs to the routing tables, and the routing protocol parameters control the information in the routing tables.

There are eight types of routing instance:

Each routing instance has a unique name and a corresponding IP Unicast table. For example, if a routing instance is configured with the name my-instance, the default Internet Protocol version 4 (IPv4) Unicast routing table is named inet.0, the name of the instance is my-instance.inet.0, and all routes for my-instance are installed into my-instance.inet.0.

The routing table is used by the routing protocol daemon (rpd) to maintain its database of routing information. In this table, rpd stores statically configured routes, directly connected interfaces (also called direct routes or interface routes), and all routing information learned from all routing protocols. rpd uses this collected routing information to select the active route to each destination, which is the route that actually is used to forward packets to that destination.

An administrator can configure global routing options and protocols for the default instance by including statements at the [edit protocols] and [edit routing-options] hierarchy levels.

To configure a routing instance type, the administrator can include the instance-type statement as follows:

routing-instances {
  <routing-instance-name> {
    interface <interface-name>;
    instance-type (forwarding | l2vpn | no-forwarding | virtual-router | 
                  virtual-switch | vpls | vrf);
   }
}

There is currently no way to create a routing instance programmatically through the SDK.

Options for Configuring Routes

If your application does not need to work directly with routes, you can simply let rpd handle routing using the default routing instance. Otherwise, you can work directly with routes in the following ways:

Configuring an Instance and Specifying Routes

When you configure a routing instance, the cnf.dd DDL file defines what is allowed to be configured, but the actual configuration is performed by an administrator on the router.

For example, the following cnf.dd DDL describes what can be configured for the jnx-routserviced sample application, which uses the default routing instance:

 object route-info {
            help "Route information";
            flag setof list;

            attribute destination {
                flag identifier nokeyword;
                help "IPv4 address of the destination";
                type ipv4addr;
                cname "rt_data_dest";
            }
            attribute prefix-len {
                help "Prefix length";
                type ranged int 0 .. 32;
                cname "rt_data_prefixlen";
            }
            attribute next-hop {
                help "Next hop for the destination";
                type ipv4addr;
                cname "rt_data_nhop";
            }
            attribute interface {
                help "Name of the logical interface";
                type interface-name;
                cname "rt_data_ifname";
            }

The following example shows what an administrator would specify as input to the CLI to add a route 11.1.2.2/32, with the next hop 11.0.1.2, and the interface as so-7/2/1.0.

route-info 11.1.2.2 {
      prefix-len 32;
      next-hop 11.0.1.2;
      interface so-7/2/1.0;
  }

The application can then add the route when the configuration is committed from the CLI.

The jnx-gateway sample application configures routing instances of type VRF for the user, control, and data components. The following DDL from its cnf.ddl file shows what configurations it specifies as permitted:

object user {
...
 attribute egress-vrf {
        type string;
        flag mandatory;
        help "Egress routing instance name";
        INSTANCE_NAME_VALIDATE; 
        cname "jnx_user_egress_vrf";
  }

...

object control {
...
      object policy {
      ...                                  
            object instance-policy {
              help "Per instance address allocation policy";
              flag setof list remove-empty; 
                   attribute instance {
                       flag identifier nokeyword;
                       type ranged string 1 .. 64;
                       INSTANCE_NAME_VALIDATE;
                       help "Routing instance name";
                       cname "jnx_ctrl_vrf";
               }

...

object data {
...
   object policy {
   ...
       object ingress-tunnel {
        ...
          attribute routing-instance {
                flag mandatory;
                type string;
                INSTANCE_NAME_VALIDATE;
                help "Routing instance name";
                cname "jnx_data_ingress_vrf";

       object egress-tunnel {
       ...
           attribute routing-instance {                                                      
                flag mandatory;
                type string;
                INSTANCE_NAME_VALIDATE;
                help "Routing instance name";
                cname "jnx_data_egress_vrf";

The following shows the values the administrator set to configure two of the actual routes:

[edit]
root@test# show routing-instances
vrf-1 {
    instance-type vrf;
    interface fe-1/2/0.0;
    interface ms-0/1/0.0;
    interface ms-0/1/0.1;
    route-distinguisher 1:1;
    vrf-import dummy;
    vrf-export dummy;
    routing-options {
    static {
        route 100.100.100.1/32 next-hop ms-0/1/0.1;
    }
}

}
vrf-2 {
    instance-type vrf;
    interface fe-1/2/1.0;
    interface ms-0/1/0.2;
    route-distinguisher 1:2;
    vrf-import dummy;
    vrf-export dummy;
    static {
        route 200.200.200.1/32 next-hop ms-0/1/0.2;
    }
}

Configuring Service Routes

When you configure a next hop VRF-to-VRF service set for the MultiServices PIC, static VRF routes must be explicitly configured. However, for service sets in which a service is attached to an interface, the router automatically adds any routes necessary to route packets from that interface to the MultiServices PIC.

For details about configuring routes for service sets and for sample code, see Service Set Configuration and Service Set Configuration in the Transit Application.

Using libssd

The CLI infrastructure provided by rpd gives you the ability to add routes; however, to intelligently manage routes in your application, you can use the libssd library. Using libssd allows you to programmatically control route addition, deletion, and modification. You can find more information on using libssd to manipulate routes in the topic Route Manager Application.

To use libssd, you first create a configuration in the CLI, just as you did for the non-programmatic usage. You then call functions to communicate with the SDK service daemon, which allow you to add, delete, and manage routes programmatically.

libssd is especially useful in scenarios where your application needs to do any of the following:

In addition, it is faster to add routes using libssd than using other programmatic methods, such as JUNOScript connections or op scripts, because these other methods involve a commit as well as locking and unlocking a configuration database.

For SDK applications written for the MultiServices PIC, two additional advantages of using libssd are the ability to specify packet distribution using flow affinity and the ability to pass opaque data to a next hop. These are discussed in IP Socket-Based Inter-Process Communication.

Service Set Configuration


2007-2009 Juniper Networks, Inc. All rights reserved. The information contained herein is confidential information of Juniper Networks, Inc., and may not be used, disclosed, distributed, modified, or copied without the prior written consent of Juniper Networks, Inc. in an express license. This information is subject to change by Juniper Networks, Inc. Juniper Networks, the Juniper Networks logo, and JUNOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Generated on Sun May 30 20:26:47 2010 for Juniper Networks Partner Solution Development Platform JUNOS SDK 10.2R1 by Doxygen 1.4.5