0000753: Handle switch migrations cleanly - PacketFence

Bug Tracking System

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000753

PacketFence

core

public

2009-07-21 09:31

2015-02-13 15:42

Reporter

obilodeau

Assigned To

Priority

normal

Severity

feature

Reproducibility

N/A

Status

closed

Resolution

open

Platform

OS Version

Product Version

Target Version

Fixed in Version

Summary

0000753: Handle switch migrations cleanly

Description

Right now when you add / migrate switches, you need to issue SQL queries by hand to close open locationlog entries. There should be a mechanism that handles that.

Additional Information

Mailing list post:
==========

Hi Matt,

you could do 1 or 2 as you want but, prior to do it (in order to
avoid any issue with PF), you should close all the open entries in the
locationlog table.

if you are not familiar with sql, you should execute something like:
UPDATE locationlog SET end_time = now() WHERE switch = 'a.b.c.d' AND
(ISNULL(end_time) or end_time = 0

We'll soon add a mechanism in PF in order to manage these situations.

Regis

On 2-Jul-09, at 1:58 PM, Matt Ashfield wrote:

> > Hi
> >
> > We are in the process of removing some network switches and
> > installing new ones. This results in two possibilities:
> >
> > 1. The new switches go in and use the same ip address as the
> > old switches
> > 2. The new switches go in and use NEW ip addresses.
> >
> > I’m wondering what we should be doing as far as packetfence is
> > concerned. In the case of option 1, the board/port indexes may be
> > off because for example, we may be removing a stack of 2 24-port
> > switches (with a single stack ip address) and replace it with 1 -48
> > port switch.
> >
> > In the case of 2, should we leave the ip address entries in
> > switches.conf for the old switches?
> >
> > Any advice is appreciated. We made some changes (using 2, but
> > removing the old switches from switches.conf) the other day and it
> > caused problems for users. We saw errors similar to:
> > thread 24: secureMacAddrViolation trap already in the queue for
> > 13.22.215.254 ifIndex 10. Won't add another one
> > (main::signalHandlerTrapListQueued)
> >
> > Cheers
> >
> > Matt
> >

Tags

No tags attached.

fixed in git revision

fixed in mtn revision

Attached Files

Relationships

Notes
(0003840) lmunro (administrator) 2015-02-13 15:42	These bugs have been sitting untouched since 2012. Closing them and possibly reopening in github tracker where relevant.

Issue History
Date Modified	Username	Field	Change
2009-07-21 09:31	obilodeau	New Issue
2009-07-21 09:31	obilodeau	Summary	Handle swich migrations cleanly => Handle switch migrations cleanly
2009-07-21 09:32	obilodeau	Additional Information Updated
2011-01-18 12:02	obilodeau	Target Version	=> 2.1.0
2011-03-03 15:15	obilodeau	Target Version	2.1.0 => +1
2011-03-03 15:19	obilodeau	Target Version	+1 => +2
2012-02-29 10:58	obilodeau	Category	future => core
2015-02-13 15:42	lmunro	Note Added: 0003840
2015-02-13 15:42	lmunro	Status	new => closed