Monitoring DHCP leases from vrf tunnels

Hello,
I am looking to monitor dhcp leases from vrf tunnels on a 4510R switch and be notified when a lease is handed out Does anyone have any suggestions on the best way to accomplish this?
Thanks!

See http://www.cisco.com/en/US/docs/ios/12_4t/12_4t4/ht_iimib.html . Assuming you're running the correct version of code, you can get VRF-aware CISCO-IPSEC-FLOW-MONITOR-MIB and CISCO-IPSEC-MIB support. You will need to make sure you have configured your device to allow for VRF-based SNMP polling. The VRF instances will not show sum totals for the system. To get that, you will need to poll using a non-VRF community string.

Similar Messages

How to view DHCP lease from ISP on a 2811

I have a remote site on a 2811 IOS 12.4(15). Interface FA 0/0 faces the ISP and is set for DHCP. What command can I run to see all of the information given out with the IP lease from the ISP? I need to find out what the IP address of the DNS servers are.
All responses appricated.
Cheers,
Frederick Sawyer

Hi,
to see traffic he can also use the RITE feature: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_rawip.html
Regards.
Alain
Don't forget to rate helpful posts.

Monitoring DHCP leases with SNMP

Hi,
is there a way to monitor the number of DHCP leases (show ip dhcp binding) of a DHCP pool created on a 2960 switch?
Regards, Leonardo

Once I got my SNMP host to accept the correct attribute and configure the event trap all I had to do was add the trap command to the router. I then bounced one of my low usage PRI's (which had 0 calls on it ) and got the following event traps on the SNMP host:
Minor
May 19, 2010 2:21:00 PM EDT
A demandNbrLayer2Change notification has been received indicating that a D-channel on Rtr_Cisco device, named has layer 1 active but layer 2 not established. Interface Index = 83 Link Status = ISDNLinkInTransition
System
May 19, 2010 2:21:01 PM EDT
System
Major
May 19, 2010 2:20:59 PM EDT
A demandNbrLayer2Change notification has been received indicating that a D-channel on Rtr_Cisco device, named has both layers 1 and 2 inactive. Interface Index = 83 Link Status = ISDNLinkDown
System
May 19, 2010 2:21:00 PM EDT
System
It doesn't tell you specifically which interface is down but at least it narrows it down to the gateway/router. Most of our gateways have only one PRI anyway.
We use Spectrum One Click for network monitoring.
Here is L2 back on line:
May 19, 2010 2:21:01 PM EDT
A demandNbrLayer2Change notification has been received indicating that a D-channel on Rtr_Cisco device, named has layer 1 active and layer 2 established. Interface Index = 83 Link Status = ISDNLinkUp
System

Some Clients wont get DHCP Lease from xServe

Hello,
today we got some strange Network Problems. Some Imacs dont get a IP Adress from our Xserve (10.5). The Xserve tries to offer a adress but the Client wont get them.
The log only says "offer send to xyz-hostname ip-adress"
The strange thing is, when i spoof the Mac Adress on the imac. I get a dhcp lease.
Is there some "Cache" we can reset ? Or simply reboot the Xserve ?
thx

