03-17-2014 12:09 AM - edited 03-07-2019 06:44 PM
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?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide