Kernel Interface

Although the kernel interface is not technically a routing protocol, it has many characteristics of one, and Advanced Routing Suite handles it similarly. The routes Advanced Routing Suite chooses to install in the kernel forwarding table are those that will actually be used by the kernel to forward packets.

The add, delete, and change operations that Advanced Routing Suite must use to update the typical kernel forwarding table take a non-trivial amount of time. The time used does not present a problem for older routing protocols (such as RIP), which are not particularly time critical and do not easily handle large numbers of routes anyway. The newer routing protocols (such as OSPF and BGP) have stricter timing requirements and are often used to process many more routes. The speed of the kernel interface becomes critical when these protocols are used.

To prevent Advanced Routing Suite from locking up for significant periods of time while installing large numbers of routes (up to a minute or more has been observed on real networks), the processing of these routes is done in batches. The size of these batches can be controlled by the tuning parameters shown below, but normally the default parameters will provide the proper functionality.

During normal shutdown processing, Advanced Routing Suite deletes all the routes it has installed in the kernel forwarding table, except for those static routes marked with flag-retain. (See Chapter 8 (Static Routes) for more information.) Optionally, Advanced Routing Suite can leave all routes in the kernel forwarding table by not deleting any routes using no-flush-at-exit. This option is useful on systems with large numbers of routes because it eliminates the need to re-install the routes when Advanced Routing Suite restarts, which can greatly reduce the time it takes to recover from a restart.

kernel background limit

Name

kernel background limit - specifies the type of routes that will be processed during a flash update

Syntax

kernel background limit number

no kernel background limit number?

Mode

Global Configuration

Parameters

number - specifies a number of routes that can be processed during one batch. The valid value range is 0 to 4,294,267,295, inclusive.

Description

Because only interface routes are normally installed during a flash update, the remaining routes are processed in batches in the background, that is, when no routing protocol traffic is being received. The kernel background limit command specifies how these batches are processed.

The negative of this command, no kernel background limit, reverts back to the default of maximum of 120 routes of lower priority. Note: Specifying a value for number in the no form has no effect on the configuration. Thus, it is displayed above as optional.

Default

if kernel background is not specified, it is the same as if the user had specified the following:

(config)# kernel background limit 120

Command History

NGC 2.2 - This command was introduced.

Examples

In the following example, the number of background route updates is limited to 40 routes.

(config)# kernel background limit 40

kernel background priority

Name

kernel background priority - specifies the priority of the processing of batches of operating system updates in relationship to the flash update processing

Syntax

kernel background priority [lower | higher | flash]

no kernel background priority [lower | higher | flash]?

Mode

Global Configuration

Parameters

lower - flash updates are processed first

higher - operating system updates are processed first

flash - operating system updates are processed that the same priority as flash updates

Description

Because only interface routes are normally installed during a flash update, the remaining routes are processed in batches in the background, when no routing protocol traffic is being received. The kernel background priority command (along with the kernel background limit command) specifies how these batches are processed.

The kernel background priority command specifies the priority of the processing of batches of operating system updates in relationship to the flash update processing. The negative form of this command, no kernel background priority, removes the configured priority value, and returns this to its default value of lower. Note: Specifying a priority value in the no form of this command has no effect on the configuration. Thus, it is displayed above as optional.

Default

If kernel background priority is not specified, it is the same as if the user had specified the following:

(config)# kernel background priority lower

Command History

NGC 2.2 - This command was introduced.

Examples

The following example sets the background priority to flash, thereby giving operational system updates the same priority as flash updates.

(config)# kernel background priority flash

kernel flash limit

Name

kernel flash limit - specifies the number of routes processed during a flash update

Syntax

kernel flash limit [ number | none ]

no kernel flash limit [ number | none ]?

Mode

Global Configuration

Parameters

number | none - specifies the maximum number of routes that can be processed during a flash update or specify that an unlimited number are processed. The valid value range for number is from 0 to 4,294,967,294, inclusive.

Description

A flash update results from protocol activity. The kernel flash limit command controls the number of routes installed during a flash update, suspending the current protocol module until the flash completes. Typically, only up to twenty interface routes are normally installed during a flash update. The remaining routes are processed in batches in the background, when no routing protocol traffic is being processed.

The negative of this command, no kernel flash, reverts back to the default of maximum of 20 routes of type interface. Note: Specifying a limit value in the no form has no effect on the configuration. Thus, it is displayed above as optional.

Default

If kernel flash limit is not specified, it is the same as if the user had specified the following
(config)# kernel flash limit 20

Command History

NGC 2.2 - This command was introduced.

Examples

In the following example, the router is configured to flash up to 40 routes at a time.

(config)# kernel flash limit 40

kernel flash type

Name

kernel flash type - specifies the type of routes that will be processed during a flash update

Syntax

kernel flash type [ interface | interior | all ]

