Hi Kevin,
I'll look into integrating the fix you mentioned. Do you still use the
Stacked module over the normal one? If so we might merge them.
Thanks!
On 14/09/09 1:36 PM, Kevin Manuel wrote:
> Hi,
>
> We figured this one out. In the “_authorizeMAC” subroutine of
> /usr/local/pf/lib/pf/SNMP/Nortel/BayStack5520Stacked.pm, the port and
> board index are only being calculated in the “authorize” section of the code
>
> if ($authorize) {
>
> #WARNING
>
> #HERE'S THE UGLY HACK
>
> my $portmask = hex('x3f');
>
> my $slotmask = hex('x3c0');
>
> $portIndx = ( $ifIndex & $portmask ) + 1;
>
> $boardIndx = ( $ifIndex & $slotmask ) >> 6;
>
> $portIndx--;
>
> $boardIndx++;
>
> and not in the “de-authorize” section of code (i.e. } else { ).
> Therefore no mac addresses were successfully being deleted from the mac
> security table. We added the above “UGLY HACK” to the “else” section of
> the subroutine and everything works fine.
>
> Also, we only use BayStack5520Stacked.pm for both stacked and single
> switch 55X0’s and it works fine (we don’t use BayStack5520.pm).
>
> Kevin
>
>
> *Sent:* September-11-09 10:36 AM
> *To:* [email protected]
> *Subject:* [Packetfence-users] mulitiple macs authorized on same port
>
> Hi,
>
>
> We’ve run into a few cases where multiple macs are being authorized on
> the same port and are trying to figure out why.
>
> An example is the log entries below. In this case, both mac addresses
> are authorized on ifIndex 8, so I went looking in the logs and found the
> following, repeating over and over. At first glance, it looks like a hub
> to me, but not sure why PF didn’t pick up on that.
>
> We have had a few occasions where our logs were not rotating correctly
> so we cleared the mac security tables of all switches and cleared the
> locationlog entries in mysql for all switches as well. Not sure if that
> is what has caused us this problem. We did not clear the iplogs. Below
> is the log entries:
>
> Sep 06 16:09:21 pfsetvlan(7): secureMacAddrViolation trap for MAC
> 00:22:48:0d:ef:78 on 192.168.201.254 ifIndex 8 (main::handleTrap)
>
> Sep 06 16:09:21 pfsetvlan(7): old mac 00:24:21:10:a8:40 on
> 192.168.201.254 ifIndex 8 is dead. (main::handleTrap)
>
> Sep 06 16:09:21 pfsetvlan(7): authorizing 00:22:48:0d:ef:78 (old entry
> 00:24:21:10:a8:40) at new location 192.168.201.254 ifIndex 8
> (main::handleTrap)
>
> Sep 06 16:09:27 pfsetvlan(16): secureMacAddrViolation trap for MAC
> 00:24:21:10:a8:40 on 192.168.201.254 ifIndex 8 (main::handleTrap)
>
> Sep 06 16:09:27 pfsetvlan(16): old mac 00:22:48:0d:ef:78 on
> 192.168.201.254 ifIndex 8 is dead. (main::handleTrap)
>
> Sep 06 16:09:27 pfsetvlan(16): authorizing 00:24:21:10:a8:40 (old entry
> 00:22:48:0d:ef:78) at new location 192.168.201.254 ifIndex 8
> (main::handleTrap)
>
> Sep 06 16:09:45 pfsetvlan(10): secureMacAddrViolation trap for MAC
> 00:22:48:0d:ef:78 on 192.168.201.254 ifIndex 8 (main::handleTrap)
>
> Sep 06 16:09:45 pfsetvlan(10): old mac 00:24:21:10:a8:40 on
> 192.168.201.254 ifIndex 8 is dead. (main::handleTrap)
>
> Sep 06 16:09:45 pfsetvlan(10): authorizing 00:22:48:0d:ef:78 (old entry
> 00:24:21:10:a8:40) at new location 192.168.201.254 ifIndex 8
> (main::handleTrap)
>
> Sep 06 16:09:49 pfsetvlan(2): secureMacAddrViolation trap for MAC
> 00:24:21:10:a8:40 on 192.168.201.254 ifIndex 8 (main::handleTrap)
>
> Sep 06 16:09:49 pfsetvlan(2): old mac 00:22:48:0d:ef:78 on
> 192.168.201.254 ifIndex 8 is dead. (main::handleTrap)
>
> Sep 06 16:09:49 pfsetvlan(2): authorizing 00:24:21:10:a8:40 (old entry
> 00:22:48:0d:ef:78) at new location 192.168.201.254 ifIndex 8
> (main::handleTrap)
>
> Sep 06 16:10:09 pfsetvlan(6): secureMacAddrViolation trap for MAC
> 00:22:48:0d:ef:78 on 192.168.201.254 ifIndex 8 (main::handleTrap)
>
> Sep 06 16:10:10 pfsetvlan(6): old mac 00:24:21:10:a8:40 on
> 192.168.201.254 ifIndex 8 is dead. (main::handleTrap)
>
> Sep 06 16:10:10 pfsetvlan(6): authorizing 00:22:48:0d:ef:78 (old entry
> 00:24:21:10:a8:40) at new location 192.168.201.254 ifIndex 8
> (main::handleTrap)
>
> Sep 06 16:10:15 pfsetvlan(4): secureMacAddrViolation trap for MAC
> 00:24:21:10:a8:40 on 192.168.201.254 ifIndex 8 (main::handleTrap)
>
> Sep 06 16:10:16 pfsetvlan(4): old mac 00:22:48:0d:ef:78 on
> 192.168.201.254 ifIndex 8 is dead. (main::handleTrap)
>
> Sep 06 16:10:16 pfsetvlan(4): authorizing 00:24:21:10:a8:40 (old entry
> 00:22:48:0d:ef:78) at new location 192.168.201.254 ifIndex 8
> (main::handleTrap)
>
> Sep 06 16:11:03 pfsetvlan(14): secureMacAddrViolation trap for MAC
> 00:22:48:0d:ef:78 on 192.168.201.254 ifIndex 8 (main::handleTrap)
>
> Sep 06 16:11:04 pfsetvlan(14): old mac 00:24:21:10:a8:40 on
> 192.168.201.254 ifIndex 8 is dead. (main::handleTrap)
>
> Sep 06 16:11:04 pfsetvlan(14): authorizing 00:22:48:0d:ef:78 (old entry
> 00:24:21:10:a8:40) at new location 192.168.201.254 ifIndex 8
> (main::handleTrap)
>
> Sep 06 16:11:11 pfsetvlan(9): secureMacAddrViolation trap for MAC
> 00:24:21:10:a8:40 on 192.168.201.254 ifIndex 8 (main::handleTrap)
>
> Sep 06 16:11:12 pfsetvlan(9): old mac 00:22:48:0d:ef:78 on
> 192.168.201.254 ifIndex 8 is dead. (main::handleTrap)
>
> Sep 06 16:11:12 pfsetvlan(9): authorizing 00:24:21:10:a8:40 (old entry
> 00:22:48:0d:ef:78) at new location 192.168.201.254 ifIndex 8
> (main::handleTrap)
>
> Matt Ashfield
>
> Network Analyst
>
> ITS - Communications and Network Services
>
> University of New Brunswick
>
> [email protected]
>
> 506.447.3033
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>
>
>
> _______________________________________________
> Packetfence-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
--
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)
------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Packetfence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
