Understanding Linux Network Internals 2005 phần 10 pdf

int nh_powerThese two fields are part of the fib_nh data structure only when the kernel is compiled with support for multipath, and are described in detail in the section " Concepts Behi

Trang 1

Value Description

RTPROT_STATIC Route installed by administrator Not used.

Table 36-9 Values of fib_protocol used by user space

RTPROT_GATED The route was added by GateD.

RTPROT_RA

The route was added by RDISC (IPv4) and ND (IPv6) router advertisements There is a mechanism, the

ICMP Router Discovery Protocol defined in RFC 1256, that lets hosts find neighboring routers rdisc, which

is part of the iputils package, is the user-space tool that implements ICMP Router Discovery Messages.

RTPROT_MRT The route was added by the Multi-Threaded Routing Toolkit (MRT).

RTPROT_ZEBRA The route was added by Zebra.

RTPROT_BIRD The route was added by BIRD.

RTPROT_DNROUTED The route was added by the DECnet routing daemon.

RTPROT_XORP The route was added by the XORP routing daemon.

Trang 2

Table 36-10 Routing metrics

u32 fib_mp_alg

Multipath caching algorithm The IP_MP_ALG_XXX IDs of the algorithms introduced in the section " Cache Support for Multipath " in Chapter 31 are listed in include/linux/ip_mp_alg.h This field is part of the data structure only when the kernel is

compiled with support for multipath caching.

#define fib_dev fib_nh[0].nh_dev

Macro used to access the nh_dev field of the first fib_nh instance of the fib_nh vector See Figure 34-1 in Chapter 34

Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com

Trang 3

#define fib_mtu fib_metrics[RTAX_MTU-1]

#define fib_window fib_metrics[RTAX_WINDOW-1]

#define fib_rtt fib_metrics[RTAX_RTT-1]

#define fib_advmss fib_metrics[RTAX_ADVMSS-1]

Macros used to access specific elements of the fib_metrics vector.

36.5.6 fib_nh Structure

For each next hop, the kernel needs to keep more than just the IP address The fib_nh structure stores that extra information in the following fields.

struct net_device *nh_dev

This is the net_device data structure associated with the device ID nh_oif (described later) Since both the ID and the pointer

to the net_device structure are needed (in different contexts), both of them are kept in the fib_nh structure, even though either one could be used to retrieve the other.

struct hlist_node nh_hash

Used to insert the structure into the hash table described in the section " Organization of Next-Hop Router Structures " in Chapter 34

struct fib_info *nh_parent

Pointer to the fib_info structure that contains this fib_nh instance See Figure 34-1 in Chapter 34

unsigned nh_flags

A set of RTNH_F_XXX flags defined in include/linux/rtnetlink.h and listed in Table 36-7 earlier in this chapter.

unsigned char nh_scope

Scope of the route used to get to the next hop It is RT_SCOPE_LINK in most cases This field is initialized by fib_check_nh

int nh_weight

Trang 4

int nh_power

These two fields are part of the fib_nh data structure only when the kernel is compiled with support for multipath, and are described in detail in the section " Concepts Behind Multipath Routing " in Chapter 31 nh_power is initialized by the kernel; nh_weight is set by the user with the keyword weight

_ _u32 nh_tclassid

This field is part of the fib_nh data structure only when the kernel is compiled with support for the routing table based classifier Its value is set with the realms keyword See the section " Policy Routing and Routing Table Based Classifier " in Chapter 35

struct fib_rule *r_next

Links these structures within a global list that contains all fib_rule structures (see Figure 35-8 in Chapter 35 ).

Trang 5

the kernel (see the section " fib_lookup with Policy Routing " in Chapter 35 , and the definitions of the three default rules local_rule , main_rule , and default_rule in net/ipv4/fib_rules.c).

unsigned char r_table

Routing table identifier Ranges from 0 to 255 When it is not specified by the user, IPROUTE2 uses the following defaults: RT_TABLE_MAIN when the user command adds a rule, and RT_TABLE_UNSPEC in other cases (e.g., when deleting a rule).

unsigned char r_action

The values allowed for this field are the rtm_type enum listed in include/linux/rtnetlink.h (RTN_UNICAST , etc.) The meanings

of these values are described in the section " rtable Structure "

This field can be explicitly set by the user using the type keyword when configuring a rule When it is not explicitly configured

by the user, IPROUTE2 sets it to RTN_UNICAST when adding rules, and RTN_UNSPEC otherwise (e.g., when deleting rules).