Sure, possibly relevant parts:
errdisable recovery cause udld
errdisable recovery cause bpduguard
errdisable recovery cause security-violation
errdisable recovery cause channel-misconfig (STP)
errdisable recovery cause pagp-flap
errdisable recovery cause dtp-flap
errdisable recovery cause link-flap
errdisable recovery cause gbic-invalid
errdisable recovery cause l2ptguard
errdisable recovery cause psecure-violation
errdisable recovery cause dhcp-rate-limit
errdisable recovery cause vmps
errdisable recovery cause storm-control
errdisable recovery cause arp-inspection
spanning-tree mode rapid-pvst
spanning-tree loopguard default
spanning-tree portfast bpduguard default
spanning-tree extend system-id
vlan internal allocation policy ascending
ip ssh time-out 60
ip ssh authentication-retries 5
ip ssh logging events
ip ssh version 2
interface GigabitEthernet1/0/1
description Gi1/0/1 to CAT-CORE
switchport trunk encapsulation dot1q
switchport mode trunk
interface GigabitEthernet1/0/4
description Gi1/0/4 to RADIUS_serv
switchport access vlan 240
switchport mode access
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
interface GigabitEthernet1/0/8
description Gi1/0/8 to DHCP_serv
switchport access vlan 240
switchport mode access
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
interface GigabitEthernet1/0/11
description Aironet 1141 AIRONET-MO-1
switchport trunk encapsulation dot1q
switchport trunk native vlan 240
switchport trunk allowed vlan 240-246,248,249
switchport mode trunk
interface Vlan240
description Admin_Vlan
ip address 192.168.240.244 255.255.255.0
ip default-gateway 192.168.240.1
ip classless
no ip http server
ip http secure-server

Monitor DHCP leases 5508 WLC

Hello all,
We have 2 5508 WLCs setup with one being the primary controller on our LAN and the other being set up as a anchor controller in our DMZ. We use this configuration for our public wifi. What I would like to know if there is any way to find out how many DHCP leases the primary controller hands out to the public wifi users in a month? Is this sort of info logged?
Any and all information is appreciated.
Thanks
Jim

Proxy disable is just going to bridge teh DHCP request to the wire vs having the WLC in the way. Unless you are using a FW as your DHCP you shouldn't need to do that.
Does that client have a static IP? Is this happening with more than one device?
HTH,
Steve
Please remember to rate useful posts, and mark questions as answered

WLC2504 clients not receiving DHCP leases

I'm stock with a 2504 using version 7.0.220.0 that won't lease out DHCP adresses
Wifi clients are unable to get a DHCP lease from an external DHCP server.
The WLC are handling 3 WLAN, 2 using internal DHCP server, 1 (that wont work) using external DHCP. The external DHCP server, is a router/firewall (out of my reach) that suffered from a power out, a short while ago, ever since the DHCP is not working on that VLAN, if client are getting static ip adresses, everything works fine. If i'm using the same network link, and plug it into a computer, I get a DHCP address.
I've enable DHCP proxy
Debbuging DHCP, using: Debug DHCP packets enable
Gives me this:
*DHCP Socket Task: Nov 08 14:21:11.397: c8:0a:a9:cc:6d:f6 DHCP received op BOOTREQUEST (1) (len 308,vlan 20, port 1, encap 0xec00)
*DHCP Socket Task: Nov 08 14:21:11.397: c8:0a:a9:cc:6d:f6 DHCP option len (including the magic cookie) 72
*DHCP Socket Task: Nov 08 14:21:11.397: c8:0a:a9:cc:6d:f6 DHCP option: message type = DHCP INFORM
*DHCP Socket Task: Nov 08 14:21:11.397: c8:0a:a9:cc:6d:f6 DHCP option: 61 (len 7) - skipping
*DHCP Socket Task: Nov 08 14:21:11.397: c8:0a:a9:cc:6d:f6 DHCP option: 12 (len 1) - skipping
*DHCP Socket Task: Nov 08 14:21:11.397: c8:0a:a9:cc:6d:f6 DHCP option: vendor class id = MSFT 5.0 (len 8)
*DHCP Socket Task: Nov 08 14:21:11.397: c8:0a:a9:cc:6d:f6 DHCP option: 55 (len 13) - skipping
*DHCP Socket Task: Nov 08 14:21:11.397: c8:0a:a9:cc:6d:f6 DHCP options end, len 72, actual 64
*DHCP Socket Task: Nov 08 14:21:11.397: c8:0a:a9:cc:6d:f6 DHCP dropping packet (no mscb) found - (giaddr 0.0.0.0, pktInfo->srcPort 68, op: 'BOOTREQUEST')
Thanks

