Hi Brent, On 05/04/11 12:47 PM, Brent Knotts wrote: > OB: No, it's not identified as a "phone port" but it detected a phone on the > port. Is this the case, is there a phone on the port? > > Yes. At this time VOIP is the exception in my environment, but as luck would > have it, my guinea pig VLAN is riddled with IP phones with PCs daisy-chained. > This will likely eventually become the norm. > > OB: If for you security is more important than convenience then no matter if > a phone is present or not you should: > OB: $this->bouncePort($ifIndex); > OB: but this would have the effect of cutting a phone conversation on VLAN > re-assignment. And your phones would have to be PoE so that when it goes > down, the PC port goes down and so the client would OB: do DHCP and obtain > correct VLAN information because of the link change. > > That should be fine for now (and for my implementation maybe permanently). I > will not be using violations aggressively and most times the PCs will be > deployed pre-registered, so in practice bouncing ports will not be too > common. For my proof-of-concept, I don't want to have to manually bounce a > port or unplug or reboot after I have registered -- it would just not look > that slick. This should be much more elegant. > > OB: Fresh ideas to improve the "VoIP with a PC behind" situation would be > really appreciated! > > Well, I have been using the IOS command "clear authentication session mac > xxxx.xxxx.xxxx" to get the job done, but that is not perfect...without a > linkdown the client still does not know to request DHCP.
We plan to implement RADIUS Change of Authorization in the near future and it will have the exact same effect as the 'clear auth session...'. The improvement is that *at least* the VLAN will be re-evaluated but as you said the client will still be in a bad state... > Perhaps bouncing the port, while imperfect, is the only way to reliably > inform the client of a change, especially when you are doing MAB and the > client is completely out of the loop otherwise. Would this be a better > default behavior than what you are doing now? I think security wins over the > minor disruption to telephone service and I would personally not prefer to > run on hacked code, but I yield to the needs of the many. > I just changed the behavior to bounce no matter if a VoIP is present or not in our stable branch. I agree that it is a better thing to do in the current situation. Cheers! -- Olivier Bilodeau [email protected] :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
