150
151 EPERM If the calling process does not have appropriate
152 privileges to alter the routing table.
153
154
155
156 In the current implementation, all routing processes run
157 locally, and the values for rtm_errno are available through
158 the normal errno mechanism, even if the routing reply mes-
159 sage is lost.
160
161
162 A process may avoid the expense of reading replies to its
163 own messages by issuing a setsockopt(3SOCKET) call indicat-
164 ing that the SO_USELOOPBACK option at the SOL_SOCKET level
165 is to be turned off. A process may ignore all messages from
166 the routing socket by doing a shutdown(3SOCKET) system call
167 for further input.
168
169
170 If a route is in use when it is deleted, the routing entry
171 is marked down and removed from the routing table, but the
172 resources associated with it are not reclaimed until all
173 references to it are released.
174
175
176 The RTM_IFINFO, RTM_NEWADDR, and RTM_ADD messages associated
177 with interface configuration (setting the IFF_UP bit) are
178 normally delayed until after Duplicate Address Detection
179 completes. Thus, applications that configure interfaces and
180 wish to wait until the interface is ready can wait until
181 RTM_IFINFO is returned and SIOCGLIFFLAGS shows that
182 IFF_DUPLICATE is not set.
183
184 Messages
185 User processes can obtain information about the routing
186 entry to a specific destination by using a RTM_GET message.
187
188
189
|
150
151 EPERM If the calling process does not have appropriate
152 privileges to alter the routing table.
153
154
155
156 In the current implementation, all routing processes run
157 locally, and the values for rtm_errno are available through
158 the normal errno mechanism, even if the routing reply mes-
159 sage is lost.
160
161
162 A process may avoid the expense of reading replies to its
163 own messages by issuing a setsockopt(3SOCKET) call indicat-
164 ing that the SO_USELOOPBACK option at the SOL_SOCKET level
165 is to be turned off. A process may ignore all messages from
166 the routing socket by doing a shutdown(3SOCKET) system call
167 for further input.
168
169
170 By default, underlying IP interfaces in an IPMP group are
171 not visible to routing sockets. As such, routing sockets
172 will not receive events related to underlying IP interfaces
173 in an IPMP group. For consistency, when an IP interface is
174 placed into an IPMP group, *RTM_DELADDR* messages will be
175 generated for each of the *IFF_UP* addresses that are not
176 migrated to the corresponding IPMP IP interface, and an
177 *RTM_IFINFO* message will be sent indicating that the
178 interface is now down. Similarly, when an underlying
179 interface is removed from an IPMP group, an *RTM_IFINFO*
180 message will be sent indicating that the interface is again
181 up, and *RTM_NEWADDR* messages will be generated for each
182 *IFF_UP* address found on the interface.
183
184
185 The *RT_AWARE* socket option at the *SOL_ROUTE* level allows
186 an application to indicate its awareness of certain
187 features, which controls routing socket behavior. The
188 supported values are:
189
190 *RTAW_DEFAULT* Default awareness.
191
192 *RTAW_UNDER_IPMP* IPMP underlying interface awareness.
193 When this is enabled, underlying IP
194 interfaces in an IPMP group will remain
195 visible to the routing socket and
196 events related to them will continue to
197 be generated.
198
199
200 An *RTM_ADD* request tied to an underlying IP interface in
201 an IPMP group will be translated to an *RTM_ADD* request for
202 its corresponding IPMP IP interface. All routing socket
203 requests other than *RTM_ADD* and *RTM_GET* will fail when
204 issued on an underlying IP interface in an IPMP group.
205
206
207 If a route is in use when it is deleted, the routing entry
208 is marked down and removed from the routing table, but the
209 resources associated with it are not reclaimed until all
210 references to it are released.
211
212
213 The RTM_IFINFO, RTM_NEWADDR, and RTM_ADD messages associated
214 with interface configuration (setting the IFF_UP bit) are
215 normally delayed until after Duplicate Address Detection
216 completes. Thus, applications that configure interfaces and
217 wish to wait until the interface is ready can wait until
218 RTM_IFINFO is returned and SIOCGLIFFLAGS shows that
219 IFF_DUPLICATE is not set.
220
221 Messages
222 User processes can obtain information about the routing
223 entry to a specific destination by using a RTM_GET message.
224
225
226
|