Understanding Static Routes for CLNS

The Connectionless Network Service (CLNS) is an ISO Layer 3 protocol that uses network service access point (NSAP) reachability information instead of IPv4 or IPv6 prefixes.

You can configure static routes to exchange CLNS routes within a CLNS island. A CLNS island is typically an IS-IS level 1 area that is part of a single IGP routing domain. An island can contain more than one area. CLNS islands can be connected by VPNs.

Example: Configuring Static Routes for CLNS

This example shows how to configure static routes for CLNS.

• Requirements
• Overview
• Configuration
• Verification

Requirements

Before you begin, configure the network interfaces. See the Junos OS Interfaces Configuration Guide for Security Devices.

Overview

In this example, you configure static routes for CLNS. In the absence of an interior gateway protocol (IGP) on a certain link, a routing device might need to be configured with static routes for CLNS prefixes to be reachable by way of that link. This might be useful, for example, at an autonomous system (AS) boundary.

• Specify the iso.0 routing table option to configure a primary instance CLNS static route.
• Specify the instance-name.iso.0 routing table option to configure a CLNS static route for a particular routing instance.
• Specify the route nsap-prefix statement to configure the destination for the CLNS static route.
• Specify the next-hop (interface-name | iso-net) statement to configure the next hop, specified as an ISO network entity title (NET) or interface name.
• Include the qualified-next-hop (interface-name | iso-net) statement to configure a secondary backup next hop, specified as an ISO network entity title or interface name.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

1. Configure the routes.
   [edit routing-options rib iso.0 static]user@host# set iso-route 47.0005.80ff.f800.0000.ffff.ffff/152 next-hop 47.0005.80ff.f800.0000.0108.0001.1921.6800.4212user@host# set iso-route 47.0005.80ff.f800.0000.0108.0001.1921.6800.4212/152 next-hop t1-0/2/2.0user@host# set iso-route 47.0005.80ff.f800.0000.eee0/152 qualified-next-hop 47.0005.80ff.f800.0000.0108.0001.1921.6800.4002 preference 20user@host# set iso-route 47.0005.80ff.f800.0000.eee0/152 qualified-next-hop 47.0005.80ff.f800.0000.0108.0001.1921.6800.4002 metric 10
2. If you are done configuring the device, commit the configuration.
   [edit]user@host# commit

Results

Confirm your configuration by issuing the show routing-options command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly.

Checking the Routing Table

Purpose

Make sure that the expected routes appear in the routing table.

Action

iso.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

47.0005.80ff.f800.0000.0108.0001.1921.6800.4212/152               
                   *[Static/5] 00:00:25
                    > via t1-0/2/2.0
47.0005.80ff.f800.0000.eee0/84                
                   *[Static/20] 00:04:01, metric 10, metric2 10
                    > to #75 0.12.0.34.0.56 via fe-0/0/1.0
47.0005.80ff.f800.0000.ffff.ffff/104               
                   *[Static/5] 00:04:01, metric2 0
                    > via t1-0/2/2.0

Meaning

The static routes appear in the routing table.