Hi Steen,
When a client is in DHCP REQ state on the controller, the controller drops DHCP inform packets. The client will not go into a RUN state on the controller (this is required for the client to pass traffic) until it receives a DHCP discover packet from the client. DHCP inform packets are forwarded by the controller when DHCP proxy is disabled.
Please check this, if still u r facing issue then provide more info.
Can you please paste a client debug of the client having DHCP issues.
Go to cli of the wlc and run the client debug . Diconnect the client then reconnect and gather the output and post.
Regards

Self-assigned IP after trying to renew DHCP lease for former network

Hi all,
MacBook Pro 15" purchased in Februrary 2008, currently running 10.5.5, up-to-date with patches as of yesterday, 10/20/2008.
For a few weeks now, I've been consistently unable to connect to wireless networks (secured or unsecured, public or private) after changing networks (i.e. going from home to a coffee shop).
I have control over my home network router, and its logs show that upon connecting to the network, OS X tries to renew a DHCP lease for the previous network it was on. Upon receiving the "bad network" DHCP reply, instead of releasing the lease and obtaining a new one, the AirPort interface is immediately assigned an IPV4LL address (from 169.254.0.0/16) and no combination of changing network settings, changing AirPort settings, or rebooting will eliminate the old DHCP lease.
The end result is that my MBP is entirely nonfunctional on some wireless networks that other clients (both Windows and Mac) seem to have no trouble accessing. The problem is quite annoying because I can't connect to access points that (previously) worked fine and whose configurations haven't changed.
In any case where this problem occurs, an old DHCP lease for a different network (10.0.0.0/8 when trying to get on 192.168.0.0/24 or vice versa) is present, so I strongly suspect a DHCP problem. In all cases, I have perfect connectivity to the access point itself, so problems with the wireless connection parameters (including encryption), or those troublesome problems with 802.11b/g/n interoperation seem highly unlikely.
One of two things would help me:
1) Please tell me how to clear the DHCP lease cache. Deleting files from /var/db/dhcpclient/leases does nothing (they appear again upon reboot, identical save for timestamps even after changing network environments, so the cache must be read at boot time and written at shutdown). Selecting "Renew DHCP lease" from the "TCP/IP" tab in the advanced network settings merely attempts to renew the existing lease (for an invalid IP address); it does not appear to release invalid leases.
2) If this is really how the DHCP client is behaving, change the DHCP client so that upon receiving the "Bad network" response, it releases (or simply abandons) the lease and obtains a new one, rather than immediately assigning an IPV4LL address to the AirPort interface.
Additionally, is there any documentation on the Apple DHCP client? Under Linux, I could alter dhcpcd parameters to diagnose things like this. I could find no documentation about the Apple DHCP client outside of Mac Help, which wasn't really any help in this case.
Finally, I do not suspect that this is an instance of the problem discussed in http://discussions.apple.com/thread.jspa?threadID=1352518&tstart=0 as my connection is rock-solid if it can get an IP address when it connects. I've never even seen it hiccup.
Thanks,
Matt Z.

I have had wireless problems intermittently for a year, and seriously for 6 weeks. Apple denied the issue and was no help in spite of many tens of thousands of people on their own discussions complaining. I found a post suggesting a couple of things which fixed the problem. I don't know if both are necessary, but the first by itself does not solve the problem.
Lock the channel of your router to channel 1, apparently Apple and 802.11n don't play well together on higher channels. When this becomes a standard this will be resolved I hope.
Open your network preferences, select 'airport' and advanced. Delete unused networks. Select your network.
Open TCP/IP and write down all the settings, configure iPv4 manually. Enter the settings manually. Turn off IpV6.
Open DNS and write down your DNS server. Delete it and re-enter it manually.
This has worked on 2 macbooks and an iMac for the last 3 weeks with no network drops.
Joe Shea
Philadelphia

Get DHCP logs from WLC?