unsigned char r_dst_len

unsigned char r_src_len

Length of the destination and source IP addresses, expressed in bits They are used to compute r_srcmask and r_dstmask When not initialized, they are set to zero.

u8 r_flags

Set of flags Currently not used.

Trang 6

When a rule is available for use, this field is 0 When the rule is removed with inet_rtm_delrule , this field is set to 1 Every time

a reference to the fib_rule data structure is removed with fib_rule_put , the reference count is decremented, and when it gets

to zero the structure is supposed to be freed At that point, however, if r_dead is not set, it means that something wrong happened (for instance, code has set the reference count incorrectly).

36.5.8 fib_result Structure

The fib_result structure is initialized by fib_semantic_match to the result of a routing lookup See Chapters 33 and 35 (in particular, the section " Semantic Matching on Subsidiary Criteria ") for more details The fields in the structure are:

unsigned char prefixlen

Prefix length of the matching route See the description of fz_order in the section " fn_zone Structure "

unsigned char nh_sel

Multipath routes are defined with multiple next hops This field identifies the next hop that has been selected.

Trang 7

unsigned char type

unsigned char scope

These two fields are initialized to the values of the fa_type and fa_scope fields of the matching fib_alias instance.

_ _u32 network

_ _u32 netmask

These two fields are included in the data structure definition only when the kernel is compiled with support for multipath caching See the section " Weighted Random Algorithm " in Chapter 33 for how they are used by the weighted random multipath caching algorithm.

struct fib_info *fi

The fib_info instance associated with the matching fib_alias instance.

struct in_device *idev

Pointer to the IP configuration block of the egress device Note that when the route is used for ingress packets that are to be delivered locally, the egress device is the loopback device.

Trang 8

unsigned rt_flags

The flags you can set in this bitmap are the RTCF_XXX values defined in include/linux/in_route.h and listed in Table 36-11

Table 36-11 Possible values for rt_flags

RTCF_NOTIFY Interested user-space applications are notified of any change to the routing entry via Netlink This option is

not yet completely implemented The flag is set with commands such as ip route get 10.0.1.0/24 notify.

RTCF_REDIRECTED The entry has been added in response to a received ICMP_REDIRECTmessage (see ip_rt_redirect and its

caller).

RTCF_DOREDIRECT

This flag is set by ip_route_input_slow when an ICMP_REDIRECT message must be sent back to the source ip_forward , described in detail in Chapter 20 , decides whether to actually send the ICMP redirect based on this flag and other information For instance, if the packet was source routed, no ICMP redirect would be generated.

RTCF_DIRECTSRC

This flag is used mostly to tell the ICMP code that it should not reply to Address Mask Request Messages The flag is set every time a call to fib_validate_source says that the source of the received packet is reachable with a next hop that has a local scope ( RT_SCOPE_HOST ) See Chapters 25 and 35 for more detail.

RTCF_BROADCAST The destination address of the route is a broadcast address.

RTCF_MULTICAST The destination address of the route is a multicast address.

RTCF_LOCAL The destination address of the route is local (i.e., configured on one of the local interfaces) This flag is also

set for local broadcast and multicast addresses (see ip_route_input_mc ).

RTCF_REJECT Not used According to the syntax of IPROUTE2's ip rule command, there is a reject keyword, but it is not

accepted.

RTCF_DIRECTDST Not used.

RTCF_FAST Not used This flag is obsolete; it used to be set to mark a route as eligible for Fast Switching, a feature that

has been dropped in the 2.6 kernels.

RTCF_MASQ Not used anymore by IPv4 The flag was supposed to mark packets coming from masqueraded source

Trang 9

Table 36-12 Possible values for rt_typeRoute type Description

RTN_UNSPEC Defines a noninitialized value This value is used, for instance, when removing an entry from the routing

table, because that operation does not require the type of entry to be specified.

RTN_LOCAL The destination address is configured on a local interface.

RTN_UNICAST The route is a direct or indirect (via a gateway) route to a unicast address This is the default value set by the

ip route command when no other type is specified by the user.

RTN_MULTICAST The destination address is a multicast address.

RTN_BROADCAST The destination address is a broadcast address Matching ingress packets are delivered locally as

broadcasts, and matching egress packets are sent as broadcasts.

RTN_ANYCAST Matching ingress packets are delivered locally as broadcasts, and matching egress packets are sent as

unicast Not used by IPv4.

