Hi!
I have the next configuration: dedicated VRF on ASR 1001 for guest access, guest's network is served by WiFi-controller (HP). In cause of unfixed bugs in controller's firmware there is no ablility to launch DHCP server on controller. So, I tried to launch it on ASR. Here is IOS version and all configuration related to guest VRF:
Cisco IOS Software, IOS-XE Software (X86_64_LINUX_IOSD-UNIVERSALK9_NPE-M), Version 15.2(1)S1, RELEASE SOFTWARE (fc2)
ip dhcp pool GUEST-NET-DHCP-POOL-TEST
vrf GUEST-NET
network 172.16.16.0 255.255.255.0
default-router 172.16.16.254
dns-server 195.49.168.2 195.49.169.4
lease 0 0 30
ip dhcp excluded-address vrf GUEST-NET 172.16.16.1 172.16.16.10
ip dhcp excluded-address vrf GUEST-NET 172.16.16.254
interface GigabitEthernet0/0/1
description ### GUEST LAN ###
ip vrf forwarding GUEST-NET
ip address 172.16.16.254 255.255.255.0
ip nat inside
negotiation auto
!
interface GigabitEthernet0/0/2
description ### AVANTEL INET ###
ip vrf forwarding GUEST-NET
ip address xxx.xxx.xxx.xxx 255.255.255.128
ip nat outside
negotiation auto
ip nat inside source list GUEST-NET-TO-NAT interface GigabitEthernet0/0/2 vrf GUEST-NET overload
WiFi controller masks clients' MAC-addresses (replies with it's own MAC). But I encountered next trouble: after a few minutes guests lose connect. I found out that in ARP-table appears real MAC-addresses of WiFi-devices instead of controller's MAC. Traffic captures showed that in moment of ARP-table change there is no ARP packets, but there is a... DHCP-Request. But after clear arp-cache and manual DHCP renew on WiFi device ARP table of ASR isn't modified. I figured out that this accident occurs after half of lease period. Here is show dhcp binding output:
Bindings from VRF pool GUEST-NET:
IP address Client-ID/ Lease expiration Type State Interface
Hardware address/
User name
172.16.16.26 01d0.23db.f399.43 Mar 12 2014 06:05 PM Automatic Active Unknown
And debug dhcp events & packets after 15 minutes:
Mar 12 17:51:44: DHCPD: Reload workspace interface GigabitEthernet0/0/1 tableid 2.
Mar 12 17:51:44: DHCPD: tableid for 172.16.16.254 on GigabitEthernet0/0/1 is 2
Mar 12 17:51:44: DHCPD: client's VPN is GUEST-NET.
Mar 12 17:51:44: DHCPD: DHCPREQUEST received from client 01d0.23db.f399.43.
Mar 12 17:51:44: DHCPD: Sending notification of ASSIGNMENT:
Mar 12 17:51:44: DHCPD: address 172.16.16.26 mask 255.255.255.0
Mar 12 17:51:44: DHCPD: htype 1 chaddr d023.dbf3.9943
Mar 12 17:51:44: DHCPD: table id 2 = vrf GUEST-NET
Mar 12 17:51:44: DHCPD: lease time remaining (secs) = 1800
Mar 12 17:51:44: DHCPD: interface = GigabitEthernet0/0/1
Mar 12 17:51:44: DHCPD: Sending DHCPACK to client 01d0.23db.f399.43 (172.16.16.26).
Mar 12 17:51:44: DHCPD: creating ARP entry (172.16.16.26, d023.dbf3.9943, vrf GUEST-NET).
Mar 12 17:51:44: DHCPD: unicasting BOOTREPLY to client d023.dbf3.9943 (172.16.16.26).
Mar 12 17:51:44: DHCPD: Reload workspace interface GigabitEthernet0/0/1 tableid 2.
Mar 12 17:51:44: DHCPD: tableid for 172.16.16.254 on GigabitEthernet0/0/1 is 2
Mar 12 17:51:44: DHCPD: client's VPN is GUEST-NET.
Mar 12 17:51:44: DHCPD: DHCPREQUEST received from client 01d0.23db.f399.43.
Mar 12 17:51:44: DHCPD: Sending notification of ASSIGNMENT:
Mar 12 17:51:44: DHCPD: address 172.16.16.26 mask 255.255.255.0
Mar 12 17:51:44: DHCPD: htype 1 chaddr d023.dbf3.9943
Mar 12 17:51:44: DHCPD: table id 2 = vrf GUEST-NET
Mar 12 17:51:44: DHCPD: lease time remaining (secs) = 1800
Mar 12 17:51:44: DHCPD: interface = GigabitEthernet0/0/1
Mar 12 17:51:44: DHCPD: Sending DHCPACK to client 01d0.23db.f399.43 (172.16.16.26).
Mar 12 17:51:44: DHCPD: broadcasting BOOTREPLY to client d023.dbf3.9943.
Mar 12 17:52:01: DHCPD: checking for stale address conflicts.
I found update arp command in context of dhcp pool, that will justify this behavior, but it's turned off by default. On the off-chance I typed no update arp, but no changes followed.
I figure out only one workaroud: set a tiny ARP-timeout on interface, but this way resolves this issue not fully. Clients still will encounter poor connenction for a little time and there will be a lot of broadcasts and it is critical (We serves up to 300 guests simultaneously).
Is it bug or feature?)
Do anybody have any considerations about workarounds?
