Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Introduction

External design and hardware

Firmware upgrade

Web-interface

Wireless controller

Command line

Testing

Conclusion

Introduction

Usually on the site of our laboratory, there are reviews of specific network equipment, certain devices and models. Occasionally, you can find articles on any technology without reference to the manufacturer. However, today we want to move a little away from the usual framework and provide our readers with a review of the wireless solution from Zyxel, which includes several components. In fairness, it is worth saying that we did not limit ourselves to any “turnkey solution”; instead, it was decided to consider several devices working both separately and in conjunction with each other.

Two types of equipment provide the work of wireless networks: access points and wireless controllers. Of course, we can also include supporting wired infrastructure here, but this time we decided not to touch on this issue. We had two access points: the Zyxel NWA5123-AC and the WAC6103D-I, as well as the hardware firewall Zyxel ZyWALL 310, which served as a controller.   

So let's get started!

External design and hardware

The Zyxel NWA5123-AC access point has a white plastic case, the dimensions of which are 130x130x55 mm with a mass of only 300 g. The top panel contains the name of the vendor, as well as a LED that displays the status of the device.

The console port, the Gigabit Ethernet interface, the connector for connecting an external power adaptor, a sticker with brief information about the device, the ventilation grate, and the system for fixing the access point to the wall or ceiling are located on the bottom panel.

The NWA5123-AC model can be powered by an AC adapter (supplied), or via PoE. Power consumption of the device is 9 watts.

Two green textolite boards, one of which serves as a wireless module, represent the electronic filling of the Zyxel NWA5123-AC access point. Unfortunately, almost all the components of interest to us are hidden under protective screens. For viewing, only the Texas Instruments TPS23756 PoE controller is available, as well as two Macronix 25L12835F flash memory modules, each of which is 16 MBytes.

The Zyxel WAC6103D-I access point is made in a white plastic case, the dimensions of which are 204x192x35 mm with a mass of 445 g. This model can be called really thin.

On the top panel there are lights indicating the status of the device as a whole, as well as wired and wireless interfaces.

Ventilation grate occupies a significant portion of the lower surface of the access point. Also here are small stickers with brief information about the model and a special mount that allows you to place the access point on the wall or under the ceiling. In a small recess, there are two Gigabit Ethernet ports; hardware switch that allows you to choose the method of placement; Reset button to reset user settings and console port. The access point is powered only with the help of Power over Ethernet technology, the use of any other power supply is not provided. Power consumption is 12.48 watts.

The hardware platform is represented by one green textolite board, the main elements are located on one side. Unfortunately, almost all chips are hidden under protective screens. For viewing, only the flash memory module Micron Technologies 29F2G08ABAEA, which is 256 MByte, and the Texas Instruments TPS23756 PoE controller are available.

We will not analyze the hardware features of the ZyWALL 310 firewall here, since in this case this device acts only as an example of network equipment that can be assigned the role of a wireless controller. The only thing that confuses us a bit is that we did not find among the large list of devices with the support of the role of WLC models with two power supplies. It seems to us that corporate products designed to work in large networks should have this option.

Firmware upgrade

Access points of the NWA5123-AC and WAC6103D-I models can operate in one of two modes: standalone or managed by a wireless controller. When working in a standalone mode, the firmware is updated using the “Firmware Package” tab of the “File Manager” item in the “MAINTENANCE” menu. The whole process takes about five minutes and does not require any specialized qualifications from the user.

You can make sure that the firmware has been updated successfully using the “DASHBOARD” menu.

When building a corporate wireless network without a controller cannot do. When access points operate in managed mode, their software is also updated using the controller. However, before proceeding to consider the process of centralized firmware upgrades at access points, we would like to consider the procedure for changing the firmware on the controller itself. In our case, the WLC functions were assigned to the Zyxel ZyWALL 310 firewall, so we’ll update it. Updating the controller is necessary not only to add new options, but also to expand the list of supported access points.

The ZyWALL 310 firmware is upgraded using the “Firmware Management” tab in the “File Manager” item of the “SERVICE” menu. The whole process takes about five minutes (without taking into account the time required to download a file with a new firmware from the Internet) and does not require any specialized training from the administrator.

In fairness, it is worth noting that the update ZyWALL 310 can occur not only in semi-automatic, but also in fully automatic mode (according to the schedule).

After the software of the controller itself has been updated, you can refer to the “Firmware” tab of the “Manage Access Points” item of the “Wireless Network” group of the “CONFIGURATION” menu to update the firmware on all managed access points. The success of a wireless network requires that all managed access points have the same firmware version. If there are discrepancies in the installed firmware, the controller will automatically update or downgrade the firmware version.

It is also worth noting that Zyxel offers the ZAC utility - Zyxel AP Configurator, which allows you to automate some routine processes of servicing several access points in a network without a controller.

So, the latest firmware is installed on the controller and access points, now we will figure out what opportunities are available to the network administrator when the access points operate in a standalone mode and under the control of the wireless controller.

Web-interface

You can access the Zyxel NWA5123-AC access point web interface using any modern browser. Access is via HTTPS. The default address is 192.168.1.2. To log on, you must enter the login and password, equal to the default admin/1234. We will not consider in detail all the features of the device web interface; however, we’ll dwell on the most interesting ones.

 

After entering the correct credentials, the user gets to the start page of the device (menu “Dashboard”), which contains information about the access point itself, the operating system and network interfaces. The administrator can optionally enable or disable the display of this or that information.

 

Using the “Network Status” item of the “Monitor” menu, the administrator can obtain information about the operation parameters of the network interfaces of the access point, as well as view statistical data.  

 

 