We've got a WLC 4402 running 5.2.157.0, and WCS 5.0.72.0.
We've got a guest wlan that uses web authentication to grant IP addresses for guest users.
We have the WLC syslogging to another server, at syslog level critical.
What we would like to do is get the MAC address of machines that are given DHCP addresses, so that we can tell who is using our wireless, or attempting to.
If syslog isn't how to get this information, is there another show command to see what machines got given DHCP addresses?
Thanks,
R

You could see this with "show dhcp leases" from the controller's CLI or you should also be able to get this info through SNMP.

Windows 7 does not wake from sleep to renew DHCP Lease

I am having trouble with DHCP and sleeping Windows 7 systems. My Windows 7 systems go to sleep after an hour or so. The Intel and Broadcom NICs we have use ARP offloading so they continue to respond to ARP while the machine is sleeping.
The problem is that after the DHCP lease expires, the NIC continues to respond to the ARP requests and that causes IP conflicts on the network because the computer is responding to ARP requests for an IP address the computer has lost its lease on. Any
time a computer is asleep for longer than the DHCP lease time then when a new computer gets the IP from the lost lease, an IP conflict is reported because the new leasee does an ARP to see if the IP is in use and the sleeping computers NIC responds to the
ARP and this results in an IP conflict for the new leasee.
I opened a ticket with the Hardware Vendor, which is Dell in this case, and they opened an engineering case with Intel - the NIC OEM. The outcome of this case what that this is Windows fault. Windows is supposed to wake up from sleep and renew
its DHCP lease at the lease half life and then go back to sleep. My computers are not doing this. They let the lease expire while they are sleeping.
Is there a problem with Windows 7 that prevents it from waking up and renewing its lease periodically? It is supposed to maintain the lease according to Dell and Intel, but in my case it it not.

Extending the lease time is a bandage on the problem, and it is what we have done while I attempt to resolve the issue.
The network group would like the lease time set to 4 hours.
Extending the lease time doesn't resolve the issue because it only makes the problem occur less freqently. With a 2 week lease, a machine needs to be asleep for 2 weeks before it causes a problem. Machines are not likely to be asleep for 2 weeks
very often.
The resolution would be to figure out why a sleeping Windows OS is not maintaining its IP address. If it is not going to renew the DHCP lease while it is asleep, it is still responsible for updating the TCP stack (and the NIC) to let it know that it
no longer has a lease to that IP address. The OS has offloaded ARP to the NIC, which continues to respond to ARP while the computer is asleep. If the OS lets the lease expire, then it needs to notify the NIC to stop responding to ARP requests for
that address.

MDT 2013 - A Connection to the deployment share could not be made - DHCP Lease was not obtained

First, let me give you some context:
Framework: MDT 2013 with MS SDK 7.1
Task Sequence: Standard Client TS with sysprep and capture.
Target workstation (build workstation): VM Guest on ESX 5.5 host, 8 vCPU, 8GB RAM, LSI Logic SAS Controller, E1000 NIC, SSD DAS
Behavior: The VM loads and installs the OS fine in PE, VM boots into OS successfully and resumes the TS, after the first system reboot, the error message occurs and it reads:
A connection to the deployment share (\\*********\DeploymentShare$) could not be made. DHCP Lease was not obtained for any Networking device! Possible Cause: Check physical connection. Retry:...... Cancel:.....
While observing this error, I didn't notice the NIC hadn't completely initialized and obtained an IP yet (network adapter icon in systray), additionally hitting retry after the NIC was initialized resumed the TS.
This behavior reoccurs with several subsequent reboots until a few more applications (Citrix Receiver, VMware Tools) with services are installed which seem to then slow the system boot-up time and then allows the TS to start after the NIC has initialized.
From several posts I've read on this forum, this particular behavior was alleviated by a "wait for IP lease" mechanism built into the TS engine which was introduced in MDT 2010 SP1, I wasn't able to find any other confirmation whether
this mechanism is still in effect with MDT 2013. Another point worth mentioning from several other posts I was able to find is that this behavior appears to manifested itself on target workstations with SSDs, which would somewhat explain the faster
TS load time vs waiting for an IP lease. I've also tried to replicate this behavior in a non-SSD and low-performance VM environment and I wasn't able to replicate it.
My question: Does anyone else have experienced this behavior with MDT 2013 and if so, how did you resolve it? Or is this a bug?

I have this issue intermittently as well. For us, it coincided with the deployment of IP phones, which meant PoE switches all around. However, the problem persisted even after we turned off PoE to the ethernet ports from which we normally PXE
boot.
As this issue has been intermittent, I've backburnered it. When it does happen, I just wait for the lease to arrive then rerun the wizard.
Thanks for the feedback, that's true the TS can be resumed manually once the lease has occured but it defeats the purpose of an automated TS if I have to keep an eye on it and intervene if I need to.
The network guys here recommended putting wireshark or network monitor on it and figuring out just what the heck is going on. Basically, what Keith Garner said. They also disabled PortFast awhile back to see if that made any difference, and it did
not.

Mac mini server refuses to get DHCP address from router

Everything was going along fine. But after a power outage the server goes to a 169. address when the router puts out 198. addresses. If I put a static 198. address in it sees the network but won't connect to the internet. I've flashed the router (everything else sees the router fine, 3 computers and a time capsule). I've had the hardware checked at the Apple store - it picked up an address right away. After narrowing everything down the problem has to be in the operating system. I even did a full time machine restore to the day before the storm. No luck. Anyone heard of this problem.

Mauricette has a point.
A server function is not designed to accept a floating or dynamic IP address. If that is the case, how do you create firewall rules that prevent those unnnecessary ports being left opened from being attacked by rogue machines in Romania and China on a hourly basis when you announce to the world that your server is available if the server IP address keep changing due to the DHCP lease change? Yes, they do have bots that do this VERY EFFICIENTLY!
By changing the very nature of your firewall rules by working with DHCP, you are opening ports you do not know to accommodate DHCP dynamic addressing, which was the reason why your Mac Mini Server stopped working in the first place. It's ok for a client, since a client isn't serving any files to any one right.
By using client based firewall rules, you are exposing your server to attacks and when they get through your Mini server, which they can if they are persistent, they get into your home network and then whatever file server services you have opened and unprotected at the time WILL BE copied by these people easily.
I have a client once who did just that. She was attacked, the hacker went through her network like a rampaging bull. They were from China. My Synology RAID server gets this attack all the time, but I have a well establish IDS system and the Synology RAID has logs that tracks attacks.
For a server setup. Use static IP and then build a strong firewall around it and protect it and never compromise.
Recently, I just noticed someone somehow hacked and broke my WPA-PSK AES passkey for one of my Wireless N network router. It was not set up with a strong password though, but thankgod I had a firewall around that so my internal networks were safe. So this teaches you that if someone wants in bad, they will get in.
Hope this helps.

My internet keeps going down and when I try to renew the DHCP lease it stops working altogether

Every couple of weeks my internet would go down, I would be surfing the web and suddenly my connection would fail. I would try renewing my DHCP lease and every time I did I would get an IPv4 address of 192.168.0.100. Originally, restarting the router would fix the problem but the past couple of times they needed a technician from the provider to fix it. Even using the Ethernet cable doesn't work either.
is there a reason why this keeps happening and how do I stop it from happening again? Is there anything I can try to fix it on my end?
my computer is a five year old MacBook, running OS X 10.9.4

Having the same problem. Watched 25 minutes of a rental and it stopped with the message"unable to load video"
Using current version IPad mini.
Ios7 is HUGH PIECE OF CRAP!!!!

How do I revoke a DHCP lease in the 10.8.4 server app?

