Introduction

Configuration

Testing

Summary

Introduction

The constant development of wireless networks forces network administrators to unceasingly upgrade their wired segments supporting operation of Wi-Fi. For now, during the usage of high speed access points, wired interfaces of access level switches begin to become a bottleneck, restricting the data transfer rates in a wireless segment. It seems incredible, but even a gigabit interface is occasionally not enough. However, the transition to the use of 10GE networks won't be considered justified for a long time as so far the speeds provided by Wi-Fi access points don't plan to cross this limit.

Foreseeing the aggravation of the situation in a wired segment in connection with the appearance of the devices with 802.11AC Wave 2 support, Cisco Systems, Inc. together with a number of other vendors founded NBASE-T alliance in 2014. The purpose of this organization became the development of Ethernet standards, that allow realizing data transfer at 2.5 and 5 Gbps, using the existing cabling infrastructure of 5e and 6 categories.

What does the appearance of the devices with "the second wave" of 802.11AC standard support threaten network administrators with? First, there will be an increase in the maximum theoretical data transfer rates to 6.8 Gbps. Of course, it is only a theoretical maximum (actual speeds will be traditionally half as high), moreover, achievable only when using the most efficient clients located in close proximity to the access point. The second improvement in 802.11AC Wave 2 standard is the support of MU-MIMO technology. Usage of MU-MIMO will allow distributing more effectively available bandwidth between several wireless clients working simultaneously. So, for example, the access point with 4x4 antenna configuration will be able to service two 2x2 clients at the same time, rather than sequentially, as it was before.

Both improvements available in 802.11AC Wave 2 will lead to a much higher utilization of the wired network segments. NBASE-T standards, enabling to prepare for implementation of the wireless equipment with support of IEEE 802.11AC Wave 2 with the minimum expenses, were developed to eliminate bottlenecks in modern L2-segments. Besides, existence of Power over Ethernet technology support, enabling to realize a remote powering of access points, surveillance cameras and other network equipment, should not be left unnoticed in NBASE-T.

Today in our test laboratory there is Cisco Catalyst WS-C3560CX-8XPD-S switch (IOS version 15.2 (6) E), with two multigigabit interfaces. The specified interfaces support the following transmission speeds: 100 Mbps, 1 Gbps, 2.5 Gbps, 5 Gbps and 10 Gbps. Of course, two multigigabit ports are not the only switch interfaces. 3560CX-8XPD model is equipped with six Gigabit Ethernet ports and also two connectors for SFP+ modules. All eight copper interfaces support PoE+ transmission, the switch's energy budget is 240W.

Configuration

Cisco 3560CX-8XPD Switch has four 10GE interfaces: Te1/0/1, Te1/0/2, Te1/0/7 and Te1/0/8, the two latter specifically have NBASE-T support.

fox_3560CX-8XPD#sho int status
Port Name Status Vlan Duplex Speed Type
Gi1/0/1 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/2 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/3 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/4 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/5 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/6 notconnect 1 auto auto 10/100/1000BaseTX
Te1/0/7 connected 1 a-full 100 100/1G/2.5G/5G/10GBaseT
Te1/0/8 connected 1 a-full 100 100/1G/2.5G/5G/10GBaseT
Te1/0/1 notconnect 1 full 10G Not Present
Te1/0/2 notconnect 1 full 10G Not Present

Multigigabit interfaces don't require any additional configuration – even speed can be determined automatically.

fox_3560CX-8XPD(config)#int te1/0/7
fox_3560CX-8XPD(config-if)#?
Interface configuration commands:
 aaa Authentication, Authorization and Accounting.
 access-session Access Session specific Interface Configuration Commands
 arp Set arp type (arpa, probe, snap) or timeout or log options
 auto Configure Automation
 auto Configure Automation
 bandwidth Set bandwidth informational parameter
 bfd BFD interface configuration commands
 bgp-policy Apply policy propagated by bgp community string
 carrier-delay Specify delay for interface transitions
 cdp CDP interface subcommands
 channel-group Etherchannel/port bundling configuration
 channel-protocol Select the channel protocol (LACP, PAgP)
 crypto Encryption/Decryption commands
 cts Configure Cisco Trusted Security
 dampening Enable event dampening
 datalink Interface Datalink commands
 default Set a command to its defaults
 delay Specify interface throughput delay
 description Interface specific description
 downshift link downshift feature
 exit Exit from interface configuration mode
 flow-sampler Attach flow sampler to the interface
 flowcontrol Configure flow operation.
 help Description of the interactive help system
 history Interface history histograms - 60 second, 60 minute and 72 hour
 hold-queue Set hold queue depth
 ip Interface Internet Protocol config commands
 ipv6 IPv6 interface subcommands
 isis IS-IS commands
 iso-igrp ISO-IGRP interface subcommands
 keepalive Enable keepalive
 l2protocol-tunnel Tunnel Layer2 protocols
 lacp LACP interface subcommands
 link Interface link related commands
 lldp LLDP interface subcommands
 load-interval Specify interval for load calculation for an interface
 location Interface location information
 logging Configure logging for interface
 mac MAC interface commands
 macro Command macro
 macsec Enable macsec on the interface
 mdix Set Media Dependent Interface with Crossover
 media-proxy Enable media proxy services
 metadata Metadata Application
 mka MACsec Key Agreement (MKA) interface configuration
 mls mls interface commands
 mvr MVR per port configuration
 neighbor interface neighbor configuration mode commands
 network-policy Network Policy
 nmsp NMSP interface configuration
 no Negate a command or set its defaults
 onep Configure onep settings
 ospfv3 OSPFv3 interface commands
 pagp PAgP interface subcommands
 power Power configuration
 priority-queue Priority Queue
 queue-set Choose a queue set for this queue
 rep Resilient Ethernet Protocol characteristics
 rmon Configure Remote Monitoring on an interface
 routing Per-interface routing configuration
 service-policy Configure CPL Service Policy
 shutdown Shutdown the selected interface
 small-frame Set rate limit parameters for small frame
 snmp Modify SNMP interface parameters
 source Get config from another source
 spanning-tree Spanning Tree Subsystem
 speed Configure speed operation.
 srr-queue Configure shaped round-robin transmit queues
 storm-control storm configuration
 subscriber Subscriber inactivity timeout value.
 switchport Set switching mode characteristics
 timeout Define timeout values for this interface
 topology Configure routing topology on the interface
 transmit-interface Assign a transmit interface to a receive-only interface
 tx-ring-limit Configure PA level transmit ring limit
 udld Configure UDLD enabled or disabled and ignore global UDLD setting
 vtp Enable VTP on this interface
fox_3560CX-8XPD(config-if)#speed ?
 100 Force 100 Mbps operation
 1000 Force 1000 Mbps operation
 10000 Force 10000 Mbps operation
 2500 Force 2500 Mbps operation
 5000 Force 5000 Mbps operation
 auto Enable AUTO speed configuration

There is no duplex setting for NBASE-T ports.

fox_3560CX-8XPD(config)#int gi1/0/1
fox_3560CX-8XPD(config-if)#du ?
 auto Enable AUTO duplex configuration
 full Force full duplex operation
 half Force half-duplex operation
fox_3560CX-8XPD(config-if)#int te1/0/7
fox_3560CX-8XPD(config-if)#du ?
% Unrecognized command

As for the Auto MDI/MDIX function operation, in this switch determination of the cable used is made regardless of the speed at which the interface functions.

When using auto negotiation the administrator can explicitly indicate what speeds are acceptable for negotiation. It is fair to say that similar setting is available for gigabit interfaces as well.

fox_3560CX-8XPD(config-if)#spe au ?
 100 Include 100 Mbps in auto-negotiation advertisement
 1000 Include 1000 Mbps in auto-negotiation advertisement
 10000 Include 10000 Mbps in auto-negotiation advertisement
 2500 Include 2500 Mbps in auto-negotiation advertisement
 5000 Include 5000 Mbps in auto-negotiation advertisement

We connected Te1/0/7 and Te1/0/8 interfaces using the patch cord. The output of some show commands is presented below.

fox_3560CX-8XPD#sho run int te1/0/7
Building configuration...
Current configuration : 59 bytes
!
interface TenGigabitEthernet1/0/7
 load-interval 30
end
fox_3560CX-8XPD#sho run int te1/0/8
Building configuration...
Current configuration : 71 bytes
!
interface TenGigabitEthernet1/0/8
 load-interval 30
 speed 5000
end
fox_3560CX-8XPD#sho int status
Port Name Status Vlan Duplex Speed Type
Gi1/0/1 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/2 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/3 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/4 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/5 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/6 notconnect 1 auto auto 10/100/1000BaseTX
Te1/0/7 connected 1 a-full a-5000 100/1G/2.5G/5G/10GBaseT
Te1/0/8 connected 1 a-full 5000 100/1G/2.5G/5G/10GBaseT
Te1/0/1 notconnect 1 full 10G Not Present
Te1/0/2 notconnect 1 full 10G Not Present
fox_3560CX-8XPD#sho int te1/0/7
TenGigabitEthernet1/0/7 is up, line protocol is up (connected)
 Hardware is Ten Gigabit Ethernet, address is 9c57.adb0.3487 (bia 9c57.adb0.3487)
 MTU 1500 bytes, BW 5000000 Kbit/sec, DLY 10 usec,
 reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation ARPA, loopback not set
 Keepalive set (10 sec)
 Full-duplex, 5000Mb/s, media type is 100/1G/2.5G/5G/10GBaseT
 input flow-control is off, output flow-control is unsupported
 ARP type: ARPA, ARP Timeout 04:00:00
 Last input 00:00:01, output 00:00:01, output hang never
 Last clearing of "show interface" counters never
 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: fifo
 Output queue: 0/40 (size/max)
 30 second input rate 0 bits/sec, 0 packets/sec
 30 second output rate 1000 bits/sec, 1 packets/sec
 538 packets input, 102715 bytes, 0 no buffer
 Received 325 broadcasts (325 multicasts)
 0 runts, 0 giants, 0 throttles
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
 0 watchdog, 325 multicast, 0 pause input
 0 input packets with dribble condition detected
 1622 packets output, 172091 bytes, 0 underruns
 0 output errors, 0 collisions, 1 interface resets
 0 unknown protocol drops
 0 babbles, 0 late collision, 0 deferred
 0 lost carrier, 0 no carrier, 0 pause output
 0 output buffer failures, 0 output buffers swapped out
fox_3560CX-8XPD#sho int te1/0/8
TenGigabitEthernet1/0/8 is up, line protocol is up (connected)
 Hardware is Ten Gigabit Ethernet, address is 9c57.adb0.3488 (bia 9c57.adb0.3488)
 MTU 1500 bytes, BW 5000000 Kbit/sec, DLY 10 usec,
 reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation ARPA, loopback not set
 Keepalive set (10 sec)
 Full-duplex, 5000Mb/s, media type is 100/1G/2.5G/5G/10GBaseT
 input flow-control is off, output flow-control is unsupported
 ARP type: ARPA, ARP Timeout 04:00:00
 Last input 00:00:01, output 00:00:09, output hang never
 Last clearing of "show interface" counters never
 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: fifo
 Output queue: 0/40 (size/max)
 30 second input rate 0 bits/sec, 0 packets/sec
 30 second output rate 0 bits/sec, 0 packets/sec
 1626 packets input, 172811 bytes, 0 no buffer
 Received 1413 broadcasts (1397 multicasts)
 0 runts, 0 giants, 0 throttles
 4 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
 0 watchdog, 1397 multicast, 0 pause input
 0 input packets with dribble condition detected
 561 packets output, 104187 bytes, 0 underruns
 0 output errors, 0 collisions, 1 interface resets
 0 unknown protocol drops
 0 babbles, 0 late collision, 0 deferred
 0 lost carrier, 0 no carrier, 0 pause output
 0 output buffer failures, 0 output buffers swapped out
fox_3560CX-8XPD#

Before we proceed directly to the performance testing, we decided to connect the access point with PoE support to Te1/0/7 interface and provide our readers with some diagnostic information.

fox_3560CX-8XPD#sho power inline tenGigabitEthernet 1/0/7
Interface Admin Oper Power Device Class Max
 (Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Te1/0/7 auto on 15.4 Ieee PD 4 30.0
Interface AdminPowerMax AdminConsumption
 (Watts) (Watts)
---------- --------------- --------------------
Te1/0/7 30.0 15.4
fox_3560CX-8XPD#sho lldp ne de
fox_3560CX-8XPD#sho lldp ne detail
------------------------------------------------
Local Intf: Te1/0/7
Chassis id: b8ec.a3ac.5c19
Port id: 1
Port Description: UPLINK
System Name: WAC6103D-I
System Description:
Linux
Time remaining: 118 seconds
System Capabilities: B,W,R
Enabled Capabilities: B,W,R
Management Addresses:
 IP: 192.168.1.2
Auto Negotiation - not supported
Physical media capabilities - not advertised
Media Attachment Unit type - not advertised
Vlan ID: - not advertised
Total entries displayed: 1
fox_3560CX-8XPD(config)#int te1/0/7
fox_3560CX-8XPD(config-if)#po
fox_3560CX-8XPD(config-if)#power ?
 inline Inline power configuration
fox_3560CX-8XPD(config-if)#power i
fox_3560CX-8XPD(config-if)#power inline ?
 auto Automatically detect and power inline devices
 consumption Configure the inline device consumption
 never Never apply inline power
 police Police the power drawn on the port
 port Configure Port Power Level
 static High priority inline power interface

At that the chapter, related to the configuration of multigigabit interfaces, came to an end.

Testing

In this section we want to provide our readers with the results of the switch’s performance tests not only when using multigigabit interfaces, but also using "standard" ports. As a traffic generator IXIA hardware and software system was used. We decided to begin with performance measurement (a bandwidth, a latency and a jitter) of 3560CX-8XPD model executing switching with the use of Gigabit Ethernet interfaces. Measurements were made for frames of different length. During these tests we didn't detect packet losses (excluding IPv6 routing test), therefore we decided not to include this diagram in the article.

Since Cisco Catalyst 3560CX-8XPD model has the feasibility to execute not only switching of Ethernet frames, but also IP packets routing, we decided not to leave this feature without attention.

It can be seen from the diagrams above that the device performance in case of L2 functions execution has much in common with L3 functions execution.

Performance measurement of the switch in case of connection to its 10GE optical ports also in L2 and L3 modes became the next stage.

The switch under test can execute not only routing of IPv4 traffic, but also IPv6. Naturally, we didn't disregard such an opportunity.

It should be noted that when routing 72 bytes packets 0.029% packet loss was observed. The value of losses is small, however we have considered it necessary to mention that.

We approached, perhaps, the most interesting part of this section – switch’s performance measurement using NBASE-T ports. The traffic generator was connected to optical interfaces of the switch (10GE). Multigigabit interfaces were connected to each other with a 0.5 meters patch cord. On the diagrams below a bandwidth, a latency and a jitter for all speeds supported by the interfaces are presented. When plotting the graphs of a latency and a jitter dependence on the packets size we, naturally, considered that frames pass the switch twice in this diagram.

In conclusion of this chapter we would like to provide our readers with the same dependences, but without the use of the switch, that is in a case when traffic generator ports are connected directly to each other.

That's where we draw the testing chapter to a close and move on to summing it all up.

Summary

In this article we considered copper multigigabit interfaces through the example of Cisco Catalyst 3560CX-8XPD compact switch, which has two ports with support of NBASE-T. The use of NBASE-T interfaces will allow updating the existing wired network segments with the minimum expenses and to be prepared for the deployment of the next generation IEEE 802.11AC Wave 2 wireless networks. NBASE-T usage allows increasing significantly the performance of the wired segments without a cable infrastructure replacement. Support of "standard" GE and 10GE speeds by the multigigabit interfaces will allow carrying out changeover of the equipment as smoothly and consistently as possible.

It is also worth noting that the introduction of the new standards with the "intermediate" speeds happened not only in a world of copper network interfaces with RJ45 (8P8C) connectors, but also in the segment of optical networks. An example is Cisco Nexus 3232C switch with high port density, carrying 32 fixed 100GE QSFP28 format interfaces, which allows providing support of the following speeds for optical interfaces: 10G/25G/40G/50G/100G. However that's quite a different story.

Overview

Power over IP (PoIP) – the technology allowing the remote device to transmit electrical energy along with the data over a single twisted pair cable. This technology is designed for various sensors, intelligent relays, ZigBee transmitters and other wireless technologies with the super-low energy consumption to which for any of several reasons it is undesirable or impossible to conduct a separate electrical cable. It is assumed that the Power over IP technology will be the most demanded for construction of the distributed sensor networks, and also for IoT support (Internet of Things).

The PoIP technology is currently under development, the publication of the first version of a standard draft is under construction, however a number of companies are already preparing for pilot use of the technology being developed in their equipment. Among the vendors actively involved in the development of prototype devices with PoIP support are: ARM, Cisco, Intel, ASUS, Broadcom, Realtek and STMicroelectronics.

Equipment and working principle

The PoIP technology doesn't affect the quality of the transmitted data. Transmission of energy is made by means of properties of the physical Ethernet layer. The main difference of PoIP from PoE (Power over Ethernet) is that PoE uses so-called out of band transmission of energy whereas a power of PoIP devices is made by means of the energy transferred by a signal itself.

For the operation the PoIP technology requires 10Base-T (IEEE 802.3) Ethernet support in the full-duplex mode from the switching equipment. It is worth noting that the recommended switch setup is automatic detection of speed and duplex though also manual configuring isn't forbidden. All equipment with support of PoIP shall support also automatic cabling (Auto MDI / MDIX). The 10Base-T standard defines a voltage value of ± 2.5 V for the transmitting pair, which together with a maximum current of 250 mA allows the device to operate at a power up to 0.5 Watts. The 10Base-T Ethernet standard supports cable segments up to 100 meters long, however when using PoIP it should be taken into account that in case of transmission of energy via the twisted pair cable there is a significant power loss depending on the distance and thickness of the conductor therefore in case when PoIP devices are connected it is recommended to use short and thick cables. Typically, the conductor's thickness for the twisted pair cable is specified in AWG (American Wire Gauge). In the table below compliance of thickness of a cable given in AWG to cross-sectional area of the conductor for solid and stranded cables is shown.

AWG Cross-section area, mm2
Solid Stranded
22 0,325 0,327-0,352
24 0,205 0,201-0,226
26 0,128 0,14-0,153

The resistivity of copper is approximately 17mOhm*mm2/m, that is the solid twisted pair cable 24 AWG 100 meters long will have resistance more than 16,5 Ohms. Thus, the maximum power which the PoIP device in this case can "expect" won't exceed 0,2 Watts.

In case your network is under congestion, UDP as a transport looks inappropriate for energy delivery, because of its unreliable nature. In this case, one should use unicast and TCP as a reliable transport protocol. To improve PoIP efficiency you need to use jumbo frames, because you can’t take advantage of any headers in PoIP process.

Until now we spoke only about a "client" part of PoIP technology. However the switch itself won't supply the devices connected to it with energy even of 0.5 Watts. In order the energy transmission was carried out, the flow of specially created traffic is necessary. Any device with IPv4 support can generate and transfer such traffic. For security reasons, and also to reduce the load on the network infrastructure, the equipment generating a traffic must be located in one local segment with PoIP clients. Reduction of network load happens also due to use of multicast. In case of each start and during an operating time in an automatic mode the choice of the most optimum traffic profile (pattern) allowing to maximize the energy received by clients is made. If for any reason the optimum traffic profile for one of devices differs from coordinated for remaining devices on this network, then for such client generation of unicast is allowed.

High availability

All PoIP clients shall register on all local generators and report to them about optimum traffic patterns. However at each moment sending a traffic is made by only one generator. All remaining generating devices are also joined for receiving a flow from the active source. The group traffic flow from the active source performs also the keepalive functions. In the absence of traffic flow during 50 msec the role of the active device takes over the equipment with the highest priority. The priority can assume values from 1 to 255, by default – 100.

Client PoIP device shall possess the built-in rechargeable battery and be capable to endure short-time miss of IP traffic flow.

Vendors

At the time of the publication three companies reported about development of the module generating IP traffic: ASUS, Cisco and Intel.

The ASUS company began to build in the traffic generator to top models of the routers. Control is made by means of the hidden PoIP gen tab of Network Utilities menu item.

 

All industrial routers, and also L3 switches of the Cisco Systems company working under control of the IOS (starting with the version 15.6(2)T), IOS XE (from version 16.04.01 Everest) and IOS XR (from version 6.1.3), possess a set of the hidden commands allowing to turn on the built in generator. PoIP support for NX-OS series switches is not planned.

cisco#sho poip ?
% Unrecognized command
cisco#sho poip devices
Capability codes:
    (G) Generator, (P) Probe, (L) LED, (W) WLAN Access Point
    (R) Relay, (S) Station, (B) Beeper, (O) Other
Device ID                          Hold-time  Capability      Port ID       IP Address
fox_temp_sensor_test1              50         P,R             Gi1/0/10      192.168.1.114
fox_humidity_probe_test1           50         P               Gi1/0/12      192.168.1.112
fox_alarm_test                     50         L,B             Gi1/0/24      192.168.1.140
fox_poip_gen                       50         G,S             Te1/0/4       192.168.1.1
Total entries displayed: 4
cisco#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
cisco(config)#poip ?
% Unrecognized command
cisco(config)#poip test
cisco(config-poip)#?
Configure commands:
  access-class                Filter client devices based on an IP access list
  authentication              Auth Manager PoIP Configuration Commands
  bandwidth                   Set max bandwidth to utilize
  default                     Set a command to its defaults
  description                 PoIP instance specific description
  interface                   Select an interface to support
  logging                     Handles logging operations
  mode                        PoIP operating mode
  network-policy              Network Policy
  password                    Secret key for MD5 authentication
  pattern                     Configure a packet pattern
  preempt                     Overthrow lower priority Active generators
  priority                    Priority level
  shutdown                    Shutdown this instance of PoIP
  static                      Define a static PoIP client
  timer                       Hold timer
  track                       Priority tracking
  version                     PoIP version

The utility of Intel company – Intel PoIP Gen, on announcement of the vendor, completely corresponds to RFC3251 (Electricity over IP) and at the moment passes a stage of internal testing, remaining unavailable to ordinary users.

Future of the standard

At the moment as a physical medium the twisted pair Ethernet cable is used. Also support of fiber optic and wireless connections is put in road-map if it is  possible to reduce energy consumption of devices even more.

The standard draft assumes a possibility of connection of PoIP device by means of two twisted pair cable for doubling of the energetic budget.

Also among innovations support of upcoming version of the IP protocol – IPv6 is declared.

Appearance of more energy efficient client devices on the basis of SoC with the low power consumption will allow expanding in the near future a scope of Power over IP technology considerably.

Introduction

Protocol purpose and main principles of its work

Configuration of equipment

The process of assigning IP address

Secondary subnet

Additional options: relay

Additional options: option 82, snooping

Additional options: import of parameters

Additional options: VRF support

DHCP and routing

Conclusion

Introduction

Behind the seeming simplicity of DHCP, a large set of opportunities, about which network administrators often don’t even know, is hidden. In this article we will not study all opportunities of the protocol in detail, however, immerse into some interesting ones. We don’t claim the fullest review of theoretical aspects, which the reader can find in any specialized literature. Here we’d like to emphasize that despite the fact of review DHCP working (RFC2131) mainly on Cisco devices, most of the parameters are also available on switches and routers of other vendors. Also we’d like to mention that the article in question is aimed at a wide audience of readers, so we will start from the simplest or even elementary things, however, hope that we won’t scare away more advanced reader.

Okay, let’s get started!

Protocol purpose and main principles of its work

DHCP (Dynamic Host Configuration Protocol) is intended for centralized IP parameters managing of end user equipment. Certainly, one is not forbidden from using DHCP for configuring servers or network equipment, but more often static configuration, which is considered to be more predictable, is used in such cases. We intentionally mentioned that the protocol is used for managing exactly IP parameters because many network administrators have a wrong stereotype that client-server protocol DHCP is limited by setting IP address only. IP address is only one of the parameters which can be configured with the help of the protocol in question. Which other parameters can be provided to a host? Among them (but this is not the whole list) are the following (RFC1533 and RFC2132): subnet mask, default gateway, addresses of DNS and WINS servers, domain name and name of the host itself, routes to particular subnets, time zone and address of time server, boot image address, TTL and MTU, addresses of POP3 and SMTP servers, address lease time. Not all options can be used or supported by the client or server, but often DHCP clients and servers support rather wide set of options.

Receiving of IP parameters is performed with the help of four messages which the client and server exchange.

 

DHCP discover message is sent by the client for discovering DHCP server in the local network segment. Looking ahead, we mention that modern topologies don’t mean direct connecting a server to each virtual network (VLAN) in which client hosts are placed. Instead of this, a special relay is used, which we’ll discuss a bit later.

After receiving DHCP discover message, DHCP servers reply to the client with DHCP offer message containing the offering parameters. The client received several such offers can choose one the most satisfying among them. To tell the truth, usually the first received DHCP offer is chosen. It’s worth noting that at this moment the server reserves the offered IP address for the client for only a short period of time, and if the client doesn’t request its using, the server will release the address for the further use (return it to the pool).

Having chosen one of the offers, the client sends broadcast DHCP request to the server for assigning the offered parameters. Before receiving an acknowledgment from the server, the client is not in the right to use the chosen IP address. The broadcast message is used here also to notify other servers that their offers are not considered, that will allow them to return address to the pool more quickly.

The server received DHCP request message sends to the client DHCP ack message that acknowledges the client’s right on using the provided IP address. It’s worth noting that in some cases the server can reject a client’s request on using the address. This situation may occur, for example, in case when the server provided another client with the IP address in question or reconfiguration of the DHCP-server was performed. If the server cannot acknowledge using of earlier offered parameters, it sends DHCP nack message to the client.

One of the necessary options sent to the client by the server is IP address lease time. This parameter specifies time interval during which the client is in right to use the provided IP parameters. After this time is over, the client has to release the used IP address or perform its extension. If the client is going to release the using IP address, DHCP release message is sent. After receiving this message, the server returns IP address belonged to the client to the pool of free addresses.

For our readers we prepared traffic dump containing the procedure of IP address getting and release by the host. All dump files from this article can be opened with the help of network analyzer Wireshark. We strongly recommend exploring in detail all fields in all packets containing in the file. One can filter DHCP messages in a bulk dump using Wireshark with the help of “bootp” display filter.

Packets from the first to the forth inclusive contain a standard procedure of getting IP parameters. In the packets 5, 6 and 7, DHCP release message noting the server about an early termination of the lease was sent by the client.

How does the server notify the client for which time IP address is provided? As all in DHCP, this information is provided in the packet as an option (option #51). Besides this, DHCP has two timers usually named T1 (renewal) and T2 (rebinding) providing by the options 58 and 59 correspondingly. T1 timer is usually equal to the half of lease time and T2 corresponds to 7/8 of lease time. For which purposes are these timers used? If T1 time interval is over after receiving DHCP ack message, the client starts the procedure of renewing IP parameters and repeats request to the server for the right to use them. If no changes occurred, the server enables extension of lease time by sending DHCP ack message. If the server doesn’t answer the request for lease extension for any reason, after T2 time interval is over, broadcast sending of DHCP request message is performed, with the help of which the client tries to find a server that is able to extend the lease of IP parameters received earlier. If this attempt is unsuccessful, at the end of lease time the client has to release received IP address.

In the previous example the server sets lease time equal to seven days. We decreased lease time to one minute and captured the process of DHCP messages exchange. From the list of packets below, one can see that almost each 30 seconds the client sends DHCP request message requesting for the acknowledgement to use received addresses from the server. Answering to this message, the server sends DHCP ack packet. For example, pairs of packets 5-6, 7-8 and 9-10 are successful attempts of lease extension. Packet #11 contains DHCP request message for which acknowledgement from the server was not received. So the client sends broadcast DHCP request (packet #12) for which (in our example) acknowledgment was not received too. Packets #13-17 contain standard DHCP discover messages sent after the host refused from the used IP address.

The picture below shows content of DHCP offer packet containing all three timers.

If the client is Cisco router, the following messages are shown in log at the moment of ending the lease.

R1#*Aug 11 21:16:12.743: %DHCP-5-RESTART: Interface GigabitEthernet0/0 is being restarted by DHCP
R1#*Aug 11 21:16:14.815: %LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to administratively down
R1#*Aug 11 21:16:15.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
R1#*Aug 11 21:16:17.847: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
R1#*Aug 11 21:16:18.847: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up

We also cannot ignore the first message sending by the client – DHCP discover. Option #55 (Parameter Request List) contains the list of options interesting for an end device. The picture below displays such a list generated by Cisco 7206VXR (NPE400) router with the operating system IOS of 15.2(4)M8 ADVENTERPRISEK9 version, performing functions of DHCP client.

The list of requested options is not static, its content depends on the type and configuration of the end device. So, for example, for the client based on Windows 7 x64 operating system the list is a bit different and shown below.

Strictly speaking, one cannot fully identify a client based on the list of requested parameters, but, nevertheless, operating system and using software leave some fingerprint in DHCP messages according to which it’s possible to approximately identify which client is used. We will not describe all possible fingerprints here, but specify some of the most interesting ones. So, for example, Cisco router includes brief information about itself to the option #61. Option #12 contains name of the requesting host. Perhaps, it’s worth noting that among the opportunities provided by Cisco ISE system, there is a function for identifying an operating system used by the client, but discussing the questions of this system working is far out of the article’s scope.

DHCP client built in Microsoft Windows 7 x64 operating system also sends some information about itself according to which it can be identified with the help of the option #60 (Vendor class identifier).

In addition to already described messages of DHCP, there is one more that we didn’t mention yet – DHCP information. With the help of it the client can request additional information which was not sent by the server in DHCP offer message.

That’s where we proceed to completion of the review of the main aspects of DHCP operating and pass directly on to its configuration.

Configuration of equipment

To configure using of DHCP on the client side is usually not very difficult. For instance, in case of using Microsoft Windows 7 operating system, the only thing that should be performed is selecting “Get IP address automatically” option in IPv4 protocol settings.

To make sure of successful receiving the address with the help of GUI is also not difficult.

One can get the information about current configuration of the computer network cards in modern Microsoft Windows operating systems with the help of ipconfig /all command.

C:\>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : torrent
Primary Dns Suffix  . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : Beeline.Gate
Ethernet adapter LAN 2:
Connection-specific DNS Suffix  . : Beeline.Gate
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT NIC
Physical Address. . . . . . . . . : 00-0C-29-CD-86-26
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 10.0.1.112(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 13 Aug 2015 21:20:01
Lease Expires . . . . . . . . . . : 14 Aug 2015 21:20:01
Default Gateway . . . . . . . . . : 10.0.1.5
DHCP Server . . . . . . . . . . . : 10.0.1.5
DNS Servers . . . . . . . . . . . : 8.8.8.8
Primary WINS Server . . . . . . . : 10.0.1.5
NetBIOS over Tcpip. . . . . . . . : Enabled

Administrator can refuse from the assigned address and request a new one via ipconfig /release and ipconfig /renew commands. It’s also worth noting that in the specified set of operating systems there is a rather powerful network utility netsh, with the help of which one can view and change parameters of network cards working. So, for example, one can get information about using IPv4 addresses with the help of netsh interface ipv4 show addresses command.

Modern SOHO routers allow connecting to a provider obtaining IP parameters dynamically. The pictures below show typical settings for connection to the ISP on the example of two modern wireless routers.

Apart from this, such devices have built-in DHCP server that allows dynamic assigning of IP addresses in the user LAN. Yes, there are not too many parameters here…

All further configurations we will perform using Cisco Systems equipment in the network emulator GNS3 of 1.3.9 version. We decided to use this emulator intentionally to provide our readers with the opportunity to repeat all the settings in question by themselves. It’s worth noting that in GNS3 of 1.4.0 version built-in support of virtual machines VMware will appear, that makes the process of new network schemas testing simpler. Certainly, even now there is an opportunity to connect emulating in GNS3 equipment with a real network and VMware virtual networks with the help of a cloud object, but we cannot consider this connection very convenient. But we’ve digressed, it’s time to get back to DHCP. As routers we will use 7206VXR (NPE400) model with IOS ADVENTERPRISEK9 of 15.2(4)M8 version. Also we need L2 switch IOU (switch built-in to GNS is not applicable because of the absence of the needed functionality).

Basically, as DHCP client in GNS3 one can use VPCS object that allows static and dynamic assigning of IP parameters. For demonstrating VPCS operating we prepared a simple schema shown below. Configuration of the server side – router R1 – we’ll discuss later.

The listing displayed below shows the process of dynamic obtaining of IP parameters by the virtual host VPCS of 0.6.1 version in GNS3 emulator.

PC1> ip ?
ip ARG ... [OPTION]
 Configure the current VPC's IP settings
 ARG ...:
 address [mask] [gateway]
 address [gateway] [mask]
 Set the VPC's ip, default gateway ip and network mask
 Default IPv4 mask is /24, IPv6 is /64. Example:
 ip 10.1.1.70/26 10.1.1.65 set the VPC's ip to 10.1.1.70,
 the gateway to 10.1.1.65, the netmask to 255.255.255.192.
 In tap mode, the ip of the tapx is the maximum host ID
 of the subnet. In the example above the tapx ip would be
 10.1.1.126
 mask may be written as /26, 26 or 255.255.255.192
 auto           Attempt to obtain IPv6 address, mask and gateway using SLAAC
 dhcp [OPTION]  Attempt to obtain IPv4 address, mask, gateway, DNS via DHCP
 -d         Show DHCP packet decode
 -r         Renew DHCP lease
 -x         Release DHCP lease
 dns ip         Set DNS server ip, delete if ip is '0'
 domain NAME    Set local domain name to NAME
PC1> ip dhcp
DDORA IP 192.168.0.101/24 GW 192.168.0.1
PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.0.101/24
GATEWAY     : 192.168.0.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.0.1
DHCP LEASE  : 86388, 86400/43200/75600
MAC         : 00:50:79:66:68:00
LPORT       : 10001
RHOST:PORT  : 192.168.56.1:10000
MTU:        : 1500

Despite the fact that VPCS requires less RAM for its work than virtual Cisco router of 7200 series, we will further use this particular router even for performing DHCP client role, because, firstly, the command line of the router is more familiar to us and, secondly, we are not limited in resources.

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int gi0/0
R2(config-if)#no sh
R2(config-if)#ip add dc
*Aug 14 08:50:40.347: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
*Aug 14 08:50:41.347: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
R2(config-if)#ip address dhcp
*Aug 14 08:50:59.183: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.0.102, mask 255.255.255.0, hostname R2
R2(config-if)#^Z
R2#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.0.102   YES DHCP   up                    up  
FastEthernet1/0            unassigned      YES unset  administratively down down
FastEthernet1/1            unassigned      YES unset  administratively down down
R2#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 192.168.0.1 to network 0.0.0.0
S*    0.0.0.0/0 [254/0] via 192.168.0.1
 192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, GigabitEthernet0/0
L        192.168.0.102/32 is directly connected, GigabitEthernet0/0
R2#sho ip dns view
DNS View default parameters:
Logging is off
DNS Resolver settings:
 Domain lookup is disabled
 Default domain name:
 Domain search list:
 Lookup timeout: 3 seconds
 Lookup retries: 2
 Domain name-servers:
 8.8.8.8
DNS Server settings:
 Forwarding of queries is disabled
 Forwarder timeout: 3 seconds
 Forwarder retries: 2
 Forwarder addresses:

From the listing above one can see that router R2 gets IP address 192.168.0.102/24 on its Gi0/0 interface. Apart from the address itself, default route and the address of DNS server were provided with the help of DHCP. More detailed information on the operating of DHCP on the client router one can get with the help of sho dhcp lease command.

R2#sho dhcp lease
Temp IP addr: 192.168.0.102  for peer on Interface: GigabitEthernet0/0
Temp  sub net mask: 255.255.255.0
 DHCP Lease server: 192.168.0.1, state: 5 Bound
 DHCP transaction id: 2155
 Lease: 86400 secs,  Renewal: 43200 secs,  Rebind: 75600 secs
Temp default-gateway addr: 192.168.0.1
 Next timer fires after: 11:53:40
 Retry count: 0   Client-ID: cisco-ca02.0468.0008-Gi0/0
 Client-ID hex dump: 636973636F2D636130322E303436382E
 303030382D4769302F30
 Hostname: R2

Naturally, displaying of debug information about DHCP messages exchange is available. The listing shown below displays the moment of refuse from the address leased before by router R2. Displaying of debug messages can be also performed on DHCP server side, but it’s worth noting that one should be especially careful during using debug command in heavy loaded networks.

R2#debug dhcp ?
 detail      DHCP packet content
 redundancy  DHCP client redundancy support
 <cr>
R2#debug dhcp
DHCP client activity debugging is on
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int gi0/0
R2(config-if)#no ip add
*Aug 14 08:59:30.487: DHCP: Sending notification of TERMINATION:
*Aug 14 08:59:30.487:   Address 192.168.0.102 mask 255.255.255.0
*Aug 14 08:59:30.491: DHCP: Client socket is opened
*Aug 14 08:59:30.491: DHCP: SRelease attempt # 1 for entry:
*Aug 14 08:59:30.491: DHCP: SRelease placed Server ID option: 192.168.0.1
*Aug 14 08:59:30.495: DHCP: SRelease: 279 bytes
*Aug 14 08:59:32.175: DHCP: SRelease attempt # 2 for entry:
*Aug 14 08:59:32.175: DHCP: SRelease placed Server ID option: 192.168.0.1
*Aug 14 08:59:32.175: DHCP: SRelease: 279 bytes
*Aug 14 08:59:34.175: DHCP: SRelease attempt # 3 for entry:
*Aug 14 08:59:34.175: DHCP: SRelease placed Server ID option: 192.168.0.1
*Aug 14 08:59:34.175: DHCP: SRelease: 279 bytes
R2(config-if)#
*Aug 14 08:59:35.999: RAC: DHCP stopped on interface GigabitEthernet0/0
R2(config-if)#
*Aug 14 09:00:07.207: DHCP: deleting entry 6AF1FA40 192.168.0.102 from list
*Aug 14 09:00:07.207: DHCP: Client socket is closed
R2(config-if)#do sho deb
DHCPC:
 DHCP client activity debugging is on

Now let’s review settings on the server side that is the configuration of router R1. The first that should be done is starting a corresponding service. In modern IOS versions DHCP service is launched by default. One can disable the specified service with the help of no service dhcp command.

R1(config)#service dhcp
R1(config)#no service dhcp

The second step is creating DHCP pool with the help of ip dhcp pool name command, where name is a name of creating pool. In the listing below on router R1 foxnetwork pool is being created, for which DNS servers, default gateway and lease time are specified. If some changes are planned in the network in the near future, we recommend significant reducing of the lease time before these changes to allow user devices to react to the happened changes as quickly as possible. After the network topology is stabilized, lease time can be significantly increased. Lease time is often set equal to several days or even weeks. Basically, value of this parameter is chosen not only according to static character of the network infrastructure, but also considering the mobility of the clients. For example, during organizing a network in a café, it should be considered that changing of visitors happens very often, so it doesn’t make sense to set lease time equal to more than one hour. With the help of network command one can choose an interface to which the pool is connected and specify range of addresses used for assigning to the clients. One can exclude some IP addresses from the range with the help of ip dhcp excluded-address global command.

ip dhcp excluded-address 192.168.0.1 192.168.0.100
ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.0
 lease 1
 default-router 192.168.0.1
 dns-server 8.8.8.8

One can view the list of created pools and their usage with the help of sho ip dhcp pool command.

R1#sho ip dhcp pool
Pool foxnetwork :
 Utilization mark (high/low)    : 100 / 0
 Subnet size (first/next)       : 0 / 0
 Total addresses                : 254
 Leased addresses               : 1
 Pending event                  : none
 1 subnet is currently in the pool :
 Current index        IP address range                    Leased addresses
 192.168.0.102        192.168.0.1      - 192.168.0.254     1

The command sho ip dhcp binding displays the list of addresses assigned to the clients.

R1#sho ip dhcp binding
Bindings from all pools not associated with VRF:
IP address          Client-ID/              Lease expiration        Type
 Hardware address/
 User name
192.168.0.101       0063.6973.636f.2d63.    Aug 21 2015 09:46 AM    Automatic
 6130.322e.3034.3638.
 2e30.3030.382d.4769.
 302f.30

One can get static information about DHCP service operating on a router with the help of sho ip dhcp server statistics command.

R1#sho ip dhcp server statistics
Memory usage         73238
Address pools        1
Database agents      0
Automatic bindings   1
Manual bindings      0
Expired bindings     0
Malformed messages   0
Secure arp entries   0
Message              Received
BOOTREQUEST          0
DHCPDISCOVER         5
DHCPREQUEST          4
DHCPDECLINE          0
DHCPRELEASE          6
DHCPINFORM           0
Message              Sent
BOOTREPLY            0
DHCPOFFER            4
DHCPACK              4
DHCPNAK              0

Sometimes in corporate networks the necessity of static binding of providing IP address to a particular client occurs. Such a binding can be performed based on the client identifier sending in option #61. Compare values of option #61 in DHCP discovery messages sending by different DHCP clients. The example of DHCP discovery sending by Cisco router is contained in foxnetwork_1.pcapng file, the same message from Microsoft Windows 7 is in foxnetwork_3.pcapng file. So, before creating a static binding of IP address to the client, one should clarify the value of identifier sent by the client operating system. After the identifier is clarified, it’s necessary to start configuration of DHCP server working on the router. Static binding is performed by creating a new DHCP pool in which one only has to specify address providing to the client and client identifier. In addition, one can specify client name with the help of client-name command (is not provided to the client in DHCP messages). The example of such a pool is shown below.

ip dhcp pool r2
 host 192.168.0.111 255.255.255.0
 client-identifier 0063.6973.636f.2d63.6130.322e.3135.3063.2e30.3030.382d.4769.302f.30
 client-name test

All other settings (apart from IP address) the client inherits from the parent pool. It's also worth noting that inheritance of the settings is also performed during using ordinary pools. Let’s review a small fragment of the network shown below.

In the listing below we created two pools for nested ranges 192.168.0.0/16 and 192.168.0.0/24. For the larger subnet the only setting is performed: address of the DNS server. The pool with the smaller more subnet contains address of the default gateway.

ip dhcp pool parent
 network 192.168.0.0 255.255.0.0
 dns-server 8.8.8.8
ip dhcp pool child
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
R1#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.0.1     YES manual up                    up 

One can make sure that the client (which role VPCS host performs) gets all necessary settings with the help of show ip command.

PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.0.2/24
GATEWAY     : 192.168.0.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.0.1
DHCP LEASE  : 86397, 86400/43200/75600
MAC         : 00:50:79:66:68:00
LPORT       : 10000
RHOST:PORT  : 192.168.228.2:10001
MTU:        : 1500

For consolidating the knowledge we recommend that the beginner readers perform the corresponding lab.

The process of assigning IP address

Earlier we reviewed ip dhcp excluded-address command that allows excluding a range of addresses from delivery. Such exclusion is helpful when in one IP subnet there are both dynamically configuring clients and hosts with the static configuration, for example, interfaces of the network equipment or server. But what if a statically configured device with the address out of excluding range exists in the network? For discovering such situations DHCP service working on Cisco router uses ICMP protocol. Probably, some of our readers will be surprised when find out that ICMP echo but not ARP is used. Yes, exactly ICMP is used and then it will be clear why. Let’s review what exactly happens at the moment of address delivery to the client, on the examples.

To start with let’s, use a simple schema with two routers R1 and R2 which we used before. R1 performs server functions and R2 – client ones. All packets of which two devices exchange we saved to the file foxnetwork_4.pcapng. The first packet is sent by the client, this is a simple gratuitous ARP, after which a broadcast message DHCP discover follows. The third packet is ARP request of DHCP server for 192.168.0.102 address. Next three packets are an ordinary ending of DHCP exchange. But what is 192.168.0.102 address? From the fourth packet (DHCP offer) it’s clear that this is the address offered to the client by the server. So, before providing an IP address the server broadcasts ARP request. But no ICMP, right? Well, let’s try to place in the network a host with the IP address that R1 plans to deliver. Our network changed a bit.

We added router R3 and assigned to its Gi0/0 interface IP address 192.168.0.103 which should be provided on the next DHCP request to router R1. The next providing IP address is shown in the listing of sho ip dhcp pool command in Current index field. We captured the process of messages exchange on receiving the address by router R2 and saved it to foxnetwork_5.pcapng file. According to the traffic dump, one can see that router R1 after receiving DHCP request sends ARP request for 192.168.0.103 address and after receiving an answer sends ICMP echo-request message, in reply to which R3 sends ICMP echo-reply. After receiving echo-reply, router R1 checks if the address 192.168.0.104 is occupied. Made sure that the address in question is free, R1 offers it to the client. So, we watched that during choosing an address for the client DHCP server checks the occupation of this address using ICMP. Cisco Systems routers performing functions of DHCP server even allow setting a number of sending ICMP echo-requests and their timeouts.

R1(config)#ip dhcp ping ?
 packets  Specify number of ping packets
 timeout  Specify ping timeout
R1(config)#ip dhcp ping pa
R1(config)#ip dhcp ping packets ?
 <0-10>  Number of ping packets (0 disables ping)
 <cr>
R1(config)#ip dhcp ping ti
R1(config)#ip dhcp ping timeout ?
 <100-10000>  Ping timeout in milliseconds

The only question is open: what is DHCP server going to do in case of receiving ARP reply but not receiving ICMP echo-reply? Let’s try to reproduce this situation. To forbid router R3 from replying to ICMP requests, one should create an access list denying ICMP echo and enter command no ip unreachables on the interface Gi0/0. The access list and configuration of Gi0/0 interface of router R3 are shown in the listing below. We’d like to pay readers’ attention to the fact that we also changed IP address of the interface because the next offered by DHCP address should be 192.168.0.105.

ip access-list extended NOICMP
 deny   icmp any any
 permit ip any any
interface GigabitEthernet0/0
 ip address 192.168.0.105 255.255.255.0
 ip access-group NOICMP in
 no ip unreachables
 duplex full
 speed 1000
 media-type gbic
 negotiation auto

And what happens now if suppose that DHCP service of Cisco routers relies exactly on ICMP? During using the shown configuration, R2 should receive the address already assigned to router R3. Fortunately, this doesn’t happen because before start using of address offered by DHCP server, the client checks the presence of this address in the network with the help of ARP. All messages of which the routers exchange are shown in foxnetwork_6.pcapng file. The sequence of actions of hosts in the network is as follows.

  1. R2 sends DHCP discover message
  2. R1 checks the availability of 192.168.0.105 address with the help of ICMP
  3. During such checking R3 replies to ARP request (that makes it possible to send ICMP message), but doesn’t reply to ICMP echo-request message
  4. Router R1, not having received ICMP message from the host with 192.168.0.105 address, offers its using to R2 client with the help of DHCP offer message
  5. R2 client receives DHCP offer message containing offered IP address from R1 server, after which performs its own checking of availability of 192.168.0.105 address with the help of ARP protocol
  6. R3 host replies to ARP request of router R2
  7. R2 considers that IP address 192.168.0.105 offered by the server is already occupied, and sends notification about this to the server with the help of DHCP decline message
  8. R1 adds 192.168.0.105 address to its base of conflicting addresses
  9. R2 again initiates search of DHCP server by sending DHCP discover message
  10. R1 server chooses the next address from the pool - 192.168.0.106 and checks if it is available
  11. R1 server offers 192.168.0.106 address to R2 client with the help of DHCP offer message
  12. R2 client requests permission on using 192.168.0.106 address from the server with the help of DHCP request message
  13. R1 server acknowledges using of 192.168.0.106 address by R2 client with the help of DHCP ack message
  14. Router R2 performs its own checking of the new address availability and makes sure that it’s free

Stop-stop-stop! There is something wrong in this list. According to the dump, after sending the second DHCP discover message, the client doesn’t perform validation of availability for the offered address and accepts it right away, after which broadcasts gratuitous ARP message. We repeated the process one more time and assigned 192.168.0.107 address to router R3. This cannot be a mistake, everything comes this exact way. But what happens if the repeatedly received address occurred to be occupied? We added one more host to our schema with the next following in order address, so there are R3 host with 192.168.0.109 address and R4 with 192.168.0.110 address that don’t reply to ICMP messages in our network.

We again initiated the procedure of obtaining an IP address by router R2. The traffic dump we saved in foxnetwork_7.pcapng file. So, having received IP address the second time, the client assigns it to its interface, sends gratuitous ARP, discovers the occupation of the address in question, after which performs a standard procedure of rejection from the received address with the help of DHCP decline message. On R3 and R4 hosts the following messages appears at this moment.

*Aug 14 15:22:04.751: %IP-4-DUPADDR: Duplicate address 192.168.0.110 on GigabitEthernet0/0, sourced by ca02.150c.0008

One can view the list of conflicting addresses on R1 with the help of sho ip dhcp conflict command.

R1#sho ip dhcp conflict
IP address        Detection method   Detection time          VRF
192.168.0.103     Ping               Aug 14 2015 01:12 PM                       
192.168.0.105     Gratuitous ARP     Aug 14 2015 02:15 PM                       
192.168.0.107     Gratuitous ARP     Aug 14 2015 03:16 PM                       
192.168.0.109     Gratuitous ARP     Aug 14 2015 03:22 PM                       
192.168.0.110     Gratuitous ARP     Aug 14 2015 03:22 PM     

Clearing of conflicting addresses base is performed with the help of clear ip dhcp conflict command.

R1#clear ip dhcp conflict ?
 *        Clear all address conflicts
 A.B.C.D  Clear a specific conflict
 vrf      DHCP vrf conflicts
R1#clear ip dhcp conflict *
R1#sho ip dhcp conflict
IP address        Detection method   Detection time          VRF
R1#

That’s where we complete the review of getting IP parameters procedure and go to review of using secondary IP subnets together with DHCP.

Secondary subnet

On increasing a number of IP devices in the network, run out of IP addresses in the pool can occur. Certainly, in some cases one can solve this problem by decreasing IP address lease time, however, situations when all devices are in up state are not rare. There are two ways out of the situation in question: increase of the earlier leased subnet or using the secondary subnet. Unfortunately, increase of the subnet is not always possible, for example, because of absence of large continuous subnets. Let’s review configuration of equipment for using the secondary subnet on the example of the network shown below. Let’s consider that subnet 192.168.0.0/30 was used initially for connecting PC1 host with router R1. After PC2 node was added, the existing range became not enough.

The listing below demonstrates main settings of router R1 before adding PC2 host. Loopback 0 interface is used for the emulation of the global network.

ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.252
 default-router 192.168.0.1
 dns-server 8.8.8.8
 domain-name foxnetwork.ru
 lease 0 1
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
interface GigabitEthernet0/0
ip address 192.168.0.1 255.255.255.252
 load-interval 30

The first from which we should begin is configuration of the router’s interface and L3 switch, on which interface it’s needed to set secondary IP address.

R1#sho run int gi0/0
Building configuration...
Current configuration : 204 bytes
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.252 secondary
 ip address 192.168.0.1 255.255.255.252
 load-interval 30
end

One of the ways of using the secondary subnet by DHCP server is creation of the second DHCP pool.

ip dhcp pool foxnetwork2
 network 192.168.1.0 255.255.255.252
 dns-server 8.8.8.8
 domain-name foxnetwork.ru
 default-router 192.168.1.1
 lease 0 1

Apart from creation of the second pool, more elegant solution exists, that is in specifying a secondary subnet presence in the settings of existing address pool.

R1#sho run | sec pool
ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.252
 network 192.168.1.0 255.255.255.252 secondary
 override default-router 192.168.1.1
 default-router 192.168.0.1
 dns-server 8.8.8.8
 domain-name foxnetwork.ru
 lease 0 1

It’s worth noting that for the secondary subnet one can change only the value of default gateway in the settings of DHCP pool. If it’s necessary to differ some other parameters, the only solution is creation of the second DHCP pool.

It remains only to check the functionality of the construction described above.

PC2> ip dh
DDORA IP 192.168.1.2/30 GW 192.168.1.1
PC2> sho ip
NAME        : PC2[1]
IP/MASK     : 192.168.1.2/30
GATEWAY     : 192.168.1.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.0.1
DHCP LEASE  : 3599, 3600/1800/3150
DOMAIN NAME : foxnetwork.ru
MAC         : 00:50:79:66:68:01
LPORT       : 10004
RHOST:PORT  : 192.168.56.1:10005
MTU:        : 1500
PC2> sho ip all
NAME   IP/MASK              GATEWAY           MAC                DNS
PC2    192.168.1.2/30       192.168.1.1       00:50:79:66:68:01  8.8.8.8
PC2> sho arp
ca:01:5f:7c:00:08  192.168.1.1 expires in 37 seconds
PC2> ping 192.168.1.1 -c 3
84 bytes from 192.168.1.1 icmp_seq=1 ttl=255 time=9.000 ms
84 bytes from 192.168.1.1 icmp_seq=2 ttl=255 time=9.000 ms
84 bytes from 192.168.1.1 icmp_seq=3 ttl=255 time=9.000 ms
PC2> ping 192.168.0.1 -c 3
84 bytes from 192.168.0.1 icmp_seq=1 ttl=255 time=5.001 ms
84 bytes from 192.168.0.1 icmp_seq=2 ttl=255 time=9.001 ms
84 bytes from 192.168.0.1 icmp_seq=3 ttl=255 time=9.000 ms
PC2> ping 192.168.0.2 -c 3
84 bytes from 192.168.0.2 icmp_seq=1 ttl=63 time=11.001 ms
84 bytes from 192.168.0.2 icmp_seq=2 ttl=63 time=19.001 ms
84 bytes from 192.168.0.2 icmp_seq=3 ttl=63 time=19.002 ms
PC2> ping 1.1.1.1 -c 3
84 bytes from 1.1.1.1 icmp_seq=1 ttl=255 time=4.000 ms
84 bytes from 1.1.1.1 icmp_seq=2 ttl=255 time=9.001 ms
84 bytes from 1.1.1.1 icmp_seq=3 ttl=255 time=9.000 ms

An obvious drawback of using secondary subnets (instead of increase of an existing network) is the necessity of using a router for transmitting traffic between hosts of primary and secondary IP networks. Using of two or more IP networks in this case doesn’t lead to the decrease of broadcast traffic that, probably, should be considered during building large corporate networks. In this case, probably, it’s better to use several virtual networks (VLAN) and different DHCP pools. One more remark that we’d like to add, is connected with using of multilayer switches. If the only MLS device performing functions of routing, switching and DHCP server is used, one can ignore the increase of delays and decrease of the network performance (because of the necessity to route traffic between hosts of primary and secondary IP networks).

During discussing the specifics of using secondary IP networks on the interfaces we cannot help but mention about ip dhcp smart-relay command that influences the router’s functioning that performs functions of DHCP relay and uses secondary IP addresses on the interfaces. Let’s review a small network shown in the picture below as an example.

Router R1 is DHCP relay and R2 performs functions of DHCP server. Suppose that on Fa1/0 interface of router R1 two IP networks are configured. The example of Fa1/0 interface of router R1 configuration is shown below. Address 2.2.2.2 is assigned to Loopback interface of router R2. Consider that routing is configured in appropriate way on both routers.

interface FastEthernet1/0
 ip address 192.168.1.1 255.255.255.0 secondary
 ip address 192.168.0.1 255.255.255.0
 ip helper-address 2.2.2.2

On router R2 DHCP pool is configured.

ip dhcp excluded-address 192.168.1.1 192.168.1.10
ip dhcp pool foxnetwork
 network 192.168.1.0 255.255.255.0
 default-router 192.168.1.1
 dns-server 8.8.8.8
 lease 0 1

By default, router R1 sends DHCP discover message from primary IP address assigned to Fa1/0 interface. As there is no DHCP pool for the network 192.168.0.0/24 on router R2, DHCP offer message will not be sent that will lead to the fact that client host PC1 will not receive IP address. Enable of smart-relay option makes router R1 after sending of three messages from the primary IP address send DHCP discover messages from the address of the secondary network in situation when for the first three messages DHCP offer was not received. Capturing of DHCP messages between routers R1 and R2 we saved to the file foxnetwork_13.pcapng. It would be good for the readers to pay attention to the field «Relay agent IP address» in DHCP discover messages.

From the routing point of view, primary and secondary networks are not different in principle. Here we don’t review using of dynamic routing protocols, some of which cannot establish neighbourship with other routers placed in secondary IP networks.

R1#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is not set
 1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
 192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/30 is directly connected, GigabitEthernet0/0
L        192.168.0.1/32 is directly connected, GigabitEthernet0/0
 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/30 is directly connected, GigabitEthernet0/0
L        192.168.1.1/32 is directly connected, GigabitEthernet0/0

Now let’s review which other options are provided by Cisco equipment during working with the protocol.

Additional options: relay

All schemas discussed above supposed setting of DHCP server directly to the user segment. Certainly, using of multilayer switch as DHCP server is also appropriate, however, during using of MLS equipment, using of IPAM systems, to which the solution of managing Cisco Network Registrar (CNR) networks belongs, can be difficult or even impossible. If a technology that allows not connecting DHCP server to each user segment and not making switches and routers perform IP addresses distribution exists? Such a function, certainly, exists and is called DHCP relay. Equipment performing function of DHCP relay intercepts broadcast messages DHCP discover and sends them to DHCP server. Enable of relay function is performed with the help of interface command ip helper-address. Let’s review a small schema shown below.

PC1 host is DHCP client. Router R1 terminates client network on itself and performs relay functions. Router R2 is DHCP server. Let’s view the main configuration parameters for both routers. On R1 device the following commands are used.

interface Loopback0
 ip address 192.168.255.1 255.255.255.255
interface FastEthernet1/0
 ip address 192.168.0.1 255.255.255.0
 ip helper-address 192.168.255.2
interface FastEthernet1/1
 ip address 192.168.1.1 255.255.255.0
router eigrp 1
 network 192.168.1.0
 redistribute connected

Configuration of router R2 is displayed below.

ip dhcp excluded-address 192.168.0.1 192.168.0.10
ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
 dns-server 8.8.8.8
 lease 0 1
interface Loopback0
 ip address 192.168.255.2 255.255.255.255
interface FastEthernet1/1
 ip address 192.168.1.2 255.255.255.0
router eigrp 1
 network 192.168.1.0
 redistribute connected

The process of getting IP address by the client with the use of relay doesn’t differ from one with placing of DHCP server directly in the client network.

PC1> ip dhcp
DDORA IP 192.168.0.11/24 GW 192.168.0.1
PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.0.11/24
GATEWAY     : 192.168.0.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.1.2
DHCP LEASE  : 3595, 3600/1800/3150
MAC         : 00:50:79:66:68:00
LPORT       : 10000
RHOST:PORT  : 192.168.56.1:10001
MTU:        : 1500
PC1> ping 192.168.255.2
84 bytes from 192.168.255.2 icmp_seq=1 ttl=254 time=29.002 ms
84 bytes from 192.168.255.2 icmp_seq=2 ttl=254 time=29.002 ms
84 bytes from 192.168.255.2 icmp_seq=3 ttl=254 time=16.001 ms
84 bytes from 192.168.255.2 icmp_seq=4 ttl=254 time=21.001 ms
84 bytes from 192.168.255.2 icmp_seq=5 ttl=254 time=32.002 ms

Naturally, we captured the process of receiving IP address by the client. In the file foxnetwork_11.pcapng there are packets sending between the client and router R1, and foxnetwork_12.pcapng file contains traffic of which routers R1 and R2 exchanged. As one can see from the dump foxnetwork_12.pcapng, exchange of DHCP messages between routers is performed with the help of unicast addresses. We recommend that our readers compare the value of «Relay agent IP address» field in both files. Also it’s interesting to view ICMP traffic sending by DHCP server in the process of getting IP address by the client. In the previous package we described algorithms using by DHCP server for checking the assignment of IP address before offering it to the client. Well, ARP protocol in this case, obviously, cannot be used at all, because sending of ARP messages via router can’t be performed.

It’s worth noting that by default ip helper-address command sends not only DHCP messages but also the whole set of other ones. One can disable relaying of the protocol with the help of no ip forward-protocol command.

switch(config)#no ip forward-protocol ?
 nd             Sun's Network Disk protocol
 sdns           Network Security Protocol
 spanning-tree  Use transparent bridging to flood UDP broadcasts
 turbo-flood    Fast flooding of UDP broadcasts
 udp            Packets to a specific UDP port
switch(config)#no ip forward-protocol udp ?
 <0-65535>      Port number
 biff           Biff (mail notification, comsat, 512)
 bootpc         Bootstrap Protocol (BOOTP) client (68)
 bootps         Bootstrap Protocol (BOOTP) server (67)
 discard        Discard (9)
 dnsix          DNSIX security protocol auditing (195)
 domain         Domain Name Service (DNS, 53)
 echo           Echo (7)
 isakmp         Internet Security Association and Key Management Protocol (500)
 mobile-ip      Mobile IP registration (434)
 nameserver     IEN116 name service (obsolete, 42)
 netbios-dgm    NetBios datagram service (138)
 netbios-ns     NetBios name service (137)
 netbios-ss     NetBios session service (139)
 non500-isakmp  Internet Security Association and Key Management Protocol (4500)
 ntp            Network Time Protocol (123)
 pim-auto-rp    PIM Auto-RP (496)
 rip            Routing Information Protocol (router, in.routed, 520)
 snmp           Simple Network Management Protocol (161)
 snmptrap       SNMP Traps (162)
 sunrpc         Sun Remote Procedure Call (111)
 syslog         System Logger (514)
 tacacs         TAC Access Control System (49)
 talk           Talk (517)
 tftp           Trivial File Transfer Protocol (69)
 time           Time (37)
 who            Who service (rwho, 513)
 xdmcp          X Display Manager Control Protocol (177)
 <cr>

Also we cannot help but mention one, probably, not the most obvious detail: on the router performing functions of DHCP relay, DHCP service should be enabled. Enable of the service is performed with the help of service dhcp command, for disable one can use no service dhcp command. In Cisco routers this service is enabled by default and in running state is not even displayed in running config.

R2#sho run | i dhcp
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#no serv dhcp
R2(config)#^Z
R2#sho run | i dhcp
no service dhcp
R2#

Administrator can also configure the behavior of DHCP relay for receiving DHCP message containing information about another relay. The specified messages can be dropped, encapsulated (DHCP server can use both options #82), sent without changes or the information about relay can be changed.

switch(config)#ip dhcp relay information policy ?
 drop         Do not forward BOOTREQUEST message
 encapsulate  Encapsulate existing information
 keep         Leave existing information alone
 replace      Replace existing information

Very close to DHCP relay topic, there are support of option #82 and DHCP snooping, which we will discuss in the next section.

Additional options: option 82, snooping

Before this moment we didn’t configure switch connecting the client with router R1, the only thing that was required that ports e0/0 and e0/1 were placed in the same virtual network. However, from time to time the necessity to provide a particular client with a particular address with the help of DHCP occurs. The problem became more difficult if the client can use different devices for connecting to the network, so his/her MAC-address and client identifier can differ, that won’t allow DHCP server to use these fields for creating a static binding. In this case switch with the support of option 82 can help. This option differs from all others by the fact that it is added to DHCP message not by the client or server but by the switch, and DHCP server analyzes its value. Fortunately, L2 IOU of adventerprisek9-15.1a version supports this function. Enable of option 82 support is performed with the help of ip dhcp relay information option command in global configuration mode. Also one should enable DHCP snooping. Commands configured on the router are displayed below.

ip dhcp relay information option
ip dhcp snooping vlan 1
ip dhcp snooping
interface Ethernet0/1
 ip dhcp snooping trust

We captured DHCP discover message on the part of network between IOU1 switch and router R1. As one can see from the picture below, the switch added option #82 to the message. Its content we are not reviewing yet.

However, despite the fact that we watched DHCP discover message in the network, the client stopped receiving IP address. Viewing of the traffic dump leads us to the fact that router R1 stopped performing relay functions. It’s unexpected, right? With the help of deb ip dhcp server packet command we enabled displaying of debug information on DHCP router. At the moment of receiving the packet with DHCP discover message, the following messages are shown in the console –so named sanity check worked.

*Aug 21 18:28:28.247: DHCPD: inconsistent relay information.
*Aug 21 18:28:28.247: DHCPD: relay information option exists, but giaddr is zero

Disable of the check specified above is performed on Fa1/0 interface of router R1 with the help of ip dhcp relay information trusted command, after which the client successfully gets IP address. The list of interfaces for which this command is enabled can be shown with the help of sho ip dhcp relay information trusted-sources call.

R1#sho ip dhcp relay information trusted-sources
List of trusted sources of relay agent information option:
FastEthernet1/0

Providing IP address to the client doesn’t consider the value of option #82 at the moment. To allow DHCP server to consider value of option #82, one should configure a special class for this client. The example of such configuration is shown below.

ip dhcp class foxnetwork
 remark test client
 relay agent information
 relay-information hex 010600040001000002080006aabbcc000100

Command remark is not necessary; however, we strongly recommend using it for not confusing in a big number of created classes. With the help of this command one should give the most clear description connected with the client for which this class is being created.

Now it’s required to use created class in DHCP server settings. Configuration of DHCP pool is displayed below.

ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
 dns-server 8.8.8.8
 lease 0 1
 class foxnetwork
 address range 192.168.0.101 192.168.0.101

Let’s repeat getting IP address by the client and make sure that PC1 received address 192.168.0.101.

PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.0.11/24
GATEWAY     : 192.168.0.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.1.2
DHCP LEASE  : 2753, 3600/1800/3150
MAC         : 00:50:79:66:68:00
LPORT       : 10003
RHOST:PORT  : 192.168.56.1:10000
MTU:        : 1500
PC1> ip dhcp
DDORA IP 192.168.0.101/24 GW 192.168.0.1
PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.0.101/24
GATEWAY     : 192.168.0.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.1.2
DHCP LEASE  : 3593, 3600/1800/3150
MAC         : 00:50:79:66:68:00
LPORT       : 10003
RHOST:PORT  : 192.168.56.1:10000
MTU:        : 1500

But what is a magic number 010600040001000002080006aabbcc000100 which we specified in command relay-information and which was sent in option #82? Let’s check from which parts it’s consist from.

010600040001000002080006aabbcc000100
0106 Beginning of the first section, 6 bytes
0004 Field curcuit-id, 4 bytes
0001 VLAN number (in hex)
0000 Number of switch port to which the client is connected (starts from zero)
0208 Beginning of the second section, 8 bytes
0006 Field remote-id, 6 bytes
aabbcc000100 MAC address of the switch, to which the client is connected

Now we can calculate the value of option #82 beforehand, without waiting for it in the captured packets. To be fair, it’s worth mentioning that Cisco switches allow changing the format of option #82.

cisco_3750(config)#ip dhcp snooping information option format remote-id ?
 hostname  Use configured hostname for remote id
 string    User defined string for remote id
cisco_3750(config)#ip dhcp snooping information option format remote-id hostname ?
 <cr>
cisco_3750(config)#ip dhcp snooping information option format remote-id string ?
 WORD  Use string for remote id (max length 63)

During configuration of the switch in this section we used functions DHCP snooping. But what is it purposed for? DHCP snooping function of the switch is purposed for the defense against attacks using DHCP. The example of such an attack is installation of rogue DHCP server or DHCP starvation attack in the result of which the attacker can completely exhaust the address space allocated by the DHCP servers. The database created at the result of DHCP snooping working can be used by other defense mechanisms among which are DAI (Dynamic ARP Inspection) and IP Source Guide. However, discussion of these functions working is out of scope of this article.

DHCP snooping function sets two roles for all ports: trusted and untrusted. To trusted ports one can connect other switches or DHCP servers, DHCP-messages received via these ports are not dropped. DHCP traffic received from untrusted ports is inspected and messages DHCP offer, ack/nack and leasequery are dropped. Inspecting of DHCP traffic from untrusted ports means, for example, the following: messages DHCP release and decline are checked on correspondence to the database, checking of the correspondence between MAC addresses in the frame and in DHCP message itself, the absence of option #82 is checked. Also one can make routers perform checking of DHCP messages on the absence of relay’s address in the message.

IOU1(config)#ip dhcp snooping verify ?
 mac-address             DHCP snooping verify mac-address
 no-relay-agent-address  DHCP snooping verify giaddr

Viewing of configurations of DHCP snooping function is performed with the help of show ip dhcp snooping command.

IOU1#sho ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
1
DHCP snooping is operational on following VLANs:
1
DHCP snooping is configured on the following L3 Interfaces:
Insertion of option 82 is enabled
 circuit-id default format: vlan-mod-port
 remote-id: aabb.cc00.0100 (MAC)
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Interface                  Trusted    Allow option    Rate limit (pps)
-----------------------    -------    ------------    ----------------
Ethernet0/1                yes        yes             unlimited
 Custom circuit-ids:

Command show ip dhcp snooping statistics displays statistical information about working of DHCP snooping.

IOU1#sho ip dhcp snooping statistics
 Packets Forwarded                                     = 229
 Packets Dropped                                       = 0
 Packets Dropped From untrusted ports                  = 0

One can view current bindings with the help of show ip dhcp snooping binding command.

IOU1#sho ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
00:50:79:66:68:00   192.168.0.101    1992        dhcp-snooping   1     Ethernet0/0
Total number of bindings: 1

Sometimes it’s necessary to add a static record to the database of DHCP snooping bindings. To perform the operation in question one should use ip dhcp snooping binding <mac-address> vlan <vid> <IP address> interface <interface-id> expiry <seconds> command. The key word expiry allows specifying time interval during which a creating record will be existing. The maximum value allowed by expiry option is 4294967295 seconds that is almost equal to 136 years.

The database of DHCP snooping function can be stored locally in nonvolatile memory or on the remote servers.

IOU1(config)#ip dhcp snooping database ?
 disk0:       Database agent URL
 disk1:       Database agent URL
 ftp:         Database agent URL
 http:        Database agent URL
 rcp:         Database agent URL
 scp:         Database agent URL
 tftp:        Database agent URL
 timeout      Configure abort timeout interval
 unix:        Database agent URL
 write-delay  Configure delay timer for writes to URL

Probably, we can also mention here that one can save on remote servers or in nonvolatile memory not only the database of DHCP snooping function but also the base of DHCP bindings that is the base of IP addresses used by the clients at the moment. Such saving of the database can be required for not losing the database at the moment of device reboot. The example of command saving the base of DHCP bindings locally is displayed below.

ip dhcp database disk1:fox.txt

However, the file will be created not right after entering the command but with some delay. By default, such delay is equal to 300 seconds. One can make sure of this delay with the help of sho run all command displaying all values of the default parameters. In the listing below the same command is shown but together with the default parameters.

ip dhcp database disk1:fox.txt write-delay 300 timeout 300

Content of the file saved this way is shown below.

R1#more disk1:fox.txt
*time* Aug 24 2015 02:07 AM
*version* 4
!IP address     Type  Hardware address   Lease expiration       VRF
192.168.1.3     id    0063.6973.636f.2d63.6130.322e.3165.3663.2e30.3030.382d.4769.302f.30  Aug 25 2015 02:03 AM

!IP address      Type     Hardware address  Interface-name

!IP address     Interface-name  Lease expiration      Server IP address  Hardware address  Vrf
*end*

One more interesting option about which we cannot help but mention here is DHCP lease query message that allows requesting from DHCP server information about leased IP addresses. DHCP lease query message can be used by the devices performing, for example, functions of DHCP relays in the case of losing the own database of active bindings because of the emergency reboot or for other reasons. This information can be used by the network equipment, for example, for the defense from IP spoofing attacks or in case when it’s necessary to perform client authentication based on his/her MAC address by SSG service. Detailed exploration of DHCP lease query message is far out of scope of this article. More detailed information about this message can be found in RFC4388 and RFC6148.

Additional options: import of parameters

Sometimes it’s necessary to provide DHCP clients with parameters that were received dynamically. Let’s review the schema below.

Router R3 is provider equipment that performs functions of DHCP server for connected clients. Router R2 is client equipment that is simultaneously DHCP client in the provider network and DHCP server in the own network to which PC1 host is connected. R3 provides addresses from 192.168.1.0/24 network, R2 provides addresses from 192.168.0.0/24 network. The task is in sending particular parameters, for example, address of DNS server, from router R3 to PC1 host. As addresses of DNS servers are sending dynamically, one cannot add them to the configuration beforehand. Instead of this, one should use import all option in the settings of DHCP pool. In the listing below there is a partial configuration of router R3. As we can see, R3 provides its clients with the address of DNS server.

ip dhcp excluded-address 192.168.1.1 192.168.1.10
ip dhcp pool test
 network 192.168.1.0 255.255.255.0
 dns-server 8.8.8.8
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0

The partial configuration of router R2 is shown below.

ip dhcp excluded-address 192.168.0.1 192.168.0.10
ip dhcp pool test2
 import all
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
interface FastEthernet1/0
 ip address 192.168.0.1 255.255.255.0
interface FastEthernet1/1
 ip address dhcp

As we can see, router R2 doesn’t contain information about DNS server, but PC1 host receives the corresponding setting.

PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.0.12/24
GATEWAY     : 192.168.0.1
DNS         : 8.8.8.8
DHCP SERVER : 192.168.0.1
DHCP LEASE  : 71323, 86400/43200/75600
MAC         : 00:50:79:66:68:00

Here we’d like to pay readers’ attention to one rather obvious thing – the order of actions. To import parameters successfully, it’s needed that corresponding DHCP pool was fully configured to the moment of receiving IP parameters from the provider’s equipment.

Additional options: VRF support

In modern enterprise networks administrators more often come to using VRF. Service of DHCP server in Cisco equipment is VRF-aware. Let’s review the situation when clients from a particular VRF or global clients (not belonging to any VRF) connect to the router. It’s worth noting that VRF has local importance, so neighboring devices don’t know if any VRFs are configured on the router.

So, in our example, router R1 has two interfaces: FE 1/0 (belongs to VRF a) and FE 1/1 (belongs to the global routing table). Connection of the clients is performed the way as shown above. In our example we will use overlapping addresses of the networks, for example, 192.168.0.0/24. Assign address 192.168.0.1/24 to both interfaces of the router. Exclude from the pool addresses from the first to ten inclusive. To check functionality of the schema we create two DHCP pools a bit differ from each other. Clients connecting to the global pool will receive address of the default gateway and address of DNS server 8.8.8.8. Clients connecting to the interface belonging to vrf a, will not receive address of the default gateway, and the address of their DNS server will be 8.8.4.4. The listing below contains main configuration parameters for router R1.

vrf definition a
 rd 1:1
address-family ipv4
 exit-address-family
ip dhcp excluded-address 192.168.0.1 192.168.0.10
ip dhcp excluded-address vrf a 192.168.0.1 192.168.0.10
ip dhcp pool global
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
 dns-server 8.8.8.8
ip dhcp pool vrfa
 vrf a
 network 192.168.0.0 255.255.255.0
 dns-server 8.8.4.4
interface FastEthernet1/0
 vrf forwarding a
 ip address 192.168.0.1 255.255.255.0
interface FastEthernet1/1
 ip address 192.168.0.1 255.255.255.0

One can view the statistics of using pools with the help of sho ip dhcp pool command showing also information about a pool belonging to a particular VRF.

R1#sho ip dhcp pool
Pool global :
 Utilization mark (high/low)    : 100 / 0
 Subnet size (first/next)       : 0 / 0
 Total addresses                : 254
 Leased addresses               : 1
 Pending event                  : none
 1 subnet is currently in the pool :
 Current index        IP address range                    Leased addresses
 192.168.0.12         192.168.0.1      - 192.168.0.254     1
Pool vrfa :
 Utilization mark (high/low)    : 100 / 0
 Subnet size (first/next)       : 0 / 0
 VRF name                       : a
 Total addresses                : 254
 Leased addresses               : 1
 Pending event                  : none
 1 subnet is currently in the pool :
 Current index        IP address range                    Leased addresses
 192.168.0.12         192.168.0.1      - 192.168.0.254     1

The command sho ip dhcp binding also displays information to which VRF the client received IP address belongs.

R1#sho ip dhcp binding
Bindings from all pools not associated with VRF:
IP address          Client-ID/              Lease expiration        Type
 Hardware address/
 User name
192.168.0.11        0100.5079.6668.01       Jan 09 2016 12:30 AM    Automatic
Bindings from VRF pool a:
IP address          Client-ID/              Lease expiration        Type
 Hardware address/
 User name
192.168.0.11        0100.5079.6668.00       Jan 09 2016 12:30 AM    Automatic

In conclusion, it’s worth noting that support of VRF and MPLS VPN is provided also for devices performing functions of DHCP relay. The readers who are interested in it can study the following commands on their own.

ip helper-address vrf
ip dhcp relay information option vpn
ip dhcp relay information option vpn-id

That’s where we complete this chapter and go to the review of connection between DHCP and routing processes.

DHCP and routing

In this part we decided to raise questions about interaction between DHCP and processes of building a routing table. We decided to begin with the dynamic routing protocols (IGP).

Suppose, we faced with the problem in its general way: it's required to set EIGRP neighboring with devices connected to the interface Gi0/0 of router R2, which IP address is configured dynamically and the range of addresses is not known.

In this case in the configuration of EIGRP routing process one should perform three commands: disable EIGRP on all interfaces (passive-interface default), enable routing for all networks (network 0.0.0.0), and enable support of Gi0/0 interface in EIGRP (no passive-interface GigabitEthernet0/0). Configuration of router R1 is typical, so we don't provide it here. Main configuration commands entered on router R2 are shown below.

interface GigabitEthernet0/0
 ip address dhcp
!
router eigrp 1
 network 0.0.0.0
 passive-interface default
 no passive-interface GigabitEthernet0/0

After this EIGRP neighboring with router R1 is performed successfully.

R2# sho ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(1)
 Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Gi0/0                    1        0/0       0/0          24       0/0           64           0
R2#sho ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
 (sec)         (ms)       Cnt Num
0   192.168.0.1             Gi0/0                    13 00:05:10   24   144  0  3

Configuration of RIP protocol is the same and is displayed below.

router rip
 version 2
 passive-interface default
 no passive-interface GigabitEthernet0/0
 network 0.0.0.0
 no auto-summary

Dynamic routing protocol OSPF can be configured the same way as EIGRP and RIP.

router ospf 1
passive-interface default
 no passive-interface GigabitEthernet0/0
 network 0.0.0.0 255.255.255.255 area 0

However, from the example of OSPF protocol configuration shown above, an obvious restriction occurs: if there are two or more interfaces which address is assigned dynamically, all these interfaces should belong to the same area. Fortunately for OSFP there is an interface command which allows enabling this protocol on a particular interface without specifying IP address, but with specifying area number. The example of such configuration is displayed below, all available interfaces are added to area 1, but Gi0/0 belongs to the backbone area.

interface GigabitEthernet0/0
 ip address dhcp
 ip ospf 1 area 0
!
router ospf 1
 router-id 2.2.2.2
 network 0.0.0.0 255.255.255.255 area 1

Dynamic routing protocol OSPF allows finding out which interfaces and why participate in routing and also to which areas they belong. For displaying the specified information command sho ip proto is purposed, the example of its work is displayed below.

R2#sho ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 1"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Router ID 2.2.2.2
 It is an area border and autonomous system boundary router
 Redistributing External Routes from,
 connected, includes subnets in redistribution
 Number of areas in this router is 2. 2 normal 0 stub 0 nssa
 Maximum path: 4
 Routing for Networks:
 0.0.0.0 255.255.255.255 area 1
 Routing on Interfaces Configured Explicitly (Area 0):
 GigabitEthernet0/0
 Routing Information Sources:
 Gateway         Distance      Last Update
 1.1.1.1              110      00:00:05
 Distance: (default is 110)

One more local dynamic routing protocol popular in the networks of large service providers is ISIS. And though ISIS is rare in corporate networks, we decided to mention it, because configuration of IGP for working with DHCP is rather simple and similar to OSPF one. ISIS doesn't support network command for specifying interfaces on which this protocol works. Instead of this, only the interface command should be used. The example of ISIS settings is shown below.

interface GigabitEthernet0/0
 ip address dhcp
 ip router isis
!
router isis
 net 49.0001.0000.0000.0002.00

Also we decided to provide our readers with the output of several diagnostic commands.

R2#sho isis neighbors
System Id      Type Interface   IP Address      State Holdtime Circuit Id
R1             L1   Gi0/0       192.168.0.1     UP    29       R2.01            
R1             L2   Gi0/0       192.168.0.1     UP    23       R2.01            
R2#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is not set
 1.0.0.0/32 is subnetted, 1 subnets
i L2     1.1.1.1 [115/10] via 192.168.0.1, 00:07:05, GigabitEthernet0/0
 2.0.0.0/32 is subnetted, 1 subnets
C        2.2.2.2 is directly connected, Loopback0
 192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, GigabitEthernet0/0
L        192.168.0.2/32 is directly connected, GigabitEthernet0/0
R2#sho ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "isis"
 Outgoing update filter list for all interfaces is not set
 Incoming update filter list for all interfaces is not set
 Redistributing: connected, isis
 Address Summarization:
 None
 Maximum path: 4
 Routing for Networks:
 GigabitEthernet0/0
 Routing Information Sources:
 Gateway         Distance      Last Update
 192.168.0.1          115      00:06:56
 Distance: (default is 115)

Let’s consider that we dealt with the dynamic routing but the questions about static routing are not less interesting.

Firstly, it may be needed to provide the client via DHCP with not only the default route but other static routes. The default route (option #3) can be provided with the help of default-router command in configuration mode of DHCP pool. Static routes are provided with the help of option #33, requested by the client. We built a small schema to illustrate working of these options.

Routers R1 and R2 have static configuration of the interfaces. To Gi0/0 interfaces 192.168.0.1/24 and 192.168.0.2/24 addresses are assigned. Also on these routers loopback 0 interfaces with addresses 1.1.1.1/32 and 2.2.2.2/32 are configured. Router R3 receives IP parameters dynamically with the help of interface command ip addr dhcp. DHCP settings on router R1 are displayed below. With the help of option 33 static routes are provided.

ip dhcp excluded-address 192.168.0.1 192.168.0.100
ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.0
 dns-server 8.8.8.8
 default-router 192.168.0.1
 option 33 ip 2.2.2.2 192.168.0.2

Naturally, we cannot help but make sure that router R3 has successfully received all necessary parameters.

R3#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.0.101   YES DHCP   up                    up  
R3#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 192.168.0.1 to network 0.0.0.0
S*    0.0.0.0/0 [254/0] via 192.168.0.1
 2.0.0.0/32 is subnetted, 1 subnets
S        2.2.2.2 [254/0] via 192.168.0.2
 192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, GigabitEthernet0/0
L        192.168.0.101/32 is directly connected, GigabitEthernet0/0
R3#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/16 ms

The whole traffic exchange we saved in dump foxnetwork_8.pcapng.

Using of option #33 is rather simple: however, it's impossible to send route with the mask different from /32 with the help of this option. One can perform sending of the route with any mask to DHCP client placed on Cisco router using option #121, but, to be honest, the rule of its configuring is a bit more difficult. All numbers are written in hexadecimal. The first octet contains the length of the mask. After it significant octets meaning addresses of the destination network followed, after them the address of the next router is specified. If it’s needed to send several routes simultaneously, all of them are written one after another without spaces. Let's review all said above on the example. Suppose, we use the previous network schema and want to send the following routes: 1.1.1.1/32 via 192.168.0.1 and 2.2.20/23 via 192.168.0.2. The first route contains four significant octets of the network, the second - three. So the records of the specified routes in hexadecimal are as follows: 2001010101C0A80001 and 17020202C0A80002, where 20 and 17 – length of the masks in hexadecimal, 01010101 and 020202 – hexadecimal record of significant octets of the network address, and C0A80001 and C0A80002 – routers’ addresses. The example of the updated configuration of DHCP pool of router R1 is shown below.

ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.0
 dns-server 8.8.8.8
 option 121 hex 2001.0101.01c0.a800.0117.0202.02c0.a800.02

However, the specified commands are not enough. By default, DHCP client based on Cisco IOS doesn't request option #121 from the server. One can make the client request this option with the help of interface command ip dhcp client request classless-static-route performed on the client. Make sure of the functioning of the specified configuration.

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int gi0/0
R3(config-if)# ip dhcp client request classless-static-route
R3(config-if)#ip add dhcp
R3(config-if)#^Z
R3#
*Aug 16 04:23:03.179: %SYS-5-CONFIG_I: Configured from console by console
*Aug 16 04:23:04.467: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.0.106, mask 255.255.255.0, hostname R3
R3#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.0.106   YES DHCP   up                    up  
R3#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is not set
 1.0.0.0/32 is subnetted, 1 subnets
S        1.1.1.1 [254/0] via 192.168.0.1
 2.0.0.0/23 is subnetted, 1 subnets
S        2.2.2.0 [254/0] via 192.168.0.2
 192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, GigabitEthernet0/0
L        192.168.0.106/32 is directly connected, GigabitEthernet0/0
R3#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms
R3#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/15/20 ms
R3#

Capture of the process of traffic exchange between three routers is provided in the file foxnetwork_9.pcapng.

Sending of static routes to DHCP clients based on other operating systems can be performed with the help of other options, but in any case, any option is just a hex-string, so DHCP server based on Cisco routers can be configured for transmitting of the routing information to the clients based on other operating systems as well.

Also it's worth noting that routes received via DHCP can be transmitted to any dynamic routing protocol with the help of redistribute static command (or redistribute static subnets in case of using OSPF).

By default, DHCP client based on Cisco IOS requests the whole set of options among which is default route (option #3). To restrict the router requesting for some options one can using corresponding interface commands.

R3(config-if)#no ip dhcp client request ?
 classless-static-route       Classless static route (121)
 dns-nameserver               DNS nameserver (6)
 domain-name                  Domain name (15)
 netbios-nameserver           NETBIOS nameserver (44)
 router                       Default router option (3)
 sip-server-address           SIP server address (120)
 static-route                 Static route option (33)
 tftp-server-address          TFTP server address (150)
 vendor-identifying-specific  Vendor identifying specific info (125)
 vendor-specific              Vendor specific option (43)
 <cr>

In the pictures below DHCP discover and DHCP offer messages from routers R3 and R1 are displayed, on router R1 in the mode of DHCP pool configuration default-router command was entered. On Gi0/0 interface of router R3 we preliminary issued no ip dhcp client request router command.

As one can see from DHCP messages shown above, router R3 doesn't request option #3, and R1 doesn't send it to the client. DHCP messages of which routers R1 and R3 exchanged are shown in the file foxnetwork_10.pcapng.

Our attentive reader, probably, has paid attention to the value of administrative distance in the routing table with which default router was appeared, receiving via DHCP – 254. Such AD value tells that almost any statically configured route or route received with the help of any IGP or even BGP seems to have more priority than one received using DHCP. One can change the distance of the default route received via DHCP using ip dhcp-client default-router distance command in global configuration mode. The command in question influences only newly received route and makes unchangeable one which was already included to the routing table. In case the router dynamically receives default route via two or more interfaces, one can change preferences with the help of interface command ip dhcp client default-router distance which influences only the default route received via a particular interface. Illustrate all said above on the example of a small network. Routers R1 and R3 are configured as DHCP servers, and R2 performs functions of DHCP client.

On router R1 the following configuration is set.

interface GigabitEthernet0/0
 ip address 192.168.12.1 255.255.255.0
ip dhcp pool test
 network 192.168.12.0 255.255.255.0
 default-router 192.168.12.1

Configuration of R3 is almost identical.

interface GigabitEthernet0/0
 ip address 192.168.23.3 255.255.255.0
ip dhcp pool test
 network 192.168.23.0 255.255.255.0
 default-router 192.168.23.3

Review the process of receiving IP parameters by router R2 during which we at first receive IP address from router R1, after which change administrative distance globally, repeat request for IP parameters, change administrative distance for Gi1/0 interface and request IP address and default route from router R3.

R2#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         unassigned      YES unset  up                    up  
GigabitEthernet1/0         unassigned      YES unset  up                    up  
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int gi0/0
R2(config-if)#ip add dh
*Aug 16 08:05:21.255: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.12.6, mask 255.255.255.0, hostname R2
R2(config-if)#do sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.12.6    YES DHCP   up                    up  
GigabitEthernet1/0         unassigned      YES unset  up                    up  
R2(config-if)#do sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
S*    0.0.0.0/0 [254/0] via 192.168.12.1
 192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, GigabitEthernet0/0
L        192.168.12.6/32 is directly connected, GigabitEthernet0/0
R2(config-if)#exi
R2(config)#ip dhcp-client default-router distance 10
R2(config)#do sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
S*    0.0.0.0/0 [254/0] via 192.168.12.1
 192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, GigabitEthernet0/0
L        192.168.12.6/32 is directly connected, GigabitEthernet0/0
R2(config)#int gi0/0
R2(config-if)#no ip add dh
R2(config-if)#ip add dh
*Aug 16 08:06:23.807: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.12.7, mask 255.255.255.0, hostname R2
R2(config-if)#do sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.12.7    YES DHCP   up                    up  
GigabitEthernet1/0         unassigned      YES unset  up                    up  
R2(config-if)#do sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
S*    0.0.0.0/0 [10/0] via 192.168.12.1
 192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, GigabitEthernet0/0
L        192.168.12.7/32 is directly connected, GigabitEthernet0/0
R2(config-if)#int gi1/0
R2(config-if)#ip dhcp client default-router distance 5
R2(config-if)#ip add dh
*Aug 16 08:07:00.471: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet1/0 assigned DHCP address 192.168.23.1, mask 255.255.255.0, hostname R2
R2(config-if)#do sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
GigabitEthernet0/0         192.168.12.7    YES DHCP   up                    up  
GigabitEthernet1/0         192.168.23.1    YES DHCP   up                    up  
R2(config-if)#do sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 + - replicated route, % - next hop override
Gateway of last resort is 192.168.23.3 to network 0.0.0.0
S*    0.0.0.0/0 [5/0] via 192.168.23.3
 192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, GigabitEthernet0/0
L        192.168.12.7/32 is directly connected, GigabitEthernet0/0
 192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.23.0/24 is directly connected, GigabitEthernet1/0
L        192.168.23.1/32 is directly connected, GigabitEthernet1/0

Also, probably, it's worth noting that administrator can manually remove or restore these or that routes received with the help of DHCP, from the routing table. Naturally, one can restore only the routes which were announced by DHCP server in DHCP offer message. To be honest, storing is performed with the administrative distance of an ordinary static route in case of not specifying AD value additionally. Also entered command ip route includes to running and/or startup router configuration.

Connecting to the provider with the use of dynamically configured IP address helps provide hosts placed in the user network with access to the global network with the help of NAT/PAT. Review the network displayed on the schema below.

Router R1 belongs to the provider and performs functions of DHCP server for the network 192.168.0.0/24. User router R2 is connected to the provider via its Gi0/0 interface, and to the user local network 192.168.1.0/24 via Gi1/0 interface. Naturally, router R1 doesn't have routes to internal client network. Settings of router R1 are rather simple and displayed below.

ip dhcp pool foxnetwork
 network 192.168.0.0 255.255.255.0
 default-router 192.168.0.1
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
interface GigabitEthernet0/0
 ip address 192.168.0.1 255.255.255.0

Configuration of PC1 host is also rather simple.

PC1> sho ip
NAME        : PC1[1]
IP/MASK     : 192.168.1.2/24
GATEWAY     : 192.168.1.1
DNS         :
MAC         : 00:50:79:66:68:00
LPORT       : 10003
RHOST:PORT  : 192.168.56.1:10002
MTU:        : 1500

The only thing left is to configure router R2. The first from which we start is creating the access list selecting IP addresses for which translation would be performed. Then it's needed to assign IP addresses to interfaces Gi0/0 and Gi1/0, specify internal and external interfaces for NAT and to create the translation itself. On translation creation, it's required to specify key word overload which makes router perform PAT. The example of R2 configuration is displayed below.

interface GigabitEthernet0/0
 ip address dhcp
 ip nat outside
 ip virtual-reassembly in
interface GigabitEthernet1/0
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
ip nat inside source list PAT interface GigabitEthernet0/0 overload
ip access-list extended PAT
 permit ip 192.168.1.0 0.0.0.255 any

Make sure of the correct configuration with the help of PC1 host.

PC1> ping 1.1.1.1
84 bytes from 1.1.1.1 icmp_seq=1 ttl=254 time=29.002 ms
84 bytes from 1.1.1.1 icmp_seq=2 ttl=254 time=29.002 ms
84 bytes from 1.1.1.1 icmp_seq=3 ttl=254 time=29.002 ms
84 bytes from 1.1.1.1 icmp_seq=4 ttl=254 time=29.002 ms
84 bytes from 1.1.1.1 icmp_seq=5 ttl=254 time=29.002 ms

Check the same after enabling of displaying debug information on router R1. Naturally, we don't recommend enabling of debug in high load networks.

R1#deb ip icmp
ICMP packet debugging is on
R1#
*Aug 16 19:58:21.931: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
*Aug 16 19:58:22.959: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
*Aug 16 19:58:23.975: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
*Aug 16 19:58:25.003: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
*Aug 16 19:58:26.035: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0

During checking the following translations are created on router R2.

R2#sho ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 192.168.0.2:16835 192.168.1.2:16835  1.1.1.1:16835      1.1.1.1:16835
icmp 192.168.0.2:17091 192.168.1.2:17091  1.1.1.1:17091      1.1.1.1:17091
icmp 192.168.0.2:17347 192.168.1.2:17347  1.1.1.1:17347      1.1.1.1:17347
icmp 192.168.0.2:17859 192.168.1.2:17859  1.1.1.1:17859      1.1.1.1:17859
icmp 192.168.0.2:18115 192.168.1.2:18115  1.1.1.1:18115      1.1.1.1:18115

Certainly, one can make sure of the correctness of the performed settings with the help of network analyzer Wireshark, analyzing passing packets.

That's where we complete the part describing mutual influence of DHCP and routing and go to the conclusion.

Conclusion

In this article we tried to describe opportunities and examples of using DHCP in rather detailed way. We didn't have an aim to review absolutely all options of all realizations and platforms, instead of this, we decided to make our readers acquainted with the most frequently used options and functions. So, for example, we intentionally missed questions about using DHCP on ATM interfaces, because are naive to believe that time of countrywide implementation of ATM is over.
Despite the fact that almost all configurations are provided for the Cisco equipment, we hope that administrators who own the equipment of other vendors will manage to find in this article a lot of interesting things.

IPv6 in Cisco or the Future is about to come

Introduction

Addressing in IPv6

Basic interface configuration

Static routes

Dynamic routing

Access lists

Tunneling in IPv4 and IPv6

Virtual routing and forwarding (VRF)

Conclusion

Introduction

The IPv6 protocol is a descendant of the IP version four, IPv4, which is widely used everywhere, and consequently, IPv6 inherited most part of the IPv4 operation logic. For instance, packet headings in IPv4 and IPv6 have much in common with; the same logic of transmitting packets is used – routing based on the destination address; the time a packet exists in the net is controlled with the help of TTL and so on. However, there are some major differences: besides the change in the length of the IP-address itself, broadcast of any kind is no longer used, including directed broadcast. Instead, multicast is used. Also, ARP disappeared; its functions are now performed by ICMP, the fact which will make IT security departments keep a close eye on this protocol, because simply banning it is no longer an option. We’re not going to describe all changes that have been introduced to the protocol as the reader can readily find them on any number of IT resources. Instead, we’ll demonstrate some practical examples of setting Cisco IOS devices to work with IPv6.

Many new network specialists are asking the question whether they should start studying IPv6 right away. In our view, these days one cannot treat IPv6 as a separate chapter of technology; on the contrary, all technics should be practiced on both IP versions. For example, studying the dynamic routing protocol EIGRP it’s worth configuring test networks in the lab both for IPv4 and IPv6. Now let’s get down to business!

Addressing in IPv6

In IPv6 the length of the protocol address is 128 bit, which is four times longer than that in IPv4. The number of addresses in IPv6 is huge and is 2128≈3,4•1038. The IP-address in IPv6 can be divided into two parts: a prefix and a host address which is also called an interface ID. Such division is very similar to that used in IPv4 in classless routing.

In IPv6, addresses are put in hexadecimal notation, each group of four digits is separated with a colon. For example: 2001:1111:2222:3333:4444:5555:6666:7777. The mask is written with a slash, for instance, /64. In an IPv6 address, there can be long sequences of zeroes, that’s why there’s a contracted notation possible. Firstly, the beginning zeroes of each group of digits can be omitted, i.e. instead of 2001:0001:0002:0003:0004:0005:0006:7000 it’s possible to write 2001:1:2:3:4:5:6:7000. The ending zeroes are not left out. If a group of digits in the address (or several groups in a row) is comprised of zeroes only, it can be replaced with a double colon. For example, instead of 2001:1:0:0:0:0:0:1 one can use a contracted notation like 2001:1::1. It has to be said that it’s only possible to contract the address in such a way once. Below are correct and incorrect notations of addresses in IPv6.

Correct notation

2001:0000:0db8:0000:0000:0000:07a0:765d
2001:0:db8:0:0:0:7a0:765d
2001:0:db8::7a0:765d

Incorrect notation

2001::db8::7a0:765d
2001:0:db8::7a:765d

Funny contractions

::/0 –default gateway
::1 – loopback
2001:2345:6789::/64 –some network address

However, not all IPv6 addresses can be assigned to global network nodes. There’re several reserved ranges and address types. An IPv6 address can belong to one the three following types

  • Unicast
  • Multicast
  • Anycast

Unicast addresses are very similar to those in IPv4. They can be assigned to end-users’ network equipment interfaces, servers and hosts. Group or Multicast addresses are intended for delivering packets to several receivers simultaneously. When Anycast addresses are used, data will be received by the nearest node with such address. Special attention should be paid to the fact that there’re no broadcast addresses in the list of those supported by IPv6. Even among Unicast addresses there’re smaller types.

  • Link local
  • Global unicast
  • Unique local

Addresses in the Unique local group are described in RFC 4193 and are very similar to private addresses in IPv4 described in RFC 1918. Link local addresses are intended for transmitting information between devices connected to the same L2-network. Most of addresses from the Global unicast range can be assigned to specific network nodes interfaces. The list of reserved addresses is below.

IPv6 address Prefix length Description Remarks
:: 128 - Analogue of 0.0.0.0 in IPv4
::1 128 Loopback Analogue of 127.0.0.1 in IPv4
::xx.xx.xx.xx 96 Built-in IPv4 IPv4-compatible. Obsolete, no longer used
::ffff:xx.xx.xx.xx 96 IPv4, depicted in IPv6 For hosts that don’t support IPv6
2001:db8:: 32 Documenting Reserved for examples. RFC 3849
fe80:: - febf:: 10 Link-Local Analogue of 169.254.0.0/16 in IPv4
fec0:: - feff:: 10 Site-Local Analogue of 10.0.0.0, 172.16.0.0, 192.168.0.0 networks. RFC 3879. Obsolete.
fc00:: 7 Unique Local Unicast Replaced Site-Local. RFC 4193
ffxx:: 8 Multicast -

Basic interface configuration

IPv6 routing is enabled with the help of the ipv6 unicast-routing command. Actually, the router will support IPv6 even without this command; however without it the device will act as a host to IPv6. Many of the commands we got used to in IPv4 are also present in IPv6, one will only have to replace the ip option with ipv6.

The address in the interface can be configured in several ways. When only IPv6 support is turned on, the link-local address is automatically assigned to the interface.

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int gi0/0
R1(config-if)#ipv6 enable
R1(config-if)#^Z
R1#show ipv6 int bri
Ethernet0/0 [administratively down/down]
unassigned
GigabitEthernet0/0 [up/up]
FE80::C800:3FFF:FED0:A008

Parts of a link-local address are calculated with the help of the EUI-64 algorithm on the base of the interface MAC-address. For this, two bytes are automatically added in the middle of the 48-byte MAC-address; in the hexadecimal notation these two bytes look like FFFE; also the seventh bit of the first byte of the MAC-address is inverted. In the pictures below one can see the scheme of the algorithm in question.

Compare the link-local address above to the physical address of the Gi0/0 interface of the router (the immaterial part of the sho int Gi0/0 command output is deleted).

R1#show int gi0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is i82543 (Livengood), address is ca00.3fd0.a008 (bia ca00.3fd0.a008)

EUI-64 part of an IPv6 address: C800:3FFF:FED0:A008.

The interface can be given an address manually with the help of the ipv6 address command, for example, ipv6 address 2001:db8::1/64. It’s possible to specify the address of a network segment only; the rest will be assigned automatically using the interface physical address converted with the help of EUI-64. For this, use the command with eui-64 key word.

R2#conf t
R2(config)#int gi0/0
R2(config-if)#ipv ad 2001:db8::/64 eui-64
R2(config-if)#^Z
R2#show ipv6 int bri
Ethernet0/0 [administratively down/down]
unassigned
GigabitEthernet0/0 [up/up]
FE80::C801:42FF:FEA4:8
2001:DB8::C801:42FF:FEA4:8

Within one L2-segment it’s possible to exchange messages only with link-local addresses and this option is sometimes used; however, in the majority of situations the interface has to be assigned an ordinary routable IPv6-address. For instance, OSPF and EIGRP neighborhood is established using link-local addresses. Automatic neighbor discovery and other service protocols also operate with link-local addresses.

R1#sho ipv6 int brief
Ethernet0/0 [administratively down/down]
unassigned
GigabitEthernet0/0 [up/up]
FE80::C800:42FF:FEA4:8
2001:DB8::1
R1#sho ipv ei ne
IPv6-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 Link-local address: Gi0/0 12 00:01:03 39 234 0 3
FE80::C801:42FF:FEA4:8
R1#ping FE80::C801:42FF:FEA4:8
Output Interface: GigabitEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::C801:42FF:FEA4:8, timeout is 2 seconds:
Packet sent with a source address of FE80::C800:42FF:FEA4:8
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/20/48 ms

Naturally, there’s still the option of automatically assigning an address in IPv6 with the help of DHCP. It’s worth noting however, that there’re two types of DHCP in IPv6: stateless and stateful. Their setting is performed with the help of ipv6 address autoconfig and ipv6 address dhcp, respectively.

Configuring a «server» part practically doesn’t differ from the same for IPv4. First of all it is necessary to create a DHCP pool, then to enable it on an interface. Enabling on an interface is implemented in explicit form using an interface command ipv6 dhcp server name, where the name of earlier created DHCP pool stands for name. It is also of note here that DHCPv6 doesn’t allow excluding definite IPv6 addresses from the range as it was done for IPv4 using a command ip dhcp excluded-address as well as implementing a manual binding of address to a client.

ipv6 dhcp pool test
address prefix 2001:1::/64
dns-server 2001:1::1
domain-name foxnetwork.ru
interface GigabitEthernet1/0
no ip address
negotiation auto
ipv6 address 2001:1::1/64
ipv6 dhcp server test
ipv6 nd managed-config-flag
ipv6 nd other-config-flag

A command ipv6 nd managed-config-flag points to a client the necessity of using DHCPv6 for allocating an address. It is also possible to inform a client about the necessity of getting additional options (address of DNS-server or name of domain) using a command ipv6 nd other-config-flag.

The information about configured DHCPv6 pools can be displayed using a command show ipv6 dhcp pool.

R2#sho ipv dhcp pool
DHCPv6 pool: test
Address allocation prefix: 2001:1::/64 valid 172800 preferred 86400 (1 in use, 0 conflicts)
DNS server: 2001:1::1
Domain name: foxnetwork.ru
Active clients: 1

A list of current clients is represented in the output of a command show ipv6 dhcp binding.

R2#show ipv6 dhcp binding
Client: FE80::C801:26FF:FEFC:1C
DUID: 00030001CA0126FC0008
Username : unassigned
IA NA: IA ID 0x00050001, T1 43200, T2 69120
Address: 2001:1::CDFD:B868:5AFF:F258
preferred lifetime 86400, valid lifetime 172800
expires at Mar 12 2015 08:56 AM (170469 seconds)

To reset current DHCPv6 bindings one should use a command clear ipv6 dhcp binding {* | ipv6-address}.

Viewing the list of interfaces where DHCPv6 protocol is operating is done using a command show ipv6 dhcp interface.

R2#show ipv6 dhcp interface
GigabitEthernet1/0 is in server mode
Using pool: test
Preference value: 0
Hint from client: ignored
Rapid-Commit: disabled

Apart from stateful DHCPv6 Cisco equipment also supports a version DHCPv6 Lite, which differs in absence of address prefix command inside a pool and an interface option managed-config-flag. In this case address of a host interface is computed on basis of a message Router Advertisement.

ipv6 dhcp pool test
dns-server 2001:1::1
domain-name foxnetwork.ru
interface GigabitEthernet1/0
no ip address
negotiation auto
ipv6 address 2001:1::1/64
ipv6 dhcp server test
ipv6 nd other-config-flag

As it was for IPv4 Cisco L3-switches and routers can function as DHCP relay, for which a command ipv6 dhcp relay destination ipv6-address is used, where ipv6-address – an address of DHCPv6 server.

A very interesting facility was introduced in DHCPv6 – prefix delegation. This function, as we suppose, will be mostly in demand among service providers as it allows delegating a large prefix to a client for distributing it in an enterprise network. Let’s consider operating of Prefix Delegation function by example. At the scheme below a router Delegating_router represents an edge router of a service provider, CE_router – client’s border equipment. Client_net1 and Client_net2 emulate devices connected to different client’s IPv6-netwoks. It’s worth making a special emphasis on that Client_net1 and Client_net2 are in different subnets, there is a trunk enabled between SW1 switch and CE_router router, where two virtual networks, #2 (for Client_net1) and #3 (for Client_net2), exist. At CE_router router own subinterface for each virtual network is configured.

The first thing from which setting up should be started is configuring of address at the link between Delegating_router and CE_router routers.

Delegating_router(config)#int gi1/0
Delegating_router(config-if)#no sh
Delegating_router(config-if)#ipv6 address 2001:DB8:1::1/64
Delegating_router(config-if)#^Z
Delegating_router#
CE_router(config)#int gi0/0
CE_router(config-if)#no sh
CE_router(config-if)# ipv6 address 2001:DB8:1::2/64
CE_router(config-if)#^Z
CE_router#

Let’s create a local pool at Delegating_router router from which prefixes will be distributed to clients.

Delegating_router(config)#ipv6 local pool c_prefix 2001:DB8::/40 48

A pool c_prefix is defined as 2001:DB8::/40 prefix from which smaller prefixes with /48 mask will be distributed to clients.

After local pool configuring it is necessary to create DHCPv6 pool which to attach to Gi1/0 interface.

Delegating_router(config)#ipv6 dhcp pool customers
Delegating_router(config-dhcpv6)# prefix-delegation pool c_prefix
Delegating_router(config-dhcpv6)#int gi1/0
Delegating_router(config-if)#ipv6 dhcp server customers

Setting of delegating router finishes here. At the client’s border router delegated prefix should be accepted using an interface command ipv6 dhcp client pd prefix, where prefix is a name of accepted prefix, this name will be used later.

CE_router#sho run int gi0/0
Building configuration...
Current configuration : 170 bytes
interface GigabitEthernet0/0
no ip address
ipv6 address 2001:DB8:1::2/64
ipv6 dhcp client pd prefix
end
CE_router#sho ipv dhcp interface gi0/0
GigabitEthernet0/0 is in client mode
Prefix State is OPEN
Renew will be sent in 3d10h
Address State is IDLE
List of known servers:
Reachable via address: FE80::C801:2FF:FEC8:1C
DUID: 00030001CA0102C80008
Preference: 0
Configuration parameters:
IA PD: IA ID 0x00040001, T1 302400, T2 483840
Prefix: 2001:DB8::/48
preferred lifetime 604800, valid lifetime 2592000
expires at Apr 09 2015 10:39 AM (2587501 seconds)
Information refresh time: 0
Prefix name: prefix
Prefix Rapid-Commit: disabled
Address Rapid-Commit: disabled

Addresses of client’s subnets will be allocated from the received prefix. As for the given client a prefix 2001:DB8::/48 was assigned addresses of client networks will be, for example, such as 2001:DB8:0:1::/64 and 2001:DB8:0:2::/64. Let’s implement corresponding configuring of CE_router router subinterfaces. As it can be seen from the listing below, addresses are not specified in an explicit form, a prefix, earlier obtained from a provider, is used instead.

CE_router#sho run int gi1/0.2
Building configuration...
Current configuration : 97 bytes
interface GigabitEthernet1/0.2
encapsulation dot1Q 2
ipv6 address prefix ::1:0:0:0:1/64
end
CE_router#sho run int gi1/0.3
Building configuration...
Current configuration : 97 bytes
interface GigabitEthernet1/0.3
encapsulation dot1Q 3
ipv6 address prefix ::2:0:0:0:1/64
end

The only thing left to do – to get addresses at client’s hosts.

Client_net1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Client_net1(config)#int gi1/0
Client_net1(config-if)#no sh
*Mar 10 11:38:07.959: %LINK-3-UPDOWN: Interface GigabitEthernet1/0, changed state to up
*Mar 10 11:38:08.959: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0, changed state to up
Client_net1(config-if)#ipv6 address autoconfig
Client_net1(config-if)#exi
Client_net1(config)#exi
Client_net1#sho ipv int bri
GigabitEthernet1/0 [up/up]
FE80::C803:1EFF:FE3C:1C
2001:DB8:0:1:C803:1EFF:FE3C:1C
Client_net1#

Another opportunity related to the use of prefixes is an option of a global detection of the router prefix. Such opportunity allows simplifying a procedure of addresses assignment on interfaces of a router or L3-switch. Let us assume that an enterprise was allocated network 2001:db8:1::/48. This means that all addresses will commence with «2001:db8:1». It is necessary to begin with the detection of a prefix.

R1(config)#ipv6 general-prefix ?
  WORD  General prefix name
R1(config)#ipv6 general-prefix fox ?
  6rd                 6rd
  6to4                6to4
  X:X:X:X::X/<0-128>  IPv6 prefix
R1(config)#ipv6 general-prefix fox 2001:DB8:1::/48
R1(config)#do sho ipv gene
IPv6 Prefix fox, acquired via Manual configuration
  2001:DB8:1::/48 Valid lifetime infinite, preferred lifetime infinite

Once the prefix is configured, it is possible to pass on to its direct assignment on the interface.

R1(config)#int gi0/0
R1(config-if)#ipv address ?
  WORD                General prefix name
  X:X:X:X::X          IPv6 link-local address
  X:X:X:X::X/<0-128>  IPv6 prefix
  autoconfig          Obtain address using autoconfiguration
  dhcp                Obtain a ipv6 address using dhcp
R1(config-if)#ipv address fox ?
  X:X:X:X::X/<0-128>  IPv6 prefix
R1(config-if)#ipv address fox 0:0:0:1::1/64
R1(config-if)#^Z
R1#sho ipv int bri
Ethernet0/0            [administratively down/down]
GigabitEthernet0/0     [up/up]
    FE80::C801:3CFF:FED0:8
    2001:DB8:1:1::1
R1#sho run int gi0/0
Building configuration...
Current configuration : 144 bytes
interface GigabitEthernet0/0
 no ip address
 duplex full
 speed 1000
 media-type gbic
 negotiation auto
 ipv6 address fox ::1:0:0:0:1/64
end

It is necessary to pay special attention to the syntax that is used for assigning address on an interface. The left part of the address is filled with bits from the main prefix (the number of bits corresponds to the length of the main prefix). The remaining part is taken out from the address specified with ipv6 address command. In principle, the left part of the address specified in the interface can be any, it is filled with zero in the example above.

The usage of the main prefix can be combined with automatic address assignment on an interface using SLAAC.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int e0/0
R1(config-if)#ipv add fox 0:0:0:2::/64 ?
  anycast  Configure as an anycast
  cga      Use CGA interface identifier
  eui-64   Use eui-64 interface identifier
  <cr>
R1(config-if)#ipv add fox 0:0:0:2::/64 eui-64
R1(config-if)#^Z
R1#sho ipv int bri
Ethernet0/0            [administratively down/down]
    FE80::C801:3CFF:FED0:6
    2001:DB8:1:2:C801:3CFF:FED0:6
GigabitEthernet0/0     [up/up]
    FE80::C801:3CFF:FED0:8
    2001:DB8:1:1::1

With the help of the sho ipv general-prefix command it is possible to view on which interfaces the addresses using a certain main prefix are configured.

R1#sho ipv general-prefix
IPv6 Prefix fox, acquired via Manual configuration
  2001:DB8:1::/48 Valid lifetime infinite, preferred lifetime infinite
   GigabitEthernet0/0 (Address command)
   Ethernet0/0 (Address command)

To be fair, it is worth noting that it is allowed to define several prefixes with one name. All configured addresses will be assigned on interfaces.

R1#sho run | i general
ipv6 general-prefix fox 2001:DB8:1::/48
ipv6 general-prefix fox 2001:DB8:2::/48
R1#sho ipv gene
IPv6 Prefix fox, acquired via Manual configuration
  2001:DB8:1::/48 Valid lifetime infinite, preferred lifetime infinite
  2001:DB8:2::/48 Valid lifetime infinite, preferred lifetime infinite
   GigabitEthernet0/0 (Address command)
   Ethernet0/0 (Address command)
R1#sho ipv int bri
Ethernet0/0            [administratively down/down]
    FE80::C801:3CFF:FED0:6
    2001:DB8:1:2:C801:3CFF:FED0:6
    2001:DB8:2:2:C801:3CFF:FED0:6
GigabitEthernet0/0     [up/up]
    FE80::C801:3CFF:FED0:8
    2001:DB8:1:1::1
    2001:DB8:2:1::1

As was mentioned above, in IPv6 ARP is no longer used. Neighbors are discovered with the help of NDP (Neighbor Discovery Protocol) through exchanging ICMP messages sending them to the group address FF02::1.

R1#show ipv6 neighbors
IPv6 Address Age Link-layer Addr State Interface
FE80::C801:42FF:FEA4:8 25 ca01.42a4.0008 STALE Gi0/0

In Windows operating systems there’s also a function of looking through the list of neighbors (the analogue of the arp –a command), but the system call is longer now.

C:\>netsh interface ipv6 show neighbors
Interface 1: Loopback Pseudo-Interface 1
Internet Address Physical Address Type
-------------------------------------------- ----------------- -----------
ff02::c Permanent
ff02::16 Permanent
ff02::1:2 Permanent
ff02::1:3 Permanent
ff02::1:ff1e:f939 Permanent
Interface 24: LAN 4
Internet Address Physical Address Type
-------------------------------------------- ----------------- -----------
2001:db8:0: 5::1 00-11-5c-1b-3d-49 Reachable (Router)
fe80::ffff:ffff:fffe Unreachable Unreachable
fe80::211:5cff:fe1b:3d49 00-11-5c-1b-3d-49 Stale (Router)
fe80::218:f3ff:fe73:33d7 Unreachable Unreachable
fe80::a541:1a9:3b2d:7734 Unreachable Unreachable
ff02::1 33-33-00-00-00-01 Permanent
ff02::2 33-33-00-00-00-02 Permanent
ff02::c 33-33-00-00-00-0c Permanent
ff02::16 33-33-00-00-00-16 Permanent
ff02::1:2 33-33-00-01-00-02 Permanent
ff02::1:3 33-33-00-01-00-03 Permanent
ff02::1:ff00:0 33-33-ff-00-00-00 Permanent
ff02::1:ff00:1 33-33-ff-00-00-01 Permanent

Routers in the local segment are discovered in a similar way; only in this case packets are sent to FF02::2. The interested node sends an RS (Router Solicitation) message and gets RA (Router Advertisement) in reply from the router. This reply contains IP parameters of the given network. The described process is shown in the picture below.

Discovery of a router connected to a local network segment is used so that the node will get an IPv6 address with the help of the stateless address autoconfiguration (SLAAC) procedure which is mistakenly also referred to as Stateless DHCP.

Static routes

By default, the IPv6 routing table contains not only networks actually connected, but local addresses as well. Besides, there’s a route to group addresses in it, too.

R1#sho ipv6 routing
IPv6 Routing Table - Default - 3 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
HA - Home Agent, MR - Mobile Router, R - RIP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external
C 2001:DB8::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:DB8::1/128 [0/0]
via GigabitEthernet0/0, receive
L FF00::/8 [0/0]
via Null0, receive

Static routes in IPv6 are set in the well-known way. The only thing one has to note is that when link-local addresses are used, besides the address of the next transition, the interface has to be specified as well.

R1#conf t
R1(config)#ipv ro ::/0 gi0/0 FE80::C801:42FF:FEA4:8
R1(config)#^Z
R1#sho ipv6 routing
IPv6 Routing Table - Default - 4 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
HA - Home Agent, MR - Mobile Router, R - RIP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external
S ::/0 [1/0]
via FE80::C801:42FF:FEA4:8, GigabitEthernet0/0
C 2001:DB8::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:DB8::1/128 [0/0]
via GigabitEthernet0/0, receive
L FF00::/8 [0/0]
via Null0, receive

Dynamic routing

To configure dynamic routing in IPv6 is not much more complicated. Firstly, the network command is no longer used for adding an interface to the routing process. Instead, the ipv6 eigrp 1 command should be run in the interface to enable EIGRP 1 or ipv6 ospf 1 area 0 to add the interface to the backbone area of the OSPF 1 process. By default, the EIGRP routing process in IPv6 is switched off and has to be enabled; however, the “best” thing here is the necessity to keep an eye on assigning the router-id parameter. In IPv4 routing, this parameter could be assigned manually or chosen automatically based on IP-addresses assigned to interfaces. If there’re no IPv4 addresses on a device, router-id for the IPv6 dynamic routing process can be only assigned manually.

For a simple network presented below, let’s configure EIGRP. The R1 router on the Gi0/0 interface has the address 2001:db8::1/64, R2 – 2001:db8::2/64.

First, let’s configure the R1 router.

R1#conf t
R1(config)#ipv6 router eigrp 1
R1(config-rtr)#no shut
R1(config-rtr)#eigrp router-id 1.1.1.1
R1(config-rtr)#int gi0/0
R1(config-if)#ipv6 eigrp 1
R1(config-if)#^Z
R1#sho ipv6 eigrp interfaces
EIGRP-IPv6 Interfaces for AS(1)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/0 0 0/0 0/0 0 0/0 0 0
R1#show ipv6 eigrp neighbors
EIGRP-IPv6 Neighbors for AS(1)

Then we run the same commands on R2, after which this EIGRP-neighborhood is established between the two routers.

R1#
*Mar 21 12:01:13.763: %DUAL-5-NBRCHANGE: EIGRP-IPv6 1: Neighbor FE80::C80E:21FF:FEE4:8 (GigabitEthernet0/0) is up: new adjacency
R1#show ipv6 eigrp neighbors
EIGRP-IPv6 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 Link-local address: Gi0/0 11 00:00:15 40 240 0 2
FE80::C80E:21FF:FEE4:8

On each of the routers let’s create a Loopback1 interface that will simulate connected networks. On R1, the Loopback1 interface will have an IPv6 address 2001:db8:1::1/64, on R2 - 2001:db8:2::1/64. There’re two ways to transmit information about new networks into the dynamic routing protocol: one can either include the new interface into the corresponding protocol or redistribute the routes (redistribute). The only thing one has to bear in mind in the second case is the necessity of specifying metrics. A metric can be specified either explicitly for each redistribution or with the help of the default-metric command. This process is exactly the same as in IPv4, so we’re not going to speak about it in detail.

Output from the R1 router.

R1#show ipv6 route
IPv6 Routing Table - default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
C 2001:DB8::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:DB8::1/128 [0/0]
via GigabitEthernet0/0, receive
C 2001:DB8:1::/64 [0/0]
via Loopback1, directly connected
L 2001:DB8:1::1/128 [0/0]
via Loopback1, receive
EX 2001:DB8:2::/64 [170/2560512]
via FE80::C80E:21FF:FEE4:8, GigabitEthernet0/0
L FF00::/8 [0/0]
via Null0, receive
R1#sho run int loo 1
Building configuration...
Current configuration : 87 bytes
interface Loopback1
no ip address
ipv6 address 2001:DB8:1::1/64
ipv6 eigrp 1
end
R1#sho run | sec router
ipv6 router eigrp 1
eigrp router-id 1.1.1.1

Output from the R2 router.

R2#show ipv6 route
IPv6 Routing Table - default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
C 2001:DB8::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:DB8::2/128 [0/0]
via GigabitEthernet0/0, receive
D 2001:DB8:1::/64 [90/130816]
via FE80::C80D:1EFF:FE28:8, GigabitEthernet0/0
C 2001:DB8:2::/64 [0/0]
via Loopback1, directly connected
L 2001:DB8:2::1/128 [0/0]
via Loopback1, receive
L FF00::/8 [0/0]
via Null0, receive
R2#sho run int lo 1
Building configuration...
Current configuration : 73 bytes
interface Loopback1
no ip address
ipv6 address 2001:DB8:2::1/64
end
R2#sho run | sec router
ipv6 router eigrp 1
eigrp router-id 2.2.2.2
redistribute connected
default-metric 1000 1 100 100 1500

If BGP is used in the network, to manage it, one will have to take a different approach: in BGP different processes are not created for IPv4 and IPv6. Instead, within one “parent” process the address-family command splits IP into versions. Below you can see the output from the R1 router. The R2 is configured in the same way.

R1#show run | sec router bgp
router bgp 65001
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 2001:DB8::2 remote-as 65002
!
address-family ipv4
no neighbor 2001:DB8::2 activate
exit-address-family
!
address-family ipv6
network 2001:DB8:1::/64
neighbor 2001:DB8::2 activate
exit-address-family
R1#show bgp ipv6 summary
BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 3, main routing table version 3
2 network entries using 336 bytes of memory
2 path entries using 208 bytes of memory
2/2 BGP path/bestpath attribute entries using 272 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 840 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DB8::2 4 65002 12 12 3 0 0 00:07:24 1
% NOTE: This command is deprecated. Please use 'show bgp ipv6 unicast'
R1#show bgp ipv6 unicast summary
BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 3, main routing table version 3
2 network entries using 336 bytes of memory
2 path entries using 208 bytes of memory
2/2 BGP path/bestpath attribute entries using 272 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 840 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DB8::2 4 65002 12 12 3 0 0 00:07:34 1
R1#show bgp ipv6 unicast
BGP table version is 3, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8:1::/64 :: 0 32768 i
*> 2001:DB8:2::/64 2001:DB8::2 0 0 65002 i

When the article was being written (the end of March 2014) in the BGP full routing table, there were 500000 prefixes for IPv4 and 17000 entries for IPv6.

The OSPF protocol is configured for operation in an IPv6 network in a similar fashion. The protocol that has to be switched on and configured is called OSPFv3. It is completely independent from IPv4. The third version of the protocol has undergone a number of changes and additions in comparison with the previous implementation of OSPF.

interface GigabitEthernet0/0
no ip address
media-type gbic
speed 1000
duplex full
negotiation auto
ipv6 enable
ipv6 ospf 1 area 0
router ospfv3 1
router-id 1.1.1.1
address-family ipv6 unicast
redistribute connected
exit-address-family

Access lists

There’re also some minor changes in access lists. For instance, a list for an interface is set with the ipv6 traffic-filter command like ipv6 traffic-filter TEST in.

R2#show run | section access
ipv6 access-list TEST
deny icmp any any echo-reply
deny icmp any any echo-request
permit ipv6 any any
R2#show ipv6 access-list
IPv6 access list test
deny icmp any any echo-reply sequence 10
deny icmp any any echo-request (5 matches) sequence 20
permit ipv6 any any (28 matches) sequence 30
interface GigabitEthernet0/0
no ip address
media-type gbic
speed 1000
duplex full
negotiation auto
ipv6 address 2001:DB8::2/64
ipv6 eigrp 1
ipv6 traffic-filter TEST in

After introducing the TEST list for the Gi0/0 interface in the scheme above, the R2 router ceases to respond to echo-requests via ICMP.

R1#ping 2001:db8::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8::2, timeout is 2 seconds:
AAAAA
Success rate is 0 percent (0/5)

Tunneling in IPv4 and IPv6

Quite as interesting a question is connected to the work of tunnels supporting IPv6. The simplest tunnels in the IPv4 medium were IPIP (IP-in-IP) and GRE. For an administrator, almost nothing changes with the introduction of IPv6 when GRE is used. However, IPIP is not supported in IPv6. Instead of it, IPv6IP can be used. A nice peculiarity of GRE is that it’s universal, thanks to which it’s possible to transfer IPv4 and IPv6 protocols both over transportation networks with IPv4 and IPv6. Key words ip or ipv6 after the tunnel mode gre command are responsible for the choice of the network protocol.

Let’s turn to our scheme again and configure a GRE tunnel between the two routers so that IPv4 could work above it, whereas the tunnel itself was in the existing IPv6 network. The listing below shows configuration of tunnel interface of the R1 router. The R2 device is configured in the same way.

R1#sho run int tunnel 1
Building configuration...
Current configuration : 180 bytes
interface Tunnel1
ip address 192.168.0.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel mode gre ipv6
tunnel destination 2001:DB8::2
tunnel path-mtu-discovery
end
R1#ping 192.168.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/87/120 ms

To date, it’s most likely that an administrator will face an opposite situation: it’ll be necessary to transmit IPv6 traffic above an IPv4 network. In this case the configuration will be symmetrical: IPv4 and IPv6 settings just change places. It is worth mentioning that currently in GRE tunnels over IPv6 keepalive messages are not supported.

Besides the given tunnels, there’re several more rather widely spread types: 6to4, 6in4, 6rd, Teredo, ISATAP; however, describing them goes way beyond the scope of this article. Co-existence of IPv4 and IPv6 networks can go along one of three scenarios: use of different tunnels mentioned above; in the dual stack mode when all devices support both versions of IP; or with the help of translations like NAT-PT.

Virtual routing and forwarding (VRF)

One more issue we’d like to discuss in this brief review of IPv6 is VRF. In a multi-protocol medium, VRF is configured slightly differently – without specifying the key ip in the beginning. Here the address-family approach that we saw in configuring BGP is also used. The key word for creating VRF is definition.

R1#conf t
R1(config)#vrf definition test
R1(config-vrf)#rd 1:1
VPN Routing/Forwarding instance configuration commands:
address-family Enter Address Family command mode
default Set a command to its defaults
description VRF specific description
exit Exit from VRF configuration mode
no Negate a command or set its defaults
rd Specify Route Distinguisher
route-target Specify Target VPN Extended Communities
vnet Virtual NETworking configuration
vpn Configure VPN ID as specified in rfc2685
R1(config-vrf)#address-family ?
ipv4 Address family
ipv6 Address family
R1(config-vrf)#address-family ipv6
R1(config-vrf-af)#?
IP VPN Routing/Forwarding instance configuration commands:
default Set a command to its defaults
exit-address-family Exit from vrf address-family configuration submode
export VRF export
import VRF import
inter-as-hybrid Inter AS hybrid mode
maximum Set a limit
mdt Backbone Multicast Distribution Tree
no Negate a command or set its defaults
protection Configure local repair
route-target Specify Target VPN Extended Communities
snmp Modify snmp parameters
R1(config-vrf-af)#^Z
R1#conf t
R1(config-if)#int loo 2
R1(config-if)#vrf forwarding test
R1(config-if)#^Z
R1#sho vrf
Name Default RD Protocols Interfaces
test 1:1 ipv6 Lo2

A routing protocol is added to VRF also with the help of the address-family option. It’s possible to add not only named processes to VRF, but numbered, too.

R1#sho run | sec router
router eigrp test
address-family ipv6 unicast vrf test autonomous-system 1
topology base
exit-af-topology
eigrp router-id 1.1.1.1
exit-address-family
R1#sho run int gi0/0
interface GigabitEthernet0/0
vrf forwarding test
no ip address
media-type gbic
speed 1000
duplex full
negotiation auto
ipv6 address 2001:DB8::1/64
end
R1#sho ipv route vrf test
IPv6 Routing Table - test - 4 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
C 2001:DB8::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:DB8::1/128 [0/0]
via GigabitEthernet0/0, receive
D 2001:DB8:2::/64 [90/2570240]
via FE80::C80E:21FF:FEE4:8, GigabitEthernet0/0
L FF00::/8 [0/0]
via Null0, receive
R1#sho eigrp address-family ipv6 vrf test neighbors
EIGRP-IPv6 VR(test) Address-Family Neighbors for AS(1)
VRF()
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 Link-local address: Gi0/0 10 00:01:53 56 336 0 3
FE80::C80E:21FF:FEE4:8

Conclusion

Completing this introductory bit, we’d like to note the following.

  1. It’s got more difficult for administrators to memorize their network addressing
  2. One has to get the hang of loooong notations of networks/hosts in IPv6
  3. One should get accustomed to and master automatic discovery and exploration of neighbors (routers and end-stations) and put up with no broadcast
  4. Node channel information is in the IP-address. ARP (and other protocols) is mostly redundant – EUI-64 is enough for detecting a host
  5. The devil is not as black as it is painted. IP is still IP – in principle everything is very similar, the change in transport doesn’t have any major effect on the principles of modern data transferring networks
  6. In the majority of situations, NAT/PAT network addresses translation – rather a resource-intensive operation – is not necessary in IPv6
  7. In a network, it’s possible that several hosts have identical valid routable IPv6 addresses. This is so called anycast. One should also get used to the fact that on a router different interfaces there can be addresses from the same subnet of unroutable link-local interfaces
  8. One can either make a gradual move from IPv4 to IPv6 or support both protocols for some time needed for a global move to IPv6
  9. Cisco and other network equipment vendors have long been ready to move to IPv6. Now it administrators’ turn.