Using the items of the “Wireless” group of the “Monitor” menu, the administrator can view information on the operation of wireless modules for both frequency bands; find out which wireless clients are connected; examine existing WDS connections; and also display a list of suspicious access points.  

 

 

 

 

 

 

The Log item contains log information about the operation of the NWA5123-AC model.

 

IP parameters are managed using the “Network” item of the “Configuration” menu. It is worth noting that the NWA5123-AC supports not only IPv4, but also IPv6. In addition, here you can choose how to discover a wireless controller.   

 

 

 

In the case access points managed by WLC, almost all parameters of their operation are set with its help. However, when standalone access points operate, the wireless parameters are managed using the “Wireless” group items in the “Configuration” menu. Here, the administrator for each of the frequency ranges can select the device operation mode (access point, monitoring mode, root access point or repeater), select a radio module profile, specify the maximum transmitted power, configure load balancing parameters on access points, and select an available radio channel.

 

 

 

 

 

Management of user accounts with access to the management interface of the access point itself is performed using the “User” item of the “Object” group of the “Configuration” menu.

 

 

 

To change and create profiles of wireless modules, you must refer to the “AP Profile” item of the same group.

 

 

 

 

 

 

 

 

 

The management of the device operation profiles in the monitoring mode is performed using the “MON Profile” item.

 

 

WDS profile settings are collected in the same section of the “Object” group.  

 

 

The “Certificate” item is intended for managing your own and trusted certificates.

 

 

 

You can change the name of the access point, set the date and time on the device, as well as control the operation parameters of the HTTP(S), SSH, Telnet, FTP and SNMP protocols using the items in the System group.

 

 

 

 

 

 

 

To change the settings for saving and sending log information, you must refer to the items in the “Log & Report” group. The “Diagnostics” item of the “Maintenance” menu is responsible for selecting the stored information.

 

 

 

 

You can change the configuration files, update the firmware, and start the script execution using the tabs of the “File Manager” item in the “Maintenance” menu.

 

 

 

If necessary, the administrator can turn off the indicator light located on the device, the corresponding setting is available in the item “LEDs” of the same menu.

 

Shutting down and rebooting the NWA5123-AC model is performed using the “Maintenance” menu items of the same name. It is worth noting that the vendor strongly recommends that you programmatically turn off access points before turning off the power supply to them.  

 

 

 

After this section has been completely written, we have discovered a new version of the firmware on the manufacturer’s website, in which the page design has been significantly reworked, but the essence has remained the same.

 

In conclusion, it is worth noting that the web interface of access points may differ slightly due to the difference in the set of supported functions. For example, the model WAC6103D-I has a hardware switch that allows you to choose the location of the access point: on the wall or on the ceiling. The corresponding setting is also present in the web interface of the model under discussion (tab “Antenna Switch” of the sub-item “Antenna” of the menu “MAINTENANCE”).

 

This concludes the study of the web interface capabilities of Zyxel access points that operate in a standalone mode, and proceed to consider the web interface of the ZyWALL 310 based wireless controller.

Wireless controller

Zyxel access points can operate in two modes: standalone, that is, independently, without a controller, and with centralized control using a wireless controller. The corresponding setting is available in the “AC Discovery” tab of the “Network” item of the “CONFIGURATION” menu.

The administrator can either completely abandon the use of the wireless controller, or specify it manually (primary and backup). An automatic search for a controller on the network is also allowed; in this case, the access point periodically broadcasts the CAPWAP control Discovery Request messages. An example of such a message is presented below.

At our disposal was the hardware firewall Zyxel ZyWALL 310, which allows us to assume the role of a wireless controller in the network. We will not consider any other features of this device other than those directly related to the management of wireless devices.

The “Wireless Network” group of the “MONITORING” menu allows the administrator to get information about access points detected (both trusted and non-trusted), the number of connected client devices, operation parameters of wireless interfaces, configured SSIDs.     

The latest firmware versions allow you to create a mesh network based on existing access points, you can view the relevant information using the “ZyMesh” item of the same group.

If necessary, the administrator can get access to the log information stored on each individual point from the controller, for which you will need to refer to the “Wireless Log” tab of the “Log” item in the “MONITORING” menu.

The connected wireless equipment is controlled using the items of the “Wireless Network” group in the “CONFIGURATION” menu. For example, using the “Controller” item, the administrator can select the country code in which the wireless network is being deployed, as well as specify the method of registering access points on the controller.

The “List of Managed Access Points” tab in the “Access Point Management” item allows you to edit certain parameters of each access point, reboot equipment, start dynamic channel selection (DCS - Dynamic Channel Selection), turn on or off the LEDs on the front panel of the access point. Using the controller, it is allowed to redefine the parameters of the transmitter power of each of the points, the SSID value, the VLAN settings and the physical port, as well as the operating parameters of the indicator lights.

Here it is worth noting that access points can operate in one of the following modes: Access Point Mode, Monitoring Mode, Root AP, and Repeater. The latter two are used in building ZyMesh networks. Access points that have a wired connection to the controller should work in the Root AP mode, for those that do not have direct access to the wired part of the network, select the Repeater mode.

The “Access Point Policy” tab is used to change the parameters of the wireless controller's detection by the access point, as well as the method for updating the firmware on the equipment under control.

Managing a large number of access points will be much more convenient if you pre-group them. The corresponding setting is available in the “Access Point Group” tab.

The choice of firmware, under the control of which the access points operate, is made using the “Firmware” tab. All controlled access points must have the same firmware version so that the controller can manage them. Unfortunately, the administrator does not have the ability to manually upload a new firmware for a particular access point to the controller, since firmware download is supported only in automatic mode and from the vendor’s website.

