From: Thrill5 on 6 May 2008 20:16 You can't prevent this from happening when you replicate the log FILES, but you can when you configure the primary also log to the secondary. "Daniel Alex" <xiance78(a)vostroen.e4ward.com> wrote in message news:fvpba6$2tj$1(a)aioe.org... > Hi, > > I still need the log replication. However, I want to know how to prevent > the secondary ACS to produce similar log files (as shown below) after > performing replication. > > RADIUS Accounting 2008-05-02.csv > RADIUS Accounting 2008-05-02(00-00-33).csv > > It always happened whenever the primary ACS performed replication towards > secondary ACS. I wonder, after the replication complete on secondary ACS, > why it needs to create a new log instead of using the current log at that > day. > > Thanks. > > "Thrill5" <nospam(a)somewhere.com> wrote in message > news:hOOdndZ2-pL6ToLVnZ2dnUVZ_jydnZ2d(a)comcast.com... >> Disable log replication, and configure the primary to also log to the >> secondary. When done this way, as each message is logged, it is >> immediately sent to the secondary server, and both logs are always up to >> date. Don't remember how to do this off the top of my head and if you >> don't find where to set this up, post a reply. >> >> "Daniel Alex" <xiance78(a)vostroen.e4ward.com> wrote in message >> news:fvmfa8$p9q$1(a)aioe.org... >>> Hi All, >>> >>> Good day everyone, I have a problem with ACS's logging and I hope anyone >>> who had similar experience could help me on this issues. >>> >>> We have two ACS on our network (primary & secondary). All our dial-up >>> customer are authenticated on primary ACS and the secondary ACS is only >>> serves as a backup ONLY when the primary ACS is fail or out of service. >>> User databases and groups including certain security & network >>> configurations are replicated to secondary ACS on daily basis (every 24 >>> hours). The logging for configuration for each ACS reports (Failed >>> Attempts, Passed Authentication, RADIUS Accounting and etc) are also >>> configured to daily basis. So far, the operational status for both are >>> fine but I found out the logging files on secondary ACS has an extra ACS >>> report which ends with "(HH-MM-SS).csv", for example, RADIUS Accounting >>> 2008-05-02(00-00-33).csv. This happens whenever the secondary ACS are in >>> replication mode and receives updates from primary ACS after every 24 >>> hours. >>> >>> In a day, the secondary ACS generates two identical ACS reports, with >>> and without '(HH-MM-SS)'. Example ACS reports generated by secondary >>> ACS; >>> >>> RADIUS Accounting 2008-05-02.csv >>> RADIUS Accounting 2008-05-02(00-00-33).csv >>> >>> It only happens on secondary ACS but not in primary ACS, although in my >>> understanding, whenever ACS in replication mode, all ACS services will >>> be temporarily suspended and return to operational once the replication >>> mode is completed. Our billing software is customized only to process >>> those normal ACS reports (logs) but not those ends with "(HH-MM-SS).csv" >>> and we have to manually extrack the content and merge it with the >>> current reports. We did not having this problem in our previous ACS >>> version 3.2 until we had upgraded our service recently. >>> >>> Question: How do I overcome this issue? Any workaround? >>> >>> Thank you very much! >>> >>> Regards, >>> >>> Daniel >>> >> >> >
From: Daniel Alex on 6 May 2008 22:07 Okay. I will test it. Thanks. "Thrill5" <nospam(a)somewhere.com> wrote in message news:V7ydnWL61-9xab3VnZ2dnUVZ_tajnZ2d(a)comcast.com... > You can't prevent this from happening when you replicate the log FILES, > but you can when you configure the primary also log to the secondary. > > "Daniel Alex" <xiance78(a)vostroen.e4ward.com> wrote in message > news:fvpba6$2tj$1(a)aioe.org... >> Hi, >> >> I still need the log replication. However, I want to know how to prevent >> the secondary ACS to produce similar log files (as shown below) after >> performing replication. >> >> RADIUS Accounting 2008-05-02.csv >> RADIUS Accounting 2008-05-02(00-00-33).csv >> >> It always happened whenever the primary ACS performed replication towards >> secondary ACS. I wonder, after the replication complete on secondary ACS, >> why it needs to create a new log instead of using the current log at that >> day. >> >> Thanks. >> >> "Thrill5" <nospam(a)somewhere.com> wrote in message >> news:hOOdndZ2-pL6ToLVnZ2dnUVZ_jydnZ2d(a)comcast.com... >>> Disable log replication, and configure the primary to also log to the >>> secondary. When done this way, as each message is logged, it is >>> immediately sent to the secondary server, and both logs are always up to >>> date. Don't remember how to do this off the top of my head and if you >>> don't find where to set this up, post a reply. >>> >>> "Daniel Alex" <xiance78(a)vostroen.e4ward.com> wrote in message >>> news:fvmfa8$p9q$1(a)aioe.org... >>>> Hi All, >>>> >>>> Good day everyone, I have a problem with ACS's logging and I hope >>>> anyone who had similar experience could help me on this issues. >>>> >>>> We have two ACS on our network (primary & secondary). All our dial-up >>>> customer are authenticated on primary ACS and the secondary ACS is only >>>> serves as a backup ONLY when the primary ACS is fail or out of service. >>>> User databases and groups including certain security & network >>>> configurations are replicated to secondary ACS on daily basis (every 24 >>>> hours). The logging for configuration for each ACS reports (Failed >>>> Attempts, Passed Authentication, RADIUS Accounting and etc) are also >>>> configured to daily basis. So far, the operational status for both are >>>> fine but I found out the logging files on secondary ACS has an extra >>>> ACS report which ends with "(HH-MM-SS).csv", for example, RADIUS >>>> Accounting 2008-05-02(00-00-33).csv. This happens whenever the >>>> secondary ACS are in replication mode and receives updates from primary >>>> ACS after every 24 hours. >>>> >>>> In a day, the secondary ACS generates two identical ACS reports, with >>>> and without '(HH-MM-SS)'. Example ACS reports generated by secondary >>>> ACS; >>>> >>>> RADIUS Accounting 2008-05-02.csv >>>> RADIUS Accounting 2008-05-02(00-00-33).csv >>>> >>>> It only happens on secondary ACS but not in primary ACS, although in my >>>> understanding, whenever ACS in replication mode, all ACS services will >>>> be temporarily suspended and return to operational once the replication >>>> mode is completed. Our billing software is customized only to process >>>> those normal ACS reports (logs) but not those ends with >>>> "(HH-MM-SS).csv" and we have to manually extrack the content and merge >>>> it with the current reports. We did not having this problem in our >>>> previous ACS version 3.2 until we had upgraded our service recently. >>>> >>>> Question: How do I overcome this issue? Any workaround? >>>> >>>> Thank you very much! >>>> >>>> Regards, >>>> >>>> Daniel >>>> >>> >>> >> > >
From: Thrill5 on 5 May 2008 23:41 Disable log replication, and configure the primary to also log to the secondary. When done this way, as each message is logged, it is immediately sent to the secondary server, and both logs are always up to date. Don't remember how to do this off the top of my head and if you don't find where to set this up, post a reply. "Daniel Alex" <xiance78(a)vostroen.e4ward.com> wrote in message news:fvmfa8$p9q$1(a)aioe.org... > Hi All, > > Good day everyone, I have a problem with ACS's logging and I hope anyone > who had similar experience could help me on this issues. > > We have two ACS on our network (primary & secondary). All our dial-up > customer are authenticated on primary ACS and the secondary ACS is only > serves as a backup ONLY when the primary ACS is fail or out of service. > User databases and groups including certain security & network > configurations are replicated to secondary ACS on daily basis (every 24 > hours). The logging for configuration for each ACS reports (Failed > Attempts, Passed Authentication, RADIUS Accounting and etc) are also > configured to daily basis. So far, the operational status for both are > fine but I found out the logging files on secondary ACS has an extra ACS > report which ends with "(HH-MM-SS).csv", for example, RADIUS Accounting > 2008-05-02(00-00-33).csv. This happens whenever the secondary ACS are in > replication mode and receives updates from primary ACS after every 24 > hours. > > In a day, the secondary ACS generates two identical ACS reports, with and > without '(HH-MM-SS)'. Example ACS reports generated by secondary ACS; > > RADIUS Accounting 2008-05-02.csv > RADIUS Accounting 2008-05-02(00-00-33).csv > > It only happens on secondary ACS but not in primary ACS, although in my > understanding, whenever ACS in replication mode, all ACS services will be > temporarily suspended and return to operational once the replication mode > is completed. Our billing software is customized only to process those > normal ACS reports (logs) but not those ends with "(HH-MM-SS).csv" and we > have to manually extrack the content and merge it with the current > reports. We did not having this problem in our previous ACS version 3.2 > until we had upgraded our service recently. > > Question: How do I overcome this issue? Any workaround? > > Thank you very much! > > Regards, > > Daniel >
From: Daniel Alex on 6 May 2008 06:18 Hi, I still need the log replication. However, I want to know how to prevent the secondary ACS to produce similar log files (as shown below) after performing replication. RADIUS Accounting 2008-05-02.csv RADIUS Accounting 2008-05-02(00-00-33).csv It always happened whenever the primary ACS performed replication towards secondary ACS. I wonder, after the replication complete on secondary ACS, why it needs to create a new log instead of using the current log at that day. Thanks. "Thrill5" <nospam(a)somewhere.com> wrote in message news:hOOdndZ2-pL6ToLVnZ2dnUVZ_jydnZ2d(a)comcast.com... > Disable log replication, and configure the primary to also log to the > secondary. When done this way, as each message is logged, it is > immediately sent to the secondary server, and both logs are always up to > date. Don't remember how to do this off the top of my head and if you > don't find where to set this up, post a reply. > > "Daniel Alex" <xiance78(a)vostroen.e4ward.com> wrote in message > news:fvmfa8$p9q$1(a)aioe.org... >> Hi All, >> >> Good day everyone, I have a problem with ACS's logging and I hope anyone >> who had similar experience could help me on this issues. >> >> We have two ACS on our network (primary & secondary). All our dial-up >> customer are authenticated on primary ACS and the secondary ACS is only >> serves as a backup ONLY when the primary ACS is fail or out of service. >> User databases and groups including certain security & network >> configurations are replicated to secondary ACS on daily basis (every 24 >> hours). The logging for configuration for each ACS reports (Failed >> Attempts, Passed Authentication, RADIUS Accounting and etc) are also >> configured to daily basis. So far, the operational status for both are >> fine but I found out the logging files on secondary ACS has an extra ACS >> report which ends with "(HH-MM-SS).csv", for example, RADIUS Accounting >> 2008-05-02(00-00-33).csv. This happens whenever the secondary ACS are in >> replication mode and receives updates from primary ACS after every 24 >> hours. >> >> In a day, the secondary ACS generates two identical ACS reports, with and >> without '(HH-MM-SS)'. Example ACS reports generated by secondary ACS; >> >> RADIUS Accounting 2008-05-02.csv >> RADIUS Accounting 2008-05-02(00-00-33).csv >> >> It only happens on secondary ACS but not in primary ACS, although in my >> understanding, whenever ACS in replication mode, all ACS services will be >> temporarily suspended and return to operational once the replication mode >> is completed. Our billing software is customized only to process those >> normal ACS reports (logs) but not those ends with "(HH-MM-SS).csv" and we >> have to manually extrack the content and merge it with the current >> reports. We did not having this problem in our previous ACS version 3.2 >> until we had upgraded our service recently. >> >> Question: How do I overcome this issue? Any workaround? >> >> Thank you very much! >> >> Regards, >> >> Daniel >> > >
|
Pages: 1 Prev: automating username/password when ssh to cisco router Next: Policy Based Routing and/or NAT |