no kernel flash type [ interface | interior | all ]?

Mode

Global Configuration

Parameters

interface - specifies routes defined by an interface

interior - specifies routes within the domain

all - specifies all routes

Description

When routes change as a result of operating system or protocol module activity, the process of notifying the Advanced Routing Suite protocol module is known as a "flash update." The kernel flash type command specifies the type of routes that will be processed during a flash update. The operating system’s forwarding table interface is the first to be notified. The flash process is concerned with the following three types of routes:

• interface routes - routes defined by an interface
• interior routes - routes within the domain
• all routes - routes defined within the domain and routes defined by an interface

The negative form of this command, no kernel flash type, resets the flash type to interface. Note: Specifying a type value in the no form of this command has no effect on the configuration. Thus, it is displayed above as optional.

Default

If kernel flash type is not specified, it is the same as if the user had specified the following:

(config)# kernel flash type interface

Command History

NGC 2.2 - This command was introduced.

Examples

The following example specifies to process all routes during a flash update.

(config)# kernel flash type all

kernel no-change

Name

kernel no-change - determines whether change operations will be performed

Syntax

kernel no-change

no kernel no-change

Mode

Global Configuration

Parameters

none

Description

On systems supporting the routing socket, the kernel no-change command determines whether change operations will be performed. If the command is configured, then change operations will not be performed, only deletes and adds will. The negative of this command, no kernel no-change, reverts back to the default of change operations being performed.

Default

By default, kernel no-change is disabled.

Command History

NGC 2.2 - This command was introduced.

Examples

The following example turns kernel no-change on.

(config)# kernel no-change

kernel no-flush-at-exit

Name

kernel no-flush-at-exit - determines whether deletions occur during shutdown

Syntax

kernel no-flush-at-exit

no kernel no-flush-at-exit

Mode

Global Configuration

Parameters

none

Description

During Advanced Routing Suite shutdown or restart, you can keep the routes in the operating system’s forwarding table. This lets the router continue forwarding packets while Advanced Routing Suite is restarted. After a restart, the protocol modules have a short time (currently three minutes) to determine their routes. After this, all residual routes that are not re-established by the protocol modules are flushed.

These are the conditions under which Advanced Routing Suite does not flush a route:

• The route is an interface route.
• The route is a static route configured in a static retain command.
• The kernel no-flush-at-exit command is configured.
• The route’s static bit is set.

The kernel no-flush-at-exit command is useful for systems with thousands of routes. On startup, Advanced Routing Suite notices which routes are in the operating system’s forwarding table and does not add them back.

The negative of this command, no kernel no-flush-at-exit, reverts to the default of disabled.

Default

By default, kernel no-flush-at-exit is disabled.

Command History

NGC 2.2 - This command was introduced.

Examples

This example turns kernel no-flush-at-exit on.

(config)# kernel no-flush-at-exit

kernel no-install

Name

kernel no-install - specifies to no install routes in the kernel Forwarding Information Base (FIB)

Syntax

kernel no-install

no kernel no-install

Mode

Global Configuration

Parameters

none

Description

The kernel no-install command specifies to not install routes in the kernel FIB. Normally, the route with the lowest preference is installed in the kernel forwarding table and is the route exported to other protocols. When this command is configured, the associated static route will not be installed in the forwarding table when it is active, but it will still be eligible to be exported to other protocols.

The negative of this command, no kernel no-install, reverts back to the default of disabled.

Default

By default, kernel no-install is disabled.

Command History

NGC 2.2 - This command was introduced.

Examples

The following example turns kernel no-install on.

(config)# kernel no-install

kernel remnant-holdtime

Name

kernel remnant-holdtime - sets the holdtime for remnant routes

Syntax

kernel remnant-holdtime time-seconds

no kernel remnant-holdtime time-seconds?

Mode

Global Configuration

Parameters

time-seconds - an integer between 0 and 900, inclusive

Description

When Advanced Routing Suite starts up, it reads the kernel forwarding table and installs corresponding routes into Advanced Routing Suite’s routing table. These routes, with the exclusion of interface routes and routes configured via the UNIX route command, are called "remnants." Remnant routes are timed out after the specified interval, or as soon as a more attractive route is learned. This method allows forwarding to occur while the routing protocols start learning routes.

The negative of this command, no kernel remnant-holdtime, reverts back to the default of 180 seconds. Note: Specifying a value for time-seconds in the no form has no effect on the configuration. Thus, it is displayed above as optional.

Default

If kernel-remnant holdtime is not specified, it is the same as if the user had specified the following:

(config)# kernel remnant-holdtime 180

Command History

NGC 2.2 - This command was introduced.

Examples

The following example changes the remnant-holdtime to 90 seconds.

(config)# kernel remnant-holdtime 90

kernel routes

Name