Lists of illegal and trusted access points are managed using the Monitoring Profiles item.

In the event of an access point failure, the wireless controller can automatically change the operating parameters of the remaining devices so as to restore the wireless coverage of the problem area. To control this option is the item "Auto Healing".

To control the positioning system Ekahau RTLS (Real Time Location Service), you need to refer to the same point.

In conclusion, we add that in order to manage ZyMesh networks, you need to refer to the “ZyMesh Profile” item of the “Object” group of the “CONFIGURATION” menu, and to manage the wireless profiles you will have to use the “Access Point Profiles” item of the same group.   

A nice feature that we found when setting up a security profile was support for fast roaming within the IEEE 802.11r standard.

Finally, we want to make one obvious conclusion that some options are available for changing both when the access point is operating in standalone mode and under the control of the controller. For example, we are talking about the choice of SSID or wireless channel. However, a number of functions appear only when choosing a centralized control method. These features include the Auto Healing option, which allows neighboring access points to try to replace a failed device.

This concludes a brief review of the capabilities for managing a wireless network using a controller and proceed to consider the capabilities of the command line interface.

Command line

Enabling/disabling access to the device command line is performed using the “SSH” and “TELNET” sub-items in the “CONFIGURATION” menu of the web interface. SSH access is enabled by default, while support for the Telnet protocol is usually disabled for security reasons.

It is also worth noting that the administrator can view the commands that will be added to the device configuration after the changes are applied.

To gain access to the device command line, you must enter a login and password.

***************** Warning **********************
* *
* Telnet service is not a secure service!! *
* Please use SSH service for remote management *
* *
************************************************
Welcome to WAC6100
Username: admin
Password:
Bad terminal type: "ansi". Will assume vt100.
Router>
apply
atse
clear
configure
copy
daily-report
debug
delete
diag Diagnostic
diaginfo
dir
disable
enable
exit
htm
interface
no
nslookup
packet-trace
ping
ping6
psm
reboot
release
rename
renew
run
setenv
show
shutdown
sshcon
telnet
test
tracepath
tracepath6
traceroute
traceroute6
wlan-report
write
Router>

The command line of the Zyxel access points is very similar to the Cisco CLI, so network administrators who are familiar with the hardware of the specified vendor will have no difficulty in understanding the Zyxel command interpreter. The only thing that confused us at the beginning was the impossibility of using abbreviated versions of commands, but you quickly get used to it, especially considering the possibility of automatic writing a command when you press the Tab key.

Router> ena
% Command not found
retval = -1
ERROR: Parse error/command not found!
Router> enable

We will not examine in detail all the features of the command line of Zyxel wireless equipment, however, a few frequently used commands will be considered.

Using the show interface all call, you can get information about which network interfaces the device has and what their status is.

Router# show interface all
No. Name Status IP Address Mask IP Assignment
===============================================================================
2 lan Up 192.168.1.21 255.255.255.0 Static
3 wlan-1 n/a n/a n/a n/a
4 wlan-1-1 Up 0.0.0.0 0.0.0.0 static

The show capwap command options allow the administrator to examine the communication status of the access point with the wireless controller.

Router# show capwap
ap
bridge
fw-updating
vlan
Router# show capwap ap
ac-ip
discovery-type
idle
info
Router# show capwap ap info
;
|
Router# show capwap ap info
 AC-IP 192.168.1.255
 Fallback Disable
 Fallback Interval 0
 Discovery type Broadcast
 SM-State DISC(2)
 msg-buf-usage 0/10 (Usage/Max)
 capwap-version 10003
 Radio Number 2/4 (Usage/Max)
 BSS Number 8/8 (Usage/Max)
 IANA ID 037a
 Description

The show cpu status command provides information about the average CPU utilization of the access point, while you will have to use the show system uptime call to view the time elapsed since the last power up.

Router# show cpu status
CPU utilization: 1 %
CPU utilization for 1 min: 1 %
CPU utilization for 5 min: 2 %
Router# show system uptime
system uptime: 00:39:20

If the device is busy searching for rogue access points, then information about the operation of this mechanism can be obtained using the show rogue-ap detection info command.

Router# show rogue-ap
containment
detection
Router# show rogue-ap detection
info
list
monitoring
status
Router# show rogue-ap detection info
;
|
Router# show rogue-ap detection info
rogue ap: 0
friendly ap: 0
adhoc: 0
unclassified ap: 0

The current configuration of the access point can be obtained using the show running-config command. Only a small part of the configuration is provided below.

Router# show running-config
!
!
hybrid-mode standalone
!
hardware-watchdog-timer 10
!
software-watchdog-timer 300
!
interface-name ge1 ge1
!
interface-name br0 lan
!

The device serial number can be obtained remotely from the output of the show serial-number command. In identifying a specific access point on the ground, the led_locator command may also be useful, which includes a special LED on the front panel of the device.

Router# show serial-number
serial number: S172L16141905
Router(config)# led_locator
blink-timer
off
on
Router(config)# led_locator blink-timer
<1..60>
Router(config)# led_locator blink-timer
Router(config)# show led_locator status
Locator LED Status : ON
Locator LED Time : 1
Locator LED Time Lease: 367

The show socket command will help determine the open ports and sessions.