RTN_NAT The source and/or destination IP address must be translated Not used because the associated feature,

FastNAT, has been dropped in the 2.6 kernels.

RTN_XRESOLVE An external resolver will take care of this route This functionality is currently not implemented.

Trang 10

_ _u32 rt_gateway

When the destination host is directly connected (it is on-link), rt_gateway matches the destination address When a gateway

is needed to reach the destination, rt_gateway is set to the next hop gateway identified by the route.

struct flowi fl

Search key used for the cache lookups, described in the section " flowi Structure "

_ _u32 rt_spec_dst

RFC 1122-specific destination, explained in the section " Preferred Source Address Selection " in Chapter 35

struct inet_peer *peer

The inet_peer structure, introduced in Chapter 19 , stores long-living information about the IP peer, which is the host with the destination IP address of this cached route There is an inet_peer structure for each remote IP address to which the local host has been talking in the recent past.

36.5.10 dst_entry Structure

The data structure dst_entry is used to store the protocol-independent information concerning cached routes L3 protocols keep their own, additional private information in separate structures (For example, IPv4 uses rtable structures.)

Here is the field-by-field description:

struct dst_entry *next

Used to link the dst_entry instances that collide into the same hash table's bucket See Figure 33-1 in Chapter 33

struct dst_entry *child

unsigned short header_len

unsigned short trailer_len

struct dst_entry *path

struct xfrm_state *xfrm

Trang 11

These fields are used by IPsec code.

struct net_device *dev

Egress device (i.e., where to transmit to reach the destination).

short obsolete

Used to define the usability status of this dst_entry instance: 0 (the default value) means the structure is valid and can be used, 2 means the structure is being removed and therefore cannot be used, and -1 is used by IPsec and IPv6 but not by IPv4.

int flags

Set of flags DST_HOST is used by TCP and means the route leads to a host (i.e., it is not a route to a network or a broadcast/multicast address) DST_NOXFRM , DST_NOPOLICY , and DST_NOHASH are used only by IPsec.

unsigned long lastuse

Timestamp used to remember the last time this entry was used It is updated when there is a successful cache lookup and it

is used by the garbage collection routines to select the best structures to free.

unsigned long expires

Timestamp that indicates when the entry will expire See the section " Expiration Criteria " in Chapter 33

u32 metrics[RTAX_MAX]

Vector of metrics, used mostly by TCP This vector is initialized with a copy of the fib_info->fib_metrics vector (if it is defined), and default values are used where needed See the function rt_set_nexthop and Chapter 35 See Table 36-10 for a

description of the vector's possible values.

The RTAX_LOCK value needs a little explanation RTAX_LOCK is not a metric but a bitmap: when the bit in position n is set, it means that the metric with enum value n has been configured with the lock options/keyword In other words, a command like ip

route add advmss lock sets the 1<<RTAX_ADVMSS bit When a metric is locked, it cannot be changed by protocol events.

Trang 12

unsigned long rate_last

unsigned long rate_tokens

These two fields are used to rate limit two types of ICMP messages See the section " Egress ICMP REDIRECT Rate Limiting " in Chapter 33 and the section " Routing Failure " in Chapter 35

short error

When the fib_lookup API (used only by IPv4) fails, the error is saved into error (with a positive sign) and used later by ip_error

to decide how to handle the failure (i.e., to decide which ICMP to generate).

struct neighbour *neighbour

struct hh_cache *hh

neighbour is the data structure that contains the L3-to-L2 address mapping for the next hop hh is the cached L2 header See the chapters in Part VI for details.

int (*input)(struct sk_buff*)

int (*output)(struct sk_buff**)

Functions used to process ingress and egress packets, respectively See the section " Cache Lookup " in Chapter 33

_ _u32 tclassid

Routing table based classifier's tag See the section " Policy Routing and Routing Table Based Classifier " in Chapter 35

struct dst_ops *ops

VFT whose functions are used to manipulate dst_entry structures.

struct rcu_head rcu_head

Takes care of mutual exclusion.

Trang 13

The dst_ops structure is the interface between the protocol-independent cache and L3 protocols that use a routing cache See the section " Interface Between the DST and Calling Protocols " in Chapter 33 Here is the field-by-field description:

unsigned short family

Address family See AF_XXX values in include/linux/socket.h.

unsigned short protocol

Protocol ID See ETH_P_XXX values in include/linux/if_ether.h.

gc is the garbage collection function invoked by dst_alloc when the number of dst_entry instances ( enTRies ) already allocated