kernel routes - limits the maximum number of routes Advanced Routing Suite will install in the kernel

Syntax

kernel routes limit

no kernel routes limit?

Mode

Global Configuration

Parameters

limit - an integer in the range of 0 to 4,294,967,295, inclusive, on 32-bit systems and 0 to 264-1, inclusive, on 64-bit systems

Description

On some systems, kernel memory is at a premium. With the kernel routes command, a limit can be placed on the maximum number of routes Advanced Routing Suite will install in the kernel. This discussion is concerned with three types of routes:

• interface routes - routes defined by an interface configuration (includes UNIX 'ifconfig' and 'route' generated routes)
• interior routes - routes within the domain
• exterior routes - routes exterior to the domain

Normally, Advanced Routing Suite adds, changes, or deletes routes in interface/interior/exterior order. That is, Advanced Routing Suite queues interface routes first, followed by interior routes, followed by exterior routes, and then processes the queue from the beginning. When the route limit is reached, Advanced Routing Suite must ensure that interface/interior/exterior route preferences are followed. This is accomplished by first deleting kernel-based routes and then turning queued changes into adds. Finally, the list of active routes in the RIB is processed in interface/internal/external order, until the route limit is reached.

The negative of this command, no kernel routes, reverts back to the default of 232-1 (4,294,967,295) routes for 32-bit systems and 264-1 routes for 64-bit systems. Note: Specifying a value for num in the no form has no effect on the configuration. Thus, it is displayed above as optional.

Default

For 32-bit systems, if kernel routes is not specified, it is the same as if the user had specified the following:

(config)# kernel routes 4294967295

For 64-bit systems, if kernel routes is not specified, it is the same as if the user had specified the following:

(config)# kernel routes 18446744073709551616

Command History

NGC 2.2 - This command was introduced.

Examples

The following example limits the number of routes to 500.

(config)# kernel routes 500

kernel trace file

Name

kernel trace file - specifies file options when tracing in the kernel interface

Syntax

kernel trace file file_name [no-timestamp || overwrite]?

no kernel trace file file_name [ no-timestamp || overwrite]?

Mode

Global Configuration

Parameters

file_name - specifies the name of the file to receive the tracing information. Note that the file name is not specified in quotes.

no-timestamp - specifies that a timestamp should not be prepended to all trace lines

overwrite - specifies to begin tracing by appending or truncating an existing file

Description

The trace file command is associated with each protocol, so that information pertaining to a single protocol can be written to its own file. The kernel trace file command specifies a file for tracing of all Kernel events. The negative form of this command disables this tracing. The specific events that are traced are controlled The no-timestamp option disables the pre-pending of a timestamp to all lines written to the trace file. The default is to prepend a timestamp to all lines written to a trace file.

The overwrite option specifies whether to start tracing by truncating or appending to an existing file.

Note: These options are not cumulative across multiple commands. Consider the following example:

(config)# kernel trace file /var/log/kernel.log
no-timestamp

(config)# kernel trace file /var/log/kernel.log
max-files 10

The option given in the second command completely replaces that given in the first. In order to specify both no-timestamp and max-files 10, they must be entered on the same line as follows.

(config)# kernel trace file /var/log/kernel.log
max-files 10 no-timestamp

Default

Kernel tracing is turned off by default.

Command History

NGC 2.2 - This command was introduced.

Examples

In the following example, kernel tracing is written to the file "/var/tmp/kernel.log". No timestamp will display at the beginning of the trace lines.

(config)# kernel trace file /var/tmp/kernel.log no-timestamp

kernel trace flag

Name

kernel trace flag - specifies Kernel-specific tracing options as well as options that are common across all protocols

Syntax

kernel trace flag ( [ route | normal | state | policy |
task | timer | all ] ) | ( [ symbol | remnants |
interface-list | request | info ] ) |
( [ packets | redirect | other | routes | interface ]
[ send | receive | send-receive ]? [detail?] )

no kernel trace flag ( [ route | normal | state | policy |
task | timer | all ] ) | ( [ symbol | remnants |
interface-list | request | info ] ) |
( [ packets | redirect | other | routes | interface ]
[ send | receive | send-receive ]? [detail?] )

Mode

Global Configuration

Parameters

Flags common to all protocols:

[ route | normal | state | policy | task | timer | all ] - These tracing flags are common to all protocols. They cannot be associated with a send, receive, or send-receive action item. Similarly, you cannot specify to show detailed information when tracing these flags. These flags are defined as follows:

• route - trace routing table changes for routes installed by this protocol or peer
• normal - trace normal protocol occurrences. Note: Abnormal protocol occurrences are always traced.
• state - trace state machine transition in the protocol
• policy - trace the application of protocol and user-specified policy to routes being imported or exported
• task - trace system interface and processing associated with this protocol
• timer - trace timer usage by this protocol
• all - turns on all trace flags

