Перейти к содержимому

Dhcp ack has been received on wan0 что это

  • автор:

Все в порядке, но.

Этот текст мало кто будет читать и мы можем написать здесь все, что угодно, например.
Вы живете в неведении. Роботы уже вторглись в нашу жизнь и быстро захватывают мир, но мы встали на светлый путь и боремся за выживание человечества. А если серьезно, то.

В целях обеспечения безопасности сайта от кибератак нам необходимо убедиться, что вы человек. Если данная страница выводится вам часто, есть вероятность, что ваш компьютер заражен или вы используете для доступа IP адрес зараженных компьютеров.

Если это ваш частный компьютер и вы пытаетесь зайти на сайт, например, из дома — мы рекомендуем вам проверить ваш компьютер на наличие вирусов.

Если вы пытаетесь зайти на сайт, например, с работы или открытых сетей — вам необходимо обратиться с системному администратору и сообщить, что о возможном заражении компьютеров в вашей сети.

  • © 2005-2023, «4PDA». 4PDA® — зарегистрированный товарный знак.

WAN and LAN Addressing Using DHCPv6 IA_NA and DHCPv6 Prefix Delegation

Using DHCPv6 IA_NA with DHCPv6 Prefix Delegation Overview

You can use DHCPv6 IA_NA to assign a global IPv6 address to the CPE WAN link and DHCPv6 prefix delegation to provide prefixes for use on the subscriber LAN. DHCPv6 IA_NA and DHCPv6 prefix delegation are done in a single DHCPv6 session. If the CPE sends both the IA_NA and IA_PD options in the same DHCPv6 Solicit message, the BNG returns both a single IPv6/128 address and an IPv6 prefix.

When at least one address is successfully allocated, the router creates a subscriber entry and binds the entry to the assigned address. If both addresses are successfully allocated, the router creates a single subscriber entry and binds both addresses to that entry.

  • Lease Times and Session Timeouts for DHCPv6 IA_NA and DHCPv6 Prefix Delegation
  • Behavior When CPE Sends Separate Renew Requests for IA_NA and IA_PD Address Types

Lease Times and Session Timeouts for DHCPv6 IA_NA and DHCPv6 Prefix Delegation

When you use DHCPv6 IA_NA together with DHCPv6 prefix delegation, note the following about session timeouts and lease times:

  • A session timeout from AAA has the highest precedence and overrides local pool lease times.
  • For DHCPv6 local server, the minimum lease time associated with an address pool takes precedence over pools with longer lease times. For example, if a CPE obtains an IA_NA address from a pool with a lease time of 3600, and a prefix from a pool with a lease time of 7200, the lease time returned in the Reply message from the BNG is 3600.
  • If AAA does not return a session timeout and the address pool does not have a configured lease time, the default setting of 86,400 (one day) is used.

Behavior When CPE Sends Separate Renew Requests for IA_NA and IA_PD Address Types

In some networks, the DHCPv6 client CPE device does both of the following:

  • Initiates negotiation for both the IA_NA and IA_PD address types in a single solicit message.
  • Sends separate lease renew requests for the IA_NA and the IA_PD and the renew requests are received back-to-back.

Starting in Junos OS Release 17.2R3, 17.4R2, 18.1R3, 18.2R2, and 18.3R1, the jdhcpd process extends the lease for both address types in this situation.

  1. When the reply is received for the first renew request, if a renew request is pending for the second address type, the client stays in the renewing state, the lease is extended for the first IA, and the client entry is updated.
  2. When the reply is received for the second renew request, the lease is extended for the second IA and the client entry is updated again.

In earlier releases, the behavior is different for this situation:

  1. The client transitions to the bound state instead of staying in the renewing state. The lease is extended for the first IA and the client entry is updated.
  2. When the reply is received for the second renew request, the lease is not renewed for the second address type and the reply is forwarded to the client. Consequently, when that lease ages out, the binding for that address type is cleared, the access route is removed, and subsequent traffic is dropped for that address or address prefix.

For dual-stacked clients over the same session (PPP over L2TP LNS, DHCP, or IPoE), enhanced subscriber management does not support configurations where both of the following are true:

  • The CPE sends separate DHCPv6 solicit messages for the IA_NA and the IA_PD.
  • The solicit messages specify a type 2 or type 3 DUID (link-layer address).

As a workaround, you must configure the CPE to send a single solicit message for both IA_NA and IA_PD when the other configuration elements are present.

See Also

DHCPv6 Options in a DHCPv6 Multiple Address Environment

In a DHCPv6 environment, DHCPv6 clients can use a single DHCPv6 Solicit message to request multiple addresses (for example, IA_NA address, IA_PD address, or both), as well as the DNS server address (DHCPv6 attribute 23). When a client requests multiple addresses, DHCPv6 uses the following guidelines to determine how options are returned to the client.

  • DNS server address—Whenever a client requests an IA_PD address (either alone or with an IA_NA address) and also requests a DNS server address, DHCPv6 returns a DNS address only when one is specified in the IA_PD pool. If the IA_PD pool does not include a DNS address, DHCPv6 ignores any DNS address configured in the IA_NA pool. If the client requests an IA_NA address (but not an IA_PD address) and also a DNS server address, DHCPv6 returns a DNS address if one is configured in the IA_NA pool.
  • Lease time—DHCPv6 returns the shortest value of the lease times configured in the IA_NA pool, the IA_PD pool, and authd . DHCPv6 uses this value to set the lifetimes and the Renew and Rebind timers.

By default, DHCPv6 local server returns the DNS server address as a global DHCPv6 option. You can override the current default behavior if you want DHCPv6 to return the DNS server address at the suboption level.

See Also

Methods for Obtaining Addresses for Both DHCPv6 Prefix Delegation and DHCPv6 IA_NA

You can set up the BNG to select global IPv6 addresses to be delegated to the requesting router in one the following ways:

  • An external source such as a AAA RADIUS server or a DHCP server using the DHCPv6 relay agent.
  • Dynamic assignment from a local pool of prefixes or global IPv6 addresses that is configured on the BNG

Address assignment for prefix delegation and IA_NA are independent. For example, you can use AAA RADIUS for DHCPv6 IA_NA, and use a local pool for prefix delegation.

  • Address Pools for DHCPv6 Prefix Delegation and DHCPv6 IA_NA
  • Using a AAA RADIUS Server to Obtain IPv6 Addresses and Prefixes
  • Junos OS Predefined Variable for Multiple DHCPv6 Address Assignment

Address Pools for DHCPv6 Prefix Delegation and DHCPv6 IA_NA

You need two separate address pools for prefix delegation and IA_NA. The pool used for IA_NA contains /128 addresses, and the pool for prefix delegation contains /56 or /48 addresses.

You can specify the name of a delegated pool to use for prefix delegation, which means that you do not need to use AAA to obtain the pool name. In this configuration, if you have also specified a pool match order, the specified delegated pool takes precedence.

You can configure pool attributes so that the IA_NA pool and the prefix delegation pool can specify different SIP servers for DNS addresses. DHCPv6 options that the BNG returns to the CPE are based on the pool from which the addresses were allocated. These options that are returned are based on the DHCPv6 Option Request option (ORO), which can be configured globally or within the IA_NA and IA_PD request.

Using a AAA RADIUS Server to Obtain IPv6 Addresses and Prefixes

When the BNG needs to obtain a global IPv6 address for the CPE WAN link and a DHCPv6 prefix, it uses the values in one of the following RADIUS attributes:

  • Framed-IPv6-Prefix —The attribute contains a global IPv6 address and a prefix. A prefix length of 128 is associated with the global IPv6 address. Prefix lengths less than 128 are associated with prefixes.
  • Framed-IPv6-Pool —The attribute contains the name of an address-assignment pool configured on the BNG, from which the BNG can select a global IPv6 address or an IPv6 prefix to send to the CPE.

Both attributes are sent from the RADIUS server to the BNG in RADIUS Access-Accept messages.

Junos OS Predefined Variable for Multiple DHCPv6 Address Assignment

To configure dynamic DHCPv6 address assignment for both DHCPv6 IA_NA and DHCPv6 prefix delegation, use the $junos-subscriber-ipv6-multi-address predefined variable In your dynamic profile. You use this variable in place of the $junos-subscriber-ipv6-address variable, which supports a single IPv6 address or prefix. The $junos-subscriber-ipv6-multi-address variable is applied as a demultiplexing source address, and is expanded to include both the host and prefix addresses.

You include the $junos-subscriber-ipv6-multi-address variable at the [edit dynamic-profile profile-name interfaces interface-name unit logical-unit-number family inet6 demux-source] hierarchy level.

See Also

Multiple DHCPv6 IA_NA and IA_PD Requests per Client Interface