Router# show socket open
No. Proto Local_Address Foreign_Address State
===============================================================================
1 tcp 127.0.0.1:6379 127.0.0.1:40195 ESTABLISHED
2 tcp 127.0.0.1:40196 127.0.0.1:6379 ESTABLISHED
3 tcp 127.0.0.1:40195 127.0.0.1:6379 ESTABLISHED
4 tcp 192.168.1.21:23 192.168.1.120:59163 ESTABLISHED
5 tcp 127.0.0.1:6379 127.0.0.1:40196 ESTABLISHED
6 tcp 127.0.0.1:6379 127.0.0.1:40193 ESTABLISHED
7 tcp 127.0.0.1:40193 127.0.0.1:6379 ESTABLISHED
8 udp 0.0.0.0:161 0.0.0.0:0
9 udp 0.0.0.0:43605 0.0.0.0:0
Router# show socket listen
No. Proto Local_Address Foreign_Address State
===============================================================================
1 tcp 0.0.0.0:80 0.0.0.0:0 LISTEN
2 tcp 127.0.0.1:50000 0.0.0.0:0 LISTEN
3 tcp 0.0.0.0:21 0.0.0.0:0 LISTEN
4 tcp 0.0.0.0:22 0.0.0.0:0 LISTEN
5 tcp 0.0.0.0:443 0.0.0.0:0 LISTEN
6 tcp 127.0.0.1:60000 0.0.0.0:0 LISTEN
7 tcp 127.0.0.1:60001 0.0.0.0:0 LISTEN
8 tcp 127.0.0.1:60002 0.0.0.0:0 LISTEN
9 tcp 127.0.0.1:60003 0.0.0.0:0 LISTEN
10 tcp 127.0.0.1:6379 0.0.0.0:0 LISTEN

Information about the access point model and firmware is provided by the show version command.

Router# show version
Zyxel Communications Corp.
model : WAC6103D-I
firmware version: V5.10(AAXH.2)
BM version : V2.3
build date : 2017-10-02 05:59:08

Information on the operation of the wireless module can be obtained using the options of the show wlan command.

Router# show wlan
<slot1,...>
all Everything
channels
country-code
radio
Router# show wlan all
;
|
Router# show wlan all
slot: slot1
 card: none
 Role: ap
 Profile: default
 SSID_profile_1: default
 SSID_profile_2:
 SSID_profile_3:
 SSID_profile_4:
 SSID_profile_5:
 SSID_profile_6:
 SSID_profile_7:
 SSID_profile_8:
 SLOT_1_Output_power: 30dBm
 Activate: yes
 WDS_Role: none
 WDS_Profile: default
 WDS_uplink: auto
 Antenna_Type: ceiling
slot: slot2
 card: none
 Role: ap
 Profile: default2
 SSID_profile_1: default
 SSID_profile_2:
 SSID_profile_3:
 SSID_profile_4:
 SSID_profile_5:
 SSID_profile_6:
 SSID_profile_7:
 SSID_profile_8:
 SLOT_2_Output_power: 30dBm
 Activate: no
 WDS_Role: none
 WDS_Profile: default
 WDS_uplink: auto
 Antenna_Type: ceiling
Router# show wlan country-code
;
|
Router# show wlan country-code
Default Country Code : ED
Router# show wlan radio
% (after 'radio'): Parse error
retval = -1
ERROR: Parse error/command not found!
Router# show wlan radio
macaddr
Router# show wlan radio macaddr
;
|
Router# show wlan radio macaddr
slot1: B8:EC:A3:AC:5C:1A
slot2: B8:EC:A3:AC:5C:1B
Router# show wlan channels
11A
11G
Router# show wlan channels 11
11A 11G
Router# show wlan channels 11A
;
cw
|
Router# show wlan channels 11A
Available Channels: ED
No. Channel string
===============================================================================
1 36 36
2 40 40
3 44 44
4 48 48
5 52 52 - (DFS)
6 56 56 - (DFS)
7 60 60 - (DFS)
8 64 64 - (DFS)
9 100 100 - (DFS)
10 104 104 - (DFS)
11 108 108 - (DFS)
12 112 112 - (DFS)
13 116 116 - (DFS)
14 120 120 - (DFS)
15 124 124 - (DFS)
16 128 128 - (DFS)
17 132 132 - (DFS)
18 136 136 - (DFS)
19 140 140 - (DFS)
Router#

A complete list of ‘show’ commands is presented below.

Router# show
aaa
address-object
address-object-match
address6-object
antenna
app-watch-dog
apply
arp-table
arpseal
boot
bridge
ca
capwap
clock
comport
console Console
contingency-access
cpu
daily-report
dcs
description
dhcp6
diag-info
diaginfo
disk
dual-image
extension-slot
force-auth
fqdn
hardware-watchdog-timer
hybrid-mode
interface
interface-name
ip
ipv6
language
led
led_locator
led_suppress
load-balancing
lockout-users
logging
mac
manager
mem
ntp
object-group
periodically-collect-data
port
power
radius-server
ram-size
reference
report
rogue-ap
rtls
running-config
serial-number
session
slide-switch
snmp
snmp-server
socket
software-watchdog-timer
speed-test
sshcon
system
username
users
version
vlan
vrpt
web-auth
wireless-hal
wlan
wlan-l2isolation-profile
wlan-macfilter-profile
wlan-monitor-profile
wlan-monitor-profile-by-slot
wlan-radio-profile
wlan-radio-profile-by-slot
wlan-security-profile
wlan-ssid-profile
wlan-wds-profile
zon
zymesh-profile

Zyxel office access points can operate in one of two modes: standalone and managed by a wireless controller. Switching between modes can be done using the hybrid configuration mode of the global configuration mode. After changing the mode, the device will automatically reboot.

Router(config)# hybrid-mode
managed
standalone

As we mentioned earlier, the Zyxel WAC6103D-I wireless access point has a software and hardware switch that allows you to explicitly specify the type of device placement: on the wall or on the ceiling. Management of this switch, obviously, can be done not only using the web interface.

