Greetings
Just fyi on the 7.4.100.0 RRM
CSCue13108
TPC in 7.4 reduces transmit power to lower than expected values
Workaround:
Setup min - max power levels for TPC, so that the power levels do
not fall below the expected value
TAC does have a engineering special that fixes this or next release
and agree "outside the RFC" but do use one lease per client and not had
any problems,thought was to clean up pool and ddns little quicker. ISC
dhcp mailing list conversations support just using shorter lease times,
I just never took it out.
best!
jim
On 2/20/2013 3:04 PM, Garret Peirce wrote:
I see a few different topics within this thread, each of which I've
run across recently.
re: ISC dhcp server - "one lease per client":
Perhaps a desirable idea - especially given the knob, but not
recommended as doing so is outside the operation of the RFC. It's
probably best as a last ditch effort only. I had been thinking of
using it myself but now shying away from it.
re: "dirty interfaces". Working with TAC on this issue currently as I
have non-grouped interfaces being marked as dirty in 7.0.240. I'm
planning on making a feature request to a) make marking dirty optional
b) have a configurable threshold, c) have a configurable timeout
period and d) logging when the condition is cleared.
In a non dot1x environment, I'm seeing unknown devices , of which
there are rightly many, trying to grab an address for which no entry
exists. When 3 requests go unanswered, the (solo) interface is marked
as dirty, which I don't understand. Now although marked, it does not
seem to then avoid using the interface for the (hardcoded) 30 minutes.
Appreciate any insight or knowing if others are seeing the same behavior.
re: 7.4.100.0 RRM - working on a similar issue. I found a 3502's 2.4
radio set on low Txpower (6) under 7.4.100.
I moved it a 7.0.240 controller within the same RF group and TxPower
(seeing the same neighbors), now running at 2. I need to move it back
to see if the problem tracks with the codeRev. 7.4.100 is in it's
default TPCv1 mode.
On Mon, Feb 18, 2013 at 10:10 AM, Bryn Jones <b.l.jo...@leeds.ac.uk
<mailto:b.l.jo...@leeds.ac.uk>> wrote:
Hi Vikki
We have used interface groups for a while with great success on
our WiSM2. We have a DHCP lease time of 20mins and we have an
interface group that consist of 20 x /15 private IP subnets so
that we have the IP capacity to cope.
Thanks
Bryn
Bryn Jones
ISS Network Development
Rm 8.01e Computing Block
EC Stoner Building
University of Leeds
UK
LS2 9JT
0113 343 7055
*From:*The EDUCAUSE Wireless Issues Constituent Group Listserv
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] *On Behalf Of *Vikki
Cutrone
*Sent:* 15 February 2013 19:13
*To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
*Subject:* [WIRELESS-LAN] Cisco Wireless Interface Groups
Hello All,
I recently configured multiple /24 subnets into a wireless
interface group on my controllers, in an effort to cut down on
multicast as well as increase the IP address space. It seems to
be working but DHCP addresses are still being consumed at an
alarming rate. Is anyone else using the interface group feature?
and if so is it working as expected?
Thank you in advance!
--
Vikki Cutrone
Network Administrator
Vassar College, Box 13
124 Raymond Ave
Poughkeepsie, NY 12604-0013
845-437-7231 <tel:845-437-7231>
********** Participation and subscription information for this
EDUCAUSE Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
********** Participation and subscription information for this
EDUCAUSE Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
--
Garry Peirce
Network Architect
Networkmaine, University of Maine System
1-207-561-3539
********** Participation and subscription information for this
EDUCAUSE Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.