DHCPv6 relay agent supports multiple IA_NA and IA_PD requests within a single DHCPv6 Solicit message. The requests can be any combination of IA_NA and IA_PD addresses, up to a maximum of eight requests. As part of the multiple IA request support, each address lease is assigned its own lease time expiration, independent of the other leases. The use of independent lease timers ensures that when one lease is torn down, the other active leases are maintained. You can use the show dhcpv6 relay binding and show dhcpv6 relay binding detail commands to display the status of the individual lease times.

The DHCPv6 support for multiple IA requests enables you to use prefix delegation to designate blocks of addresses, as described in RFC 3633, IPv6 Prefix Options for DHCPv6 . For example, you might want to delegate multiple address blocks to a customer premises equipment (CPE) router as a means to simplify flow classification and service monetization in your IPv6 environment.

Example: Configuring a Dual Stack That Uses DHCPv6 IA_NA and DHCPv6 Prefix Delegation over PPPoE

Requirements

This example uses the following hardware and software components:

  • MX Series 5G Universal Routing Platform
  • Junos OS Release 11.4 or later

Overview

This design uses DHCPv6 IA_NA and DHCPv6 prefix delegation in your subscriber access network as follows:

  • The access network is PPPoE.
  • DHCPv6 IA_NA is used to assign a global IPv6 address on the WAN link. The address comes from a local pool that is specified using AAA RADIUS.
  • DHCPv6 prefix delegation is used for subscriber LAN addressing. It used a delegated prefix from a local pool that is specified using AAA RADIUS.
  • DHCPv4 is used for subscriber LAN addressing.
  • DHCPv6 subscriber sessions are layered over an underlying PPPoE subscriber session.
Topology

Figure 1: PPPoE Subscriber Access Network with DHCPv6 IA_NA and DHCPv6 Prefix Delegation

Table 1 describes the configuration components used in this example.

Table 1: Configuration Components Used in Dual Stack with DHCPv6 IA_NA and DHCPv6 Prefix Delegation

Profile that creates a PPPoE logical interface when the subscriber logs in.

Interface used for communication with the RADIUS server.

Underlying Ethernet interface.

VLAN demux interface that runs over the underlying Ethernet interface.

Loopback interface for use in the access network. The loopback interface is automatically used for unnumbered interfaces.

Pool that provides IPv4 addresses for the subscriber LAN.

Pool that provides a global IPv6 address to the CPE WAN link.

Pool that provides a pool of prefixes that are delegated to the CPE and used for assigning IPv6 global addresses on the subscriber LAN.

Configuration

  • CLI Quick Configuration
  • Configuring a DHCPv6 Local Server for DHCPv6 over PPPoE
  • Configuring a Dynamic Profile for the PPPoE Logical Interface
  • Configuring a Loopback Interface
  • Configuring a VLAN Demux Interface over an Ethernet Underlying Interface
  • Configuring an Interface for Communication with RADIUS Server
  • Specifying the BNG IP Address
  • Configuring RADIUS Server Access
  • Configuring RADIUS Server Access Profile
  • Configuring Local Address-Assignment Pools
CLI Quick Configuration

The following is the complete configuration for this example:

dynamic-profiles < pppoe-subscriber-profile < routing-instances < "$junos-routing-instance" < interface "$junos-interface-name"; >> interfaces < pp0 < unit "$junos-interface-unit" < ppp-options < chap; pap; >pppoe-options < underlying-interface "$junos-underlying-interface"; server; >keepalives interval 30; family inet < unnumbered-address "$junos-loopback-interface"; >family inet6 < unnumbered-address "$junos-loopback-interface"; >> > > > > system < services < dhcp-local-server < dhcpv6 < group v6-ppp-subscriber < interface pp0.0; >> > > > interfaces < ge-0/2/5 < gigether-options < no-auto-negotiation; >unit 0 < family inet < address 203.0.113.99/32; >> > ge-0/3/0 < hierarchical-scheduler maximum-hierarchy-levels 2; flexible-vlan-tagging; encapsulation flexible-ethernet-services; unit 1; >demux0 < unit 1 < proxy-arp; vlan-tags outer 1 inner 1; demux-options < underlying-interface ge-0/3/0; >family pppoe < duplicate-protection; dynamic-profile pppoe-subscriber-profile; >> > lo0 < unit 0 < family inet < address 203.0.113.1/32 < primary; preferred; >> family inet6 < address 2001:db8:0::1/128 < primary; preferred; >> > > > routing-options < router-id 203.0.113.0; >access < radius-server < 203.0.113.99 < secret "$ABC123$ABC123$ABC123"; ## SECRET-DATA timeout 45; retry 4; source-address 203.0.113.1; >> profile Access-Profile < authentication-order radius; radius < authentication-server 203.0.113.99; accounting-server 203.0.113.99; >accounting < order [ radius none ]; update-interval 120; statistics volume-time; >> address-assignment < pool v4-pool < family inet < network 203.0.113.161/32; range v4-range-0 < low 203.0.113.161; high 203.0.113.255; >dhcp-attributes < maximum-lease-time 99999; >> > pool v6-ia-na-pool < family inet6 < prefix 2001:db8:1000:0000::/64; range v6-range-0 < low 2001:db8:1000::1/128; high 2001:db8:1000::ffff:ffff/128; >> > pool v6-pd-pool < family inet6 < prefix 2001:db8:2012::/48; range v6-pd prefix-length 64; >> > address-protection; >
Configuring a DHCPv6 Local Server for DHCPv6 over PPPoE
  • CLI Quick Configuration
  • Step-by-Step Procedure
  • Results
CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

edit system services dhcp-local-server dhcpv6 edit group v6-ppp-subscriber set interface pp0.0 
Step-by-Step Procedure

To layer DHCPv6 above the PPPoE IPv6 family (inet6), associate DHCPv6 with the PPPoE interfaces by adding the PPPoE interfaces to the DHCPv6 local server configuration. Because this example uses a dynamic PPPoE interface, we are using the pp0.0 (PPPoE) logical interface as a wildcard to indicate that a DHCPv6 binding can be made on top of a PPPoE interface.

To configure a DHCPv6 local server:

    Access the DHCPv6 local server configuration.

[edit] user@host# edit system services dhcp-local-server dhcpv6 
[edit system services dhcp-local-server dhcpv6] user@host# edit group v6-ppp-subscriber 
[edit system services dhcp-local-server dhcpv6 group v6-ppp-subscriber] user@host# set interface pp0.0 
Results

From configuration mode, confirm your configuration by entering the show command.

[edit] user@host# show system < services < dhcp-local-server < dhcpv6 < group v6-ppp-subscriber < interface pp0.0; >> > > >

If you are done configuring the device, enter commit from configuration mode.

Configuring a Dynamic Profile for the PPPoE Logical Interface
  • CLI Quick Configuration
  • Step-by-Step Procedure
  • Results
CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

edit dynamic-profiles pppoe-subscriber-profile edit routing-instances $junos-routing-instance set interface $junos-interface-name exit edit interfaces pp0 unit $junos-interface-unit set family inet unnumbered-address "$junos-loopback-interface" set family inet6 unnumbered-address "$junos-loopback-interface" set pppoe-options underlying-interface "$junos-underlying-interface" set pppoe-options server set ppp-options pap set ppp-options chap set keepalives interval 30 
Step-by-Step Procedure

Create a dynamic profile for the PPPoE logical interface. This dynamic profile supports both IPv4 and IPv6 sessions on the same logical interface.

To configure the dynamic profile:

    Create and name the dynamic profile.

[edit] user@host# edit dynamic-profiles pppoe-subscriber-profile 
[edit dynamic-profiles pppoe-subscriber-profile] user@host# edit routing-instances $junos-routing-instance user@host# set interface $junos-interface-name 
[edit dynamic-profiles pppoe-subscriber-profile] user@host# edit interfaces pp0 
[edit dynamic-profiles pppoe-subscriber-profile interfaces pp0] user@host# edit unit $junos-interface-unit 
[edit dynamic-profiles pppoe-subscriber-profile interfaces pp0 unit "$junos-interface-unit"] user@host# set pppoe-options underlying-interface $junos-underlying-interface 
[edit dynamic-profiles pppoe-subscriber-profile interfaces pp0 unit "$junos-interface-unit"] user@host# set pppoe-options server 
[edit dynamic-profiles pppoe-subscriber-profile interfaces pp0 unit "$junos-interface-unit"] user@host# set family inet unnumbered-address $junos-loopback-interface 
[edit dynamic-profiles pppoe-subscriber-profile interfaces pp0 unit "$junos-interface-unit"] user@host# set family inet6 unnumbered-address $junos-loopback-interface 
[edit dynamic-profiles pppoe-subscriber-profile interfaces pp0 unit "$junos-interface-unit"] user@host# set ppp-options chap user@host# set ppp-options pap 
[edit dynamic-profiles pppoe-subscriber-profile interfaces pp0 unit "$junos-interface-unit"] user@host# set keepalives interval 30 
Results

From configuration mode, confirm your configuration by entering the show command.

