I have seen a few similar posts, but nothing so far that fits my scenario, I think.
I keep getting random users in this VLAN reporting IP conflicts. These desktop systems are left on 24/7. Right now, we only have one VLAN DHCP being served from this core switch.
There are only 29 computers pulling DHCP on this VLAN, but I have a large range allocated to them for growth. These are desktop systems, so they don't swap network ports, and they don't have dual NICs, nor do they have WiFi. So I am at a lose as to why we would be seeing IP conflicts with such an obvious open pool of IPs, and with MAC addresses not changing. It has been my experience that pretty much unless something happens(offline for several days, NIC replacement, etc.) to the MAC every IP renewal gives the same IP back.
Core#sho ip dhcp pool OUR-Workstations
Pool OUR-Workstations :
Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
Total addresses : 254
Leased addresses : 28
Excluded addresses : 49
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased/Excluded/Total
10.1.32.183 10.1.32.1 - 10.1.32.254 28 / 49 / 254
Core#sho ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type State Interface
10.1.32.50 0180.1f02.5f5e.b6 Dec 18 2013 11:34 PM Automatic Active Vlan32
10.1.32.51 01f0.4da2.2e9f.06 Dec 19 2013 07:57 AM Automatic Active Vlan32
10.1.32.54 01b8.ac6f.45b4.27 Dec 19 2013 09:54 AM Automatic Active Vlan32
10.1.32.55 0100.2564.c8bd.ea Dec 19 2013 09:33 AM Automatic Active Vlan32
10.1.32.58 01b8.ac6f.45c4.97 Dec 19 2013 04:18 AM Automatic Active Vlan32
10.1.32.61 01b8.ac6f.3693.05 Dec 19 2013 05:12 AM Automatic Active Vlan32
10.1.32.62 01b8.ac6f.35f0.eb Dec 19 2013 05:18 AM Automatic Active Vlan32
10.1.32.63 0100.2564.c8c7.ae Dec 19 2013 12:26 AM Automatic Active Vlan32
10.1.32.65 01f0.4da2.2fba.66 Dec 19 2013 01:44 AM Automatic Active Vlan32
10.1.32.66 01b8.ac6f.46eb.b8 Dec 19 2013 01:05 AM Automatic Active Vlan32
10.1.32.67 01b8.ac6f.45c9.7a Dec 18 2013 10:54 PM Automatic Active Vlan32
10.1.32.68 01b8.ac6f.45c3.dc Dec 19 2013 07:12 AM Automatic Active Vlan32
10.1.32.70 01b8.ac6f.35f1.48 Dec 19 2013 05:15 AM Automatic Active Vlan32
10.1.32.88 01b8.ac6f.37bc.3e Dec 19 2013 06:37 AM Automatic Active Vlan32
10.1.32.97 01b8.ac6f.368f.f5 Dec 19 2013 06:42 AM Automatic Active Vlan32
10.1.32.101 01b8.ac6f.45bb.9e Dec 19 2013 06:17 AM Automatic Active Vlan32
10.1.32.110 01f0.4da2.2d47.5a Dec 19 2013 06:17 AM Automatic Active Vlan32
10.1.32.118 01f0.1faf.1d37.97 Dec 19 2013 07:19 AM Automatic Active Vlan32
10.1.32.121 0100.2564.c95a.c1 Dec 19 2013 06:53 AM Automatic Active Vlan32
10.1.32.144 01b8.ac6f.1d37.34 Dec 19 2013 09:16 AM Automatic Active Vlan32
10.1.32.167 0100.2564.c94e.f0 Dec 19 2013 07:34 AM Automatic Active Vlan32
10.1.32.170 01e0.db55.e9d7.01 Dec 19 2013 07:38 AM Automatic Active Vlan32
10.1.32.171 0100.03ff.2eba.66 Dec 18 2013 01:20 PM Automatic Active Vlan32
10.1.32.178 0124.7703.f1c2.e5 Dec 18 2013 10:02 AM Automatic Selecting Vlan32
10.1.32.235 01f0.4da2.2c92.33 Dec 19 2013 09:53 AM Automatic Active Vlan32
10.1.32.238 01b8.ac6f.3649.aa Dec 19 2013 05:21 AM Automatic Active Vlan32
10.1.32.241 01b8.ac6f.1d2a.2f Dec 18 2013 10:08 PM Automatic Active Vlan32
10.1.32.247 01b8.ac6f.45b5.8f Dec 19 2013 05:15 AM Automatic Active Vlan32
Not sure what the SELECTING status is for 10.1.32.178, but I assume I caught this at a point IP renewal.
Cisco IOS DHCP service doesn't reallocate the same IP to a client that is renewing its binding, it will try to offer the next IP available that is not excluded manually or that either didn't receive a DHCPDECLINE or a positive reply to an icmp echo test or ARP test.It will circle like this upto end of pool and starting at start of pool again.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...