Fastiron 08070 Dhcpguide
Fastiron 08070 Dhcpguide
Fastiron 08070 Dhcpguide
Export Restrictions
These products and associated technical data (in print or electronic form) may be subject to export control laws of the United
States of America. It is your responsibility to determine the applicable regulations and to comply with them. The following notice
is applicable for all products or technology subject to export control:
These items are controlled by the U.S. Government and authorized for export only to the country of ultimate destination for use by the
ultimate consignee or end-user(s) herein identified. They may not be resold, transferred, or otherwise disposed of, to any other country
or to any person other than the authorized ultimate consignee or end-user(s), either in their original form or after being incorporated
into other items, without first obtaining approval from the U.S. government or as otherwise authorized by U.S. law and regulations.
Disclaimer
THIS CONTENT AND ASSOCIATED PRODUCTS OR SERVICES ("MATERIALS"), ARE PROVIDED "AS IS" AND WITHOUT WARRANTIES OF
ANY KIND, WHETHER EXPRESS OR IMPLIED. TO THE FULLEST EXTENT PERMISSIBLE PURSUANT TO APPLICABLE LAW, ARRIS
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, TITLE, NON-INFRINGEMENT, FREEDOM FROM COMPUTER VIRUS,
AND WARRANTIES ARISING FROM COURSE OF DEALING OR COURSE OF PERFORMANCE. ARRIS does not represent or warrant
that the functions described or contained in the Materials will be uninterrupted or error-free, that defects will be corrected, or
are free of viruses or other harmful components. ARRIS does not make any warranties or representations regarding the use of
the Materials in terms of their completeness, correctness, accuracy, adequacy, usefulness, timeliness, reliability or otherwise. As
a condition of your use of the Materials, you warrant to ARRIS that you will not make use thereof for any purpose that is unlawful
or prohibited by their associated terms of use.
Limitation of Liability
IN NO EVENT SHALL ARRIS, ARRIS AFFILIATES, OR THEIR OFFICERS, DIRECTORS, EMPLOYEES, AGENTS, SUPPLIERS, LICENSORS
AND THIRD PARTY PARTNERS, BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, PUNITIVE, INCIDENTAL, EXEMPLARY OR
CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER, EVEN IF ARRIS HAS BEEN PREVIOUSLY ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES, WHETHER IN AN ACTION UNDER CONTRACT, TORT, OR ANY OTHER THEORY ARISING FROM
YOUR ACCESS TO, OR USE OF, THE MATERIALS. Because some jurisdictions do not allow limitations on how long an implied
warranty lasts, or the exclusion or limitation of liability for consequential or incidental damages, some of the above limitations
may not apply to you.
Trademarks
ARRIS, the ARRIS logo, Ruckus, Ruckus Wireless, Ruckus Networks, Ruckus logo, the Big Dog design, BeamFlex, ChannelFly,
EdgeIron, FastIron, HyperEdge, ICX, IronPoint, OPENG, SmartCell, Unleashed, Xclaim, ZoneFlex are trademarks of ARRIS
International plc and/or its affiliates. Wi-Fi Alliance, Wi-Fi, the Wi-Fi logo, the Wi-Fi CERTIFIED logo, Wi-Fi Protected Access (WPA),
the Wi-Fi Protected Setup logo, and WMM are registered trademarks of Wi-Fi Alliance. Wi-Fi Protected Setup™, Wi-Fi Multimedia™,
and WPA2™ are trademarks of Wi-Fi Alliance. All other trademarks are the property of their respective owners.
DHCP Clients....................................................................................................................................................................................... 15
DHCP client.................................................................................................................................................................................................15
DHCP over default Virtual Ethernet port (Layer 3 devices)........................................................................................................... 16
Default Virtual Ethernet port creation (Layer 3 devices)............................................................................................................... 16
DHCP client in continuous discovery mode (Layer 2 and Layer 3 devices).................................................................................17
DHCP client as a new device............................................................................................................................................................. 17
DHCP client behavior after reboot...................................................................................................................................................18
BootP and DHCP relay parameters......................................................................................................................................................... 19
Configuring an IP helper address............................................................................................................................................................ 19
Configuring the BOOTP and DHCP reply source address.....................................................................................................................20
Changing the IP address used for stamping BootP and DHCP requests............................................................................................20
Changing the maximum number of hops to a BootP relay server..................................................................................................... 21
DHCP auto-provisioning .......................................................................................................................................................................... 21
Auto-provisioning using the bootfile.bin option....................................................................................................................................22
DHCP auto-provisioning using the manifest file option....................................................................................................................... 23
DHCP auto-provisioning options............................................................................................................................................................. 24
Disabling or re-enabling the DHCP client .............................................................................................................................................. 24
DHCP auto-provisioning on Layer 2 and Layer 3 devices..................................................................................................................... 25
Scenario 1: DHCP auto-provisioning on a Layer 3 device............................................................................................................. 25
Scenario 2: DHCP auto-provisioning with a TFTP server in a different network........................................................................ 26
Scenario 3: DHCP client connected through a DHCP snooping device....................................................................................... 27
Scenario 4: DHCP client option 12................................................................................................................................................... 27
Scenario 5: DHCP auto-provisioning on a Layer 2 device............................................................................................................. 28
Configuration notes and feature limitations for DHCP auto-provisioning......................................................................................... 28
High Availability and 802.1BR considerations................................................................................................................................ 29
Upgrade considerations.................................................................................................................................................................... 29
How DHCP client-based auto-provisioning and flash image update works............................................................................... 30
Validating the IP address and lease negotiation............................................................................................................................ 30
Flash image download and update .................................................................................................................................................30
DHCP Servers...................................................................................................................................................................................... 37
DHCP Servers............................................................................................................................................................................................. 37
Configuration considerations for DHCP servers............................................................................................................................ 38
Configuring the DHCP server and creating an address pool........................................................................................................39
Default DHCP server settings........................................................................................................................................................... 42
DHCP server options................................................................................................................................................................................. 42
Recommendations and limitations..................................................................................................................................................45
Upgrade considerations.................................................................................................................................................................... 46
Disabling or re-enabling the DHCP server on the management port.................................................................................................47
Setting the wait time for ARP ping response......................................................................................................................................... 47
DHCP relay agent information support (option 82) ............................................................................................................................. 48
Enabling relay agent information (option 82)........................................................................................................................................ 48
Configuring the IP address of the DHCP server.....................................................................................................................................48
Configuring the boot image..................................................................................................................................................................... 49
Deploying an address pool configuration to the server....................................................................................................................... 49
Specifying default router available to the client.................................................................................................................................... 49
Specifying DNS servers available to the client....................................................................................................................................... 50
Configuring the domain name for the client..........................................................................................................................................50
Configuring the lease duration for the address pool............................................................................................................................50
Specifying addresses to exclude from the address pool...................................................................................................................... 51
Configuring the NetBIOS server for DHCP clients................................................................................................................................. 51
Configuring the subnet and mask of a DHCP address pool.................................................................................................................52
Configuring the TFTP server.....................................................................................................................................................................52
Configuring X Window System Display Manager IP addresses (option 49)........................................................................................52
Configuring vendor details and vendor specific information (option 43 and option 60) ................................................................ 53
Enabling static IP to MAC address mapping...........................................................................................................................................54
Configuring Avaya IP telephony (options 176 and 242)........................................................................................................................55
Configuring WPAD (option 252)............................................................................................................................................................... 56
Displaying DHCP server information...................................................................................................................................................... 57
DHCPv4................................................................................................................................................................................................ 61
DHCPv4 overview...................................................................................................................................................................................... 61
DHCP Assist configuration........................................................................................................................................................................61
How DHCP Assist works.................................................................................................................................................................... 62
Configuring DHCP Assist................................................................................................................................................................... 64
Dynamic ARP Inspection overview ......................................................................................................................................................... 65
ARP poisoning.................................................................................................................................................................................... 65
How Dynamic ARP Inspection works............................................................................................................................................... 66
Configuration notes and feature limitations for DAI..................................................................................................................... 67
Configuring Dynamic ARP Inspection.............................................................................................................................................. 67
Enabling or disabling DAI syslog messages.................................................................................................................................... 68
Displaying ARP information.............................................................................................................................................................. 69
Configuring DAI to support Multi-VRF............................................................................................................................................. 71
Enabling trust on a port for a specific VRF......................................................................................................................................71
DHCP snooping..........................................................................................................................................................................................72
DHCPv6................................................................................................................................................................................................ 91
DHCPv6 overview...................................................................................................................................................................................... 91
DHCP relay agent for IPv6........................................................................................................................................................................ 91
Configuring a DHCPv6 relay agent.......................................................................................................................................................... 91
DHCPv6 relay agent include options.......................................................................................................................................................92
Specifying the IPv6 DHCP relay include options.................................................................................................................................... 93
DHCPv6 Relay Agent Prefix Delegation Notification............................................................................................................................. 93
DHCPv6 Relay Agent Prefix Delegation Notification limitations.................................................................................................. 94
Upgrade and downgrade considerations....................................................................................................................................... 95
Configuring DHCPv6 Relay Agent Prefix Delegation Notification................................................................................................ 95
Enabling DHCPv6 Relay Agent Prefix Delegation Notification on an interface.......................................................................... 95
Assigning the administrative distance to DHCPv6 static routes.................................................................................................. 96
Displaying DHCPv6 relay agent and prefix delegation information............................................................................................ 96
Clearing the DHCPv6 delegated prefixes and packet counters....................................................................................................98
DHCPv6 snooping......................................................................................................................................................................................98
How DHCPv6 snooping works.......................................................................................................................................................... 98
Configuration notes and feature limitations for DHCPv6 snooping............................................................................................99
Configuring DHCPv6 snooping.......................................................................................................................................................100
Configuring DHCPv6 snooping for Multi-VRF............................................................................................................................... 101
Displaying DHCPv6 snooping information................................................................................................................................... 102
Document Conventions
The following tables list the text and notice conventions that are used throughout this guide.
NOTE
A NOTE provides a tip, guidance, or advice, emphasizes important information, or provides a reference to related
information.
CAUTION
A CAUTION statement alerts you to situations that can be potentially hazardous to you or cause damage to
hardware, firmware, software, or data.
DANGER
A DANGER statement indicates conditions or situations that can be potentially lethal or extremely hazardous to you.
Safety labels are also attached directly to products to warn of these conditions or situations.
Convention Description
bold text Identifies command names, keywords, and command options.
italic text Identifies a variable.
[] Syntax components displayed within square brackets are optional.
Default responses to system prompts are enclosed in square brackets.
{x|y|z} A choice of required parameters is enclosed in curly brackets separated by vertical bars. You must
select one of the options.
x|y A vertical bar separates mutually exclusive elements.
<> Nonprinting characters, for example, passwords, are enclosed in angle brackets.
... Repeat the previous element, for example, member[member...].
\ Indicates a “soft” line break in command examples. If a backslash separates two lines of a command
input, enter the entire command at the prompt without the backslash.
Document Feedback
Ruckus is interested in improving its documentation and welcomes your comments and suggestions.
White papers, data sheets, and other product documentation are available at https://www.ruckuswireless.com.
For product support information and details on contacting the Support Team, go directly to the Support Portal using https://
support.ruckuswireless.com, or go to https://www.ruckuswireless.com and select Support.
Open a Case
When your entire network is down (P1), or severely impacted (P2), call the appropriate telephone number listed below to get
help:
• Continental United States: 1-855-782-5871
• Canada: 1-855-782-5871
• Europe, Middle East, Africa, and Asia Pacific, toll-free numbers are available at https://support.ruckuswireless.com/
contact-us and Live Chat is also available.
Self-Service Resources
The Support Portal at https://support.ruckuswireless.com/contact-us offers a number of tools to help you to research and
resolve problems with your Ruckus products, including:
• Technical Documentation—https://support.ruckuswireless.com/documents
• Community Forums—https://forums.ruckuswireless.com/ruckuswireless/categories
• Knowledge Base Articles—https://support.ruckuswireless.com/answers
Using these resources will help you to resolve some issues, and will provide TAC with additional data from your troubleshooting
analysis if you still require assistance through a support case or RMA. If you still require help, open and manage your case at
https://support.ruckuswireless.com/case_management
DHCP server options In previous releases, it was possible to configure DHCP server options on page 42
a number of DHCP server options. Ths list of
supported DHCP server options has been
extended significantly, providing more scope for
DHCP client provisioning and configuration.
Updated content for defect fix From 08.0.70, POE firmware is bundled with the Configuration notes and feature limitations
ICX image file. If the ICX software is upgraded, for DHCP auto-provisioning on page 28
the POE firmware is automatically updated after
the upgrade completes.
Minor editorial updates Minor editorial updates were made throughout All chapters.
the Configuration Guide.
Supported hardware
This guide supports the following Ruckus products:
• Ruckus ICX 7750 Series
• Ruckus ICX 7650 Series
• Ruckus ICX 7450 Series
• Ruckus ICX 7250 Series
• Ruckus ICX 7150 Series
For information about what models and modules these devices support, see the hardware installation guide for the specific
product family.
DHCP overview
The Dynamic Host Configuration Protocol (DHCP) is based on the Bootstrap Protocol (BOOTP) and provides several configuration
parameters stored in DHCP server databases to DHCP clients upon request.
DHCP enables the automatic configuration of client systems. DHCP removes the need to configure devices individually. Clients
can set network properties by connecting to the DHCP server instead. This protocol consists of two components; a protocol to
deliver host-specific configuration parameters from a DHCP server to a host, and a mechanism to allocate leased or permanent
IP addresses to hosts. DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses
and deliver configuration parameters to dynamically configured hosts.
DHCP client
A host on an IP network can use BOOTP or DHCP to obtain its IP address from a BOOTP or DHCP server. To obtain the address,
the client sends a BOOTP or DHCP request.
The request is a subnet directed broadcast and is addressed to UDP port 67. A limited IP broadcast is addressed to IP address
255.255.255.255 and is not forwarded by the Ruckus Layer 3 switch or other IP routers. When the BOOTP or DHCP client and
server are on the same network, the server receives the broadcast request and replies to the client. However, when the client
and server are on different networks, the server does not receive the client request, because the Layer 3 switch does not forward
the request.
You can configure the Layer 3 switch to forward BOOTP or DHCP requests. To do so, configure a helper address on the interface
that receives the client requests, and specify the BOOTP or DHCP server IP address as the address you are helping the BOOTP or
DHCP requests to reach. Refer to Configuring an IP helper address on page 19. Instead of the server IP address, you can specify
the subnet directed broadcast address of the IP subnet the server is in.
The DHCP client supports the dynamic IP address allocation method, where an IP address is assigned to a client for a limited
period of time (or until the client explicitly relinquishes the address). Permanent IP address allocation to the hosts and statically
assigned IP addresses are not supported.
Ruckus devices support a DHCP client on physical ports, LAG ports, Virtual Ethernet ports, and Control Bridge (CB) ports
(802.1BR-enabled). The DHCP client is not supported on tunnel ports, stacking ports when stacking is enabled, or PE ports in
802.1BR-enabled Ruckus devices.
NOTE
On a Layer 3 device, DHCP over a Virtual Ethernet port is supported only for the default Virtual Ethernet port. The DHCP
client is disabled on other VIrtual Ethernet ports.
NOTE
On a Layer 3 device, DHCP client support for PE ports on 802.1BR-enabled Ruckus devices includes the ability to
participate in the initial DHCP IP discovery phase to create a default Virtual Ethernet port. However, because PE ports
are considered Layer 2 switching ports, they cannot be assigned an IP address. Refer to "Default Virtual Ethernet port
creation" in this document for more information.
NOTE
To create a Virtual Ethernet port, at least one port must be a member of the default VLAN of the device.
If Virtual Ethernet port creation is successful, the IP address that is acquired through the physical port is released, and an IP
address will be re-acquired through the default Virtual Ethernet port.
NOTE
The index of the default Virtual Ethernet port is the first available index. For example, on a device with no startup
configuration, the default Virtual Ethernet port will have an index of 1.
If default Virtual Ethernet port creation fails, the IP address acquired will be assigned to the physical interface port or ports
connecting the DHCP server if the connecting ports are Layer 3 ports.
Possible Reasons for Failure of Virtual Ethernet Port creation. The member ports of the default VLAN are queried to check
for certain configured items. If any of the items are found, default Virtual Ethernet creation fails without other conditions being
checked. These configured items result in failure:
• IP routing
• vrf
• ip policy
• route-only
• rpf-mode
• ip-mac
DHCP Discovery is attempted 5 times based on the exponential back-off algorithm, as per RFC 2131. Retries occur at these
intervals: x+4 seconds, where x is the starting system time, x+8 seconds, x+16 seconds, x+32 seconds, and x+64 seconds. After
the DHCP client reaches the maximum retransmission delay of 64 seconds, it waits 2 seconds and then restarts the discovery
process. The five-interval cycle repeats continuously.
NOTE
Discovery intervals may vary by +1 or -1 seconds, depending on system performance.
The DHCP discovery broadcast is received by the DHCP servers present in the network. There are three possible responses to
this message:
• No response
• Single response
• More than one response
If the client does not receive a DHCP server response, there is a possibility that the client could be disabled on the device. If the
client receives a response from the server (refer to "DORA process"), the client starts the DHCP request and obtains the IP
address lease. If the client receives a response from more than one server, the client acknowledges the first response received,
which is the default behavior.
NOTE
The DORA process is the standard Discover, Offer, Request, Acknowledge process used by DHCP to allocate IP
addresses dynamically to clients through a lease period. Refer to the following graphic for a description of the ICX
implementation.
In the Layer 3 software image, when the DHCP client device boots up without any IP address, the client initiates the DHCP
discovery on all ports. DHCP discovery packets are sent from all DHCP client-eligible ports in the device. The default discovery
mechanism is similar to the switch version.
If the software version is Layer 3, when the DHCP client comes up after a reboot with a previously obtained IP address, the DHCP
client sends the DHCP request packets only on the ports where the DHCP client was enabled previously on the device.
By default, the Layer 3 switch uses the lowest-numbered IP address on the interface that receives the request as the Gateway
address. You can override the default by specifying the IP address you want the Layer 3 switch to use.
• Hop count - Each router that forwards a BootP/DHCP packet increments the hop count by one. Routers also discard a
forwarded BootP/DHCP request instead of forwarding the request if the hop count is greater than the maximum
number of BootP/DHCP hops allowed by the router. By default, a Ruckus Layer 3 switch forwards a BootP/DHCP request
if its hop count is four or less but discards the request if the hop count is greater than four. You can change the
maximum number of hops the Layer 3 switch allows to a value from 1 through 15.
NOTE
The BootP/DHCP hop count is not the TTL parameter.
Specify the server IP address or the subnet directed broadcast address of the server's IP subnet as the helper address. You can
configure up to 16 helper addresses on each interface. You can configure a helper address on an Ethernet port or a virtual
interface.
1. Enter the global configuration mode by issuing the configure terminal command.
The commands in the example above add a helper address for server 10.95.7.6 to the port. If the port receives a client
request for any of the applications that the Layer 3 switch is enabled to forward, the Layer 3 switch forwards the client
request to the server.
4. By default, an IP helper does not forward client broadcast requests to a server within the network. To forward a client
broadcast request when the client and server are on the same network, configure an IP helper with the unicast option
on the interface connected to the client.
The previous example configures an IP helper unicast option on unit 1, slot 1, port 2. The IP helper with unicast
parameter forwards the client request to the server 10.10.10.1, which is within the network.
1. Enter the global configuration mode by issuing the configure terminal command.
device(config)# ip helper-use-responder-ip
The default value the Layer 3 switch uses to stamp the packet is the lowest-numbered IP address configured on the interface that
received the request. If you want the Layer 3 switch to use a different IP address to stamp requests received on the interface, use
either of the following methods to specify the address.
The BootP/DHCP stamp address is an interface parameter. You can change the parameter on the interface that is connected to
the BootP/DHCP client.
1. Enter the global configuration mode by issuing the configure terminal command.
3. Change the BootP or DHCP stamp address for requests received on port 1/1/1 to 10.157.22.26.
The previous example changes the BootP or DHCP stamp address for requests received on port 1/1/1 to 10.157.22.26.
The Layer 3 switch will place this IP address in the Gateway Address field of BootP or DHCP requests that the Layer 3
switch receives on port 1/1/1 and forwards to the BootP or DHCP server.
When the Layer 3 switch receives a BootP or DHCP request, the Layer 3 switch looks at the value in the Hop Count field.
• If the hop count value is equal to or less than the maximum hop count the Layer 3 switch allows, the Layer 3 switch
increments the hop count by one and forwards the request.
• If the hop count is greater than the maximum hop count the Layer 3 switch allows, the Layer 3 switch discards the
request.
You can change the maximum number of hops the Layer 3 switch allows for forwarded BootP or DHCP requests.
NOTE
The BootP and DHCP hop count is not the TTL parameter.
1. Enter the global configuration mode by issuing the configure terminal command.
device(config)# bootp-relay-max-hops 10
The example allows the Layer 3 switch to forward BootP or DHCP requests that have passed through ten previous hops
before reaching the Layer 3 switch. Requests that have traversed 11 hops before reaching the switch are dropped. Since
the hop count value initializes at zero, the hop count value of an ingressing DHCP Request packet is the number of Layer
3 routers that the packet has already traversed.
DHCP auto-provisioning
DHCP auto-provisioning allows Layer 2 and Layer 3 devices to automatically obtain leased IP addresses through a DHCP server,
negotiate address lease renewal, and obtain flash image and configuration files. The DHCP client and auto-provisioning are
enabled by default on all DHCP client-eligible ports. Auto-provisioning allows clients to boot up with the latest image and
configuration without manual intervention. Refer to the DHCP server section for details on DHCP server configuration and
options.
NOTE
DHCP auto-provisioning is platform independent and has no difference in behavior or configuration across platforms.
1. Once a lease is obtained from the server, the device uses the information from the DHCP server to contact the TFTP
server to update the image file.
2. The device compares the file name of the requested flash image with the image stored in flash. In a stacking
configuration, the device compares the file name with the image stored in the Active Controller only.
3. If the .bin file names match, then the DHCP client skips the flash image download. If auto-provisioning is enabled, the
DHCP client proceeds with downloading the configuration files. If the .bin file names are different, the DHCP client
downloads the new image from a TFTP server, and then writes the downloaded image to flash. In a stacking
configuration, the device copies the flash image to flash in all stack member units.
4. The code determines which flash (primary or secondary) to use based on how the device is booted.
5. In a stacking configuration, the member units use the same flash as the Active Controller. Once the flash is updated with
the newer flash image, the device is reloaded and all member units in a stacking configuration are reloaded as well. If
auto-provisioning is enabled, the DHCP client then proceeds to download the configuration files.
6. If the DHCP client detects that the new image is older than the current running image, the device continues to reload
after a syslog notification that the device is downgrading and may lose the configuration. The following example shows a
syslog notification.
The bundle of Image file, boot loader and PoE firmware can be configured as a .txt file on the DHCP server using option 67. Auto-
provisioning using the manifest file occurs as follows.
1. Once a lease is obtained from the server, the device uses the information from the DHCP server to contact the TFTP
server to update the image file.
4. If the flash image is different, the device downloads the new flash image from the TFTP server and checks for the boot
image. If the boot image matches, the DHCP client skips the boot image. If the boot image does not match, the DHCP
client downloads the new boot image from the TFTP server, and then writes the downloaded image to flash. In a
stacking configuration, the device copies the flash and boot image to flash in all stack member units.
5. The code determines which flash (primary or secondary) to use based on how the device is booted.
6. In a stacking configuration, the member units use the same flash as the Active Controller. Once the flash is updated with
the newer flash image, the device is reloaded and all member units in a stacking configuration are reloaded as well. If
auto-configuration is enabled, after reload the DHCP client then proceeds to download the configuration files.
7. If the DHCP client detects that the new image is older than the current running image, the device continues to reload
after a syslog notification that the device is downgrading and may lose the configuration. The following is an example of
the syslog notification.
1. On a switch, enter the global configuration mode by issuing the configure terminal command.
3. On a switch, enter the ip dhcp-client enable command to re-enable the DHCP client.
4. On a router, enter the ip dhcp-client disable command to disable the DHCP client service on all physical interface and
virtual interface level.
5. On a router, enter the no ip dhcp-client disable command to re-enable the DHCP client service on all physical interface
and virtual interface level.
8. On a router, enter the ip dhcp-client enable command at the interface configuration level to re-enable the DHCP client.
9. On a router, enter the ip dhcp-client enable command at the virtual interface level to re-enable the DHCP client.
• If the non-default VLAN has multiple untagged ports connected to different DHCP servers, the first port that received the
IP address offer will be considered and the other port will not receive an IP address. This behavior applies for default
VLANs, too.
• After an image update and device reload, the option 3 (router) installs the default route to maintain the connectivity with
the TFTP or DHCP servers. In releases prior to FastIron 8.0.40, option 3 was supported only on Layer 2 devices. The
default route added by the DHCP client device from option 3 (router) will be of the lowest metric (254). If the device has a
default route, the DHCP provided route is also appended to the routing table.
IP address is configured on the switch (globally) IP address is configured on the specific client port
IP default gateway is configured as “Default gateway X.X.X.X (option 3) Default route is configured as “IP route” with distance metric 254
In this scenario, the DHCP client and server are part of the same network, but the TFTP server is part of a different network. Here
the DHCP client device needs a default route for TFTP server reachability.
1. The FastIron router (DHCP client) connected to the DHCP server is booted.
2. The client obtains a dynamic IP address lease from the DHCP server through the untagged member port 2 of the VLAN 2
(which is a non-default VLAN) along with other DHCP server options.
3. Once DHCP server options are enabled, the router option 3 is processed and installs the default route onto the device.
Options 6,12, 15, and 150 are processed as well.
4. If auto-provisioning is enabled and the image file comparison is successful, the client downloads the new image using
the TFTP server IP address specified in the DHCP server.
5. If auto-provisioning is enabled, the client downloads the configuration file after connecting to the TFTP server and
applies the running configuration on the device.
In this scenario, the DHCP client and server are connected in the same network, but the TFTP server is connected in a different
network through the DHCP server. Here the DHCP client device needs a default route to reach the TFTP server. The steps are the
same as in scenario 1, except that the TFTP server will be reachable after the new image update as the router option 3, which is
the default gateway IP address 192.0.0.1, is installed.
In this scenario, the DHCP client and server are connected through ports on which DHCP snooping or relay agent are enabled
and are part of non-default VLANs. The working scenario is the same as Scenario 1.
In this scenario, the DHCP clients 1 and 2 are connected to the DHCP server in the same subnet. Subsequently, both receive the
same host name. The DHCP client 3 is connected to the DHCP server in a different subnet and it is assigned with the host name
of the second pool.
2. The client sends the DHCP discovery packets on all DHCP client-eligible ports that are up.
3. The client obtains the dynamic IP address from the DHCP server along with option 3.
4. Once the new router image is brought up, the client tries to connect to the TFTP server using the default route.
• The show ip command does not display the image file name if the bootfile on the DHCP server is configured as
manifest.txt, when the Layer 2 switch acts as a DHCP client.
• When the Layer 2 switch acts as a DHCP client, the show ip command does not display the image file name if the
bootfile on the DHCP server is configured as manifest.txt.
• During the DHCP auto-provisioning process, the client accepts either the TFTP server name or the TFTP server IP
address. If the server name is configured, the client ignores the server IP address.
• During auto-provisioning using the manifest.txt file, if the flash images are the same, the boot image download is
skipped.
• The DHCP server accepts more than one default router in the address pool if the image is a Layer 2 image.
• The DHCP client contacts the TFTP server to obtain the hostnameMAC-config.cfg file five times only if the TFTP server is
busy, or if the TFTP server is not reachable. If the TFTP server is reachable, the DHCP client contacts the TFTP server only
once.
• In a stacking configuration, the DHCP client flash image download waits five minutes for all member units to join and
update. Then the DHCP client downloads the new image from the TFTP server using the TFTP server IP address (option
150), if it is available. If the TFTP server IP address is not available, the DHCP client requests the TFTP file from the DHCP
server.
• If the enable aaa console command is configured, the DHCP client will not request for the configuration files.
DHCP is supported on 802.1BR-enabled devices as a normal stacking device. In a Campus Fabric (SPX) configuration, the DHCP
client is able to send packets through all CB and PE ports. PE ports can be members of the VE.
Upgrade considerations
When upgrading from FastIron 08.0.60 or previous releases to FastIron 08.0.61 or later, if rules to create default VE are met, the
following occur automatically: the default VE is created, the DHCP client is enabled over the default VE, and it acquires the IP
address.
NOTE
The lease time interval is configured on the DHCP server, not on the client device. The ip dhcp-client lease
command is set by the system, and is non-operational to a user.
4. If the existing address is static, the device keeps it and the DHCP client process is ended.
5. For a leased IP address, when the lease interval reaches the renewal point, the device requests a renewal from the DHCP
server:
• If the device is able to contact the DHCP server at the renewal point in the lease, the DHCP server extends the lease.
This process can continue indefinitely.
• If the device is unable to reach the DHCP server after four attempts, it continues to use the existing IP address until
the lease expires. When the lease expires, the dynamic IP address is removed and the device contacts the DHCP
server for a new address.
Once a lease is obtained from the server, the device compares the file name of the requested flash image with the image stored
in flash. In a stacking configuration, the device compares the file name with the image stored in the Active Controller only.
• If the .bin file names match, then the DHCP client skips the flash image download. If auto-provisioning is enabled, the
DHCP client proceeds with downloading the configuration files.
• If the .bin file names are different, then the DHCP client downloads the new image from a TFTP server and then writes
the downloaded image to flash. In a stacking configuration, the device copies the flash image to flash in all stack
member units.
The code determines which flash (primary or secondary) to use based on how the device is booted. In a stacking configuration,
the member units use the same flash as the active controller. Once the flash is updated with the newer flash image, the device is
reloaded, and any member units in a stacking configuration are reloaded as well. If auto-provisioning is enabled, the DHCP client
then proceeds to download the configuration files.
If the device successfully contacts the TFTP server and the server has the configuration file, the files are merged. If there is a
conflict, the server file takes precedence. If the device is unable to contact the TFTP server, or if the files are not found on the
server, the TFTP part of the configuration download process ends.
1. On a switch or a router enter the global configuration mode by issuing the configure terminal command.
3. Enter the ip dhcp-client auto-update enable command to enable DHCP auto-provisioning after it has been disabled.
To help identify them, the keyword dynamic is appended to output for all dynamic DHCP options that are reflected in the
running configuration.
NOTE
Only the IP address and the default gateway/default route are persistent across reloads (after the write memory is
executed to save the configuration). The remaining DHCP options that are obtained from the DHCP server are relearned
when the ICX device reboots.
It is not possible to manually configure the dynamic option. If you attempt to configure a dynamic option manually, an error is
displayed stating “Manual configuration is not allowed for this option."
NOTE
If a static IP Address is configured manually for the device after obtaining a dynamic IP Address and DHCP options from
the DHCP server, all DHCP options are released along with the dynamic IP Address.
1. On a switch enter the show running-config command. Examine the output to identify dynamically obtained options.
These options have a “dynamic” tag appended to them in the running configuration.
Current configuration:
!
ver 08.0.61b1T211
!
stack unit 1
module 1 icx7250-24-port-management-module
module 2 icx7250-sfp-plus-8port-80g-module
!
!
!
vlan 1 name DEFAULT-VLAN by port
!
!
!
hostname TestHostName dynamic
ip address 10.10.10.2 255.255.255.0 dynamic
ip dns domain-list ManualDomain.com
ip dns domain-list testStaticDomain.com
ip dns domain-list testDomain.com dynamic
ip dns server-address 20.20.20.8 20.20.20.9 20.20.20.5 10.10.10.5(dynamic)
ip default-gateway 10.10.10.1 dynamic
!
!
!
interface ethernet 1/1/21
disable
!
interface ethernet 1/2/2
speed-duplex 1000-full
!
interface ethernet 1/2/4
speed-duplex 1000-full
!
interface ethernet 1/2/5
speed-duplex 1000-full
!
interface ethernet 1/2/6
speed-duplex 1000-full
!
interface ethernet 1/2/7
speed-duplex 1000-full
!
interface ethernet 1/2/8
speed-duplex 1000-full
!
!
!
lldp run
!
!
end
2. On a switch enter the show configuration command. Examine the output to identify dynamically obtained options.
These options have a “dynamic” tag appended to them in the running configuration.
end
1. On a router enter the show running-config command. Examine the output to identify dynamically obtained options.
These options have a “dynamic” tag appended to them in the running configuration.
Current configuration:
!
ver 08.0.61b1T213
!
stack unit 1
module 1 icx7250-24-port-management-module
module 2 icx7250-sfp-plus-8port-80g-module
!
!
vlan 1 name DEFAULT-VLAN by port
!
!
!
hostname TestHostName dynamic
ip dns domain-list ManualDomain.com
ip dns domain-list testDomain.com dynamic
ip dns domain-list testStaticDomain.com
ip dns server-address 20.20.20.8 20.20.20.9 10.10.10.5(dynamic) 20.20.20.5
ip route 0.0.0.0/0 10.10.10.1 distance 254 dynamic
!
!
interface ethernet 1/1/7
ip address 10.10.10.2 255.255.255.0 dynamic
!
interface ethernet 1/1/21
disable
!
interface ethernet 1/2/2
speed-duplex 1000-full
!
interface ethernet 1/2/4
speed-duplex 1000-full
!
interface ethernet 1/2/5
speed-duplex 1000-full
!
interface ethernet 1/2/6
speed-duplex 1000-full
!
interface ethernet 1/2/7
speed-duplex 1000-full
!
interface ethernet 1/2/8
speed-duplex 1000-full
!
!
lldp run
!
!
end
2. On a router enter the show configuration command. Examine the output to identify dynamically obtained options.
These options have a “dynamic” tag appended to them in the running configuration.
!
Startup-config data location is flash memory
!
Startup configuration:
!
ver 08.0.61b1T213
!
stack unit 1
module 1 icx7250-24-port-management-module
module 2 icx7250-sfp-plus-8port-80g-module
!
!
vlan 1 name DEFAULT-VLAN by port
!
!
!
ip dns domain-list ManualDomain.com
ip dns domain-list testStaticDomain.com
ip dns server-address 20.20.20.8 20.20.20.9 20.20.20.5
ip route 0.0.0.0/0 10.10.10.1 distance 254 dynamic
!
!
!
interface ethernet 1/1/7
ip address 10.10.10.2 255.255.255.0 dynamic
!
interface ethernet 1/1/21
disable
!
interface ethernet 1/2/2
speed-duplex 1000-full
!
interface ethernet 1/2/4
speed-duplex 1000-full
!
interface ethernet 1/2/5
speed-duplex 1000-full
!
interface ethernet 1/2/6
speed-duplex 1000-full
!
interface ethernet 1/2/7
speed-duplex 1000-full
!
interface ethernet 1/2/8
speed-duplex 1000-full
!
!
lldp run
!
!
end
DHCP Servers
All FastIron devices can be configured to function as DHCP servers.
DHCP introduces the concept of a lease on an IP address. The DHCP server can allocate an IP address for a specified amount of
time or can extend a lease for an indefinite amount of time. DHCP provides greater control of address distribution within a
subnet. This feature is crucial if the subnet has more devices than available IP addresses. In contrast to BOOTP, which has two
types of messages that can be used for leased negotiation, DHCP provides seven types of messages.
DHCP allocates temporary or permanent network IP addresses to clients. When a client requests the use of an address for a time
interval, the DHCP server guarantees not to reallocate that address within the requested time and tries to return the same
network address each time the client makes a request. The period of time for which a network address is allocated to a client is
called a lease. The client may extend the lease through subsequent requests. When the client is done with the address, the
address can be released back to the server. By asking for an indefinite lease, clients may receive a permanent assignment.
DHCP clients can be IP phones, desktops, or network devices, as illustrated in the following figure. The clients can be connected
directly or through other networks using relays. The DHCP server provides information such as the DNS server name, TFTP
server name, and also the image to pick for bootup to the DHCP client. Once the client obtains the IP address, TFTP server name,
and boot image name, the client can download the image from the TFTP server and boot with that image.
In some environments, it may be necessary to reassign network addresses due to exhaustion of the available address pool. In
this case, the allocation mechanism reuses addresses with expired leases.
If the client is directly connected (the giaddr field is zero), the DHCP server matches the DHCP DISCOVER message with
DHCP pools that contain the subnets configured on the receiving interface. If the client is not directly connected (the
giaddr field of the DHCP DISCOVER message is not zero), the DHCP server matches the DHCP DISCOVER message with a
DHCP pool that has the subnet that contains the IP address in the giaddr field.
6. Use the clear ip dhcp-server binding command to delete a specific lease or all lease entries from the lease binding
database.
The asterisk used in the example above clears all the IP addresses.
Where a FastIron device is configured as a DHCP server, you can configure DHCP options. These options are passed to the
connected DHCP clients and allow configuration of parameters such as default router, host name, and domain name server.
1 Subnet Mask Specifies the client subnet mask (per RFC 950). This is not configurable using the option command.
This option is configured using the network (dhcp) command.
Network <router IP> <subnet mask>
3 Router Option Specifies an IP addresses of the default router on the client subnet. Only one router can be
specified.
NOTE
Option 3 is not supported on non-default VRFs and management VRFs.
NOTE
Option 3 functions only when there is no previously configured route on the DHCP client.
If the route received by the DHCP client from the DHCP server is already configured on
the client, the following syslog message is displayed: DHCP: Failed to configure default
gateway.
4 Time Server Specifies a list of Time Servers available to the client. Time Servers are listed in order of preference.
5 Name Server Specifies a list of Name Servers available to the client. Name Servers are listed in order of
preference.
6 Domain Name Server Specifies a list of Domain Name System (RFC 1035) name servers available to the client. Servers are
listed in order of preference.
7 Log Server Specifies a list of UDP log servers available to the client. Servers are listed in order of preference.
8 Quotes Server Specifies a list of Quotes servers available to the client. Servers are listed in order of preference.
9 LPR Server Specifies a list of Line Printer Servers available to the client. Servers are listed in order of preference.
10 Impress Server Specifies a list of Imagen Impress Servers available to the client. Servers are listed in order of
preference.
11 RLP Server Specifies a list of Resource Location Servers available to the client. Servers are listed in order of
preference.
If a URL does not include a path component, the path /uap is assumed.
100 Pcode Specifies the TZ-POSIX string used to provide timezone details.
101 Tcode Specifies the TZ-Database string used to provide timezone details.
102 - 111 Removed/Unassigned These options are supported if the value type is defined as IP, ASCII, or HEX
112 Netinfo Address This option is supported if the option value type is IP, ASCII, or HEX
113 Netinfo Tag This option is supported if the option value type is IP, ASCII, or HEX
114 URL This option is supported if the option value type is IP, ASCII, or HEX
120 SIP Servers Specifies the IP address or, preferably, the DNS fully qualified domain name to be used by the
Session Initiation Protocol (SIP) client to locate a SIP server.
125 V-I VendorSpeciInfo This option is supported if the value type is defined as IP, ASCII, or HEX This option is supported if
the value type is defined as IP, ASCII, or HEX
126 - 127 Removed/Unassigned These options are supported if the option value type is IP, ASCII, or HEX
128 - 135 PXE-VendorSpecific These options are supported if the option value type is IP, ASCII, or HEX
NOTE
Options not listed in the table are not supported or not configurable using the option command.
A DHCP server assigns and manages IPv4 addresses from multiple address pools, using dynamic address allocation. The DHCP
server also contains the relay agent to forward DHCP broadcast messages to network segments that do not support these types
of messages.
The following options (if configured) are prioritized, with additional options added as needed:
• 3 - Router Option
DHCP options are not validated by the DHCP server. You must ensure the values are configured correctly.
Upgrade considerations
In FastIronFastIron 08.0.61 or earlier releases, it was possible to configure a subset of these DHCP options using specific
commands. For example, dhcp-default-router allows configuration of the DHCP default router (which is now also configurable
using DHCP option 3). When upgrading to FastIron 08.0.70, any configured DHCP options are retained. However, the
configuration is stored and shown in the new options format. The following table shows the options available in earlier releases
and a mapping between the new option format and the corresponding commands available in earlier releases.
Option number and name Command in release 08.0.70 Command in release 08.0.61 and earlier
1 - Subnet Mask network router-IP subnet mask network router-IP subnet mask
Note that this essential option is configured
using the network command. It is not
configurable using the option command.
3 - Router Option option 3 ip router -IP dhcp-default-router router -IP
6 - Domain Name Server option 6 ip server-IP-address dns-server server-IP-address
12 - Hostname option 12 ascii hostname host-name hostname
15 - Domain name option 15 ascii domain-name domain-name ascii-string-domain-name
47 - NetBIOS over TCP/IP Name Server option 47 ip Server-IP netbios-name-server Server-IP
49 - X Window System Display Manager option 49 ip XWindow-manager-IP xwindow-manager XWindow-manager-IP
66 - TFTP server hostname option 66 ascii TFTP-server-hostname tftp-server TFTP-server-hostname
67 - Bootfile name option 67 ascii bootfile-name bootfile bootfile-name
150 - TFTP server IP address option 150 ip TFTP-server-IP tftp-server TFTP-server-IP
176 - ip-telephony voice server option 176 mcipadd mcport,… ip-telephony voice mcipadd mcport,…
242 - ip-telephony data server option 242 mcipadd mcport,… ip-telephony data mcipadd mcport,…
252 - Proxy-Auto Config (PAC) option 252 ascii URL-to-config-file wpad URL-to-config-file
60 - Vendor-Specific Information option 60 ascii VCI vendor-class ascii-string-VCI
Note that the existing commands are still supported. However, it is recommended that you configure these using the option
command where appropriate. The configuration is stored and shown in the options format, irrespective of whether the option is
configured using the option command or the commands available in previous releases.
If required, you can prevent the response to DHCP client requests received on the management port by disabling DHCP server
support on the port. When the DHCP server is disabled, DHCP client requests that are received on the management port are
discarded.
1. Enter global configuration mode by issuing the configure terminal command.
At startup, the server reconciles the lease binding database by sending an ARP ping packet out to every client. If there is no
response to the ARP ping packet within a set amount of time (set in seconds), the server deletes the client from the lease binding
database. The minimum setting is 5 seconds and the maximum is 30 seconds.
NOTE
Do not alter the default value unless it is necessary. Increasing the value of this timer may increase the time to get
console access after a reboot.
2. Specify the number of seconds to wait for a response to an ARP ping packet.
The following example configures a wait ARP ping packet timeout response to 20 seconds.
In a metropolitan Ethernet-access environment, the DHCP server can centrally manage IP address assignments for a large
number of subscribers. If DHCP option 82 is disabled, a DHCP policy can only be applied per subnet, rather than per physical
port. When DHCP option 82 is enabled, a subscriber is identified by the physical port through which it connects to the network.
This option enables the DHCP server to echo relay agent information in all replies.
NOTE
It is not possible to configure relay agent echo (option 82) using the option command. The command and syntax to
configure option 82 is shown below.
In this task example, the DHCP client should use the boot image called "ICX". This variable can have an extension of .bin, .txt,
or .cfg.
device(config-dhcp-cabo)# deploy
NOTE
Specify one default router IP address only. Do not enter multiple router addresses.
3. Specify the IP addresses of the DNS servers that are available to the DHCP clients.
You can set a lease duration for days, hours, or minutes, or any combination of the three.
device(config-dhcp-cabo)# lease 1 4 32
In the example, the lease duration has been set to one day, four hours, and 32 minutes.
You can specify a single address or a range of addresses that should be excluded from the address pool.
3. Specify the address that should be excluded from the address pool.
3. Specify the subnet network and mask length of the DHCP address pool.
NOTE
If DHCP options 66 (TFTP server name) and 150 (TFTP server IP address) are both configured, the DHCP client ignores
option 150 and tries to resolve the TFTP server name (option 66) using DNS.
The first example configures a TFTP server by specifying its IP address, while the second example configures a TFTP
server by specifying its server name.
The X Window client is a DHCP client in a network that solicits configuration information by broadcasting a DHCP discovery
packet on bootup or when the DHCP client is enabled. The DHCP server provides the IP addresses of systems running the X
Window System Display Managers available in the network in their preferred order as part of the DHCP offer message.
On receipt of a discovery packet from the client, a DHCP offer message must be sent back. Option 49 must be added with the IP
addresses of systems running the X Window System Display Manager in the network, along with other mandatory options. You
can configure a maximum of three IP addresses in a DHCP server pool.
NOTE
Option 49 is ignored if the client is a non-X Window client.
2. Configure an address pool in the DHCP server and enter DHCP server pool configuration mode.
3. Enter the xwindow-manager command along with the IP addresses of the X Window System Display Managers
separated by spaces.
The following example configures the IP addresses of systems running the X Window System Display Manager in the DHCP
configuration pool.
Configuring the DHCP option 60 helps in identifying the incoming DHCP client. If the vendor class identifier (VCI) advertised by
the DHCP client matches with the DHCP server, the server makes a decision to exchange the vendor-specific information (VSI)
configured as part of DHCP option 43.
The Ruckus ICX DHCP server can recognize the DHCP client device using the VCI (option 60) and pass specific information to this
device type only (using option 43). However, the DHCP server can be configured to always pass additional information using
option 43 (regardless of the client).
In summary:
• Option 60 defines the vendor type and configuration value
• Option 43 defines vendor specific information.
• If option 60 is configured, the vendor specific information (defined in option 43) is returned to clients that provide the
appropriate vendor type and configuration value.
• If option 60 is not configured, the vendor specific information is sent to all clients.
NOTE
Save the configuration to retain the configuration through warm or cold reboots.
3. Specify (option 60) the vendor type and configuration value for the DHCP client using the option command.
NOTE
If the ascii option contains a space, you must enter it with double quotes as shown in the previous example.
4. Specify (option 43) the vendor specific information using the option command.
The following example configures option 60 and option 43 (hex) for a Ruckus Access Point (AP).
The following example configures option 60 and option 43 (ASCII) for a Ruckus AP.
This configuration is useful when you want to have selected clients assigned with particular IP addresses from the server.
Whenever a DHCP discover message is received from these clients, based on the static configuration, the IP address will be
assigned with the other required parameters.
3. Enter the static-mac-ip-mapping command followed by the IP address and MAC address for mapping.
The following example enables the static MAC address to IP address mapping.
On receipt of a discovery packet from the Avaya IP telephone client, a DHCP offer message must be sent back. Options 176 and
242 must be added with the details of IP telephony voice and data servers present in the network, along with mandatory options.
Option Paramaters
mcport portnum
tftpsrvr/httpsrvr/tlssrvr server-ip-address
Specifies the IP telephony L2QAUD or L2QSIG priority value. The range is from 1 to 6. The default value is
6.
l2qvlan vlan-id
vlantest secs
The number of seconds a phone attempts to return to the previously known voice VLAN. This is not
applicable for the default VLAN.
Option 242: Data server options mcipadd ip-address
mcport portnum
L2QAUD is the IP telephony L2 audio priority value. L2QSIG is the IP telephony L2 signaling priority value.
This range is from 1 through 6. The default value is 6.
l2qvlan vlan-id
Option Paramaters
vlantest secs
The number of seconds a phone attempts to return to the previously known voice VLAN. This is not
applicable for the default VLAN.
NOTE
Options 176 and 242 are ignored for non-Avaya IP telephone clients.
2. Configure an address pool in the DHCP server and enter DHCP server pool configuration mode.
3. Enter the option command followed by the supported parameters. The parameters you can add for IP telephony data
are mcipadd, mcport, httpsrvr, l2qaud, l2qsig, l2qvlan, tftpsrvr, tlssrvr, and vlantest.
The following example specifies the MCIP address and MCPORT of the data server.
4. Enter the option command followed by the supported parameters. The parameters you can add for IP telephony voice
are mcipadd, mcport, httpsrvr, l2qaud, l2qsig, l2qvlan, tftpsrvr, tlssrvr, and vlantest.
The following example specifies the MCIP address and MCPORT of the voice server.
5. Enter the show ip dhcp-server address-pools command to view and verify the IP telephony options.
The WPAD protocol can use a DNS or DHCP server to locate a PAC file. DHCP detection involves the URL being pushed to the user
in the DHCP assignment, while DNS detection is based on an informed guess, using known information about the DNS. A web
browser that supports both methods checks the DHCP assignment first, and then attempts the DNS method. If the browser is
unable to load a PAC file through the DHCP or DNS methods, it will allow direct Internet access.
NOTE
The PAC file must have the file name wpad.dat for the DNS method to function.
2. Configure an address pool in the DHCP server and enter DHCP server pool configuration mode.
3. Enter the option command followed by the full network location of the PAC file.
4. Enter the show ip dhcp-server address-pools command to view the configured network location of the PAC file.
Use one of the commands to view DHCP server information. The commands do not need to be entered in the specified order.
• Display a specific active lease, or all active leases.
• Display information about active leases, deployed address pools, undeployed address pools, and server uptime.
device(config)# show ip
Switch IP address: 10.44.16.116
Subnet mask: 255.255.255.0
Default router address: 10.44.16.1
TFTP server address: 10.44.16.41
Configuration filename: foundry.cfg
Image filename: None
• Display the Layer 2 device configuration using the show run command.
• Display the Layer 3 device configuration using the show run command.
!
ver 08.0.40
!
module 1 icx7750-20-qxg-port-management-module
module 2 icx7750-qsfp-6port-qsfp-240g-module
!
vlan 1 name DEFAULT-VLAN by port
!
ip dns server-address 10.44.3.111
interface ethernet 0/1/2
ip address 10.44.3.233 255.255.255.0 dynamic
ip dhcp-client lease 691109
interface ethernet 0/1/15
ip address 10.0.0.1 255.0.0.0
ip helper-address 1 10.44.3.111
!
end
DHCPv4 overview
The Dynamic Host Configuration Protocol for DHCPv4 enables DHCP servers to pass configuration parameters such as IPv4
addresses to IPv4 hosts.
On FastIron devices, you can configure Dynamic ARP Inspection, DHCPv4 snooping, and IP Source Guard together. The Ruckus
implementation of these features provides enhanced network security by filtering untrusted DHCP packets.
The Dynamic Host Configuration Protocol (DHCP) is based on the Bootstrap Protocol (BOOTP) and provides configuration
parameters such as IP addresses, default routes, DNS server addresses, access control, QoS policies, and security policies stored
in DHCP server databases to DHCP clients upon request. DHCP enables the automatic configuration of client systems. DHCP
removes the need to configure devices individually. Clients can set network properties by connecting to the DHCP server instead.
This protocol consists of two components; a protocol to deliver host-specific configuration parameters from a DHCP server to a
host, and a mechanism to allocate network addresses to hosts.
DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver
configuration parameters to dynamically configured hosts.
DHCP Assist ensures that a DHCP server that manages multiple IP subnets can readily recognize the requester IP subnet, even
when that server is not on the client local LAN segment. The Ruckus Layer 2 switch does so by stamping each request with its IP
gateway address in the DHCP discovery packet.
NOTE
Ruckus Layer 2 switches provide BOOTP/DHCP assistance by default on an individual port basis. Refer to Changing the
IP address used for stamping BOOTP and DHCP requests in the Ruckus FastIron Layer 3 Routing Configuration Guide.
By allowing multiple subnet DHCP requests to be sent on the same wire, you can reduce the number of router ports required to
support secondary addressing, as well as reduce the number of DHCP servers required by allowing a server to manage multiple
subnet address assignments.
FIGURE 6 DHCP requests in a network without DHCP Assist on the Layer 2 switch
In a network operating without DHCP Assist, hosts can be assigned IP addresses from the wrong subnet range because a router
with multiple subnets configured on an interface cannot distinguish among DHCP discovery packets received from different
subnets.
In the example depicted, a host from each of the four subnets supported on a Layer 2 switch requests an IP address from the
DHCP server. These requests are sent transparently to the router. Because the router is unable to determine the origin of each
packet by subnet, it assumes the lowest IP address or the "primary address" is the gateway for all ports on the Layer 2 switch and
stamps the request with that address.
When the DHCP request is received at the server, it assigns all IP addresses within that range only.
With DHCP Assist enabled on a Ruckus Layer 2 switch, correct assignments are made because the Layer 2 switch provides the
stamping service.
FIGURE 7 DHCP requests in a network with DHCP Assist operating on a FastIron switch
When the stamped DHCP discovery packet is then received at the router, it is forwarded to the DHCP server. The DHCP server
then extracts the gateway address from each request and assigns an available IP address within the corresponding IP subnet.
The IP address is then forwarded back to the workstation that originated the request.
NOTE
When DHCP Assist is enabled on any port, Layer 2 broadcast packets are forwarded by the CPU. Unknown unicast and
multicast packets are still forwarded in hardware, although selective packets such as IGMP, are sent to the CPU for
analysis. When DHCP Assist is not enabled, Layer 2 broadcast packets are forwarded in hardware.
NOTE
The DHCP relay function of the connecting router must be turned on.
The gateway list contains a gateway address for each subnet that will be requesting addresses from a DHCP server. The list
allows the stamping process to occur. Each gateway address defined on the Layer 2 switch corresponds to an IP address of the
Ruckus router interface or other router involved.
When multiple IP addresses are configured for a gateway list, the Layer 2 switch inserts the addresses into the discovery packet
in a round-robin fashion. Up to 32 gateway lists can be defined for each Layer 2 switch.
2. Configure the required gateway lists. Up to eight addresses can be defined for each gateway list in support of ports that
are multihomed.
3. Enter interface configuration mode and associate gateway list 1 with interface 1/1/2.
Dynamic ARP Inspection (DAI) enables the Ruckus device to intercept and examine all ARP request and response packets in a
subnet and discard packets with invalid IP-to-MAC address bindings. DAI can prevent common man-in-the-middle (MiM) attacks
such as ARP cache poisoning, and disallow misconfiguration of client IP addresses.
DAI allows only valid ARP requests and responses to be forwarded and supports Multi-VRFs with overlapping address spaces.
ARP poisoning
ARP provides IP communication within a Layer 2 broadcast domain by mapping an IP address to a MAC address. Before a host
can talk to another host, it must map the IP address to a MAC address first. If the host does not have the mapping in its ARP
table, it creates an ARP request to resolve the mapping. All computers on the subnet receive and process the ARP requests, and
the host whose IP address matches the IP address in the request sends an ARP reply.
An ARP poisoning attack can target hosts, switches, and routers connected to the Layer 2 network by poisoning the ARP caches
of systems connected to the subnet and by intercepting traffic intended for other hosts on the subnet. For instance, a malicious
host can reply to an ARP request with its own MAC address, thereby causing other hosts on the same subnet to store this
information in their ARP tables or replace the existing ARP entry. Furthermore, a host can send gratuitous replies without having
received any ARP requests. A malicious host can also send out ARP packets claiming to have an IP address that actually belongs
to another host (for example, the default router). After the attack, all traffic from the device under attack flows through the
attacker computer and then to the router, switch, or host.
When you enable DAI on a VLAN, by default, all member ports are untrusted. You must manually configure trusted ports. In a
typical network configuration, ports connected to host ports are untrusted. You configure ports connected to other switches or
routers as trusted.
DAI inspects ARP packets received on untrusted ports, as shown in the following figure. DAI carries out the inspection based on
IP-to-MAC address bindings stored in a trusted binding database. For the Ruckus device, the binding database is the ARP table
and the DHCP snooping table, which supports DAI, DHCP snooping, and IP Source Guard. To inspect an ARP request packet, DAI
checks the source IP address and source MAC address against the ARP table. For an ARP reply packet, DAI checks the source IP,
source MAC, destination IP, and destination MAC addresses. DAI forwards the valid packets and discards those with invalid IP-to-
MAC address bindings.
When ARP packets reach a trusted port, DAI lets them through, as shown in the following figure.
• DHCP-Snooping ARP - Information collected from snooping DHCP packets when DHCP snooping is enabled on VLANs.
DHCP snooping entries are stored in a different table and are not part of the ARP table.
• Valid - The mapping is valid, and the port is resolved. This is always the case for static ARP entries.
• Pending - For normal dynamic ARP entries before they are resolved. Their status changes to valid when they are
resolved, and the port is mapped. Refer to System reboot and the binding database on page 73.
NOTE
You must save the configuration with the write memory command and reload the software to place the change into
effect.
This command defines an ARP inspection entry in the static ARP table and maps the device IP address 10.20.20.12 with
its MAC address, 0000.0002.0003. The ARP entry will be moved to the ARP table once the DAI receives a valid ARP packet
with the matching IP and MAC addresses on a device port. Until then, the ARP entry will remain in Pend (pending) status.
3. NOTE
Dynamic ARP Inspection must be enabled to use static ARP inspection entries.
The command enables DAI on VLAN 2. ARP packets from untrusted ports in VLAN 2 will undergo DAI.
4. Enable trust on any ports that will bypass DAI.
a) To enable trust on a port, enter interface configuration mode.
These commands change the CLI to the interface configuration level of port 1/1/4 and set the trust setting of port
1/1/4 to trusted.
5. Enable DHCP snooping to populate the DHCP snooping IP-to-MAC address binding database. Refer to text on DHCP
snooping for more information.
The following example configures a dynamic ARP inspection table entry, enables DAI on VLAN 2, and designates port 1/1/4 as
trusted.
Syslog messages are enabled by default on FastIron devices. Follow these steps to disable DAI messages.
2. Enter the ip arp inspection syslog disable command to disable syslog messages.
Use the following commands to view ARP-related information. The commands do not need to be entered in the specified order,
and can be used to view the ARP table as well as ARP inspection status and trusted or untrusted ports.
The output of this command displays all ARP entries in the system.
2. Display the ARP inspection status for a VLAN and the trusted and untrusted port.
This command displays DAI information for VLAN 2. DAI is disabled on the VLAN, and port 1/1/4 is the only trusted port.
The following example displays ARP inspection entries with a specific Ethernet port.
The following example displays ARP inspection entries with a specific IP address.
The following example displays ARP inspection entries with a specific LAG.
The following example displays ARP inspection entries with a specific VLAN.
The following example displays ARP inspection entries with a specific VLAN.
You can enable DAI on individual VLANs and assign any interface as the ARP inspection trusted interface. If an interface is a
tagged port in this VLAN, you can turn on the trusted port per VRF, so that traffic intended for other VRF VLANs will not be
trusted.
2. NOTE
DAI requires that the ACL-per-port-per-VLAN setting be enabled.
Enable the ACL-per-port-per-VLAN setting. You must save the setting and reload for it to take effect.
This example enables ACL-per-port-per-VLAN, saves the change, and reloads the device to make the change active.
3. Return to global configuration mode, and configure DAI on a VLAN.
This example creates a static ARP inspection entry for the VRF named "one-ipv4."
This example configures the VRF named "vrf2" as a trusted VRF on port 1/1/4.
DHCP snooping
DHCP snooping enables the Ruckus device to filter untrusted DHCP packets in a subnet. DHCP snooping can ward off MiM
attacks, such as a rogue DHCP server sending false DHCP server reply packets with the intention of misdirecting other users.
DHCP snooping can also stop unauthorized DHCP servers and prevent errors stemming from user misconfiguration of DHCP
servers.
DHCP snooping is often used with Dynamic ARP Inspection and IP Source Guard.
Beginning with FastIron release 8.0.30b, the DHCP binding database in the Ruckus device is decoupled from the ARP database.
For more information, refer to ARP and DHCP snoop entries on page 66.
The lease time is refreshed when the client renews its IP address with the DHCP server; otherwise, the Ruckus device removes
the entry when the lease time expires.
In earlier releases, in the Layer 3 software image, DHCP snooping did not learn the secure IP-to-MAC address mapping for a
client, if the client port was not a Virtual Ethernet (VE) interface with an IP subnet address. In other words, the client IP address
had to match one of the subnets of the client port in order for DHCP to learn the address mapping.
• There is a limit on the maximum number of DHCP snooping entries that the device can learn. This is determined by the
system-max parameter max-dhcp-snoop-entries. The maximum value is 3072 and the default value is 1024. This value
is also applicable to the flash file where DHCP snooping entries are stored.
• DHCP snooping is not supported along with DHCP auto-configuration.
• You cannot apply MAC address filters on a VLAN member on which DHCP snooping is already enabled and vice versa.
• ACLs are supported on member ports of a VLAN on which DHCP snooping and Dynamic ARP Inspection (DAI) are
enabled. Refer to Client IP-to-MAC address mappings on page 73.
• DHCP snooping supports DHCP relay agent information (DHCP option 82). Refer to DHCP relay agent information and
option 82 insertion on page 77 for more information.
• For default VLAN ID changes, DHCP snooping and Dynamic ARP Inspection should be re-applied on the new default
VLAN.
To run DHCP snooping, you must first enable support for ACL filtering based on VLAN membership or VE port membership.
Enter the following commands at the global configuration level.
NOTE
You must save the configuration and reload the software for the changes to take effect.
NOTE
DHCP snooping is disabled by default and the trust setting of ports is untrusted by default. DHCP snooping must be
enabled on the client and the DHCP server VLANs.
3. Change the trust setting of the ports that are connected to the DHCP server to trusted at the interface configuration
level.
4. If required, disable the learning of DHCP clients on ports at the interface configuration level. Disabling the learning of
DHCP clients can be configured on a range of ports as well.
5. Clear the DHCP binding database. You can remove all entries in the database or for a specific IP address only.
The first command removes all entries from the DHCP binding database and the second removes entries for a specific IP
address.
The following example configures VLAN 2 and VLAN 20, and changes the CLI to the global configuration level to enable DHCP
snooping on the two VLANs.
device(config)# vlan 2
device(config-vlan-2)# untagged ethe 1/1/3 to 1/1/4
device(config-vlan-2)# router-interface ve 2
device(config-vlan-2)# exit
device(config)# ip dhcp snooping vlan 2
device(config)# vlan 20
device(config-vlan-20)# untagged ethe 1/1/1 to 1/1/2
device(config-vlan-20)# router-interface ve 20
device(config-vlan-20)# exit
device(config)# ip dhcp snooping vlan 20
On VLAN 2, client ports 1/1/3 and 1/1/4 are untrusted. By default all client ports are untrusted. Thus, only DHCP client request
packets received on ports 1/1/3 and 1/1/4 are forwarded. On VLAN 20, ports 1/1/1 and 1/1/2 are connected to a DHCP server.
DHCP server ports are set to trusted.
Thus, DHCP server reply packets received on ports 1/1/1 and 1/1/2 are forwarded, and client IP/MAC binding information is
collected. The example also sets the DHCP server address for the local relay agent.
device(config)# interface ve 2
device(config-vif-2)# ip address 10.20.20.1/24
device(config-vif-2)# ip helper-address 1 10.30.30.4
device(config-vif-2)# interface ve 20
device(config-vif-20)# ip address 10.30.30.1/24
Use one of the following commands to view DHCPv4 snooping information. The commands do not need to be entered in the
specified order.
1. Display the DHCP snooping status for a VLAN and the trusted and untrusted ports in the VLAN.
You can enable DHCP snooping on individual VLANs and assign any interface as the DHCP trust interface. If an interface is a
tagged port in this VLAN, you can turn on the trust port per VRF, so that traffic intended for other VRF VLANs is not trusted
2. To configure DHCP snooping to support a Multi-VRF instance, enable the ACL-per-port-per-VLAN setting.
4. Set the port as a trusted port. The trust port setting for DHCP snooping can be specified per VRF.
The default trust setting for a port is untrusted. For ports that are connected to host ports, leave their trust settings as
untrusted.
5. Configure the IP helper address on the client port if the client and server are in the same VLAN and the client and server
ports are Layer 3 interfaces with IP addresses.
device(config)# interface ve 2
device(config-vif-2)# ip helper-address 1 10.1.1.2
If the client and server are in different VLANs, configure the server port as the trust port.
6. Clear any entry specific to a VRF instance, as required.
The Ruckus device inserts DHCP option 82 when relaying DHCP request packets to DHCP servers. When DHCP server reply
packets are forwarded back to DHCP clients, and sub-option 2 as RID (remote ID) matches the local port MAC address, then
DHCP option 82 is deleted. The vlan/port information is used to forward the DHCP reply.
The DHCP relay agent (the FastIron switch) inserts DHCP option 82 attributes when relaying a DHCP request packet to a DHCP
server.
The FastIron switch deletes DHCP option 82 attributes before forwarding a server reply packet back to a DHCP client.
The DHCP option 82 insertion or deletion feature is available only when DHCP snooping is enabled on both client and server
ports.
Sub-option 1: Circuit ID
The Circuit ID (CID) identifies the circuit or port from which a DHCP client request was sent. The FastIron switch uses this
information to relay DHCP responses back to the proper circuit; for example, the port number on which the DHCP client request
packet was received.
Ruckus FastIron devices support the general CID packet format. This simple format encodes the CID type, actual information
length, VLAN ID, slot number, and port number. This format is compatible with the format used by other vendors’ devices. The
following figure illustrates the general CID packet format.
Sub-option 2: Remote ID
The Remote ID (RID) identifies the remote host end of the circuit (the relay agent). Ruckus devices use the MAC address to
identify itself as the relay agent. The following figure illustrates the RID packet format.
Sub-option 6: Subscriber ID
The Subscriber ID (SID) is a unique identification number that enables an Internet Service Provider (ISP) to perform the following
actions:
• Identify a subscriber
• Assign specific attributes to that subscriber (for example, host IP address, subnet mask, and domain name server (DNS)
• Trigger accounting
The second byte (N in the figure) is the length of the ASCII string that follows. The FastIron switch supports up to 50 ASCII
characters.
When processing DHCP packets the FastIron switch applies the following default behavior when DHCP option 82 is enabled:
• Subjects all ports in the VLAN to DHCP option 82 processing
• Uses the general CID packet format
• Uses the standard RID packet format
• Replaces relay agent information received in DHCP packets with its own information
• Does not enable SID processing
Option 82 is automatically enabled when you enable DHCP snooping on the VLAN.
1. To disable Option 82, enter global configuration mode by issuing the configure terminal command.
5. You can also re-enable DHCP option 82 after it has been disabled on a range of ports. First, specify the range of ports at
the global configuration level and then enter the dhcp snooping relay information command.
The following example re-enables DHCP option 82 at the interface configuration level.
You can configure the device to keep the information instead of replacing it, or to drop (discard) messages that contain relay
agent information.
2. Configure the device to keep the relay agent information contained in a DHCP message.
3. Alternately, configure the device to drop the relay agent information contained in the DHCP message.
4. Enable interface 1/1/4 to insert the SID, CID, or RID information in the DHCP packets.
The following example enables interface 1/1/4 to insert the CID information in the DHCP packets.
The following example enables interface 1/1/4 to insert the RID information in the DHCP packets.
Use one of the following commands to view DHCP Option 82 processing. The commands do not need to be entered in the
specified order.
1. Enter the show ip dhcp relay information command to display information about the Circuit ID, Remote ID, and
forwarding policy for DHCP Option 82.
2. Enter the show ip dhcp snooping vlan command to display information about the trusted ports, untrusted ports, and
ports on which DHCP Option 82 is disabled.
The output shows the DHCP option 82 enabled on the device and the configured Subscriber ID to be Ruckus001.
NOTE
The port up or down time is required only for physical ports and not for loopback, ve, or tunnel ports.
Configuring the source IP address of a DHCP client packet on the DHCP relay agent
Enables the DHCP server to know the source subnet or network of a DHCP-client packet.
By default, a DHCP relay agent forwards a DHCP client packet with the source IP address set to the IP address of the outgoing
interface to the DHCP server. You can configure ACLs on a DHCP server to provide or block DHCP services to particular subnets
or networks. The ip bootp-use-intf-ip command configures a DHCP relay agent to set the source IP address of a DHCP client
packet with the IP address of the incoming interface for the packet. This reveals the source subnet or network of a DHCP client
packet to the DHCP server and enables the DHCP server to process or discard the DHCP traffic according to the configured ACLs.
Enter the ip bootp-use-intf-ip command in global configuration mode of the DHCP relay agent.
device(config)# ip bootp-use-intf-ip
IP Source Guard
You can use IP Source Guard together with Dynamic ARP Inspection on untrusted ports.
The Ruckus implementation of the IP Source Guard technology supports configuration on a port, specific VLAN memberships on
a port (Layer 2 devices only), and specific ports on a Virtual Ethernet (VE) interface (Layer 3 devices only).
When IP Source Guard is first enabled, only DHCP packets are allowed, while all other IP traffic is blocked. IP Source Guard allows
IP traffic when the system learns valid IP addresses. The system learns of a valid IP address from DHCP snooping.
When a new IP source entry binding on the port is created or deleted, the ACL is recalculated and reapplied in the hardware to
reflect the change in IP source bindings. By default, if IP Source Guard is enabled without any IP source binding on the port, an
ACL that denies all IP traffic is loaded on the port.
NOTE
When IPv4 ACLs and IP source guard are configured on the same port, both the rules will be clubbed together
and the combined number of filters in that ACL must not exceed 1024.
• On certain Ruckus devices, such as ICX 7150 that have smaller TCAM, the IP source guard entries are limited to 256
entries. The scaling number of 256 per port in ICX 7150 and 520 per port in all other platforms is not guaranteed and
depends on the number of free TCAM rules. Since IP source guard is programmed in the TCAM and if there are fewer
TCAM rules, then the number of free TCAM rules will determine the number of IP source guard entries that are allowed.
• When IPSG and DHCP snooping are enabled on SPX Virtual (PE) ports and DHCP clients are learnt on the port, system
performance may be degraded if more than 256 clients are learnt on the same port.
• You can enable IP Source Guard on a range of ports within a given slot only. Enabling IP Source Guard across multiple
slots is not supported.
• The number of configured ACL rules affect the rate at which hardware resources are used when IP Source Guard is
enabled. Use the show access-list hw-usage on command to enable hardware usage for an ACL, followed by the show
access-list access-list-id command to determine the hardware usage for an ACL. Modifying the ACL rules ensures that
more hardware resources are provided for IP Source Guard addresses. For example.
• If you enable IP Source Guard in a network topology that has DHCP clients, you must also enable DHCP snooping. If you
do not enable DHCP snooping, all IP traffic, including DHCP packets, are blocked.
• When you enable IP Source Guard in a network topology that does not have DHCP clients, you must create an IP source
binding for each client that is allowed access to the network. Data packets are blocked if you do not create an IP source
binding for each client.
• IP Source Guard protection enables concurrent support with MAC authentication.
• IP Source Guard is supported on a VE with or without an assigned IP address.
• IP Source Guard supports multi-VRF instances.
To run IP Source Guard, you must first enable support for ACL filtering based on VLAN membership or VE port membership.
Enter the following commands at the global configuration level.
NOTE
You must save the configuration and reload the software for the changes to take effect.
4. To enable IP Source Guard on a range of ports, enter interface configuration mode and specify the range of ports.
When enabling IP Source Guard on a range of ports, you can choose only a range of ports within a given slot.
5. Enable IP Source Guard on the range of ports specified in the previous step.
NOTE
If you try to configure IP Source Guard across different modules, the following error displays.
Note that because static IP source bindings consume system resources, you should avoid unnecessary bindings.
1. Enter global configuration mode by issuing the configure terminal command.
2. Enter the ip source binding command followed by a valid IP address and the interface number. Entering the VLAN
number is optional.
If you enter a VLAN number, the binding applies to that VLAN only. If you do not enter a VLAN number, the static binding
applies to all VLANs associated with the port.
1. Enter the global configuration mode by issuing the configure terminal command.
device(config)# vlan 12
4. Add ports Ethernet 23 through Ethernet 24 as tagged ports and exit the mode.
1. Enter the global configuration mode by issuing the configure terminal command.
device(config)# vlan 12
device(config)# vlan 2
device(config-vlan-2)# tagged ethe 2/1/36 ethe 12/1/38 to 12/1/39 ethe 17/2/2 ethe 55/1/32
device(config-vlan-2)# router-interface ve 2
device(config-vlan-2)# interface ve 2
The following example configures IP Source Guard on untagged ports in a virtual interface.
To configure IP Source Guard to support a VRF instance, you must first enable the ACL-per-port-per-VLAN setting.
The Ruckus implementation of IP Source Guard supports configuration on a port, on specific VLAN memberships on a port (Layer
2 devices only), and on specific ports on a virtual interface (VE) (Layer 3 devices only).
device(config-if-e1000-1/1/1)# per-vlan 2
device(config-if-e1000-1/1/1-vlan-2)# source-guard enable
device(config)# interface ve 30
device(config-vif-30)# source-guard enable ethernet 1/1/1
If the VLAN ID is not provided, this setting will be applied on the port.
NOTE
All static source guard entries in the IP source guard table will be populated as "Yes".
DHCPv6 overview
The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6
network addresses to IPv6 nodes.
The DHCPv6 protocol offers the capability of automatic allocation of reusable network addresses and additional configuration
flexibility.
On FastIron devices, you can configure DHCPv6 snooping, the DHCPv6 relay agent, DHCPv6 relay include options, and the
DHCPv6 Relay Agent Prefix Delegation Notification.
A DHCPv6 relay agent, which may reside on the client link, but is transparent to the client, relays messages between the client
and the server. Multiple DHCPv6 relay agents can exist between the client and server. DHCPv6 relay agents can also receive
relay-forward messages from other relay agents; these messages are forwarded to the DHCPv6 server specified as the
destination.
When the relay agent receives a message, it creates a new relay-forward message, inserts the original DHCPv6 message, and
sends the relay-forward message as the DHCPv6 server.
3. Specify the relay destination (the DHCP server) address on the interface.
The IPv6 address is the destination address to which client messages are forwarded and which enables DHCPv6 relay
service on the interface. You can configure up to 16 relay destination addresses on an interface.
4. Specify the outgoing interface parameter.
Use the outgoing-interface parameter when the destination relay address is a link-local or multicast address. Specify
the interface type as ethernet, tunnel interface, or VE. Specify the port-num as the port number.
The following example enables the DHCPv6 relay agent function and specifies the relay destination address (i.e. the DHCP server)
on an interface.
In some network environments, it is useful for the relay agent to add information to the DHCPv6 message before relaying it. The
information that the relay agent carries can also be used by the DHCP server to make decisions about the addresses, delegated
prefixes, and configuration parameters that the client should receive. The DHCPv6 relay-forward message contains relay agent
parameters that identify the client-facing interface on which the reply messages can be forwarded. You can use either one or all
of the parameters as client identifiers.
The relay agent may send the interface-ID option (18) to identify the interface on which a client message was received. If the relay
agent cannot use the address in the link-address field to identify the interface through which the response to the client will be
relayed, the relay agent must include an interface-ID option in the relay-forward message. If the relay agent receives a relay-reply
message with an interface-ID option, the relay agent relays the message to the client through the interface identified by the
option. The server must also copy the interface-ID option from the relay-forward message into the relay-reply message the
server sends to the relay agent in response to the relay-forward message.
The remote-ID option (37) may be added by the DHCP relay agent that terminates switched or permanent circuits and uses a
mechanism to identify the remote host end of the circuit. The remote ID must be unique. A DHCPv6 relay agent can be
configured to include a remote-ID option in the relay-forward DHCPv6 messages.
The client link layer (MAC) address option (79) can be used along with other identifiers to associate DHCPv4 and DHCPv6
messages from a dual-stack client, and is useful in environments where operators using an existing DHCPv4 system with the
client link layer address as the customer identifier need to correlate DHCPv6 assignments using the same identifier.
NOTE
If you enable the client link layer (MAC) option and save the configuration, and then downgrade to a version of the
software that does not support this feature, an error message displays. You must remove any configuration related to
this option before the downgrade and add the configuration after the upgrade to prevent this error.
The options include the interface-ID, remote-ID, or link layer option. Perform the following steps to include the DHCPv6 relay
options.
3. Enter the ipv6 dhcp-relay include-options command followed by the required options: interface-ID, remote-ID or
link-layer-option.
A route is added to the IPv6 route table on the provider edge router (PE) for the delegated prefix to be delegated to requesting
routers. The DHCP server chooses a prefix for delegation and responds with it to the CPEx. to the external network, and to
enable the correct forwarding of the IPv6 packets for the delegated IPv6 prefix. Adding the delegated prefix to the IPv6 route
table ensures that the unicast Reverse Path Forwarding (uRPF) works correctly.
Because the PE is also a DHCPv6 relay agent (it relays DHCPv6 messages between the CPE and the DHCP server), it examines all
DHCPv6 messages relayed between the CPE and the DHCP server and gathers information about a delegated prefix and then
manages the advertisement of this delegated prefix to the external network.
synchronized. The NTP synchronization is needed for the correct updating of the prefix age. If the NTP is not configured,
then the DHCP prefix delegation will still read the flash, but the prefix age may not be correct.
You can disable the DHCPv6 Relay Agent Prefix Delegation Notification at the system or the interface level by setting the IPv6
DHCP relay maximum delegated prefixes to 0 at the system or interface level as required.
Make sure that there is enough free space in the flash memory to save information about delegated prefixes in flash on both the
Active and Standby management processor.
2. Set the maximum number of prefixes that can be learned at the global level.
You can limit the maximum number of prefixes that can be learned at the global level. The range is from 0 through 512.
The default value is 500. The DHCPv6 prefix delegation default for the ICX 7750 is 50.
The following example sets the maximum number of prefixes that can be learned at the global level to 500.
You can limit the maximum number of prefixes that can be delegated. The range is from 0 through 512. The default
value is 100. The sum of all the delegated prefixes that can be learned at the interface level is limited by the system max.
The following example sets the number of delegated prefixes that can be learned to 100.
The value parameter is used to assign the administrative distance to DHCPv6 static routes on the interface. The range is
from 1 to 255. The default value is 10. If the value is set to 255, then the delegated prefixes for this interface will not be
installed in the IPv6 static route table.
The following example sets the administrative distance to the DHCPv6 static routes on the interface to 25.
Use one of the following commands to view DHCPv6 relay agent and prefix delegation information. The commands do not need
to be entered in the specified order.
The output of this command displays information about the relay options available to the prefixed delegates for a
specific interface.
The output of this command displays the DHCPv6 relay agent information configured on the device.
3. Enter the show ipv6 dhcp-relay interface command.
The output of this command displays DHCPv6 relay information for a specific interface.
4. Enter the show ipv6 dhcp-relay destinations command.
The output of this command displays information about the delegated prefixes' configured destinations for a specific
interface.
5. Enter the show ipv6 dhcp-relay prefix-delegation-information command.
The output of this command displays additional information about the DHCPv6 prefix delegation.
6. Enter the show ipv6 dhcp-relay delegated-prefixes command.
The output of this command displays information about the delegated prefixes.
1. Clear the DHCPv6 delegated prefixes using the clear command at the privileged EXEC level.
This command clears the DHCPv6 delegated prefixes for VRF1. If you do not provide the VRF name, the information for
the default VRF is cleared. You can also use the all or interface keywords. Optionally, you can also clear a specific
DHCPv6 delegated prefix.
2. Clear all the DHCPv6 packet counters using the clear command at the privileged EXEC level.
DHCPv6 snooping
In an IPv6 domain, a node can obtain an IPv6 address using the following mechanisms:
• IPv6 address auto-configuration using router advertisements
• The DHCPv6 protocol
In a typical man-in-the-middle (MiM) attack, the attacker can snoop or spoof the traffic act as a rogue DHCPv6 server. To prevent
such attacks, DHCPv6 snooping helps to secure the IPv6 address configuration in the network.
DHCPv6 snooping enables the Ruckus device to filter untrusted DHCPv6 packets in a subnet on an IPv6 network. DHCPv6
snooping can ward off MiM attacks, such as a malicious user posing as a DHCPv6 server sending false DHCPv6 server reply
packets with the intention of misdirecting other users. DHCPv6 snooping can also stop unauthorized DHCPv6 servers and
prevent errors due to user misconfiguration of DHCPv6 servers.
To run DHCPv6 snooping, you must first enable support for ACL filtering based on VLAN membership or VE port membership.
Enter the following commands at the global configuration level.
NOTE
You must save the configuration and reload the software for the changes to take effect.
NOTE
DHCP snooping is disabled by default and the trust setting of ports is untrusted by default. DHCPv6 snooping must be
enabled on the client and the DHCP server VLANs.
3. Change the trust setting of the ports that are connected to the DHCP server to trusted at the interface configuration
level.
Port 1/1/1 is connected to a DHCPv6 server. The commands change the CLI to the interface configuration level of port
1/1/1 and set the trust setting of port 1/1/1 to trusted.
4. If required, disable the learning of DHCP clients on ports at the interface configuration level. Disabling the learning of
DHCP clients can be configured on a range of ports as well.
5. Clear the DHCP binding database. You can remove all entries in the database or for a specific IP address only.
The first command removes all entries from the DHCP binding database and the second removes entries for a specific IP
address.
The following example configures VLAN 10, and changes the CLI to the global configuration level to enable DHCPv6 snooping on
the configured VLANs.
device(config)# vlan 10
device(config-vlan-10)# untagged ethernet 1/1/1 to 1/1/3
device(config-vlan-10)# exit
device(config)# ipv6 dhcp6 snooping vlan 10
On VLAN 10, client ports 1/1/2 and 1/1/3 are untrusted. By default, all client ports are untrusted. Only DHCPv6 client's SOLICIT
and REQUEST packets received on ports 1/1/2 and 1/1/3 are forwarded.
Port 1/1/1 is connected to a DHCPv6 server. The DHCPv6 server ADVERTISE and REPLY packets received on port 1/1/1 are
forwarded.
You can enable DHCPv6 snooping on individual VLANs and assign any interface as the DHCPv6 trust interface. If an interface is a
tagged port in this VLAN, you can turn on the trust port per VRF, so that traffic intended for other VRF VLANs is not trusted.
2. To configure DHCP snooping to support a Multi-VRF instance, enable the ACL-per-port-per-VLAN setting.
The trust port setting for DHCP snooping can be specified per VRF.
5. Configure the DHCPv6 relay agent on the VE interface if the client and server are not in the same VLAN.
6. To clear a DHCPv6 binding database of a specific Multi-VRF enter the following command.
7. To clear a specific DHCPv6 binding belonging to a specific IPv6 address and VRF, enter the following command.
8. To clear default VRF DHCPv6 snooping entries, enter the following command.
Use one of the following commands to view DHCPv6 snooping information. The commands do not need to be entered in the
specified order.
1. Enter the show ipv6 dhcp6 snooping command.
The output of this command displays information about the DHCPv6 snooping status and ports
2. Enter the show ipv6 dhcp6 snooping info command.
The output of this command displays the DHCPv6 snooping binding database.