[edit dynamic-profiles pppoe-subscriber-profile] user@host# show routing-instances < "$junos-routing-instance" < interface "$junos-interface-name"; >> interfaces < pp0 < unit "$junos-interface-unit" < ppp-options < chap; pap; >pppoe-options < underlying-interface "$junos-underlying-interface"; server; >keepalives interval 30; family inet < unnumbered-address "$junos-loopback-interface"; >family inet6 < unnumbered-address "$junos-loopback-interface"; >> > >

If you are done configuring the device, enter commit from configuration mode.

Configuring a Loopback Interface
  • CLI Quick Configuration
  • Step-by-Step Procedure
  • Results
CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

edit interfaces lo0 set unit 0 family inet address 203.0.113.1/32 primary set unit 0 family inet address 203.0.113.1/32 preferred set unit 0 family inet6 address 2001:db8:0::1/128 primary set unit 0 family inet6 address 2001:db8:0::1/128 preferred 
Step-by-Step Procedure

To configure a loopback interface:

    Create the loopback interface and specify a unit number.

[edit] user@host# edit interfaces lo0 unit 0 
[edit interfaces lo0 unit 0] user@host# set family inet address 203.0.113.1/32 primary preferred 
[edit interfaces lo0 unit 0] user@host# set family inet6 address 2001:db8:0::1/128 primary preferred 
Results

From configuration mode, confirm your configuration by entering the show command.

[edit interfaces lo0] user@host# show unit 0 < family inet < address 203.0.113.1/32 < primary; preferred; >> family inet6 < address 2001:db8:0::1/128 < primary; preferred; >> >

If you are done configuring the device, enter commit from configuration mode.

Configuring a VLAN Demux Interface over an Ethernet Underlying Interface
  • CLI Quick Configuration
  • Step-by-Step Procedure
  • Results
CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

edit interfaces set ge-0/3/0 hierarchical-scheduler maximum-hierarchy-levels 2 set ge-0/3/0 flexible-vlan-tagging set ge-0/3/0 encapsulation flexible-ethernet-services exit edit interfaces demux0 unit 1 set vlan-tags outer 1 set vlan-tags inner 1 set demux-options underlying-interface ge-0/3/0 set family pppoe dynamic-profile pppoe-subscriber-profile set family pppoe duplicate-protection set proxy-arp 
Step-by-Step Procedure

To configure a VLAN demux interface over an Ethernet underlying interface:

    Configure the underlying Ethernet interface.

[edit] user@host# edit interfaces ge-0/3/0 user@host# set flexible-vlan-tagging user@host# set encapsulation flexible-ethernet-services user@host# set hierarchical-scheduler maximum-hierarchy-levels 2 
[edit] user@host# edit interfaces demux0 unit 1 
[edit interfaces demux0 unit 1] user@host# set vlan-tags outer 1 inner 1 
[edit interfaces demux0 unit 1] user@host# set demux-options underlying-interface ge-0/3/0 
[edit interfaces demux0 unit 1] user@host# set family pppoe dynamic-profile pppoe-subscriber-profile 
[edit interfaces demux0 unit 1] user@host# set family pppoe duplicate-protection 
[edit interfaces demux0 unit 1] user@host# set proxy-arp 
Results

From configuration mode, confirm your configuration by entering the show command.

[edit interfaces] user@host# show ge-0/3/0 < hierarchical-scheduler maximum-hierarchy-levels 2; flexible-vlan-tagging; encapsulation flexible-ethernet-services; >demux0 < unit 1 < proxy-arp; vlan-tags outer 1 inner 1; demux-options < underlying-interface ge-0/3/0; >family pppoe < duplicate-protection; dynamic-profile pppoe-subscriber-profile; >> >

If you are done configuring the device, enter commit from configuration mode.

Configuring an Interface for Communication with RADIUS Server
  • CLI Quick Configuration
  • Step-by-Step Procedure
  • Results
CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

edit interfaces ge-0/2/5 set unit 0 family inet address 203.0.113.99 set gigether-options no-auto-negotiation 
Step-by-Step Procedure

To configure the interface:

    Create the interface, specify a unit number, and configure the address.

[edit] user@host# edit interfaces ge-0/2/5 
[edit interfaces ge-0/2/5] user@host# set unit 0 family inet address 203.0.113.99 
[edit interfaces ge-0/2/5] user@host# set gigether-options no-auto-negotiation 
Results

From configuration mode, confirm your configuration by entering the show command.

[edit interfaces ge-0/2/5] user@host# show gigether-options < no-auto-negotiation; >unit 0 < family inet < address 203.0.113.99/32; >>

If you are done configuring the device, enter commit from configuration mode.

Specifying the BNG IP Address
  • CLI Quick Configuration
  • Step-by-Step Procedure
  • Results
CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

edit routing-options set router-id 203.0.113.0 

Best Practice:

We strongly recommend that you configure the BNG IP address, thereby avoiding unpredictable behavior if the interface address on a loopback interface changes.

Step-by-Step Procedure

To configure the IP address of the BNG:

    Access the routing-options configuration.

[edit] user@host# edit routing-options 
[edit routing-options] user@host# set router-id 203.0.113.0 
Results

From configuration mode, confirm your configuration by entering the show command.

[edit routing-options] user@host# show router-id 203.0.113.0;

If you are done configuring the device, enter commit from configuration mode.

Configuring RADIUS Server Access
  • CLI Quick Configuration
  • Step-by-Step Procedure
  • Results
CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

edit access radius-server 203.0.113.99 set secret "$ABC123$ABC123$ABC123" set timeout 45 set retry 4 set source-address 203.0.113.1 
Step-by-Step Procedure

To configure RADIUS servers:

    Create a RADIUS server configuration, and specify the address of the server.

[edit] user@host# edit access radius-server 203.0.113.99 
[edit access radius-server 203.0.113.99] user@host# set secret "$ABC123$ABC123$ABC123" 
[edit access radius-server 203.0.113.99] user@host# set source address 203.0.113.1 
[edit access radius-server 203.0.113.99] user@host# set retry 4 
[edit access radius-server 203.0.113.99] user@host# set timeout 45 
Results

From configuration mode, confirm your configuration by entering the show command.

[edit access] user@host# show radius-server < 203.0.113.99 < secret "$ABC123$ABC123$ABC123"; ## SECRET-DATA timeout 45; retry 4; source-address 203.0.113.1; >>

If you are done configuring the device, enter commit from configuration mode.

Configuring RADIUS Server Access Profile
  • CLI Quick Configuration
  • Step-by-Step Procedure
  • Results
CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

edit access profile Access-Profile set authentication-order radius set radius authentication-server 203.0.113.99 set radius accounting-server 203.0.113.99 set accounting order radius set accounting order none set accounting update-interval 120 set accounting statistics volume-time 
Step-by-Step Procedure

To configure a RADIUS server access profile:

    Create a RADIUS server access profile.

[edit] user@host# edit access profile Access-Profile 
[edit access profile Access-Profile] user@host# set authentication-order radius 
[edit access profile Access-Profile] user@host# set radius authentication-server 203.0.113.99 user@host# set radius accounting-server 203.0.113.99 
[edit access profile Access-Profile] user@host# set accounting order [ radius none ] user@host# set accounting update-interval 120 user@host# set accounting statistics volume-time 
Results

From configuration mode, confirm your configuration by entering the show command.

[edit access] user@host# show profile Access-Profile < authentication-order radius; radius < authentication-server 203.0.113.99; accounting-server 203.0.113.99; >accounting < order [ radius none ]; update-interval 120; statistics volume-time; >>

If you are done configuring the device, enter commit from configuration mode.

Configuring Local Address-Assignment Pools
  • CLI Quick Configuration
  • Step-by-Step Procedure
  • Results
CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

edit access address-assignment set pool v4-pool family inet network 203.0.113.161/32 set pool v4-pool family inet range v4-range-0 low 203.0.113.161 set pool v4-pool family inet range v4-range-0 high 203.0.113.255 set pool v4-pool family inet dhcp-attributes maximum-lease-time 99999 set pool v6-ia-na-pool family inet6 prefix 2001:db8:1000:0000::/64 set pool v6-ia-na-pool family inet6 range v6-range-0 low 2001:db8:1000::1/128 set pool v6-ia-na-pool family inet6 range v6-range-0 high 2001:db8:1000::ffff:ffff/128 set pool v6-pd-pool family inet6 prefix 2001:db8:2012::/48 set pool v6-pd-pool family inet6 range v6-pd prefix-length 64 
Step-by-Step Procedure

Configure three address-assignment pools for DHCPv4, DHCPv6 IA_NA, and DHCPv6 prefix delegation.

To configure the address-assignment pools:

    Configure the address-assignment pool for DHCPv4.