by the protocol is greater than or equal to the threshold gc_thresh

struct dst_entry * (*check)(struct dst_entry *, _ _u32 cookie)

void (*destroy)(struct dst_entry *)

void (*ifdown)(struct dst_entry *, struct net_device *dev, int how)

struct dst_entry * (*negative_advice)(struct dst_entry *)

void (*link_failure)(struct sk_buff *)

void (*update_pmtu)(struct dst_entry *dst, u32 mtu)

int (*get_mss)(struct dst_entry *dst, u32 mtu)

See the section " Interface Between the DST and Calling Protocols " in Chapter 33

Trang 14

With the flowi data structure, it is possible to define classes of traffic based on the combination of fields such as ingress and egress

devices, parameters from the L3 and L4 protocol headers, etc It is commonly used as a search key for lookups, as a traffic selector for

IPsec policies, and other advanced uses Here is a brief description of its fields:

The only flag defined in this variable, FLOWI_FLAG_MULTIPATHOLDROUTE , originally was used by the multipath code, but

it is not used anymore.

union { } uli_u

Union whose fields are mainly structures that can be used to specify the values of L4 parameters The protocols currently supported are TCP, UDP, ICMP, DECnet, and the IPsec suite.

Because the data structure is not flat, but contains unions and structs, the kernel provides a set of macros that can be used to access

some of its fields.

Trang 15

out_slow_mc

out_slow_tot and out_slow_mc play the same role as in_slow_tot and in_slow_mc for the egress traffic

in_no_route

Number of ingress packets that could not be forwarded because the routing table did not know how to reach the destination

IP address (which is possible only if no default gateway is configured or usable) See ip_route_input_slow There is no counter to keep track of the locally generated packets that could not be sent for lack of a route.

Trang 16

These two counters represent the number of packets that were dropped because the sanity check failed on the destination or source IP addresses, respectively Examples of sanity checks are that the source IP address cannot be multicast or broadcast and that the destination address cannot belong to the so-called zero-networkthat is, it cannot look like 0.n.n.n.

gc_total

gc_ignored

gc_goal_miss

gc_dst_overflow

These four fields are updated by rt_garbage_collect , described in the section " rt_garbage_collect Function " in Chapter 33

gc_total keeps track of the number of times rt_garbage_collect is invoked.

gc_ignored is the number of times rt_garbage_collect returns immediately because it was called too recently.

gc_goal_miss is the number of times the cache has been scanned by rt_garbage_collect without meeting the goal set at the beginning of the function.

gc_dst_overflow is the number of times gc_garbage_collect fails by not reducing the number of cache entries below the ip_rt_max_size threshold.

in_hlist_search

out_hlist_search

These are updated by the routines used for the cache lookups, ip_route_input and _ _ip_route_output_key, respectively

They represent the number of cache elements that have been tested and did not match (not just the number of cache misses).

36.5.14 ip_mp_alg_ops Structure

ip_mp_alg_ops represents the interface between the routing cache and the Multipath caching feature It consists of the following function

pointers:

void (*mp_alg_select_route) (const struct flowi *flp, struct rtable *rth, struct rtable **rp)

void (*mp_alg_flush) (void)

Trang 17

void (*mp_alg_set_nhinfo) (_ _u32 network, _ _u32 netmask, unsigned char prefixlen, const struct fib_nh *nh)

void (*mp_alg_remove) (struct rtable *rth)

These functions are invoked by the algorithm-independent wrappers described in the section " Interface Between the Routing Cache and Multipath " in Chapter 33

Trang 18

36.6 Functions and Variables Featured in This Part of the Book

Table 36-13 summarizes the main functions, variables, and data structures introduced or referenced in the chapters of this book covering the routing subsystem You can find more in the section " Generic Helper Routines and Macros " and " Helper Routines " in Chapter 32 , and the two "Helper Routines", in Chapter 35

Table 36-13 Functions, variables, and data structures in the routing subsystemFunctions

for_ifa, endfor_ifa

for_primary_ifa, endfor_ifa

Macros used to browse the IPv4 addresses configured on a network device See the section

" Primary and Secondary IP Addresses " in Chapter 32

FIB_RES_XXX Set of macros used to access the fields of the fib_result structure See the section "Generic

Helper Routines and Macros " in Chapter 32 LOOPBACK

Initialization routines See the section " Routing Subsystem Initialization " in Chapter 32