Router(config)# antenna
config
sw-control
Router(config)# antenna sw-control
enable
Router(config)# antenna sw-control enable
;
|
Router(config)# antenna sw-control enable
Router(config)# antenna config
slot1
slot2
Router(config)# antenna config s
slot1 slot2
Router(config)# antenna config slot
slot1
slot2
Router(config)# antenna config slot1
chain3
Router(config)# antenna config slot1 chain3
ceiling
wall
Router(config)# antenna config slot1 chain3 wall
;
|
Router(config)# antenna config slot1 chain3 wall

To conclude our brief overview of the command line capabilities of the Zyxel wireless terminal equipment, we would like to point out two obvious commands: reboot — reboot the device; copy running-config startup-config — saves the changes made by the administrator.

Testing

Traditionally, we begin this section with measuring the device booting time, which is the time interval from the moment the equipment is powered up and until the first ICMP echo reply is received. The Zyxel NWA5123-AC access point boots in 65 seconds, while the WAC6103D-I will take a little longer to boot - 68 seconds. We consider this a good result. We also decided to find out in what time the access points can not only boot, but also successfully register on the controller. We tracked the registration of access points using the “Access Points List” tab of the “Access Points” item of the “Wireless Network” group of the “MONITORING” menu. The NWA5123-AC model takes approximately 95 seconds to boot and register with the wireless controller. Model WAC6103D-I for the same operation will take about 105 seconds. Thus, it turns out that the procedure of searching for the controller and registering on it takes approximately 30-40 additional seconds. In our opinion, this is quite a decent result.

Zyxel wireless equipment supports mesh networks (ZyMesh feature). We decided to find out in what time the access point of the NWA5123-AC model would boot, connect to the existing wireless network based on the ZyWAL 310 controller and the root access point WAC6103D-I. The whole process of booting and association took approximately 101 seconds (measurements were made according to the access point state in the web interface of the controller), thus connecting to the existing ZyMesh network from one hop takes about 6 seconds.

The time it takes to boot the wireless controller will depend on which particular device plays the role of the WLC on the network. At our disposal was the hardware firewall Zyxel ZyWALL 310, which in our tests was assigned the role of controller. In our case, the ZyWALL 310 model booted in 115 seconds (of course, we understand that the indicated time depends on the firmware version and activated services).

The next, no less traditional test is a device security check, conducted with the help of a network security scanner Positive Technologies XSpider 7.8. When scanning both access points, five open ports were detected: UDP-161 (SNMP), TCP-443 (HTTPS), TCP-22 (SSH), TCP-21 (FTP) and TCP-80 (HTTP). In both cases, the network security scanner detected well-known credentials for the SNMP protocol. To the credit of the vendor, it is worth noting that the administrator is notified of this each time on connecting to the AP web interface.

However, what really raises concerns is also related to the support of the SNMP protocol - these are suspicions of multiple vulnerabilities in protocol implementations. The standard recommendation in this case is to disable support for the first version of SNMP protocol.  

Both of our access points (models NWA5123-AC and WAC6103D-I) allow you to specify the IP address of the main and backup controllers explicitly. This feature will be useful in a situation when the control interface of the access points and the wireless controller are located in different network segments, different IP subnets. We decided to test the functionality of this option, so we installed a router between the access points and the controller, and then set the controller address for one of them.

Testing has shown that the access point has successfully registered to the controller.

Obviously, this solution cannot be called scalable, since the administrator would have to configure each access point manually. Fortunately, there is an industrial solution, which we also decided to test. Its essence is to inform the access points of the controller address using DHCP. We captured the DHCP Discover message sent by the device and found option # 138 (CAPWAP Access Controllers) in the list of requested options.

We added the appropriate setting to our test DHCP server configuration and rebooted the access point.

switch#sho run | sec dhcp
ip dhcp excluded-address 192.168.20.1 192.168.20.199
ip dhcp pool test2
network 192.168.20.0 255.255.255.0
default-router 192.168.20.10
dns-server 8.8.8.8
option 138 ip 192.168.1.1

The second access point also registered to the wireless controller successfully.

One of the differences between the access points being tested in our laboratory is the presence of an external power supply. For example, the NWA5123-AC model has an external power adapter, whereas for the WAC6103D-I model, its use is not provided for in principle. Regardless of the model, both devices make it possible to consume power using PoE technology, which requires either special injectors or a switch with the support of the corresponding technology. A more scalable solution, obviously, is the use of switches supporting IEEE 802.3af-2003 and IEEE 802.3at-2009 standards. The listing below provides information on the power consumption of both access points with light user traffic.