[edit] user@host# edit access address-assignment pool v4-pool user@host# edit family inet user@host# set network 203.0.113.161 user@host# set range v4-range-0 low 203.0.113.161 user@host# set range v4-range-0 high 203.0.113.255 user@host# set dhcp-attributes maximum-lease-time 99999 
[edit] user@host# edit access address-assignment pool v6-ia-na-pool user@host# edit family inet6 user@host# set prefix 2001:db8:1000:0000::/64 user@host# set range v6-range-0 low 2001:db8:1000::1/128 user@host# set range v6-range-0 high 2001:db8:1000::ffff:ffff/128 
[edit] user@host# edit access address-assignment pool v6-pd-pool user@host# edit family inet6 user@host# set prefix 2001:db8:2012::/48 user@host# set range v6-pd prefix-length 64 
[edit access] user@host# set address-protection 
Results

From configuration mode, confirm your configuration by entering the show command.

[edit access] user@host# show address-assignment < pool v4-pool < family inet < network 203.0.113.161/32; range v4-range-0 < low 203.0.113.161; high 203.0.113.255; >dhcp-attributes < maximum-lease-time 99999; >> > pool v6-ia-na-pool < family inet6 < prefix prefix 2001:db8:1000:0000::/64 ; range v6-range-0 < low 2001:db8:1000::1/128; high 2001:db8:1000::ffff:ffff/128; >> > pool v6-pd-pool < family inet6 < prefix 2001:db8:2012::/48; range v6-pd prefix-length 64; >> > address-protection; >

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

  • Verifying Active Subscriber Sessions
  • Verifying Both IPv4 and IPv6 Address in Correct Routing Instance
  • Verifying Dynamic Subscriber Sessions
  • Verifying DHCPv6 Address Pools Used for DHCPv6 Prefix Delegation
  • Verifying DHCPv6 Address Bindings
  • Verifying PPP Options Negotiated with the Remote Peer
Verifying Active Subscriber Sessions
Purpose

Verify active subscriber sessions.

Action

From operational mode, enter the show subscribers summary command.

user@host>show subscribers summary Subscribers by State Active: 2 Total: 2 Subscribers by Client Type DHCP: 1 PPPoE: 1 Total: 2
Meaning

The fields under Subscribers by State show the number of active subscribers.

The fields under Subscribers by Client Type show the number of active DHCP and PPPoE subscriber sessions.

Verifying Both IPv4 and IPv6 Address in Correct Routing Instance
Purpose

Verify that the subscriber has both an IPv4 and IPv6 address and is placed in the correct routing instance.

Action

From operational mode, enter the show subscribers command.

user@host>show subscribers Interface IP Address/VLAN ID User Name LS:RI pp0.1073741825 203.0.113.162 SBRSTATICUSER default:default pp0.1073741825 2001:db8:1000::1 default:default
Meaning

The Interface field shows that two subscriber sessions are running on the same interface. The IP Address field shows that one session is assigned an IPv4 address, and the second session is assigned an IPv6 address by DHCPv6 IA_NA.

The LS:RI field shows that the subscriber is placed in the correct routing instance and that traffic can be sent and received.

Verifying Dynamic Subscriber Sessions
Purpose

Verify dynamic PPPoE and DHCPv6 subscriber sessions. In this example configuration the DHCPv6 subscriber session should be layered over the underlying PPPoE subscriber session.

Action

From operational mode, enter the show subscribers detail command.

user@host>show subscribers detail Type: PPPoE User Name: SBRSTATICUSER IP Address: 203.0.113.162 IP Netmask: 255.0.0.0 Logical System: default Routing Instance: default Interface: pp0.1073741825 Interface type: Dynamic Dynamic Profile Name: pppoe-subscriber-profile MAC Address: 00:00:5E:00:53:01 State: Active Radius Accounting ID: 2 Session ID: 2 Login Time: 2011-12-08 09:11:41 PST Type: DHCP IPv6 Address: 2001:db8:1000::1 Logical System: default Routing Instance: default Interface: pp0.1073741825 Interface type: Static MAC Address: 00:00:5E:00:53:31 State: Active Radius Accounting ID: 3 Session ID: 3 Underlying Session ID: 2 Login Time: 2011-12-08 09:12:11 PST DHCP Options: len 42 00 08 00 02 0b b8 00 01 00 0a 00 03 00 01 00 01 02 00 00 01 00 06 00 02 00 03 00 03 00 0c 00 00 00 00 00 00 00 00 00 00 00 00
Meaning

When a subscriber has logged in and started both an IPv4 and an IPv6 session, the output shows the active underlying PPPoE session and the active DHCPv6 session.

The Session ID field for the PPPoE session is 2. The Underlying Session ID for the DHCP session is 2, which shows that the PPPoE session is the underlying session.

Verifying DHCPv6 Address Pools Used for DHCPv6 Prefix Delegation
Purpose

Verify the delegated address pool used for DHCPv6 prefix delegation and the length of the IPv6 prefix that was delegated to the CPE.

Action

From operational mode, enter the show subscribers extensive command.

user@host>show subscribers extensive Type: PPPoE User Name: SBRSTATICUSER IP Address: 203.0.113.162 IP Netmask: 255.0.0.0 Logical System: default Routing Instance: default Interface: pp0.1073741825 Interface type: Dynamic Dynamic Profile Name: pppoe-subscriber-profile MAC Address: 00:00:5E:00:53:31 State: Active Radius Accounting ID: 2 Session ID: 2 Login Time: 2011-12-08 09:11:41 PST IPv6 Delegated Address Pool: v6-na-pool Type: DHCP IPv6 Address: 2001:db8:1000::1 Logical System: default Routing Instance: default Interface: pp0.1073741825 Interface type: Static MAC Address: 00:00:5E:00:53:31 State: Active Radius Accounting ID: 3 Session ID: 3 Underlying Session ID: 2 Login Time: 2011-12-08 09:12:11 PST DHCP Options: len 42 00 08 00 02 0b b8 00 01 00 0a 00 03 00 01 00 01 02 00 00 01 00 06 00 02 00 03 00 03 00 0c 00 00 00 00 00 00 00 00 00 00 00 00 IPv6 Delegated Address Pool: v6-na-pool IPv6 Delegated Network Prefix Length: 64
Meaning

The IPv6 Delegated Address Pool field shows the name of the pool that DHCPv6 used to assign the IPv6 address for this subscriber session.

Verifying DHCPv6 Address Bindings
Purpose

Display the address bindings in the client table on the DHCPv6 local server.

Action

From operational mode, enter the show dhcpv6 server binding detail command.

user@host>show dhcpv6 server binding detail Session Id: 580547 Client IPv6 Address: 2001:db8:1000::4/128 Client DUID: LL0x1-00:01:02:00:00:01 State: BOUND(DHCPV6_LOCAL_SERVER_STATE_BOUN D) Lease Expires: 2012-01-05 07:06:04 PST Lease Expires in: 82943 seconds Lease Start: 2012-01-04 07:06:04 PST Last Packet Received: 2012-01-04 07:06:04 PST Incoming Client Interface: pp0.1073926645 Server Ip Address: 0.0.0.0 Client Pool Name: v6-na-pool-0 Client Id Length: 10 Client Id: /0x00030001/0x00010200/0x0001
Meaning

The Client IPv6 Address field shows the /128 address that was assigned to the CPE WAN link using DHCPv6 IA_NA.

The Client Pool Name field shows the name of the address pool that was used to assign the Client IPv6 Address .

Verifying PPP Options Negotiated with the Remote Peer
Purpose

Verify PPP options negotiated with the remote peer.

Action

From operational mode, enter the show ppp interface interface extensive command.

user@host>show ppp interface pp0.1073741825 extensive Session pp0.1073926645, Type: PPP, Phase: Network LCP State: Opened Last started: 2012-01-04 07:05:33 PST Last completed: 2012-01-04 07:05:33 PST Negotiated options: Authentication protocol: pap, Magic number: 191301485, Local MRU: 1492, Peer MRU: 65531 Authentication: PAP State: Grant Last started: 2012-01-04 07:05:33 PST Last completed: 2012-01-04 07:05:33 PST IPCP State: Opened Last started: 2012-01-04 07:05:34 PST Last completed: 2012-01-04 07:05:34 PST Negotiated options: Local address: 203.0.113.1, Remote address: 203.0.113.162 IPV6CP State: Opened Last started: 2012-01-04 07:05:34 PST Last completed: 2012-01-04 07:05:34 PST Negotiated options: Local interface identifier: 2a0:a50f:fc71:e049, Remote interface identifier: 201:2ff:fe00:1 
Meaning

The output shows the PPP options that were negotiated with the remote peer.

Under IPCP, the Negotiated options field shows the IPv4 local and remote addresses that were negotiated by IPCP.

Under IPV6CP, the Negotiated options field shows the IPv6 local and remote interface identifier that were negotiated by IPv6CP.

Troubleshoot a Lightweight AP that Fails to Join a WLC

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