Hello Everyone,
I have some devices (security cameras) that have successfully requested a DHCP lease. Since then I went ahead and manually created a static reservation for them with a MAC hardware address in the DHCP. For whatever reason they are not switching over to the reserved address. The leases were originally for 1 day. It has been 5 days now. After the first day I switched my lease time to 1 hour. I have done everything short of leaving the devices off for 24 hours.
In Lion server, I could revoke the lease via the gui. No such luck now. My call to Applecare resulted in a "there is no way in 10.8.4 to do this". They said it would switch to the new reserved address after the initial lease period timed out, so I'm hoping the representative was wrong twice. They mentioned a complete lease wipe, but couldn't say if this would cause me to lose my list of reserved static addresses, which isn't an option.
It seems crazy that such a basic feature wouldn't make it into this release of the DHCP service. Any help would be greatly appreciated!

Are there any DHCP queries from the cameras? Check the DHCP server log via Console.app or Server.app (or Terminal.app) for details. (I don't know the 10.8 path to the DHCP logs offhand.)
According to a FAQ over at the Vivotek site, the following is the setup sequence for various recent cameras; the boxes start up in the "I don't have an IP address" self-allocated address block oddly enough, and apparently don't ask for a DHCP address? (You may well be aware of all of this, but this is the block that DHCP clients use when they first communicate with DHCP servers.)
If you are using our new product such as IP7138 / IP7139 / FD7131 / VS7100… etc, no matter your network environment is what, you can always find the camera by Installation Wizard II with the IP address 169.254.x.y.
And then, please double click the camera found by Installation Wizard II or directly type the IP address to your Internet Explorer URL box to access your camera (you do not need to change your PC's IP address). After access your camera, please go to "Network" page to configure proper network settings.
See if the devices are available via mDNS, as well; download the Bonjour Browser and have a look around your LAN. (If you're very lucky, the cameras might be visible and chatting on mDNS.)
Might also try resetting one of the cameras back to factory defaults, and seeing if you can get them to re-ask the DHCP server.
(I've had issues with some HP printers and DHCP clients and IP address assignment, but that's fodder for another discussion. And I also wouldn't rule out a rogue DHCP server, either. I've seen all sorts of unexpected stuff connected to networks over the years...)

N82 does not correctly process DHCP leases

I have no problem attaching my new N82 to my, and friends, home wireless networks. However, it fails to connect to the Univeristy Campus network giving the error: "Web: No gateway reply!"
This is because the phone doesn't correctly process DHCP leases with the 'network of one'' (2545.255.255.255) subnet mask.
Campus network details:
HP WAP 530 enterprise access point. The DHCP server is an ISC dhcp server giving out ip address in the standard private class C address range (192.168.1.0) with a subnet mask of (255.255.255.255), and a default route of 192.168.1.1.
This works on Windows 2000/XP/Vista and MAC OSX, but many embedded devices will not add the default route as they see it as outside their subnet. Many institutions use 255.255.255.255 to mitigate inter host communication.
This means I cannot use my N82 at work and I'm not happy. Beware, don't assume you can use your Nokia device at work.

If task manager says it's still running, then obviously it hasn't completed, contrary to what you said. Maybe this .exe process isn't written correctly. For example, maybe it is dependent on the current directory it is launched from, and so double-clicking it causes it to be launched from the directory it lives in, but when run from this java app, the working directory is somewhere else.

Continually have to renew DHCP lease

Occasionally my MBP will loose wireless connection. It often happens when my phone accesses the wireless Linksys router.
Every time it happens, I open network preferences, go to Advanced and "Renew DHCP Lease" and it fixes it.
Almost looks like I could use a script or something to make it renew DHCP lease when wireless disconnects.
Any ideas?

BoyHowdyDoo wrote:
Try another router. They are cheap.
I guess they're cheap for most people who are happy overspending for Apple products.
Usually not a problem with your Mac.
None of my other non-Apple devices have any problem connecting.
I really appreciate you being one of the few trying to help. My negative comments come from my frustration at Apple.

Monitoring DHCP leases from vrf tunnels

Similar Messages

Maybe you are looking for