![]() |
|
IP isn't really useful without a number of other protocols, such as ICMP and the many flavors of ARP and address assignment. Just studying IP doesn't give you everything you need to know.
Both ARP and Proxy ARP are motivated by a desire for efficiency. While nodes, at least those on the same subnet, could communicate simply by sending Layer 2 broadcasts, every node would hear and have to process the broadcast for every data packet sent.
Table 20. IP-to-Sub-IP Mapping Mechanisms
Sub-IP Protocol | Logical | Mapping | Transmission System | |
Permanent | Temporary | |||
LAN | IP | ARP | MAC | N/A |
PPP with dynamic addressing | Negotiated by IPCP | |||
Other dial-up | Static dialer map | E.164 telephone number (POTS and ISDN) | "Button"[1] B channel | |
Frame Relay | Static Frame Relay map Inverse ARP | DLCI | ||
ATM | Static ATM map | NSAP address | VPI/VCI | |
X.25 | Static X.25 map | X.121 address | LCN | |
LANE | MAC[2] | MAC NSAP | VPI/VCI |
[1]Think of the lighted button on a multiline phone. This is usually a physical identifier telling you which specific telephone interface is active.
[2]There is a triple address mapping here, first from IP to the emulated MAC address and second from the emulated MAC address to a VPI/VCI going to the LAN Emulation client (LEC) serving the destination. The LEC does the final mapping to the destination MAC.
ARP allows you to broadcast only once to find the MAC address of another node on your subnet. Once you know that and store the information in your local ARP table, you can unicast to that node.
ARP tables periodically expire and refresh, for several reasons. First, the ARP table is of limited size and it can become filled up with stale entries. Second, what if the NIC changes on another node, changing the MAC address associated with the IP address? What if a DHCP lease expires and the host is inactive for a time and then acquires a new address?
Some of the original host implementations of ARP taught us about broadcast storms. When all the hosts were time-synchronized and sent out an ARP according to the same timer value, the network became congested from all the ARP requests. Since the default behavior of ARP is to retransmit if it gets no response, the responses lost by congestion caused even worse congestion. Competent ARP implementations now randomize the timeout on their ARP tables.
IPv6 provides a mechanism for changing Link Layer addresses on demand rather than waiting for timeouts: sending Neighbor Advertisements to all nodes. These advertisements contain the new Link Layer address.
When Proxy ARP is enabled, a router will respond to an ARP request with its own MAC address, if the requested IP address in the ARP request has a prefix that is present in its routing table. Unfortunately, the router has knowledge only of the prefix, not of hosts on it, so it may answer for a dead (but obviously not forgotten) host. Other mechanisms, such as TCP timeouts, will usually tell the originating host that the destination is down, but there is apt to be needless retransmission traffic before this is discovered.
Proxy ARP is needed when the hosts are not terribly bright: they cannot be configured with a default gateway, nor do they understand routing. You will need Proxy ARP if you are using the Cisco Local Area Mobility (LAM) feature.
In addition to the black hole problem, Proxy ARP has other disadvantages. There will be more ARP traffic on the subnet, and the ARP tables will have to be larger to contain references to off-subnet hosts.
The ARP tables are configured on a per-interface basis:
interface e0/0 ip proxy-arp
While Proxy ARP is not a true feature of IPv6, it is possible for a router to issue non-override Neighbor Advertisements on behalf of the host and achieve a similar effect.
Inverse ARP is a means of discovering your interface address on an NBMA medium such as Frame Relay. Frame Relay and ATM, loosely speaking, are Layer 2 protocols, but they have an end-to-end property more like that seen at higher levels.
Inverse ARP is really a means of learning IP addresses rather than MAC addresses. It could equally well have been discussed in the section on dynamically acquiring IP addresses, but it fits better into the discussion of ARP alternatives.
Since Frame Relay is non-broadcast, you can't use a broadcast ARP to map between an IP address and a Frame Relay DLCI. The Inverse ARP protocol [RFC 2390] is one way to do this. Another way is to use static mapping statements, but these become difficult to maintain in large networks.
When a Frame Relay interface or subinterface initializes, it checks the local management interface to determine which PVCs are up. It then sends an Inverse ARP request over every active PVC, and will receive the corresponding IP address if Inverse ARP is enabled at the other end.
Whenever a new PVC comes up, the interface should send it a new Inverse ARP. For Frame Relay, the Inverse ARP requests contain:
Table 21. Fields in Inverse ARP
Field | Completed by |
DLCI | Sender |
IP Address | Sender |
Destination's DLCI (learned from the management interface) | Sender |
Destination IP | Zero-filled by sender, completed by receiver |
You configure this on a subinterface, or on a Frame Relay physical interface without subnetting, with:
interface s0/0 encapsulation frame-relay interface s0/0.1 ip address sender's-IP sender's-mask frame-relay interface-dlci sender's-DLCI
For all practical purposes, ICMP is part of every IP implementation. It is the set of mechanisms that IP uses to signal errors or to send information to other IP speakers, both routers and end hosts. As opposed to ARP, it does have scope beyond a single subnet, although in practice some ICMP messages are of link-local scope. ICMP packets follow IP packets, with a common header (Figure 24) and variable additional information [RFC 0792, updated by RFC 0950]. The Type field indicates the ICMP message type and thus the format of the rest of the message. The Code field contains supplemental information on why the ICMP message was issued.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24. ICMPv4 Header
Table 22 lists the currently defined ICMP codes. Once a code is assigned, it is never reassigned, so there are many obsolete or experimental codes. Those highlighted are the ones you are likely to see.
Table 22. ICMPv4 Codes
Code | Category | Used in ICMPv6? | Name | Comment |
0 | Informational | Echo Request | Ping probe | |
1 | Unassigned | |||
2 | Unassigned | |||
3 | Error | Yes | Destination Unreachable | |
4 | Error | No | Source Quench | Use deprecated by [RFC 1812] |
5 | Discovery | Yes | Redirect | |
6 | Informational | Alternate Host Address | ||
7 | Unassigned | |||
8 | Informational | Echo [Reply] | Ping response | |
9 | Discovery | Yes | Router Advertisement | Used by IRDP[1] |
10 | Discovery | Yes | Router Solicitation | Used by IRDP |
11 | Time Exceeded | |||
12 | Error | Yes | Parameter Problem | Mostly for IP developers |
13 | Information | Timestamp | ||
14 | Information | Timestamp Reply | ||
15 | Information | Information Request | ||
16 | Information | Information Reply | ||
17 | Information | Address Mask Request | ||
18 | Information | Address Mask Reply | ||
19 | Reserved (for Security) | |||
20 - 29 | Reserved (for Robustness Experiment) | |||
30 | Information | Experimental Traceroute | Standard traceroute uses UDP probe and echo reply | |
31 | Error | Datagram Conversion Error | Experimental | |
32 | Discovery | No | Mobile Host Redirect | |
33 | Information | No | IPv6 Where-Are-You | |
34 | Information | No | IPv6 I-Am-Here | |
35 | Information | TBD | Mobile Registration Request | |
36 | Information | TBD | Mobile Registration Reply | |
37 - 255 | Reserved |
[1]ICMP Router Discovery Protocol.
Your basic tools for active connectivity checking are ping and traceroute. Think of ping as an end-to-end test. It's not quite a Transport Layer test because it doesn't consider transport identifiers, but it is end-to-end as long as there are no tunnels, proxies, or address translators in the path.
ping sends out an echo request and expects to receive an echo reply. Most implementations send several consecutive pings and time each one. Cisco supports an extended ping, which allows you to vary IP parameters (e.g., packet length) and to test non-IP protocols such as IPX.
traceroute is hop-by-hop at the Network Layer. It uses different protocol mechanisms than ping, and relies on the TTL mechanism. traceroute information complements that given to you by ping. As with ping, Cisco supports an extended IP traceroute in which you can vary IP parameters.
traceroute generates UDP datagrams and encapsulates them in IP packets. The UDP packets don't have a predefined port, but Cisco starts with a number in the 33000 range. Cisco increments the port number on successive transmissions.
traceroute, in its first iteration, sets the TTL to 1, and the packet, as it should, triggers an ICMP TTL Exceeded message to be returned from routers one hop away. Cisco sends three such packets on each pass.
On the second iteration, traceroute sets the TTL to 2, and routers two hops away generate the ICMP response. In successive iterations, the TTL continues to be incremented until either the destination is reached or a hop count limit is reached.
traceroute may fail due to access lists rather than lack of connectivity. Access lists that cause it to fail include deny rules for high-numbered UDP ports. ping and traceroute both can fail because outbound ICMP is being denied. If inbound ICMP is denied, ping might fail but traceroute may work.
When a Cisco router receives a packet with a destination for which it has no matching route table entry, it drops the packet and returns an ICMP Host Unreachable message to the source address.
If a host, or a router that is the destination address for a packet, receives a packet with an unknown protocol ID or port number, it sends "unreachable" with the appropriate type code.
Table 23. ICMP Unreachable Codes
ICMP Code | Name | Sent by EndHost[1] | Explanation |
0 | net unreachable | Router | Router had no route to the destination subnet |
1 | host unreachable | Host | |
2 | protocol unreachable | Host | Unknown IP protocol number received at an end host |
3 | port unreachable | Host | Relevant TCP or UDP port not supported on the final destination host |
4 | fragmentation needed and DF set | Router | |
5 | source route failed | Router |
[1]Or router, when it is the endpoint.
Denial of service attacks may try to overwhelm your router with bogus packets. While under attack, you may want to disable or rate-limit unreachable messages:
interface e0/0 [no] ip unreachables
or
interface e0/0 ip icmp rate-limit unreachable [df] milliseconds
The most obvious special case is that the destination is not found in the FIB and there is no default route. In this case, the router creates an ICMP Destination Unreachable message and returns this to the originating host. The source address of this ICMP packet is that of the router interface that received it, and the destination address is that of the originator of the packet that could not be forwarded.
If a packet fails a filtering test, the default action prescribed in [RFC 1812] is to return an Internet Control Message Protocol (ICMP) Destination Administratively Prohibited message. This can be questioned both from a security and a performance standpoint, but it is the expected behavior. Figure 25 shows how filtering may be used to prevent this message from returning to the source.
Figure 25. Suppressing Destination Administratively Prohibited Messages
From the security view, returning the Destination Administratively Prohibited error message reveals to a potential attacker that there is something the router administrator has gone to the effort of protecting. This may make things interesting to the attacker, whereas returning a destination unreachable or simply timing out does not reveal the protected resource.
During the forwarding process, your router may detect a packet whose time to live (TTL) has expired. I have always liked this condition, as it sounds so much like a line from a movie about the Mob telling the router "Do what ya gotta do." The reasons for sending TTL exceeded are much more mundane.
Routers send Time to Live Exceeded messages when an outgoing IP header is being constructed and the TTL field is decremented and hits zero. TTL reaching zero is assumed to mean the packet is in an infinite loop.
Failure to reassemble all fragments after a packet has been fragmented is another reason to receive a Time to Live Exceeded message. This comes from end hosts, not routers, when a fragment reassembly timer expires. The timer is started after any fragment of the packet is received.
Don't fall into the trap of assuming that TTL expiration is always due to loops. Especially in routing protocols, setting the TTL to 1 is a perfectly good way to control the propagation of multicasts, keeping them link-local.
Available path information may cause a host to direct outgoing traffic to some specific router, but the router may know better and want the host to send subsequent traffic to some other router. In practice, this means that if the router realizes it is sending traffic back out the same interface on which it received the packet, it should redirect.
Redirection functions, as seen in Figure 26, allow network relays to send traffic to a different router.
Figure 26. Basic Redirection
That next router is accessible to the sending router because it is on the same medium as defined by the prefix. Since that second router is a better path to the destination than the original receiving router, the first router will send a redirect to the host informing it of the second path.
Note that redirection makes no sense on a point-to-point medium. It is most commonly used on broadcast media, but potentially could be used on nonbroadcast multiaccess media.
Redirection is on by default. If you know that there is no other router on the medium or you otherwise do not want redirection, you must disable it.
interface e0/0 no ip redirects
Until recently, redirection was incompatible with the Cisco Hot Standby Router Protocol (HSRP). Configuring HSRP on an interface still disables IP redirect, although there now is a way to make the two mechanisms work together.
In the interaction between standard ICMP and HSRP, the key problem is that ICMP must redirect to the virtual MAC address, not the real one of the currently active HSRP router. If that real address were used, and the HSRP router went down, the redirected packets would go into a black hole.
The HSRP support for the ICMP redirect feature intercepts ICMP redirects originated in a router before they actually leave the router. It examines the new next-hop feature and compares it to a list of active HSRP router real IP addresses. If the feature finds that the proposed next-hop address belongs to a real interface of an HSRP router, it changes the next-hop address to the virtual next hop associated with the HSRP group.
If there is no match, IOS next compares the destination address to the list of remaining routers. It will forward the packet to another router if, and only if, that router is not running HSRP. In other words, it will not redirect to an HSRP-enabled router that is in HSRP standby. For this reason, the most efficient design is one in which every router on the subnet is the active router in at least one HSRP group.
IPv6 has its own version of ICMP, which includes some extremely important new types used for neighbor discovery.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Message Body + | |
Figure 27. ICMPv6 Header
Notice that the ICMPv6 header does have a checksum, while the IPv6 header does not. ICMPv6 is Option Type 58.
Table 24. ICMPv6 Message Types
Type | Category | Meaning |
1 | Error | Destination Unreachable |
2 | Error | Packet Too Big |
3 | Error | Time Exceeded |
4 | Error | Parameter Problem |
128 | Informational | Echo Request |
129 | Informational | Echo Reply |
133 | Discovery | Router Solicitation |
134 | Discovery | Router Advertisement |
135 | Discovery | Neighbor Solicitation |
136 | Discovery | Neighbor Advertisement |
137 | Discovery | Redirect |
Discovery Mechanisms
IPv6 no longer uses an explicit ARP. Instead, it has a set of five ICMPv6 messages that cover the IPv4 functions of ARP, IRDP, and redirect [RFC 2461]. These mechanisms, generically called discovery, provide a new way to detect if a neighbor on the same subnet is down. This neighbor unreachability mechanism also provides a fast way to learn if a router is down.
Table 25. IPv6 Discovery Messages
Message Type | Closest IPv4 Equivalent | Usage |
Router Solicitation | ICMP/IRDP Solicitation | When an interface becomes enabled, hosts may send out Router Solicitations that request routers to generate Router Advertisements immediately rather than at their next scheduled time. |
Router Advertisement | ICMP/IRDP Advertisement | 1. Sent unsolicited at periodic intervals. 2. Sent in response to Router Solicitation. Router Advertisements contain prefixes that are used for on-link determination and/or address configuration, a suggested hop limit value, etc. |
Neighbor Solicitation | ARP Request (1) ICMP Echo Request (2) | (1) Sent by a node to determine the Link Layer address of a neighbor. (2) Sent to verify that a neighbor is still reachable via a cached Link Layer address. Neighbor Solicitations are also used for duplicate address detection. |
Neighbor Advertisement | ARP Reply ICMP Echo Response | A response to a Neighbor Solicitation message. A node may also send unsolicited Neighbor Advertisements to announce a Link Layer address change. |
Redirect | ICMP Redirect | Used by routers to inform hosts of a better first hop for a destination. |
Address Resolution in IPv6
IPv6 replaces ARP and certain uses of Echo with the Neighbor Solicitation message. This is multicast to the solicited-node multicast address associated with the target address. It includes the sender's Link Layer address, so the recipient can resolve the IPv6 address of the sender.
The recipient, when present, returns a unicast Neighbor Advertisement that contains its Link Layer address.
Because the Neighbor Solicitation is multicast, it can detect whether multiple nodes have been assigned the same address. In IPv4, this requires pinging the address with echo packets.
Discovery uses only the low-order, link-local part of IPv6 addresses, so site-level renumbering will not affect any current address caches.
Half-Link Handling in IPv6: Neighbor Unreachability Detection
An upper-layer protocol, if it has the necessary interface to IPv6, can start Neighbor Unreachability Detection by hinting to IPv6 that it isn't hearing acknowledgements or other traffic that would suggest a node is up. If IPv6 receives higher-layer confirmation, it doesn't attempt Neighbor Unreachability Detection.
If there are no such hints, the node periodically sends unicast Neighbor Solicitations to all the neighbors to which it is actively sending traffic. Failure to receive the corresponding Neighbor Advertisement indicates a problem. By comparing the unreachability detection of the two nodes, you will quickly find out if one node is dead, if the solicitations are not getting to the target, or if the advertisements are not getting to the originator.
Table 26. Link-Local Control Mechanisms in IPv4 and IPv6
Function | IPv4 | IPv6 |
Host finding best exit | Passively listens to routing | Router Discovery |
Changed sub-IP address | New ARP | Router Advertisement |
Finding prefix length | Configuration, ICMP Mask Request | Router Advertisement |
Information for autoconfiguration[1] | N/A | Router Advertisement |
Consistent MTU | If coded in DHCP | Router Advertisement |
Sub-IP resolution after redirect | ARP | Redirect |
Multiple prefixes for link | Secondaries | Router Advertisements followed by redirects[2] |
Neighbor unreachability | No IPv4 proper; router hellos | Neighbor Discovery[3] |
Address resolution security | None | IPSec on ICMP |
[1]Other than DHCP.
[2]Multiple prefixes can be associated with the same link. By default, hosts learn all on-link prefixes from Router Advertisements. However, routers may be configured to omit some or all prefixes from Router Advertisements. In such cases hosts assume that destinations are off-link and send traffic to routers. A router can then issue redirects as appropriate. Unlike the case for IPv4, the recipient of an IPv6 redirect assumes that the new next hop is on-link. In IPv4, a host ignores redirects specifying a next hop that is not on-link according to the link's network mask. It is expected to be useful on nonbroadcast and shared media links in which it is undesirable or not possible for nodes to know all prefixes for on-link destinations [RFC 2461].
[3]Neighbor Unreachability Detection is part of the base significantly improving the robustness of packet delivery in the presence of failing routers, partially failing or partitioned links, and nodes that change their Link Layer addresses. For instance, mobile nodes can move off-link without losing any connectivity due to stale ARP caches [RFC 2461].
DHCP is the descendant of BOOTP, which is obsolete. DHCP servers have typically been on hosts, but as of IOS 12.0(1)T, Cisco routers can act as DHCP servers. Check to see if your specific router platform has this capability.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op (1) | htype (1) | hlen (1) | hops (1) | +---------------+---------------+---------------+---------------+ | xid (4) | +-------------------------------+-------------------------------+ | secs (2) | flags (2) | +-------------------------------+-------------------------------+ | ciaddr (4) | +---------------------------------------------------------------+ | yiaddr (4) | +---------------------------------------------------------------+ | siaddr (4) | +---------------------------------------------------------------+ | giaddr (4) | +---------------------------------------------------------------+ | | | chaddr (16) | | | | | +---------------------------------------------------------------+ | | | sname (64) | +---------------------------------------------------------------+ | | | file (128) | +---------------------------------------------------------------+ | | | options (variable) | +---------------------------------------------------------------+
Figure 28. DHCP Message
What do these fields mean, especially those with rather cryptic names like giaddr?
Table27. DHCP Packet Field Usage
Field | Usage |
op | Message op code / message type. 1 = BOOTREQUEST, 2 = BOOTREPLY |
htype | Hardware address type, see ARP section in "Assigned Numbers" RFC; e.g., '1' = 10mb Ethernet |
hlen | Hardware address length (e.g. '6' for 10mbethernet) |
hops | Client sets to zero; optionally used by relay agents when booting via a relay agent |
xid | Transaction ID, a random number chosen by the client; used by the client and server to associate messages and responses between a client and a server |
secs | Filled in by the client; seconds elapsed since client began address acquisition or renewal process |
flags | Flags (see Table 2) |
ciaddr | Client IP address; only filled in if client is in BOUND, RENEW, or REBINDING state and can respond to ARP requests |
yiaddr | 'your' (client) IP address |
siaddr | IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK by server |
giaddr | Relay agent IP address; used in booting via a relay agent |
chaddr | Client hardware address |
sname | Optional server host name; null terminated string |
file | Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER |
options | var Optional Parameters field |
DHCP Protocol Operation
Figure 29 shows the basic timeline of DHCP operation.
Server Client Server (not selected) (selected) v v v | | | | Begins initialization | | | | | _____________/|\____________ | |/DHCPDISCOVER | DHCPDISCOVER \| | | | Determines | Determines configuration | configuration | | | |\ | ____________/ | | \________ | /DHCPOFFER | | DHCPOFFER\ |/ | | \ | | | Collects replies | | \| | | Selects configuration | | | | | _____________/|\____________ | |/ DHCPREQUEST | DHCPREQUEST\ | | | | | | Commits configuration | | | | | _____________/| | |/ DHCPACK | | | | | Initialization complete | | | | . . . . . . | | | | Graceful shutdown | | | | | |\ ____________ | | | DHCPRELEASE \| | | | | | Discards lease | | | v v v
Figure 29. DHCP Operational Timeline
Most DHCP servers support two modes of operation. In the first, more common mode, the address is automatically assigned and has a lease time. In other words, it is a soft-state protocol. It is possible to make this semi-soft by specifying an infinite lease time for certain client IDs.
The other mode of operation, typically used for servers, ensures that a given client ID will always get the same address, either with a very long-term or infinite lease. While such hosts could be manually configured, it's simpler to administer all your servers if you centralize their address assignment onto the DHCP server.
IOS-Based DHCP Servers and Their Capabilities
Router-based DHCP servers may need access to address binding information on another machine, which is retrieved with FTP, RCP, or TFTP. You can have more than one such database agent. When you configure Cisco DHCP, you need to decide if you will use a DHCP database agent. If so, enter the command
ip dhcp database url [timeout seconds | write-delay seconds]
If you will not use a database agent but will keep all information on the router, turn off conflict logging.
no ip dhcp conflict logging
DHCP, of course, can provide more than just the client's own address.
Table 28. Cisco-Supported DHCP Options
DHCP Option Name | Function |
(Local) Domain Name | The domain name to use in resolving partial hostnames. |
DHCP Message Type | DHCPDISCOVER DHCPOFFER DHCPREQUEST DHCPDECLINE DHCPACK DHCPNAK DHCPRELEASE DHCPINFORM |
DNS | Gives a client a list of DNS name servers, typically in order of preference. |
Hostname | Tells the host what DNS name to use. This may be a fully qualified domain name or relative to the local domain. |
IP Address Lease Time | The client's requested lease time. The DHCP server returns the lease time it is granting. |
NetBIOS over TCP/IP Name Server | Gives the client a list of NetBIOS name servers, in order of preference. |
NetBIOS over TCP/IP Node Type | Tells the client if it is a B, P, M, or H node (see [RFC 1001; RFC 1002] ) |
Rebinding (T2) Time | Maximum time from address assignment until the client transitions to the REBINDING state. If no DHCPACK (from the RENEWING state transition) arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to any DHCP server to extend its lease. |
Renewal (T1) Time | Maximum address assignment until the client must send a DHCPREQUEST to extend its lease. |
Router | Gives the client a list of the IP addresses on its subnet. These are usually listed in order of preference. Remember that you can give the virtual address of a group of HSRP routers. |
Server Identifier | IP address of the DHCP server issuing the message. |
Subnet Mask | Tells the client what subnet mask to use. |
Setting Up Dynamic Address Pools
The mandatory parts of setting up an address pool are:
ip dhcp excluded-address low-address [high-address] ip dhcp pool name
You are now in DHCP configure-pool mode. It is mandatory to establish the address pool from which assignments are made.
network network-number [mask | /prefix-length]
You will probably want to configure the lease time, but if you don't, the lease time will default to one day.
lease {days [hours][minutes] | infinite}
While you are still in DHCP address pool configuration mode, you can specify optional parameters for DHCP to send to the client.
domain-name domain dns-server address [address2 ... address8] netbios-name-server address [address2 ... address8] netbios-node-type type default-router address [address2 ... address8]
Setting Up Static Address Assignment from DHCP
What if you want to set up fixed rather than dynamic addresses?
ip dhcp pool name host address [mask | /prefix-length]
Now specify the way the server will identify the specific host requesting the address. You can use either its MAC address or a unique identifier programmed into the host.
hardware-address hardware-address type ! or client-identifier unique-identifier
You can set optional parameters, such as domain name, as you did for dynamic assignment. Optionally, specify the client name, which will become the low-order part of the fully qualified domain name. For example, if you specified the default domain as certificationzone.com, and if you put lab as the parameter of the client name command, the host would have the FQDN of lab.certificationzone.com.
client-name name
DHCP Relay Agents: General and IOS Implementation
DHCP relay agents forward DHCP client requests received on one of their interfaces toward a DHCP server. DHCP proxies are themselves clients that work through an intermediate Layer 1/2 facility such as a cable modem or PPP dial-up to obtain an address for the router itself.
Let's talk first about the basic behavior of a DHCP relay -- or, more precisely, a BOOTP relay, since that is where the mechanism was first defined [RFC 1542]. I'll describe the most common usage; there are special cases you can see in the RFC, such as a device that has an IP address but still uses the DHCP server to obtain option information.
You enable relaying by configuring an appropriate ip helper statement on the interface.
When the relay agent sees a DHCPREQUEST with a broadcast destination address, it first examines the Gateway Address field (giaddr) and fills it with the IP address of the interface on which the broadcast DHCPREQUEST was received. This will let the DHCP server return it to the relay interface. The DHCPREQUEST packet is now forwarded to the destination address in the IP helper.
The DHCP server fills in the yiaddr field with the assigned IP address of the requesting client, and adds Option fields as required.
After the router containing the relay agent receives the DHCPREPLY, it uses the giaddr field to tell which internal interface should receive the packet. At that interface, the relay examines the Layer 2 address information in the combination of htype, hlen, and chaddr fields. It constructs a Layer 2 frame using chaddr as the destination address and its own Layer 2 address as the frame-level source address, and unicasts it to the requesting client.
The DHCP server in IOS has no mass storage and can service only a limited number of requests. It can, however, forward unsatisfied requests to secondary, host-based DHCP servers listed in ip helper commands.
When the Cisco DHCP relay agent observes several DHCP requests being retransmitted by the same client, it assumes the request is not being satisfied because the DHCP server being used is out of addresses. It will then change the Gateway Address (giaddr) field in the DHCP request and forward the request again. With a different giaddr, if the server has secondary address pools, the server will try to satisfy the request from a different pool. You can set up secondary pools on the IOS servers as well as on the database agents.
If all address pools in the router and on the agents are exhausted, the IOS DHCP server silently drops the address request.
Before the actual address is assigned, the DHCP server pings the address to be sure it is not already present, producing an error message if this takes place. Most DHCP clients, as a final check, issue an ARP to their assigned address to see if anyone else answers.
You can either propose an address to use or request dynamic assignment of an address during PPP setup, specifically in the IP control protocol phase. After validation by CHAP (preferably) or PPP, the calling host can send a configuration request option on its IPCP message. If the calling host wants the called host to assign an IP address, the caller fills the Address field with zeroes. Otherwise, if the calling host wants to use a specific IP address, it puts that in the Address field, aware that it can be rejected.
The router can either directly allocate an address from a local pool or act as proxy to RADIUS or DHCP. A RADIUS server used in this manner can apply additional validation criteria.
Figure 30. IPCP Address Sources: Alternatives in Obtaining an Address for a PPP Client
IPv6 provides a way for interfaces to learn addresses dynamically, without an explicit address server. If you are familiar with the way addresses are assigned in AppleTalk or in the OSI Connectionless Network Protocol (CLNP), you will see distinct similarities.
You can use stateless configuration only on multicast-capable media.
Generate a link-local address by prefixing the well-known link-local prefix (FE80::/10) to its own identifier, which is usually the MAC address. The host is allowed to send a Router Solicitation in parallel with generating the address and to listen for the Router Advertisement in response. Parallel operation usually saves time in configuration.
Check that the same address is not already in use by sending a Neighbor Solicitation message to the tentative address. Typically, a host will retransmit that solicitation several times to be sure it is heard. If the address is in use, the neighbor will respond with a Neighbor Advertisement. On receipt of such an advertisement, the host is unable to autoconfigure under the standard protocol rules. It must be configured manually or by DHCPv6, unless implementation-specific steps have been taken to give the host an alternate identifier.
Assuming the tentative address is unique, the host now can communicate with other hosts on the same link. If no communication off the link is necessary, autoconfiguration is done.
If the host does expect to communicate with non-local addresses, it must find routers and change its prefix to one known within a wider scope. The information to do this is contained in Router Advertisement messages. These are multicast periodically, and the host may listen briefly to use one that is transmitted in a timely way. Otherwise, the host sends a Router Solicitation to the all-routers multicast group to trigger a new set of Router Advertisements.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O| Reserved | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-
Figure 31. Router Advertisement
A Router Advertisement is an ICMPv6 message and has the usual ICMP header with type code 134.
Table 29. Fields in Neighbor Advertisement Fixed Header
Field | Usage |
Cur Hop Limit | If nonzero, is to be inserted into the Maximum Hops field of packets generated by the host. |
M Bit | When the M bit is 1, the host must use stateful autoconfiguration (DHCPv6), using its link-local address. If the bit is 0, stateless autoconfiguration can continue. |
O Bit | When set, the O bit means that the host may do stateless autoconfiguration, but must use DHCPv6 to obtain configuration other than the address. |
Router Lifetime | Lifetime associated with the default router in seconds. The maximum value corresponds to 18.2 hours. A lifetime of 0 indicates that the router is not a default router and should not appear on the default router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own Lifetime fields. |
Reachable Time | The time, in milliseconds, for which a node assumes a neighbor is reachable after having received a reachability confirmation. Used by the Neighbor Unreachability Detection algorithm. |
Retrans Timer | The time, in milliseconds, between retransmitted Neighbor Solicitation messages. Used by address resolution and the Neighbor Unreachability Detection algorithm. |
Table 30. IPv6 Options Used in Discovery
Option | Function |
Authentication Header | If a Security Association for the IP authentication header exists between the sender and the destination address, then the sender should include this header. |
Source Link Layer address | The Link Layer address of the interface from which the Router Advertisement is sent. Only used on Link Layers that have addresses. A router may omit this option in order to enable inbound load sharing across multiple Link Layer addresses. |
MTU | Should be sent on links that have a variable MTU (as specified in the document that describes how to run IP over the particular link type). May be sent on other links. |
Prefix Information | Options that contain information used by stateless address autoconfiguration to generate site-local and global addresses. It should be noted that the stateless and stateful address autoconfiguration fields in Router Advertisements are processed independently of one another, and a host may use both stateful and stateless address autoconfiguration simultaneously. One Prefix Information Option field, the "autonomous address-configuration flag," indicates whether or not the option even applies to stateless autoconfiguration. If it does, additional Option fields contain a subnet prefix together with lifetime values indicating how long addresses created from the prefix remain preferred and valid. |
[IE-IPAS-WP1-F03]
[2006-02-14-00]
|