This document describes the AireOS Wireless LAN Controller (WLC) Discovery and Join Process.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

  • Basic knowledge of the configuration of Lightweight Access Points (LAPs) and Cisco WLCs
  • Basic knowledge of Lightweight Access Point Protocol (CAPWAP)

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Overview of the WLC Discovery and Join Process

In a Cisco Unified Wireless network, the LAPs must first discover and join a WLC before they can service wireless clients.

However, this presents a question: how did the LAPs find the management IP address of the controller when it is on a different subnet?

If you do not tell the LAP where the controller is via DHCP option 43, Domain Name System (DNS) resolution of Cisco-capwap-controller.local_domain , or statically configure it, the LAP does not know where in the network to find the management interface of the controller.

In addition to these methods, the LAP does automatically look on the local subnet for controllers with a 255.255.255.255 local broadcast. Also, the LAP remembers the management IP address of any controller it joins across reboots. Therefore, if you put the LAP first on the local subnet of the management interface, it finds the controller management interface and remembers the address. This is called priming. This does not help find the controller if you replace a LAP later on. Therefore, Cisco recommends use of the DHCP option 43 or DNS methods.

The LAPs always connect to the management interface address of the controller first with a discovery request. The controller then tells the LAP the Layer 3 AP-manager interface (which can also be the management by default) IP address so the LAP can send a join request to the AP-manager interface next.