dst_alloc Allocate an entry for the routing cache See the section "Cache Entry Allocation and Reference

Counts " in Chapter 33

Trang 19

fib_magic Used by the kernel to insert routes under specific conditions See the section "Routes Inserted by

the Kernel: The fib_magic Function "

fib_rules_detach

fib_rules_attach

Enables and disables routing policies when network devices are registered and unregistered, respectively See the section " Impacts on the policy database " in Chapter 32

rtmsg_fib Used to send notification on a specific Netlink multicast group when routes are added or

removed See the section " Netlink Notifications " in Chapter 32 ip_route_input

Routing table lookup routines See Chapter 35

ip_route_input_mc Lookup routines used for multicast destinations.

fn_hash_insert Add a new route to a routing table See the section " Adding a Route " in Chapter 34

fn_hash_delete Remove a route from a routing table See the section "Deleting a Route" in Chapter 34.

rt_intern_hash Add an entry to the routing cache See the section " Adding Elements to the Cache " in Chapter 33

Trang 20

Various routines used to manage cache entries associated with multipath routes See the section

" Interface Between the Routing Cache and Multipath " in Chapter 33 More routines are listed in the section " Helper Routines " in the same chapter.

dst_dev_event Handler used by the DST subsystem to process notifications from the neTDev_chain notification

chain See the section " External Events " in Chapter 32 RT_CACHE_STAT_INC Update per-CPU statistics See the section "Statistics."

rt_hash_mask Size of the routing cache (i.e., number of buckets of the hash table).

dst_garbage_list List of dst_entry instances that cannot be removed because they are still referenced See Chapter

33 fib_tables List of fib_table instances See Figure 34-1 in Chapter 34

fib_rules List of routing policies See the section " fib_lookup with Policy Routing " in Chapter 35

fib_info_cnt Number of outstanding fib_info instances See the section "Dynamic resizing of global hash

tables " in Chapter 34 fib_info_hash

Trang 21

fib_info_devhash Hash table used to search fib_nh instances See the section "Organization of Next-Hop Router

Structures " in Chapter 34

fib_props Vector whose elements are used by the lookup routine fib_semantic_match to map route types to

return values See the section " Return value from fib_semantic_match " in Chapter 35 Data structures

Trang 22

36.7 Files and Directories Featured in This Part of the Book

Figure 36-6 lists the files and directories referred to in the chapters in Part VII

Figure 36-6 Files and directories featured in this part of the book

Trang 23

About the Authors

Christian Benvenuti received his masters degree in computer science at the University of Bologna in Italy He collaborated for a few

years with the International Center for Theoretical Physics (ICTP) in Trieste, where he developed ad-hoc software based on the Linux kernel, was a scientific consultant for a project on remote collaboration, and served as an instructor for several training sessions on networking The trainings, held mainly in Europe, Africa, and South America were all based on Linux systems and addressed to scientists from developing countries, where the ICTP has been promoting Linux for many years He occasionally collaborates with a nonprofit organization founded by ICTP members, Collaborium.org , to continue promoting Linux on developing countries.

In the past few years he worked as a software engineer for Cisco Systems in the Silicon Valley, where he focused on Layer 2 switching, high availability, and network security.

Trang 24

Our look is the result of reader comments, our own experimentation, and feedback from distribution channels Distinctive covers

complement our distinctive approach to technical topics, breathing personality and life into potentially dry subjects.

Philip Dangler was the production editor, and Audrey Doyle was the copyeditor for Understanding Linux Network Internals Sada Preisch

proofread the book Mary Brady and Colleen Gorman provided quality control Rachel Monaghan, Lydia Onofrei, and Laurel Ruma

provided production assistance Angela Howard wrote the index.

Karen Montgomery designed the cover of this book, based on a series design by Hanna Dyer and Edie Freedman The cover image is a

19th-century engraving from Men: A Pictorial Archive from 19th Century Sources) Karen Montgomery produced the cover layout with

Adobe InDesign CS using Adobe's ITC Garamond font.

David Futato designed the interior layout The chapter opening images are from Men: A Pictorial Archive from 19th Century Sources

This book was converted by Keith Fahlgren to FrameMaker 5.5.6 with a format conversion tool created by Erik Ray, Jason McIntosh,

Neil Walls, and Mike Sierra that uses Perl and XML technologies The text font is Linotype Birka; the heading font is Adobe Myriad

Condensed; and the code font is LucasFont's TheSans Mono Condensed The illustrations that appear in the book were produced by

