1route(1M) System Administration Commands route(1M)
2
6 route - manually manipulate the routing tables
7
9 route [-fnvq] sub-command [ [modifiers] args]
10 route [-fnvq] [-p [-R root-dir]] add | delete [modifiers] destination gateway
13 [args]
14 route [-fnvq] change | get [modifiers] destination
17 [gateway [args]]
18 route [-fn] monitor [modifiers]
21 route [-fnvq] flush [modifiers]
24 route -p [-R root-dir] show
27
30 route manually manipulates the network routing tables. These tables are
31 normally maintained by the system routing daemon, such as in.routed(1M)
32 and in.ripngd(1M).
33 route supports a limited number of general options, but a rich command
36 language. Users can specify an arbitrary request that can be delivered
37 by means of the programmatic interface discussed in route(7P).
38 route uses a routing socket and the new message types RTM_ADD,
41 RTM_DELETE, RTM_GET, and RTM_CHANGE. While only superusers can modify
42 routing tables, the RTM_GET operation is allowed for non-privileged
43 users.
44
46 -f Flush the routing tables of all gateway entries. If you
47 use the -f option in conjunction with any of the route
48 sub-commands, route flushes the gateways before perform‐
49 ing the sub-command. Specify the table to flush by plac‐
50 ing the inet or inet6 modifier immediately after the -f
51 option. If unspecified, flushing IPv4 (inet) routes is
52 the default.
53 -n Prevent attempts to print host and network names symbol‐
56 ically when reporting actions. This option is useful
57 when name servers are unavailable.
58 -p Make changes to the network route tables persistent
61 across system restarts. The operation is applied to the
62 network routing tables first and, if successful, is then
63 applied to the list of saved routes used at system
64 startup. In determining whether an operation was suc‐
65 cessful, a failure to add a route that already exists or
66 to delete a route that is not in the routing table is
67 ignored. Particular care should be taken when using host
68 or network names in persistent routes, as network-based
69 name resolution services are not available at the time
70 routes are added at startup.
71 -q Suppress all output.
74 -R root-dir Specify an alternate root directory where route applies
77 changes. This option is ignored unless used in conjunc‐
78 tion with the -p option. When -R is specified, route
79 changes are applied only to the list of saved routes to
80 be used at startup, not to the network routing tables.
81 In addition, certain checks, such as the existence of
82 network interfaces used with -ifp, are skipped. This can
83 be useful from within JumpStart scripts, where the root
84 directory of the system being modified is in a location
85 other than /.
86 -v Print additional details in verbose mode.
89 Subcommands
92 The following subcommands are supported:
93 add Add a route.
95 change Change aspects of a route (such as its gateway).
98 delete Delete a specific route.
101 flush Remove all gateway entries from the routing table.
104 get Look up and display the route for a destination.
107 monitor Continuously report any changes to the routing information
110 base, routing lookup misses, or suspected network partition‐
111 ings.
112 show Display the list of routes to be applied at system startup.
115 Can be used only in conjunction with the -p option.
116 The add and delete sub-commands have the following syntax:
120 route [ -fnvq ] cmd destination gateway [metric/netmask]
122 where cmd is add or delete, destination is the destination host or net‐
127 work, and gateway is the next-hop intermediary through which packets
128 should be routed. Modifiers described in OPERANDS can be placed any‐
129 where on the command line.
130 The get and change sub-commands have the following syntax:
133 route [ -fnvq ] cmd destination [gateway [metric/netmask]]
135 where cmd is get or change, destination is the destination host or net‐
140 work, and gateway is the next-hop intermediary through which packets
141 should be routed. Modifiers described in OPERANDS can be placed any‐
142 where on the command line.
143 The monitor sub-command has the following syntax:
146 route monitor [ -inet | -inet6 ]
148
152 route executes its sub-commands on routes to destinations by way of
153 gateways.
154 Destinations and Gateways
156 By default, destination and gateway addresses are interpreted as IPv4
157 addresses. All symbolic names are tried first as a host name, using
158 getipnodebyname(3SOCKET). If this lookup fails in the AF_INET case,
159 getnetbyname(3SOCKET) interprets the name as that of a network.
160 Including an optional modifier on the command line before the address
163 changes how the route sub-command interprets it.
164 The following modifiers are supported:
167 -inet Force the address to be interpreted as an IPv4 address, that
169 is, under the AF_INET address family.
170 -inet6 Force the address to be interpreted as an IPv6 address, that
173 is, under the AF_INET6 address family.
174 For IPv4 addresses, routes to a particular host are by default distin‐
178 guished from those to a network by interpreting the Internet address
179 specified as the destination. If the destination has a local address
180 part (that is, the portion not covered by the netmask) of 0, or if the
181 destination is resolved as the symbolic name of a network, then the
182 route is assumed to be to a network; otherwise, it is presumed to be a
183 route to a host.
184 You can force this selection by using one of the following modifiers:
187 -host Force the destination to be interpreted as a host.
189 -net Force the destination to be interpreted as a network.
192 For example:
196 Destination Destination Equivalent
201 ───────────────────────────────────────────────────────────
202 128.32 -host 128.0.0.32
203 128.32.130 -host 128.32.0.130
204 -net 128.32 128.32.0.0
205 -net 128.32.130 128.32.130.0
206 Two modifiers avoid confusion between addresses and keywords (for exam‐
210 ple., host used as a symbolic host name). You can distinguish a desti‐
211 nation by preceding it with the -dst modifier. You can distinguish a
212 gateway address by using the -gateway modifier. If the destination is
213 directly reachable by way of an interface requiring no intermediary IP
214 router to act as a gateway, this can be indicated by using the -inter‐
215 face or -iface modifier.
216 In the following example, the route does not refer to an external gate‐
219 way (router), but rather to one of the machine's interfaces. Packets
220 with IP destination addresses matching the destination and mask on such
221 a route are sent out on the interface identified by the gateway
222 address. For interfaces using the ARP protocol, this type of route is
223 used to specify that all matching destinations are local to the physi‐
224 cal link. That is, a host could be configured to ARP for all addresses,
225 without regard to the configured interface netmask, by adding a default
226 route using this command. For example:
227 example# route add default hostname -interface
229 where gateway address hostname is the name or IP address associated
234 with the network interface over which all matching packets should be
235 sent. On a host with a single network interface, hostname is usually
236 the same as the nodename returned by the uname -n command. See
237 uname(1).
238 For backward compatibility with older systems, directly reachable
241 routes can also be specified by placing a 0 after the gateway address:
242 example# route add default hostname 0
244 This value was once a route metric, but this metric is no longer used.
249 If the value is specified as 0, then the destination is directly reach‐
250 able (equivalent to specifying -interface). If it is non-zero but can‐
251 not be interpreted as a subnet mask, then a gateway is used (default).
252 With the AF_INET address family or an IPv4 address, a separate subnet
255 mask can be specified. This can be specified in one of the following
256 ways:
257 o IP address following the gateway address . This is typically
259 specified in decimal dot notation as for inet_addr(3SOCKET)
260 rather than in symbolic form.
261 o IP address following the -netmask qualifier.
263 o Slash character and a decimal length appended to the desti‐
265 nation address.
266 If a subnet mask is not specified, the mask used is the subnet mask of
269 the output interface selected by the gateway address, if the classful
270 network of the destination is the same as the classful network of the
271 interface. Otherwise, the classful network mask for the destination
272 address is used.
273 Each of the following examples creates an IPv4 route to the destination
276 192.0.2.32 subnet with a subnet mask of 255.255.255.224:
277 example# route add 192.0.2.32/27 somegateway
279 example# route add 192.0.2.32 -netmask 255.255.255.224 somegateway
280 example# route add 192.0.2.32 somegateway 255.255.255.224
281 For IPv6, only the slash format is accepted. The following example cre‐
286 ates an IPv6 route to the destination 33fe:: with a netmask of 16 one-
287 bits followed by 112 zero-bits.
288 example# route add -inet6 3ffe::/16 somegateway
290 In cases where the gateway does not uniquely identify the output inter‐
295 face (for example, when several interfaces have the same address), you
296 can use the -ifp ifname modifier to specify the interface by name. For
297 example, -ifp lo0 associates the route with the lo0 interface. If the
298 named interface is an underlying interface in an IPMP (IP multipathing)
299 group, then requests to add a route will automatically be translated to
300 the corresponding IPMP IP interface, and requests to delete or change a
301 route on an underlying interface will fail.
302 Routing Flags
304 Routes have associated flags that influence operation of the protocols
305 when sending to destinations matched by the routes. These flags can be
306 set (and in some cases cleared, indicated by ~) by including the fol‐
307 lowing modifiers on the command line:
308 Modifier Flag Description
313 ───────────────────────────────────────────────────────────────────────
314 -interface ~RTF_GATEWAY Destination is directly reachable
315 -iface ~RTF_GATEWAY Alias for interface modifier
316 -static RTF_STATIC Manually added route
317 -nostatic ~RTF_STATIC Pretend route was added by kernel or
318 routing daemon
319 -reject RTF_REJECT Emit an ICMP unreachable when matched
320 -blackhole RTF_BLACKHOLE Silently discard packets duing updates
321 -proto1 RTF_PROTO1 Set protocol specific routing flag #1
322 -proto2 RTF_PROTO2 Set protocol specific routing flag #2
323 -private RTF_PRIVATE Do not advertise this route
324 -multirt RTF_MULTIRT Creates the specified redundant route
325 -setsrc RTF_SETSRC Assigns the default source address
326 The optional modifiers -rtt, -rttvar, -sendpipe, -recvpipe, -mtu, -hop‐
330 count, -expire, and -ssthresh provide initial values to quantities
331 maintained in the routing entry by transport level protocols, such as
332 TCP. These can be individually locked either by preceding each modifier
333 to be locked by the -lock meta-modifier, or by specifying that all
334 ensuing metrics can be locked by the -lockrest meta-modifier.
335 Some transport layer protocols can support only some of these metrics.
338 The following optional modifiers are supported:
339 -expire Lifetime for the entry. This optional modifier is not cur‐
341 rently supported.
342 -hopcount Maximum hop count. This optional modifier is not currently
345 supported.
346 -mtu Maximum MTU in bytes.
349 -recvpipe Receive pipe size in bytes.
352 -rtt Round trip time in microseconds.
355 -rttvar Round trip time variance in microseconds.
358 -sendpipe Send pipe size in bytes.
361 -ssthresh Send pipe size threshold in bytes.
364 -secattr Security attributes of the route. This modifier is avail‐
367 able only if the system is configured with the Solaris
368 Trusted Extensions feature.
369 The -secattr modifier has the following format:
371 min_sl=val,max_sl=val,doi=val,cipso
373 or:
375 sl=VAL,doi=VAL,cipso
377 In the first form, above, the val for min_sl and max_sl is
379 a sensitivity label in either hex or string form. The val
380 for doi is a non-negative integer. The route will apply
381 only for packets with the same domain of interpretation as
382 defined by the doi value and within the accreditation
383 range defined by the min_sl and max_sl values. The cipso
384 keyword is optional and set by default. Valid min_sl,
385 max_sl and doi keyword/value pairs are mandatory. Note
386 that if val contains a space, it must be protected by dou‐
387 ble quotes.
388 The second form, above, is equivalent to specifying the
390 first form with the same VAL for min_sl and max_sl. The
391 second form should be used for the get command, because
392 get uses only a single sensitivity label.
393 Compatibility
396 The modifiers host and net are taken to be equivalent to -host and
397 -net. To specify a symbolic address that matches one of these names,
398 use the dst or gateway keyword to distinguish it. For example: -dst
399 host
400 The following two flags are also accepted for compatibility with older
403 systems, but have no effect.
404 Modifier Flag
409 ───────────────────────────────────────────────────────────
410 -cloning RTF_CLONING
411 -xresolve RTF_XRESOLVE
412 The -ifa hostname modifier is also accepted, but has no effect.
416
418 /etc/defaultrouter List of default routers
419 /etc/hosts List of host names and net addresses
422 /etc/networks List of network names and addresses
425
428 See attributes(5) for descriptions of the following attributes:
429 ┌─────────────────────────────┬─────────────────────────────┐
434 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
435 ├─────────────────────────────┼─────────────────────────────┤
436 │Availability │SUNWcsu │
437 └─────────────────────────────┴─────────────────────────────┘
438
440 uname(1), in.ripngd(1M), in.routed(1M), netstat(1M), routed(1M),
441 ioctl(2), getipnodebyname(3SOCKET), getnetbyname(3SOCKET),
442 inet_addr(3SOCKET), defaultrouter(4), hosts(4), networks(4),
443 attributes(5), ARP(7P), ip(7P), route(7P), routing(7P)
444
446 add [ host| network] destination:gateway flags
447 The specified route is being added to the tables. The values
449 printed are from the routing table entry supplied in the ioctl(2)
450 call. If the gateway address used was not the primary address of
451 the gateway (the first one returned by getipnodebyname(3SOCKET))
452 the gateway address is printed numerically as well as symbolically.
453 delete [ host| network] destination:gateway flags
456 change [ host| network] destination:gateway flags
457 As add, but when deleting or changing an entry.
459 destination done
462 When the -f flag is specified, or the flush sub-command is used,
464 each routing table entry deleted is indicated with a message of
465 this form.
466 Network is unreachable
469 An attempt to add a route failed because the gateway listed was not
471 on a directly-connected network. Give the next-hop gateway instead.
472 not in table
475 A delete operation was attempted for an entry that is not in the
477 table.
478 entry exists
481 An add operation was attempted for a route that already exists in
483 the kernel.
484 routing table overflow
487 An operation was attempted, but the system was unable to allocate
489 memory to create the new entry.
490 insufficient privileges
493 An attempt to add, delete, change, or flush a route failed because
495 the calling process does not have appropriate privileges.
496
499 Specifying that destinations are local (with the -interfacemodifier)
500 assumes that the routers implement proxy ARP, meaning that they respond
501 to ARP queries for all reachable destinations. Normally, using either
502 router discovery or RIP is more reliable and scalable than using proxy
503 ARP. See in.routed(1M) for information related to RIP.
504 Combining the all destinations are local route with subnet or network
507 routes can lead to unpredictable results. The search order as it
508 relates to the all destinations are local route are undefined and can
509 vary from release to release.
510SunOS 5.11 3 Feb 2009 route(1M)