The AP goes through this process on startup:

  1. The LAP boots and DHCPs an IP address if it was not previously assigned a static IP address.
  2. The LAP sends discovery requests to controllers through the various discovery algorithms and builds a controller list. Essentially, the LAP learns as many management interface addresses for the controller list as possible via:
    1. DHCP option 43 (good for global companies where offices and controllers are on different continents).
    2. DNS entry for cisco-capwap-controller (good for local businesses — can also be used to find where brand new APs join) If you use CAPWAP, make sure there is a DNS entry for cisco-capwap-controller .
    3. Management IP addresses of controllers the LAP remembers previously.
    4. A Layer 3 broadcast on the subnet.
    5. Statically configured information.
    6. Controllers present in the mobility group of the WLC the AP last joined.

    From this list, the easiest method to use for deployment is to have the LAPs on the same subnet as the management interface of the controller and allow the LAPs Layer 3 broadcast to find the controller. This method must be used for companies that have a small network and do not own a local DNS server.

    The next easiest method of deployment is to use a DNS entry with DHCP. You can have multiple entries of the same DNS name. This allows the LAP to discover multiple controllers. This method must be used by companies that have all of their controllers in a single location and own a local DNS server. Or, if the company has multiple DNS suffixes and the controllers are segregated by suffix.

    DHCP option 43 is used by large companies to localize the information by the DHCP. This method is used by large enterprises that have a single DNS suffix. For example, Cisco owns buildings in Europe, Australia, and the United States. In order to ensure that the LAPs only join controllers locally, Cisco cannot use a DNS entry and must use DHCP option 43 information to tell the LAPs what the management IP address of their local controller is.

    Finally, static configuration is used for a network that does not have a DHCP server. You can statically configure the information necessary to join a controller by the console port and the APs CLI. For information on how to statically configure controller information by use of the AP CLI, use this command:

    AP#capwap ap primary-base

    1. Primary Controller system name (previously configured on LAP).
    2. Secondary Controller system name (previously configured on LAP).
    3. Tertiary Controller system name (previously configured on LAP).
    4. Primary controller (if the LAP has not been previously configured with any Primary, Secondary, or Tertiary controller names. Used to always know which controller is a brand new LAPs join).
    5. If none of the previous conditions are seen, load balance across controllers by use of the excess capacity value in the discovery response. If two controllers have the same excess capacity, then send the join request to the first controller that responded to the discovery request with a discovery response. If a single controller has multiple AP-managers on multiple interfaces, choose the AP-manager interface with the least number of APs. The controller responds to all discovery requests without a certificate chec or AP credentials. However, join requests must have a valid certificate to get a join response from the controller. If the LAP does not receive a join response from its choice, the LAP tries the next controller in the list, unless the controller is a configured controller (Primary/Secondary/Tertiary).

    Debug from the Controller

    There are a few debug commands on the controller you can use to see this entire process on the CLI:

    • debug capwap events enable : Shows discovery packets and join packets.
    • debug capwap packet enable : Shows packet level information of the discovery and join packets.
    • debug pm pki enable : Shows certificate validation process.
    • debug disable-all : Turns off debugs.

    With a terminal application that can capture output to a log file, console in or secure shell (SSH)/Telnet to your controller, and enter these commands:

    config session timeout 120 config serial timeout 120 show run-config (and spacebar thru to collect all) debug mac addr (in xx:xx:xx:xx:xx format) debug client debug capwap events enable debug capwap errors enable debug pm pki enable 

    After the debugs are captured, use the debug disable-all command to disable all debugs.

    The next sections show the output of these debug commands when the LAP registers with the controller.

    debug capwap events enable

    This command provides information on the CAPWAP events and errors that occur at the CAPWAP discovery and join process.

    This is the debug capwap events enable command output for a LAP that has the same image as the WLC:

    Note: Some lines of the output have been moved to the second line due to space constraints.

    debug capwap events enable *spamApTask7: Jun 16 12:37:36.038: 00:62:ec:60:ea:20 Discovery Request from 172.16.17.99:46317 !--- CAPWAP discovery request sent to the WLC by the LAP. *spamApTask7: Jun 16 12:37:36.039: 00:62:ec:60:ea:20 Discovery Response sent to 172.16.17.99 port 46317 !--- WLC responds to the discovery request from the LAP. *spamApTask7: Jun 16 12:38:43.469: 00:62:ec:60:ea:20 Join Request from 172.16.17.99:46317 
    !--- LAP sends a join request to the WLC.
    *spamApTask7: Jun 16 12:38:33.039: 00:62:ec:60:ea:20 Join Priority Processing status = 0, Incoming Ap's Priority 1, MaxLrads = 75, joined Aps =0
    *spamApTask7: Jun 16 12:38:43.469: 00:62:ec:60:ea:20 Join Request from 172.16.17.99:46317

    *spamApTask7: Jun 16 12:38:43.472: 00:62:ec:60:ea:20 Join Version: = 134256640

    *spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 apType = 46 apModel: AIR-CAP2702I-E-K9

    *spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 Join resp: CAPWAP Maximum Msg element len = 90

    *spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 Join Response sent to 172.16.17.99:46317
    *spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 CAPWAP State: Join
    !--- WLC responds with a join reply to the LAP.
    *spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Configuration Status from 172.16.17.99:46317
    *spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 CAPWAP State: Configure !--- LAP requests for the configuration information from the WLC.

    *spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Updating IP info for AP 00:62:ec:60:ea:20 -- static 0, 172.16.17.99/255.255.254.0, gtw 172.16.16.1
    *spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Updating IP 172.16.17.99 ===> 172.16.17.99 for AP 00:62:ec:60:ea:20
    *spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Running spamDecodeVlanProfMapPayload for00:62:ec:60:ea:20
    *spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Setting MTU to 1485
    *spamApTask7: Jun 16 12:38:44.019: 00:62:ec:60:ea:20 Configuration Status Response sent to 172:16:17:99

    !--- WLC responds by providing all the necessary configuration information to the LAP. *spamApTask7: Jun 16 12:38:46.882: 00:62:ec:60:ea:20 Change State Event Request from 172.16.17.99:46317

    *spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 Radio state change for slot: 0 state: 2 cause: 0 detail cause: 69
    *spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 Change State Event Response sent to 172.16.17.99:46317
    .
    .
    .
    .

    *spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 CAPWAP State: Run

    *spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 Sending the remaining config to AP 172.16.17.99:46317!
    .
    .
    .
    . !--- LAP is up and ready to service wireless clients. *spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for RrmInterferenceCtrl payload sent to 172:16:17:99

    *spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for RrmNeighbourCtrl payload sent to 172.16.17.99

    *spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for RrmReceiveCtrl payload sent to 172:16:17:99

    *spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for CcxRmMeas payload sent to 172.16.17.99
    !--- WLC sends all the RRM and other configuration parameters to the LAP.

    As mentioned in the previous section, once a LAP registers with the WLC, it checks to see if it has the same image as the controller. If the images on the LAP and the WLC are different, the LAPs download the new image from the WLC first. If the LAP has the same image, it continues to download the configuration and other parameters from the WLC.

    You see these messages in the debug capwap events enable command output if the LAP downloads an image from the controller as a part of the registration process:


    *spamApTask6: Jun 17 14:23:28.677: 00:62:ec:60:ea:20 Sending image data block of length 1324 and msgLength = 1327

    *spamApTask6: Jun 17 14:23:28.677: 00:62:ec:60:ea:20 Image Data Request sent to 172.16.17.201:46318

    *spamApTask6: Jun 17 14:23:28.693: 00:62:ec:60:ea:20 Image data Response from 172.16.17.201:46318

    Once the image download is complete, the LAP reboots and run the discovery and join the algorithm again.

    debug pm pki enable

    As a part of the join process, the WLC authenticates each LAP by confirmation that its certificate is valid.

    When the AP sends the CAPWAP Join Request to the WLC, it embeds its X.509 certificate in the CAPWAP message. The AP also generates a random session ID that is also included in the CAPWAP Join Request. When the WLC receives the CAPWAP Join Request, it validates the signature of the X.509 certificate with the AP public key and checks that the certificate was issued by a trusted certificate authority.

    It also looks at the start date and time for the AP certificate validity interval and compares that date and time to its own date and time (hence the controller clock needs to be set close to the current date and time). If the X.509 certificate is validated, the WLC generates a random AES encryption key. The WLC plumbs the AES keys into its crypto engine so it can encrypt and decrypt future CAPWAP Control Messages exchanged with the AP. Note that data packets are sent in the clear in the CAPWAP tunnel between the LAP and the controller.

    The debug pm pki enable command shows the certification validation process that occurs at the join phase on the controller. The debug pm pki enable command also displays the AP hash key at the join process, if the AP has a self-signed certificate (SSC) created by the LWAPP conversion program. If the AP has a Manufactured Installed Certificate (MIC), you do not see a hash key.

    Note: All APs manufactured after June 2006 have a MIC.

    Here is the output of the debug pm pki enable command when the LAP with a MIC joins the controller:

    Note: Some lines of the output have been moved to the second line due to space constraints.

    *spamApTask4: Mar 20 11:05:15.687: [SA] OpenSSL Get Issuer Handles: locking ca cert table

    *spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: x509 subject_name /C=US/ST=California/L=San Jose/O=Cisco Systems/
    CN=AP3G2-1005cae83a42/emailAddress=support@cisco.com
    *spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: issuer_name /O=Cisco Systems/CN=Cisco Manufacturing CA
    *spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: CN AP3G2-1005cae83a42
    *spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: issuerCertCN Cisco Manufacturing CA
    *spamApTask4: Mar 20 11:05:15.688: [SA] GetMac: MAC: 1005.cae8.3a42
    *spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: openssl Mac Address in subject is 10:05:ca:e8:3a:42
    *spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: CN AP3G2-1005cae83a42
    *spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: issuerCertCN Cisco Manufacturing CA
    *spamApTask4: Mar 20 11:05:15.688: [SA] GetMac: MAC: 1005.cae8.3a42
    *spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: openssl Mac Address in subject is 10:05:ca:e8:3a:42
    *spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: Cert Name in subject is AP3G2-1005cae83a42

    *spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: Extracted cert issuer from subject name.


    *spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: Cert is issued by Cisco Systems.

    *spamApTask4: Mar 20 11:05:15.688: [SA] Retrieving x509 cert for CertName cscoDefaultMfgCaCert
    *spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: called to evaluate
    *spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: Found matching CA cert cscoDefaultMfgCaCert in row 5
    *spamApTask4: Mar 20 11:05:15.688: [SA] Found CID 260e5e69 for certname cscoDefaultMfgCaCert

    *spamApTask4: Mar 20 11:05:15.688: [SA] CACertTable: Found matching CID cscoDefaultMfgCaCert in row 5 x509 0x2cc7c274

    *spamApTask4: Mar 20 11:05:15.688: [SA] Retrieving x509 cert for CertName cscoDefaultNewRootCaCert
    *spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: called to evaluate
    *spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: Found matching CA cert cscoDefaultNewRootCaCert in row 4

    *spamApTask4: Mar 20 11:05:15.688: [SA] Found CID 28d7044e for certname cscoDefaultNewRootCaCert
    *spamApTask4: Mar 20 11:05:15.688: [SA] CACertTable: Found matching CID cscoDefaultNewRootCaCert in row 4 x509 0x2cc7c490
    *spamApTask4: Mar 20 11:05:15.691: [SA] Verify User Certificate: X509 Cert Verification return code: 1
    *spamApTask4: Mar 20 11:05:15.691: [SA] Verify User Certificate: X509 Cert Verification result text: ok
    *spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: called to evaluate
    *spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: Found matching CA cert cscoDefaultMfgCaCert in row 5

    *spamApTask4: Mar 20 11:05:15.691: [SA] Verify User Certificate: OPENSSL X509_Verify: AP Cert Verfied Using >cscoDefaultMfgCaCert

    *spamApTask4: Mar 20 11:05:15.691: [SA] OpenSSL Get Issuer Handles: Check cert validity times (allow expired NO)
    *spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: called to evaluate
    *spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: Found matching ID cert cscoDefaultIdCert in row 2
    *spamApTask4: Mar 20 11:05:15.691: [SA] sshpmFreePublicKeyHandle: called with 0x1b0b9380

    *spamApTask4: Mar 20 11:05:15.691: [SA] sshpmFreePublicKeyHandle: freeing public key


    Debug from the AP

    If the controller debugs do not indicate a join request, you can debug the process from the AP if the AP has a console port. You can see the AP boot up process with these commands, but you must first get into enable mode (default password is Cisco).

    • debug dhcp detail : Shows DHCP option 43 information.
    • debug ip udp : Shows all UDP packets received and transmitted by the AP.
    • debug capwap client event : Shows capwap events for the AP.
    • debug capwap client error : Shows capwap errors for AP.
    • debug dtls client event : Shows DTLS events for the AP.
    • debug dtls error enable : Shows DTLS errors for the AP.
    • undebug all : Disables debugs on the AP.

    Here is an example of the output from the debug capwap commands. This partial output gives an idea of the packets sent by the AP at the boot process to discover and join a controller.

    AP can discover the WLC via one of these options :

    !--- AP discovers the WLC via option 43

    *Jun 28 08:43:05.839: %CAPWAP-5-DHCP_OPTION_43: Controller address 10.63.84.78 obtained through DHCP
    *Jun 28 08:43:15.963: %CAPWAP-3-EVENTLOG: Discovery Request sent to 10.63.84.78 with discovery type set to 2

    !--- capwap Discovery Request using the statically configured controller information.

    *Jun 28 08:43:15.963: %CAPWAP-3-EVENTLOG: Discovery Request sent to 10.63.84.32 with discovery type set to 1

    !--- Capwap Discovery Request sent using subnet broadcast.

    *Jun 28 08:43:15.963: %CAPWAP-3-EVENTLOG: Discovery Request sent to 255.255.255.255 with discovery type set to 0

    !--- capwap Join Request sent to AP-Manager interface on DHCP discovered controller.

    *Jun 28 08:40:29.031: %CAPWAP-5-SENDJOIN: sending Join Request to 10.63.84.78

    LAP Does Not Join the Controller, Why?

    Check the Basics First

    • Can the AP and the WLC communicate?
    • Make sure the AP gets an address from DHCP (check the DHCP server leases for the MAC address of the AP).
    • Ping the AP from the controller.
    • Check if the STP configuration on the switch is correct, so packets to the VLANs are not blocked.
    • If pings are successful, ensure the AP has at least one method by which to discovery at least a single WLC Console or telnet/ssh into the controller to run debugs.
    • Each time the AP reboots, it initiates the WLC discovery sequence and tries to locate the AP. Reboot the AP and check if it joins the WLC.

    Here are some of the commonly seen issues due to which the LAPs do not join the WLC.

    Field Notice: Certificate Expirations — FN63942

    Certificates embedded in the hardware are valid for a period of 10 years after manufacturing. If your APs or WLC are more than 10 years old, expired certificates can cause AP join issues. More information on this issue is available in this field notice:

    Potential Problems to Look For: Examples

    Problem 1: The controller time is outside the certificate validity interval

    Complete these steps in order to troubleshoot this problem:

      Issue debug dtls client error + debug dtls client event commands on the AP:


    *Jun 28 09:21:25.011: DTLS_CLIENT_EVENT: dtls_process_Certificate: Processing. Peer certificate verification failed 001A
    *Jun 28 09:21:25.031: DTLS_CLIENT_ERROR: ../capwap/base_capwap/capwap/base_capwap_wtp_dtls.c:509 Certificate verified failed!
    *Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_send_Alert: Sending FATAL : Bad certificate Alert
    *Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_client_process_record: Error processing Certificate.
    *Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_disconnect: Disconnecting DTLS connection 0x8AE7FD0
    *Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_free_connection: Free Called. for Connection 0x8AE7FD0
    *Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_send_Alert: Sending FATAL : Close notify Alert

    Note: If the time is not set correctly on the controller, choose Commands > Set Time in the controller GUI mode, or issue the config time command in the controller CLI in order to set the controller time.

    AP00c1.649a.be5c#show crypto ca cert
    .
    .
    .
    .
    Certificate
    Status: Available
    Certificate Serial Number (hex): 7D1125A900000002A61A
    Certificate Usage: General Purpose
    Issuer:
    cn=Cisco Manufacturing CA SHA2
    o=Cisco
    Subject:
    Name: AP1G2-00c1649abe5c
    e=support@cisco.com
    cn=AP1G2-00c1649abe5c
    o=Cisco Systems
    l=San Jose
    st=California
    c=US
    CRL Distribution Points:
    http://www.cisco.com/security/pki/crl/cmca2.crl
    Validity Date:
    start date: 01:05:37 UTC Mar 24 2016
    end date: 01:15:37 UTC Mar 24 2026
    Associated Trustpoints: Cisco_IOS_M2_MIC_cert
    Storage:
    .
    .
    .

    Problem 2: Mismatch in Regulatory domain

    You see this message in the debug capwap events enable command output:

    *spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 AP 00:cc:fc:13:e5:e0: Country code is not configured(BE ).
    *spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 AP 00:cc:fc:13:e5:e0: Country code is not configured(BE ).
    *spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Setting MTU to1485
    *spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 AP 00:cc:fc:13:e5:e0: Country code is not configured(BE ).
    *spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Regulatory Domain Mismatch: AP 00:cc:fc:13:e5:e0 not allowed to join. Allowed domains: 802.11bg:-A
    *spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Finding DTLS connection to delete for AP (192:168:47:29/60390)
    *spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Disconnecting DTLS Capwap-Ctrl session 0x1d4df620 for AP (192:168:47:29/60390). Notify(true)
    *spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 acDtlsPlumbControlPlaneKeys: lrad:192.168.47.29(60390) mwar:10.63.84.78(5246)


    WLC msglog show these messages :

    *spamApTask5: Jun 28 11:52:06.536: %CAPWAP-3-DTLS_CLOSED_ERR: capwap_ac_sm.c:7095 00:cc:fc:13:e5:e0: DTLS connection
    closed forAP 192:168:47:28 (60389), Controller: 10:63:84:78 (5246) Regulatory Domain Mismatch

    The message clearly indicates there is a mismatch in the regulatory domain of the LAP and the WLC. The WLC supports multiple regulatory domains, but each regulatory domain must be selected before an AP can join from that domain. For example, the WLC that uses regulatory domain -A can only be used with APs that use regulatory domain -A (and so on). When you purchase APs, ensure they share the same regulatory domain. Only then can the APs register with the WLC.

    Note: Both 802.1b/g and 802.11a radios must be in the same regulatory domain for a single AP.

    Problem 3: AP authorization list enabled on the WLC; LAP not in the authorization list

    In such cases, you see this message on the controller in the output of the debug capwap events enable command:

    Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Received CAPWAP DISCOVERY REQUEST from AP 00:0b:85:51:5a:e0 to 00:0b:85:33:52:80 on port '1' Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Successful transmission of CAPWAP Discovery-Response to AP 00:0b:85:51:5a:e0 on Port 1 Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Received LWAPP DISCOVERY REQUEST from AP 00:0b:85:51:5a:e0 to ff:ff:ff:ff:ff:ff on port '1' Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Successful transmission of CAPWAP Discovery-Response to AP 00:0b:85:51:5a:e0 on Port 1 Wed Sep 12 17:42:50 2007: 00:0b:85:51:5a:e0 Received CAPWAP JOIN REQUEST from AP 00:0b:85:51:5a:e0 to 00:0b:85:33:52:80 on port '1' Wed Sep 12 17:42:50 2007: 00:0b:85:51:5a:e0 AP ap:51:5a:e0: txNonce 00:0B:85:33:52:80 rxNonce 00:0B:85:51:5A:E0 Wed Sep 12 17:42:50 2007: 00:0b:85:51:5a:e0 CAPWAP Join-Request MTU path from AP 00:0b:85:51:5a:e0 is 1500, remote debug mode is 0 Wed Sep 12 17:42:50 2007: spamRadiusProcessResponse: AP Authorization failure for 00:0b:85:51:5a:e0 

    If you use a LAP that has a console port, you see this message when you issue the debug capwap client error command:

    AP001d.a245.a2fb# *Mar 1 00:00:52.267: LWAPP_CLIENT_ERROR_DEBUG: spamHandleJoinTimer: Did not receive the Join response *Mar 1 00:00:52.267: LWAPP_CLIENT_ERROR_DEBUG: No more AP manager IP addresses remain. 

    This again is a clear indication the LAP is not part of the AP authorization list on the controller.

    You can view the status of the AP authorization list with this command:

    (Cisco Controller) >show auth-list Authorize APs against AAA . enabled Allow APs with Self-signed Certificate (SSC) . disabled

    In order to add a LAP to the AP authorization list, use the config auth-list add mic command. For more information on how to configure LAP authorization, refer to Lightweight Access Point (LAP) Authorization in a Cisco Unified Wireless Network Configuration Example.

    Problem 4: There is a certificate or public key corruption on the AP

    The LAP does not join a controller because of a certificate issue.

    Issue the debug capwap errors enable and debug pm pki enable commands. You see messages that indicate the certificates or keys that are corrupted.

    Note: Some lines of the output have been moved to second lines due to space constraints.

    Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0 CAPWAP Join Request does not include valid certificate in CERTIFICATE_PAYLOAD from AP 00:0f:24:a9:52:e0. Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0 Deleting and removing AP 00:0f:24:a9:52:e0 from fast path Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0 Unable to free public key for AP

    Use one of these two options in order to resolve the problem:

    • MIC AP — Request a return materials authorization (RMA).
    • LSC AP — Re provision your LSC certificate.

    Problem 5: Controller receives AP discovery message on wrong VLAN (you see the discovery message debug, but not response)

    You see this message in the debug capwap events enable command output:

    Received a Discovery Request with subnet broadcast with wrong AP IP address (A.B.C.D)! 

    This message means the controller received a discovery request by a broadcast IP address with a source IP address which is not in any configured subnets on the controller. This also means the controller is the one that drops the packet.

    The problem is that the AP is not what sent the discovery request to the management IP address. The controller reports a broadcast discovery request from a VLAN that is not configured on the controller. This typically occurs when trunks allowed VLANs and did not restrict them to wireless VLANs.

    Complete these steps in order to resolve this problem:

    1. If the controller is on another subnet, the APs must be primed for the controller IP address, or the APs must receive the controllers IP address with the use one of the discovery methods.
    2. The switch is configured to allow some VLANs not on the controller. Restrict the allowed VLANs on the trunks.

    Problem 6: AP Not Able to Join the WLC, Firewall Blocking Necessary Ports

    If a firewall is used in the enterprise network, ensure these ports are enabled on the firewall for the LAP to join and communicate with the controller.

    You must enable these ports:

    • Enable these UDP ports for CAPWAP traffic:
      • Data — 5247
      • Control — 5246
      • 16666 — 16666
      • 16667 — 16667

      These ports are optional (dependent on your requirements):

      • UDP 69 for TFTP
      • TCP 80 and/or 443 for HTTP or HTTPS for GUI access
      • TCP 23 and/or 22 for Telnet or SSH for CLI access

      Problem 7: Duplicate IP address in the network

      This is another common issue seen when the AP tries to join the WLC. You can see this error message when the AP tries to join the controller.

      No more AP manager IP addresses remain 

      One of the reasons for this error message is when there is a duplicate IP address on the network that matches the AP manager IP address. In such a case, the LAP keeps power cycle initiations and cannot join the controller.

      The debugs show the WLC receives LWAPP discovery requests from the APs and transmits a LWAPP discovery response to the APs.

      However, WLCs do not receive LWAPP join requests from the APs.

      In order to troubleshoot this issue, ping the AP manager from a wired host on the same IP subnet as the AP manager. Then, check the ARP cache. If a duplicate IP address is found, remove the device with the duplicate IP address or change the IP address on the device so it has a unique IP address on the network.

      The AP can then join the WLC.

      Problem 8: LAPs with Mesh image not able to join WLC

      The Lightweight Access Point does not register with the WLC. The log displays this the error message:

      AAA Authentication Failure for UserName:5475xxx8bf9c User Type: WLAN USER

      This can happen if the Lightweight Access Point was shipped with a mesh image and is in Bridge mode. If the LAP was ordered with mesh software on it, you need to add the LAP to the AP authorization list. Choose Security > AP Policies and add AP to the Authorization List. The AP must then join, download the image from the controller, then register with the WLC in bridge mode. Then you need to change the AP to local mode. The LAP downloads the image, reboots, and registers back to the controller in local mode.

      Problem 9: Bad address «Microsoft DHCP»

      Access points can renew their IP addresses quickly when an attempt to join a WLC is made, which can cause Windows DHCP servers to mark these IPs as «BAD_ADDRESS» which could quickly deplete the DHCP pool.

      Check for more information: Chapter: Client Roaming

      DHCP and BOOTP Relay Agent

      You can configure a Juniper Networks switch to act as a Dynamic Host Configuration Protocol (DHCP) or Bootstrap Protocol (BOOTP) relay agent. If you configure a switch to be a DHCP relay agent, you can also enable smart DHCP relay.

      You can also enable BOOTP support when the switch is configured as a DHCP server. For more details, read this topic.

      DHCP and BOOTP Relay Overview for Switches

      You can configure a Juniper Networks switch to act as a Dynamic Host Configuration Protocol (DHCP) or Bootstrap Protocol (BOOTP) relay agent. This means that if the switch receives a broadcast DHCP or BOOTP request from a locally attached host (client), it relays the message to a specified DHCP or BOOTP server. You should configure the switch to be a DHCP/BOOTP relay agent if you have locally attached hosts and a distant DHCP or BOOTP server.

      You can configure the switch to use the gateway IP address (giaddr) as the source IP address of the switch for relayed DHCP packets when the switch is used as the DHCP relay agent. For information on configuring this option, see the source-address-giaddr configuration statement.

      You can also use smart DHCP relay, which enables you to configure alternative IP addresses for the gateway interface so that if the server fails to reply to the requests sent from the primary gateway address, the switch can resend the requests using the alternative gateway addresses. To use this feature, you must configure a Layer 3 interface, Layer 3 subinterface, or IRB interface with multiple IP addresses and configure that interface to be a relay agent.

      Because DHCP and BOOTP messages are broadcast and are not directed to a specific server, switch, or router, Juniper switches cannot function as both a DHCP server and a DHCP/BOOTP relay agent at the same time. The Junos operating system (Junos OS) generates a commit error if both options are configured at the same time, and the commit operation does not succeed until one of the options is removed.

      • DHCP Client and Server Model
      • DHCP Client, Server, and Relay Agent Model

      DHCP Client and Server Model

      DHCP IP address allocation works on a client/server model in which the server, in this case a Junos OS, assigns the client reusable IP information from an address pool. A DHCP client might receive offer messages from multiple DHCP servers and can accept any one of the offers; however, the client usually accepts the first offer it receives. See Figure 1.

      Figure 1: DHCP Client/Server Model
      Figure 2: DHCP Four-Step Transfer

      DHCP consists of a four-step transfer process beginning with a broadcast DHCP discovery message from the client. As the second step, the client receives a DHCP offer message from the server. This message includes the IP address and mask, and some other specific parameters. The client then sends a DHCP request message to accept the IP address and other parameters that it received from the server in the previous step. The DHCP server sends a DHCP response message and removes the now-allocated address from the DHCP address pool. See Figure 2.

      Because the DHCP discovery message from the client is a broadcast message and because broadcast messages cross other segments only when they are explicitly routed, you might have to configure a DHCP relay agent on the switch interface so that all DHCP discovery messages from the clients are forwarded to one DHCP server.

      DHCP Client, Server, and Relay Agent Model

      The DHCP relay agent is located between a DHCP client and DHCP server and forwards DHCP messages between servers and clients as following:

      1. The DHCP client sends a discover packet to find a DHCP server in the network from which to obtain configuration parameters for the subscriber (or DHCP client), including an IP address.
      2. The DHCP relay agent receives the discover packet and forwards copies to each of the two DHCP servers. The DHCP relay agent then creates an entry in its internal client table to keep track of the client’s state.
      3. In response to receiving the discover packet, each DHCP server sends an offer packet to the client. The DHCP relay agent receives the offer packets and forwards them to the DHCP client.
      4. On receipt of the offer packets, the DHCP client selects the DHCP server from which to obtain configuration information. Typically, the client selects the server that offers the longest lease time on the IP address.
      5. The DHCP client sends a request packet that specifies the DHCP server from which to obtain configuration information.
      6. The DHCP relay agent receives the request packet and forwards copies to each of the two DHCP servers.
      7. The DHCP server requested by the client sends an acknowledgement (ACK) packet that contains the client’s configuration parameters.
      8. The DHCP relay agent receives the ACK packet and forwards it to the client.
      9. The DHCP client receives the ACK packet and stores the configuration information.
      10. If configured to do so, the DHCP relay agent installs a host route and Address Resolution Protocol (ARP) entry for this client.
      11. After establishing the initial lease on the IP address, the DHCP client and the DHCP server use unicast transmission to negotiate lease renewal or release. The DHCP relay agent “snoops” on all of the packets unicast between the client and the server that pass through the router (or switch) to determine when the lease for this client has expired or been released. This process is referred to as lease shadowing or passive snooping.

      Configuring DHCP and BOOTP Relay

      You can configure a switch to act as a Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) server or DHCP relay agent. When a switch is a relay agent, if a locally attached host issues a DHCP or BOOTP request as a broadcast message, the switch relays the message to a specified DHCP or BOOTP server. You should configure a switch to be a DHCP and BOOTP relay agent if you have locally attached hosts and a remote DHCP or BOOTP server.

      This task uses the Enhanced Layer 2 Software (ELS) configuration style.If your switch runs software that does not support ELS, see Configuring DHCP and BOOTP Relay. For ELS details, see Using the Enhanced Layer 2 Software CLI.

      To configure a switch to be a server, use the dhcp-local-server statement. To configure a switch to be a relay agent, use the dhcp-relay statement.

      If you want to enable BOOTP support when the switch is configured to be a DHCP server, enter the following statement:

      [edit system services dhcp-local-server] user@switch# set overrides bootp-support

      If you want to enable BOOTP support when the switch is configured to be a DHCP relay agent, enter the following statement:

      [edit forwarding-options dhcp-relay] user@switch# set overrides bootp-support

      Configuring DHCP and BOOTP Relay on QFX Series

      You can configure the QFX Series to act as a Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) relay agent. This means that if a locally attached host can issue a DHCP or BOOTP request as a broadcast message and the switch relays the message to a specified DHCP or BOOTP server. You should configure a switch to be a DHCP and BOOTP relay agent if you have locally attached hosts and a remote DHCP or BOOTP server.

      This task uses a release of Junos OS that does not support the Enhanced Layer 2 Software (ELS) configuration style. If your switch runs software that supports ELS, see Configuring DHCP and BOOTP Relay. For ELS details, see Using the Enhanced Layer 2 Software CLI.

      If you configure a switch to be a DHCP relay agent, you can also enable smart DHCP relay, which allows you to configure alternative gateway addresses for a DHCP server so that if the server fails to reply to the requests sent using the primary gateway address, the switch can resend the requests via the alternative gateway addresses. To use this feature, you must configure a routed VLAN interface or Layer 3 logical interface with multiple IP addresses and configure that interface to be a relay agent.

      • Configuring a DHCP and BOOTP Relay Agent on QFX Series
      • Configuring DHCP Smart Relay on QFX Series

      Configuring a DHCP and BOOTP Relay Agent on QFX Series

      To configure a switch to act as a DHCP and BOOTP relay agent, include the bootp statement at the [edit forwarding-options helpers] hierarchy level:

      [edit forwarding-options helpers] bootp < apply-secondary-as-giaddr text-description; client-response-ttl number; description text-description; interface (interface-name | interface-group) < client-response-ttl number; description text-description; maximum-hop-count number; minimum-wait-time seconds; no-listen; server address apply-secondary-as-giaddr > maximum-hop-count number; minimum-wait-time seconds; relay-agent-option; server server-identifier >

      To include a description of the BOOTP service, DHCP service, or interface, use the description statement.

      To configure a logical interface or a group of logical interfaces with a specific DHCP relay or BOOTP configuration, include the interface statement.

      To stop packets from being forwarded, include the no-listen statement.

      To set the maximum allowed number in the hops field of the BOOTP message, include the maximum-hop-count statement. BOOTP messages that have a larger number in the hops field than the maximum allowed are not forwarded. If you omit the maximum-hop-count statement, the default maximum number of hops is four.

      To set the minimum allowed number of seconds in the secs field of the BOOTP message, include the minimum-wait-time statement. This setting configures a minimum number of seconds since the client sent its first BOOTP request. BOOTP messages that have a smaller number in the secs field than the allowed minimum are not forwarded. The default value for the minimum wait time is zero (0).

      To set the IP address that specify the DHCP or BOOTP server for the router, switch, or interface, include the server statement. You can include multiple server statements.

      To set an IP time-to-live (TTL) value for DHCP response packets sent to a DHCP client, include the client-response-ttl statement.

      The following example demonstrates a BOOTP relay agent configuration.

      user@host# show forwarding-options helpers < bootp < description "dhcp relay agent global parameters"; server 192.168.55.44; server 172.16.0.3 routing-instance c3; maximum-hop-count 10; minimum-wait-time 8; interface < xe-0/0/1 < description "use this info for this interface"; server 10.10.10.10; server 192.168.14.14; maximum-hop-count 11; minimum-wait-time 3; >xe-0/0/2 < no-listen; ###ignore DHCPDISCOVER messages on this interface >all < description "globals apply to all other interfaces"; >> > >

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *