PacketFence - BTS - PacketFence | |||||
| View Issue Details | |||||
| ID | 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 | OS Version | |||
| Product Version | |||||
| Target Version | Fixed in Version | ||||
| fixed in git revision | |||||
| fixed in mtn revision | |||||
| 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. | ||||
| Steps To Reproduce | |||||
| 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. | ||||
| Relationships | |||||
| Attached Files | |||||
| 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 | ||
| Notes | |||||
|
|
|||||
|
|
||||