switch#sho lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
nwa5123-ac Gi1/0/3 120 B,W,R 1
wac6103d-i Gi1/0/5 120 B,W,R 1
Total entries displayed: 2
switch#sho power inline
Module Available Used Remaining
(Watts) (Watts) (Watts)
------ --------- -------- ---------
1 240.0 30.8 209.2
Interface Admin Oper Power Device Class Max
(Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Gi1/0/1 auto off 0.0 n/a n/a 30.0
Gi1/0/2 auto off 0.0 n/a n/a 30.0
Gi1/0/3 auto on 15.4 Ieee PD 0 30.0
Gi1/0/4 auto off 0.0 n/a n/a 30.0
Gi1/0/5 auto on 15.4 Ieee PD 4 30.0
Gi1/0/6 auto off 0.0 n/a n/a 30.0
Te1/0/7 auto off 0.0 n/a n/a 30.0
Te1/0/8 auto off 0.0 n/a n/a 30.0
switch#sho power inline gi1/0/3 de
Interface: Gi1/0/3
Inline Power Mode: auto
Operational status: on
Device Detected: yes
Device Type: Ieee PD
IEEE Class: 0
Discovery mechanism used/configured: Unknown
Police: off
Power Allocated
Admin Value: 30.0
Power drawn from the source: 15.4
Power available to the device: 15.4
Actual consumption
Measured at the port: 3.2
Maximum Power drawn by the device since powered on: 4.5
Absent Counter: 0
Over Current Counter: 0
Short Current Counter: 0
Invalid Signature Counter: 0
Power Denied Counter: 0
Power Negotiation Used: None
LLDP Power Negotiation --Sent to PD-- --Rcvd from PD--
Power Type: - -
Power Source: - -
Power Priority: - -
Requested Power(W): - -
Allocated Power(W): - -
Four-Pair PoE Supported: No
Spare Pair Power Enabled: No
Four-Pair PD Architecture: N/A
switch#
switch#sho power inline gi1/0/5 de
Interface: Gi1/0/5
Inline Power Mode: auto
Operational status: on
Device Detected: yes
Device Type: Ieee PD
IEEE Class: 4
Discovery mechanism used/configured: Unknown
Police: off
Power Allocated
Admin Value: 30.0
Power drawn from the source: 15.4
Power available to the device: 15.4
Actual consumption
Measured at the port: 4.3
Maximum Power drawn by the device since powered on: 5.2
Absent Counter: 0
Over Current Counter: 0
Short Current Counter: 0
Invalid Signature Counter: 0
Power Denied Counter: 0
Power Negotiation Used: None
LLDP Power Negotiation --Sent to PD-- --Rcvd from PD--
Power Type: - -
Power Source: - -
Power Priority: - -
Requested Power(W): - -
Allocated Power(W): - -
Four-Pair PoE Supported: No
Spare Pair Power Enabled: No
Four-Pair PD Architecture: N/A
switch#

We also decided to measure the temperature of the case of access points at the time of a small load on the network. It turned out that the case temperature of the NWA5123-AC model was 35°C, while the temperature of the WAC6103D-I case was 36°C with an average room temperature of about 25°C. We consider the temperature readings to be normal.

In addition to functionality tests, we would like to provide our readers with the results of access point performance tests that form the basis of any wireless network. But first, it is impossible not to indicate the main parameters of our test bench.  

Component PC Laptop
MB ASUS Maximus VIII Extreme ASUS M60J
CPU Intel Core i7 7700K 4 GHz Intel Core i7 720QM 1.6 GHz
RAM DDR4-2133 Samsung 64 GBytes DDR3 PC3-10700 SEC 16 GBytes
NIC Intel PRO/1000 PT
ASUS PCE-AC88
Atheros AR8131
Zyxel NWD6605
OS Windows 7 x64 SP1 Rus Windows 7 x64 SP1 Rus

We started our measurements with the NWA5123-AC model, using the ASUS PCE-AC88 wireless network card as a client. Measurements were made for both frequency ranges for one, five, and fifteen simultaneous TCP connections. As a test tool, we used the JPerf utility version 2.0.2.   

We also carried out similar tests for the WAC6103D-I model.

We repeated the performance measurement of the access point WAC6103D-I, but this time we used a USB network interface card, the Zyxel NWD6605, as a wireless client. The measurement results are presented in the diagrams below.

Let us now return to the functionality tests and check the operation of the system when the traffic is switched by the controller or locally. Recall that when using local switching, the access point immediately sends user data to the virtual network (VLAN) that corresponds to the user's SSID. Otherwise, all the data is encapsulated in CAPWAP by AP and sent towards the controller, which then itself sends the frames to the desired virtual network. But first, create the appropriate SSID. Using the “SSID” tab of the “Access Point Profiles” item of the “Object” group, you need to create a security profile and then bind it to the SSID profile.

Please note that the switching mode is selected using the "Transfer Mode" option when creating an SSID profile.

We decided to schematically depict the traffic path during local switching.

The next step to be performed is to associate the SSID profile with a group of access points and add the necessary points to the group. The corresponding setting is available in the “Access Point Group” tab of the “Access Point Management” item in the “Wireless Network” group of the “CONFIGURATION” menu.

If all settings have been made correctly, a new SSID will appear in the list of available networks.

So, we are ready to carry out a test connection of the wireless client. Access points are connected to the switch Gi1/0/3 and Gi1/0/5 ports, while the ZyWAL 310 is connected to the Gi1/0/2 interface. SSID fox corresponds to a virtual network with VID 30. On our test L3 switch, we created an SVI corresponding to VLAN 30.

 switch#sho vla bri
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi1/0/1, Gi1/0/4, Gi1/0/6, Te1/0/7, Te1/0/8, Te1/0/1, Te1/0/2
20 test active
30 SSID_fox active
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
switch#sho lldp ne
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
nwa5123-ac Gi1/0/3 120 B,W,R 1
wac6103d-i Gi1/0/5 120 B,W,R 1
Total entries displayed: 2
switch#sho int tru
Port Mode Encapsulation Status Native vlan
Gi1/0/2 on 802.1q trunking 1
Gi1/0/3 on 802.1q trunking 1
Gi1/0/5 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi1/0/2 1-4094
Gi1/0/3 1-4094
Gi1/0/5 1-4094
Port Vlans allowed and active in management domain
Gi1/0/2 1,20,30
Gi1/0/3 1,20,30
Gi1/0/5 1,20,30
Port Vlans in spanning tree forwarding state and not pruned
Gi1/0/2 1,20,30
Gi1/0/3 1,20,30
Gi1/0/5 1,20,30
switch#sho ip int bri | e unas
Interface IP-Address OK? Method Status Protocol
Vlan1 192.168.1.10 YES NVRAM up up
Vlan20 192.168.20.10 YES NVRAM up up
Vlan30 192.168.30.10 YES manual up up
switch#sho ip dhcp pool SSID_fox
Pool SSID_fox :
Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
Total addresses : 254
Leased addresses : 0
Excluded addresses : 199
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased/Excluded/Total
192.168.30.200 192.168.30.1 - 192.168.30.254 0 / 199 / 254

The condition for the successful completion of this test will be the access of the wireless client to VLAN 30, the discovery of the client's MAC address on the port to which one of the access points is connected.

So, we have connected to the detected fox SSID.

Make sure the switch SVI is available from the client.

C:\>ping 192.168.30.10
Pinging 192.168.30.10 with 32 bytes of data:
Reply from 192.168.30.10: bytes=32 time=4ms TTL=255
Reply from 192.168.30.10: bytes=32 time=3ms TTL=255
Reply from 192.168.30.10: bytes=32 time=3ms TTL=255
Reply from 192.168.30.10: bytes=32 time=3ms TTL=255
Ping statistics for 192.168.30.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 4ms, Average = 3ms

Now we verify that the client’s MAC address is visible through the corresponding switch interface.

switch#sho mac address-table dy vla 30
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
30 240a.6449.70af DYNAMIC Gi1/0/3
Total Mac Addresses for this criterion: 1

As an additional check, we see that the wireless client obtained the IP parameters dynamically using a DHCP pool configured on our test L3 switch.

C:\>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : FOX
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Mixed
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Wireless LAN adapter Беспроводное сетевое соединение 5:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Broadcom 802.11ac Network Adapter
Physical Address. . . . . . . . . : 24-0A-64-49-70-AF
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::a861:9ebc:9e29:2e4e%38(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.30.200(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 25 декабря 2017 г. 2:05:19
Lease Expires . . . . . . . . . . : 26 декабря 2017 г. 2:13:31
Default Gateway . . . . . . . . . : 192.168.30.10
DHCP Server . . . . . . . . . . . : 192.168.30.1
DHCPv6 IAID . . . . . . . . . . . : 707005028
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-F9-D5-EB-90-E6-BA-97-A9-30
DNS Servers . . . . . . . . . . . : 2001:470:1f1d:d01::1
8.8.8.8
NetBIOS over Tcpip. . . . . . . . : Enabled

Now turn off our test wireless client and reconfigure our network so that the access point forwards all traffic through the tunnel to the wireless controller. It is worth noting, however, that in this case the VLAN corresponding to our SSID must be pre-created on the ZyWAL 310.

We also decided to provide our readers with a data path map for sending traffic through a wireless controller.

We will now verify the availability for the client of the switch SVI interface.

C:\>ping 192.168.30.10
Pinging 192.168.30.10 with 32 bytes of data:
Reply from 192.168.30.10: bytes=32 time=1ms TTL=255
Reply from 192.168.30.10: bytes=32 time=3ms TTL=255
Reply from 192.168.30.10: bytes=32 time=3ms TTL=255
Reply from 192.168.30.10: bytes=32 time=2ms TTL=255
Ping statistics for 192.168.30.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 3ms, Average = 2ms

In addition, in order to recognize the test as completely successful, we need to discover the client's MAC address on the switch interface to which the wireless controller is connected.

switch#sho mac address-table | i 240a.6449.70af
30 240a.6449.70af DYNAMIC Gi1/0/2

Experimental results convincingly prove that Zyxel’s wireless networking solution successfully handles both local switching and user data transmission through the controller. In the latter case, the administrator has additional options for filtering user traffic, for example, it can be subjected to anti-virus scanning.

This concludes the testing of the wireless solution based on Zyxel equipment and proceeds to the debriefing.

Conclusion

In general, we were pleased with the solution for the organization of wireless networks offered by Zyxel. The solution we tested included two access points of the NWA5123-AC and WAC6103D-I models, as well as a wireless controller based on the ZyWALL 310 firewall. Judging by the changes made to the firmware of the controllers and access points, this direction is being actively developed by Zyxel, that is, it seems to us, we should expect even greater improvements and innovations in the near future.

Firewall and other Zyxel security devices support the wireless controller functions, as it seems to us, is a good idea, as in this case administrators can filter even local traffic (when switching traffic using a controller/firewall).

The strengths of the individual models and solution entirely include the following:

  • mesh support;
  • powering the access points using PoE;
  • support fast roaming 802.11r;
  • a wide range of access point models;
  • the ability to assign the functions of a wireless controller not only to specialized devices, but, for example, to firewalls;
  • support of local switching by the access point, or the ability to send user data to the controller using CAPWAP;
  • automatical firmware update;
  • support for multiple wireless controllers at the same time;
  • the ability to search for rogue access points in the controlled area;
  • the presence of several methods of authentication and billing of wireless clients;
  • the ability to automate some routine processes of managing access points without using a controller;
  • availability of software tools that simplify the process of planning a wireless network and its monitoring.

Unfortunately, we cannot fail to point out the discovered defects:

  • not all wireless controllers currently support work with all models of access points (it is planned to be corrected);
  • wrong time zones (fixed in the latest firmware versions);
  • suspicion of vulnerabilities in the implementation of the SNMPv1 protocol;
  • not the highest data transfer rate in the wireless segment.

We would like to give a little explanation regarding the last item in the list. The results of testing wireless networks depend on many factors: the configuration of the room, the channel used, the presence of other wireless networks and interference not related to Wi-Fi.

At the time of writing this review, the average price of the NWA5123-AC access point in German-speaking Europe countries, according to website Geizhals Preisvergleich, was about 130 euro, while the WAC6103D-I model cost from 250 euro and above. The price of the ZyWALL 310 firewall started at 700 euro, excluding additional licenses.

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

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.

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

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.

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

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.

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

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)

Fragmentation

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

Fragmentation

In literature we can often meet mentioning that fragmentation in IPv6 is impossible. Really, having a careful look at IPv6 packet header one can find out that there are no fields responsible for fragmentation procedure in it. In the picture below comparison of headers for IPv4 and IPv6 packets is presented. Modified fields are marked with dark grey.

As one can see from the comparison above, Identification, Flags and Fragment Offset fields were removed.

Let’s make a little experiment for which prepare a scheme presented below.

The routers use the following addresses on their interfaces with a standard /64 mask.

Router and interface Address
R1 Gi0/0 2001:db8:12::1
R2 Gi0/0 2001:db8:12::2
R2 Gi1/0 2001:db8:23::2
R3 Gi1/0 2001:db8:23::3

To start with we should check if the fields mentioned above are really absent in IPv6 header, for doing this let’s make sure of the connectivity between routers R1 and R3 with the help of ICMP and study content of one of the packets intercepted on link R1-R2.

R1#ping 2001:db8:23::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:23::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/14/16 ms

 

The next step is to discover MTU value for Gi0/0 interface of router R1.

R1#sho ipv int gi0/0
GigabitEthernet0/0 is up, line protocol is up
 IPv6 is enabled, link-local address is FE80::C801:33FF:FEC4:8
 No Virtual link-local address(es):
 Global unicast address(es):
 2001:DB8:12::1, subnet is 2001:DB8:12::/64
 Joined group address(es):
 FF02::1
 FF02::2
 FF02::1:FF00:1
 FF02::1:FFC4:8
 MTU is 1500 bytes
 ICMP error messages limited to one every 100 milliseconds
 ICMP redirects are enabled
 ICMP unreachables are sent
 ND DAD is enabled, number of DAD attempts: 1
 ND reachable time is 30000 milliseconds (using 30000)
 ND advertised reachable time is 0 (unspecified)
 ND advertised retransmit interval is 0 (unspecified)
 ND router advertisements are sent every 200 seconds
 ND router advertisements live for 1800 seconds
 ND advertised default router preference is Medium
 Hosts use stateless autoconfig for addresses.

As MTU value for IPv6 is equal to 1500 bytes, we cannot transmit ICMP messages of a larger size. For checking this, we sent several echo requests of 2000 bytes using ping command.

R1#ping 2001:db8:23::3 si
R1#ping 2001:db8:23::3 size 2000
Type escape sequence to abort.
Sending 5, 2000-byte ICMP Echos to 2001:DB8:23::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms

It is surprising, isn’t it? Let’s have a look at the dump and check what actually is happening in the network.

In IPv6 packet presented above an extension header named Fragment Header for IPv6 and absent before has appeared. It is exactly this extension header that contains such important for fragmentation process fields as Offset, More Fragments and Identification. Therefore, fragmentation in IPv6 is possible and is performed by a sender using the auxiliary extension header Fragment Header for IPv6.

It’s worth noting that IPv6 packet header has a strictly fixed length of 40 bytes and all auxiliary options are placed at the following headers. The given method is named IPv6 header chain. Please, take attention to the value of Next Header field in IPv6 packet header and Fragment Header for IPv6 following it.

Let’s continue our experiments and manually decrease MTU value for router R2 on link R2-R3.

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int gi1/0
R2(config-if)#ipv mtu ?
 <1280-1500> MTU (bytes)
R2(config-if)#ipv mtu 1300
R2(config-if)#do sho ipv int gi1/0 | i MTU
 MTU is 1300 bytes

Now we generate several large packets on router R1 again.

R1#ping 2001:db8:23::3 size 2000
Type escape sequence to abort.
Sending 5, 2000-byte ICMP Echos to 2001:DB8:23::3, timeout is 2 seconds:
B!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 28/33/36 ms

The first packet was lost but all other packets were successfully delivered. Now let’s take a look at the traffic dump. So R1 router performs fragmentation straight away and sends two packets of 1496 and 560 bytes (in the picture below Length field displays Ethernet frame length which header is 14 bytes).

However, the first packet cannot be transmitted via link R2-R3 and router R2 announces of it in generated ICMP message Packet Too Big (Type=2, Code=0). Router R1 reacts on the received ICMP message and starts sending data using smaller packets of 1296 and 760 bytes.

So yes, IPv4 behaves totally different: the router on the traffic route will just fragment transmitted IP packets without DF flag in the header if packet size is more than MTU value for the outbound interface and drop IP packets with set DF bit in the same case. Of course, an intermediate router will generate ICMP message (Type=2, Code=4) Destination Unreachable (Fragmentation Needed), but the sender cannot react on it because of set DF bit.

In conclusion, we would like to take our readers attention to the size of IPv6 packets which were created at the result of fragmentation for transmitting via IPv6 channel with MTU equal to 1300 bytes. The packets had a size of 1296 and 760 bytes. Why exactly 1296 but not 1300 bytes? The answer is hidden in the details of fragmentation procedure realization and exactly in the size of Offset field of Fragment Header for IPv6. The point is that Offset field has a length of 13 bits and points at the amount of blocks 8 bytes each on which the given fragment is shifted. Thus, fragment offset shall be divisible by 8 bytes. The similar situation takes place for IPv4 as well, where Fragment Offset field has exactly the same length.

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.