Robert Romano, Jessamyn Read, and Lesley Borash using Macromedia FreeHand MX and Adobe Photoshop CS The tip and warning

icons were drawn by Christopher Bing.

Trang 25

[SYMBOL] [A] [B] [C] [D] [E] [F] [ ] [H] [I] [J] [K] [L] [M] [N] [ ] [P] [ ] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Trang 26

802.3 standard, compared to Ethernet protocols

Trang 27

addbr command, brctl utility 2nd

addif command, brctl utility

addifr command, brctl utility

af_packet_priv field, packet_type structure

age_list field, net_bridge structure

age_list structure

ageing_time field, net_bridge structure

ageing_timer field, net_bridge_fdb_entry structure

Trang 28

allocs field, neigh_statistics structure

anycast_delay field, neigh_parms structure

AppleTalk Address Resolution Protocol

AppleTalk Datagram Delivery Protocol

application layer

communication choices made by

data units for (messages)

arch_initcall macro

Arkin, Ofir ("ICMP Usage in Scanning")

ARP (Address Resolution Protocol)

arpd daemon implementing

binding routing cache to

Trang 29

updated with gratuitous ARP

initialization and cleanup

instance of neigh_ops structure for

asynchronous garbage collection

Trang 30

autoconfig field, ipv4_config structure

avg_blog field, softnet_data structure 2nd 3rd 4th

AVL data structure

avl_height field, inet_peer structure

avl_left field, inet_peer structure

avl_right field, inet_peer structure

AX25 device, tx_queue_len value for

ax25_kiss_rcv function

ax25_ptr field, net_device structure

Trang 31

base_addr field, net_device structure 2nd

base_reachable_time field, neigh_parms structure

base_reachable_time file

base_reachable_time variable

Big Endian format

big_endian.h file

BIRD routing protocol daemon 2nd

black hole route

bonding device 2nd

notifications on

processing of ingress frames

tx_queue_len value for

boot-time initialization routines

boot-time kernel options 2nd 3rd

boot-time PCI device activities

BOOTP protocol, IP configuration using

version 2.2 and earlier

BPDUs (Bridge Protocol Data Units) 2nd

Trang 32

br_ioctl_hook function pointer

Trang 34

configuring bridge devices and ports

creating bridge devices and ports

bridge 2nd

access bridges

adding ports to

address learning by

aging mechanism for addresses 2nd 3rd

between LANs of different technologies

binding real device to

broadcast address, handling

loop topology not working with

merging LANs using

multicast address, handling

multiple bridge scenarios

multiple, advantages of

naming

net_device field for

notifying of topology change

passive learning by

setup routine for

Trang 35

store and forward bridge

bridge_forward_delay field, net_bridge structure

bridge_hello_time field, net_bridge structure

bridge_id field, net_bridge structure

configuring, user-space tools for

data structures for 2nd

files and directories for, list of

frame processing by

functions for, list of

ingress traffic, handling

initialization of code for

Trang 36

local delivery of

packet type for

packet, testing for

Trang 37

Carrier Sense Multiple Access with Collision Detection protocol (CSMA/CD)

cb field, sk_buff structure

change_mtu function pointer, net_device structure 2nd

change_nexthops macro 2nd

channeling

check virtual function, dst_ops structure 2nd

checksum field, ICMP header

sk_buff structure fields for

status values for

updating, when required

child field, dst_entry structure

class_dev field, net_device structure

Trang 38

cleanup_module function 2nd

cleanup_once function

clip_tbl structure

cloned field, sk_buff structure 2nd

cnf field, in_device structure

cng_level field, softnet_data structure 2nd 3rd 4th

code field, ICMP header

compile options, finding symbols associated with

compiler directives, conditional

completion_queue field, softnet_data structure

concurrency, interrupts and

condition checks, compile-time optimization for

Trang 39

confirmed field, neighbour structure

congestion control algorithms, fragmentation incompatible with

congestion management for reception of frames

connected_output function, neigh_ops structure

constructor function, neigh_table structure 2nd

CSMA/CD (Carrier Sense Multiple Access with Collision Detection protocol)

csum field, sk_buff structure 2nd

Tiêu đề	Understanding Linux Network Internals 2005 phần 10 pdf
Trường học	Unknown
Chuyên ngành	Computer Science
Thể loại	lecture notes
Năm xuất bản	2005
Thành phố	Unknown

Định dạng
Số trang	128
Dung lượng	3,21 MB