Ahhh, so the VLAN change process when using MAB is not a flip of the VLAN via
SNMP, but instead a forced re-authentication of the MAC? That was unclear in
the document, but certainly makes sense. I will be testing later today, but I
want to be sure I have a firm command of what I should expect to see.
I found the appropriate tidbit from the logs from my testing at that time:
Mar 21 12:39:04 pfcmd(0) INFO: pfcmd calling node_modify for xx.xx.xx.xx.xx.xx
(main::command_param)
Mar 21 12:39:04 pfcmd(0) INFO: VLAN isolation is enabled and node_modify is
part of adjustswitchportvlanreasons (main::vlan_reevaluation)
Mar 21 12:39:04 pfcmd(0) INFO: xx.xx.xx.xx.xx.xx is currentlog connected at
y.y.y.y ifIndex 154 in VLAN 800 (main::vlan_reevaluation)
Mar 21 12:39:04 pfcmd(0) INFO: MAC: xx.xx.xx.xx.xx.xx, PID: 1, Status: reg.
Returned VLAN: 40 (pf::vlan::fetchVlanForNode)
Mar 21 12:39:04 pfcmd(0) INFO: calling /usr/local/pf/bin/flip.pl for node
xx.xx.xx.xx.xx.xx (current VLAN = 800 but should be in VLAN 40)
(main::vlan_reevaluation)
Mar 21 12:39:04 flip.pl(0) INFO: flip.pl called with xx.xx.xx.xx.xx.xx (main::)
Mar 21 12:39:04 flip.pl(0) INFO: switch port for xx.xx.xx.xx.xx.xx is y.y.y.y
ifIndex 154 connection type: Wired MAC Auth (main::)
Mar 21 12:39:08 pfsetvlan(21) INFO: local (127.0.0.1) trap for switch y.y.y.y
(main::parseTrap)
Mar 21 12:39:08 pfsetvlan(1) INFO: nb of items in queue: 1; nb of threads
running: 0 (main::startTrapHandlers)
Mar 21 12:39:08 pfsetvlan(1) INFO: reAssignVlan trap received on y.y.y.y
ifIndex 154 (main::handleTrap)
Mar 21 12:39:09 pfsetvlan(1) INFO: finished (main::cleanupAfterThread)
As one would expect (seeing as it is not working), I do not see a
re-authentication immediately following this.
I am certain that shut/no shut (or even periodic re-authentication) would put
the port where it is supposed to be, but I will attempt to verify this in my
testing.
What SNMP OID should I be looking for when I perform my testing? Is there a
common reason why this forced reauth process may not be succeeding? Other SNMP
requests are clearly succeeding.
Thanks for the very quick reply...I will provide the remaining information as
soon as I can re-test (I have been using a real person's equipment to test on,
so I need to get a lab set up as to be less disruptive).
Failed to mention, but using 2.1.0 running on CentOS on VMWare.
Cisco does have the bug in its database. The ID is CSCtj56811.
Thanks,
Brent
From: Francois Gaudreault [mailto:[email protected]]
Sent: Tuesday, March 22, 2011 12:41 PM
To: [email protected]
Subject: Re: [Packetfence-users] problem flipping VLAN with multi-domain 802.1x
Hi Brent,
I am attempting to set up a proof-of-concept of Packetfence using MAC
Authentication only with a multi-domain setup (data VLAN and voice VLAN on same
port, authenticating separately). Initial authentication itself is working, as
both voice and data are initially assigned to the correct VLANs (I have set the
phones up to auto-register according to their Vendor MAC prefix, and the
computers end up in the registration VLAN. Once I mark the node as registered,
it attempts to set the VLAN but this process fails to move the workstation into
the proper VLAN. I have tested this with pfcmd_vlan. The SNMP request itself
succeeds, and while the configuration of the port changes, it does not affect
the assignment of the existing MAC on the port.
Keep in mind that with MAB , VLANs are dynamically assigned by RADIUS, so the
VLAN change is a bit different. In fact, the port VLAN is not set using the
standard "switchport access vlan" line. So my question is, how your AAA
profiles look like? do you see new RADIUS requests when you do the
registration? Can you grab some logs from the packetfence.log for the
registration part?
Also, can you provide a status of the dot1x on the port when the devices are
plugged in?
My bet is that the re-authentication command sent to the switch by SNMP is not
working. In order to validate that assumption, please do the following :
- unreg the devices
- plugged the device into the switchport, you should have the registration vlan
assigned
- register your device
- bounce the port (either sh/no sh or unplug/plug the wire)
- At this point you should be in the production network.
IOS version on the 4500 is 12.2(53)SG4. It is the (n-1) version. Latest and
greatest (54) has a bug with multi-domain authentication, and version must be
>= 12.2(50) for required features (hoping this tidbit will help others).
Thanks for the input here. Do you know if Cisco is aware of this bug, or if a
new version is now available?
Thanks.
--
Francois Gaudreault, ing. jr
[email protected]<mailto:[email protected]> :: +1.514.447.4918
(x130) :: www.inverse.ca<http://www.inverse.ca>
Inverse inc. :: Leaders behind SOGo (www.sogo.nu<http://www.sogo.nu>) and
PacketFence (www.packetfence.org<http://www.packetfence.org>)
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Packetfence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