Kernel-specific flags that do not allow send, receive, send-receive, or detail actions:

[ symbol | remnants | interface-list | request | info ] - These Kernel-specific flags cannot be associated with the send, receive, or send-receive action items. These flags are defined as follows:

• symbol - specifies to trace symbols, which are read from the kernel. The only useful way to specify this level of tracing is via the Advanced Routing Suite -t option, because the symbols are read from the kernel before parsing the configuration file.
• remnants - specifies to trace remnants, or routes read from the kernel when Advanced Routing Suite starts
• interface-list - specifies to trace the interface list. interface-list is useful when specified with the Advanced Routing Suite -t option because the first interface list scan is performed before any configuration information is processed.
• request - specifies to trace requests that specify to add, delete, or change routes in the kernel forwarding table
• info - specifies to trace info messages, which are messages received from the routing socket, such as TCP lossage, routing lookup failure, and route resolution requests. Advanced Routing Suite does not currently process these messages, but logs the information if requested.

Kernel-specific flags that allow associated actions:

[ packets | redirect | other | routes | interface ] - These Kernel-specific flags can be associated with the send, receive, or send-receive action items. These flags are defined as follows:

• packets - specifies to trace all kernel packet types
• redirect - specifies to trace redirect messages, which are received from the kernel
• other - specifies to trace other messages that are received from the kernel, including those mentioned in the info type above. This option is currently not being used and is reserved for future use.
• routes - specifies to trace routes that are exchanged with the kernel, including add, delete, or change messages and add, delete, or change messages received from other processes
• interface - specifies to trace interface status messages that are received from the kernel. These are supported only on systems with networking code derived from BSD 4.4.

[send | receive | send-receive ]? - optionally specify whether to limit the tracing to packets sent, received, or both

[detail?] - optionally specify to use a more verbose format when displaying information about the contents of packets instead of one or two lines

Description

Use the kernel trace flag command to specify tracing flags for Kernel tracing. Each flag must reside on its own configuration line. For example, you cannot specify to trace both symbol and remnant packets in the same command.

Default

The default is for no flags to be explicitly configured.

Command History

NGC 2.2 - This command was introduced.

Examples

In the following example, trace flags specify that both the sent and received redirect and interface messages are traced in detail. This tracing information will be written to the file /var/tmp/kernel.log.

(config)# kernel trace file /var/tmp/kernel.log

(config)# kernel trace flag redirect send-receive detail

(config)# kernel trace flag interface send-receive detail

show kernel

Name

show kernel - displays information about kernel settings and support

Syntax

show kernel

Mode

User Execution

Parameters

none

Description

The show kernel query displays information about kernel settings and support.

These fields have the following meanings.

no-change - If this setting is set to "on" for systems supporting the routing socket, then change operations will not be performed. Only deletes and adds will be performed. This is useful on early versions of the routing socket code where the change operation was broken. This option can be toggled with the kernel no-change command.

no-flush-at-exit - During normal shutdown processing, Advanced Routing Suite deletes from the kernel forwarding table all routes that the kernel does not flag as "retain". Setting this option to "on" prevents route deletions at shutdown. During a Advanced Routing Suite shutdown/restart sequence, it may be desirable to keep in the kernel forwarding table the routes that existed at the time of the Advanced Routing Suite shutdown. This allows the router to continue forwarding packets while Advanced Routing Suite is being restarted.

After a restart, the protocol modules are given a short amount of time (currently three minutes) to determine their routes. After three minutes, all residual routes not re-established by the protocol modules are flushed.

There are four conditions under which Advanced Routing Suite does not flush a route:

• Interface routes
• Static routes with "retain" specified
• Routes specified with "noflushexit"
• Routes with static bit set

The no-flush-at-exit option is convenient on systems with thousands of routes. Upon startup, Advanced Routing Suite will notice the routes that are in the kernel's forwarding table and not add them back.

This option can be toggled with the kernel no-flush-at-exit command.

reject support - This value indicates whether the operating system supports reject routes.

blackhole support- This value indicates whether the operating system supports blackhole routes.

variable length subnet support - This value indicates whether the operating system supports data forwarding using variable length subnet masks.

host route support - This value indicates whether the operating system supports hosts routes.

multipath support - This value indicates whether the operating system supports multipath routing.

IPv4 forwarding enabled - This value indicates whether IPv4 forwarding is turned on in the operating system.

UDP checksums enabled - This value indicates whether UDP checksums are turned on in the operating system.

Command History

NGC 2.2 - This command was introduced.

Examples

The following example displays a response for the show kernel query.

> show kernel

no-change: on no-flush-at-exit: off
reject support: yes blackhole support: yes
variable length subnet support: no
host route support: yes
multipath support: yes IPv4 forwarding enabled: yes
IPv6 forwarding enabled: no UDP checksums enabled: no