Flag "no-multiline" not working on Syslog-ng
Hello community, I have the following diagram between some PE and Syslog-ng: Cisco devices -> Syslog-ng (running on Solaris) Syslog-ng version: o NTPSYSLOG# syslog-ng -V o syslog-ng 3.0.4 o Revision: ssh+git://bazsi@git.balabit //var/scm/git/syslog-ng/syslog-ng-ose--mainline--3.0#master#1b5d618e301ad94aa20e692ffba16469dece8d10 o Compile-Date: Sep 2 2009 06:15:53 o Enable-Threads: off o Enable-Debug: off o Enable-GProf: off o Enable-Memtrace: off o Enable-Sun-STREAMS: on o Enable-Sun-Door: on o Enable-IPv6: on o Enable-Spoof-Source: on o Enable-TCP-Wrapper: off o Enable-SSL: on o Enable-SQL: off o Enable-Linux-Caps: off o Enable-Pcre: on One of the cisco devices sends a particular log line that is splited in two lines (there is a line-break in between): *Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1)* * received in update for prefix XXXX:XXXX:XXX.XXX.XXX.X/XXX from X.X.X.X* When the log reaches the Syslog-ng on Solaris server, it is logged like this: *Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1)* *Mar 13 10:33:14 PE06PVAL01 1182435: received in update for prefix XXXX:XXXX:XXX.XXX.XXX.X/XXX from X.X.X.X* The log is transfered by UDP from the cisco device to the Solaris server (where the syslog-ng runs). This is the configuration used in syslog-ng: *ntpsyslog> more /etc/syslog-ng/syslog-ng.conf* *@version: 3.0* *#* *# syslog-ng configuration file.* *#* *# See syslog-ng(8) and syslog-ng.conf(5) for more information.* *#* *options {* * stats_freq (0);* * flush_lines (0);* * time_reopen (10);* * log_fifo_size (1000);* * long_hostnames(off);* * use_dns (yes);* * use_fqdn (no);* * create_dirs (no);* * keep_hostname (yes);* * perm(0640);* *};* *source s_sys { sun-streams ("/dev/log" door("/etc/.syslog_door")); internal(); udp(flags("no-multi-line")); };* *destination d_cons { file("/dev/console"); };* *destination d_mesg { file("/var/adm/messages"); };* *destination d_mail { file("/var/log/syslog"); };* *destination d_auth { file("/var/log/authlog"); };* *destination d_mlop { usertty("operator"); };* *destination d_mlrt { usertty("root"); };* *destination d_mlal { usertty("*"); };* *destination cisco { file("/respaldo/syslog/cisco/cisco.log"); };* *#----------------------------------------------------------------------* *# Forward to a nisip server* *#* *destination cnc-cisco { udp("X.X.X.X" port(X)); };* *#----------------------------------------------------------------------* *filter f_filter1 { level(err) or* * (level(notice) and facility (auth, kern)); };* *filter f_filter2 { level(err) or* * (facility(kern) and level(notice)) or* * (facility(daemon) and level(notice)) or* * (facility(mail) and level(crit)); };* *filter f_filter3 { level(alert) or* * (facility(kern) and level(err)) or* * (facility(daemon) and level(err)); };* *filter f_filter4 { level(alert); };* *filter f_filter5 { level(emerg); };* *filter f_filter6 { facility(kern) and level(notice); };* *filter f_filter7 { facility(mail) and level(debug); };* *#filter f_filter10 { level(alert); };* *filter f_filter9 { facility(user) and level(alert); };* *filter f_cisco { facility(local2); };* *# Alternativa* *log { source(s_sys_cisco); filter(f_cisco); destination(cisco); };* *# Alternativa* *source s_juniper { file("/respaldo/syslog/juniper/juniper.log"); };* *destination d_juniper_tcp { tcp("X.X.X.X" port(X)); };* *filter f_juniper_tcp {not match("TOPO|/kernel:|snmpd|trace_*|PING_*|BGP_*|bgp_*|repeated|task|task_connect|EVENT|received iff message|rshd|cron" value("MESSAGE* *")); };* *log { source(s_juniper); filter(f_juniper_tcp); destination(d_juniper_tcp); };* *source s_cisco { file("/respaldo/syslog/cisco/cisco.log"); };* *destination d_cisco_tcp { tcp("X.X.X.X" port(X)); };* *log { source(s_cisco); destination(d_cisco_tcp); };* *##################################* *# FWD from Syslog to CNC Cisco* *##################################* *source s_cisco { file("/respaldo/syslog/cisco/cisco.log"); };* *log {source(s_cisco); destination(cnc-cisco); };* *ntpsyslog>* I have tried different configurations in order to make the "no-multi-line" flag work. However, none of them have worked: destination cisco { file("/respaldo/syslog/cisco/cisco.log" flags(no-multi-line)); }; source s_sys { sun-streams ("/dev/log" door("/etc/.syslog_door")); internal(); udp(flags("no-multi-line")); }; If more information is required, please do not hesitate to ask for it. Thank you beforehand for your help. Alan Sam
Hi, "Alan Sam" <samsiu.a@gmail.com> írta 2015-04-28 11:51-kor:
If more information is required, please do not hesitate to ask for it.
Can you record at least one pair of logs into a pcap file? (On solaris you can use snoop instead of tcpdump, the filtering syntax is very similar, maybe the same, only the switches and options are different from tcpdump) I would look that closer. Kind regards, György Pásztor
Hello All, Thank you for your response. The protocol used is: UDP This is a screenshot that shows that Solaris (where syslog-ng) is running receives the log in two diffrent lines. Can this explain why the flag "no-multi-linme" in syslog-ng (in Solaris) is not working? Thank you so much beforehand. Best regards, Alan Sam [image: Inline image 1] On Wed, Apr 29, 2015 at 5:26 AM, PÁSZTOR György < pasztor@linux.gyakg.u-szeged.hu> wrote:
Hi,
"Alan Sam" <samsiu.a@gmail.com> írta 2015-04-28 11:51-kor:
If more information is required, please do not hesitate to ask for it.
Can you record at least one pair of logs into a pcap file? (On solaris you can use snoop instead of tcpdump, the filtering syntax is very similar, maybe the same, only the switches and options are different from tcpdump) I would look that closer.
Kind regards, György Pásztor
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Hi, On 05/07/2015 09:50 PM, Alan Sam wrote:
Hello All,
Thank you for your response.
The protocol used is: UDP
This is a screenshot that shows that Solaris (where syslog-ng) is running receives the log in two diffrent lines. Can this explain why the flag "no-multi-linme" in syslog-ng (in Solaris) is not working?
Wow, it was really 'low resolution'. Zooming in showed that there isn't any kind of UDP packet fragmentation happening (not surprising, the kernel would reassembele fragments transparently to syslog-ng) but the sender device actually splits the logs into multiple packets so syslog-ng does exactly what it should do. Yet another broken syslog implementation on Cisco's side :( I'm not aware of how such logs could get concatenated without writing an app which postprocesses the logs. Regards, Sandor
Hi, "Sandor Geller" <sandor.geller@ericsson.com> írta 2015-05-08 09:32-kor:
Wow, it was really 'low resolution'. Zooming in showed that there isn't any kind of UDP packet fragmentation happening (not surprising, the
That's what, why I asked a pcap file. It would required smaller attached file, and would gave us more info. I found a new theory, based on: 1 pic ~= 1 Mword 1 pcap ~= 1000 pic!
kernel would reassembele fragments transparently to syslog-ng) but the sender device actually splits the logs into multiple packets so syslog-ng does exactly what it should do. Yet another broken syslog implementation on Cisco's side :(
As basically all of their syslog implementation.
I'm not aware of how such logs could get concatenated without writing an app which postprocesses the logs.
That's another thing, I asked a pcap file. I gave up. Maybe there is a chance to do that with some patterndb magic, where we can "process" and "correlate", etc. Kind regards, Gyu
unsubscribe On Fri, May 8, 2015 at 1:37 AM, PÁSZTOR György < pasztor@linux.gyakg.u-szeged.hu> wrote:
Hi,
"Sandor Geller" <sandor.geller@ericsson.com> írta 2015-05-08 09:32-kor:
Wow, it was really 'low resolution'. Zooming in showed that there isn't any kind of UDP packet fragmentation happening (not surprising, the
That's what, why I asked a pcap file. It would required smaller attached file, and would gave us more info. I found a new theory, based on: 1 pic ~= 1 Mword 1 pcap ~= 1000 pic!
kernel would reassembele fragments transparently to syslog-ng) but the sender device actually splits the logs into multiple packets so syslog-ng does exactly what it should do. Yet another broken syslog implementation on Cisco's side :(
As basically all of their syslog implementation.
I'm not aware of how such logs could get concatenated without writing an app which postprocesses the logs.
That's another thing, I asked a pcap file. I gave up. Maybe there is a chance to do that with some patterndb magic, where we can "process" and "correlate", etc.
Kind regards, Gyu
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
-- *Nullius In Verba*
Hello Community, This is the cap file. Sorry for the low resol picture Thank you very much in advanced. Regards, Alan On Fri, May 8, 2015 at 5:37 AM, PÁSZTOR György < pasztor@linux.gyakg.u-szeged.hu> wrote:
Hi,
"Sandor Geller" <sandor.geller@ericsson.com> írta 2015-05-08 09:32-kor:
Wow, it was really 'low resolution'. Zooming in showed that there isn't any kind of UDP packet fragmentation happening (not surprising, the
That's what, why I asked a pcap file. It would required smaller attached file, and would gave us more info. I found a new theory, based on: 1 pic ~= 1 Mword 1 pcap ~= 1000 pic!
kernel would reassembele fragments transparently to syslog-ng) but the sender device actually splits the logs into multiple packets so syslog-ng does exactly what it should do. Yet another broken syslog implementation on Cisco's side :(
As basically all of their syslog implementation.
I'm not aware of how such logs could get concatenated without writing an app which postprocesses the logs.
That's another thing, I asked a pcap file. I gave up. Maybe there is a chance to do that with some patterndb magic, where we can "process" and "correlate", etc.
Kind regards, Gyu
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Hello Community, Thank you all for your help regarding this issue reported. We finally concluded that Cisco devide is sending the log in two different lines. Now we have a new situation regarding the syslog-ng configuration file: - A patch had to be created in order to concat the log. - The logs that arrive to the server with syslog-ng come like this: Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1) Mar 13 10:33:14 PE06PVAL01 1182435: received in update for prefix XXX:XXX:XX.X.XXX.0/24 from A.B.C.D - The patch concats the log and generates a new line that is inserted into the same cisco log file: Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1) received in update for prefix XXX:XXX:XX.X.XXX.0/24 from A.B.C.D - This new line that has the whole log line is sent to another server (let us call it Server X) with a syslog-ng tool running - On server X, i get these two log lines: Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1) Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1) received in update for prefix XXX:XXX:XX.X.XXX.0/24 from A.B.C.D The question is: Is there a way to configure the syslog-ng in Server X so that: - Discards the log line that contains "BGP-3-INVALID_MPLS: Invalid MPLS label (1)" - Accepts the log line that contains "BGP-3-INVALID_MPLS: Invalid MPLS label (1) received in update for prefix" - Accepts all other logs The syslog-ng configuration file on Server X is the following:
cat /etc/syslog-ng.conf #@version: 3.0 # syslog-ng configuration file for the server. # # See syslog-ng(8) and syslog-ng.conf(8) for more information. #
options { flush_lines (0); time_reopen (10); log_fifo_size (10000); long_hostnames (off); use_dns (yes); create_dirs (yes); keep_hostname (yes); }; # Client Source source s_local { internal(); }; source s_syslog_udp { udp(port(514)); }; # Server Source source s_juniper_tcp { tcp(port(1001) keep-alive(yes)); }; source s_cisco_tcp { tcp(port(1002) keep-alive(yes)); }; # Client Destination destination d_local { file("/var/adm/syslog/syslog-ng.log"); }; destination d_juniper_tcp { file("/var/adm/syslog/juniper.log"); }; destination d_cisco_tcp { file("/var/adm/syslog/cisco.log"); }; # Server Destination destination d_syslog { file("/var/adm/syslog/syslog.log"); }; destination d_mail { file("/var/adm/syslog/mail.log"); }; # Server Filter filter f_mail { facility(mail) and level(debug .. emerg); }; filter f_syslog { level(info .. emerg) and not facility(mail) and not program(syslog-ng); }; filter f_syslog-ng { program(syslog-ng); }; # Client Log log { source(s_local); destination(d_local); destination(d_syslog); }; log { source(s_syslog_udp); destination(d_syslog); }; # Server Log log { source(s_local); filter(f_syslog-ng); destination(d_syslog); }; log { source(s_local); filter(f_mail); destination(d_mail); }; log { source(s_local); filter(f_syslog); destination(d_syslog); }; log { source(s_juniper_tcp); destination(d_juniper_tcp); }; log { source(s_cisco_tcp); destination(d_cisco_tcp); }; Thank you so much for your help. Best regards, Alan On Fri, May 8, 2015 at 5:37 AM, PÁSZTOR György < pasztor@linux.gyakg.u-szeged.hu> wrote:
Hi,
"Sandor Geller" <sandor.geller@ericsson.com> írta 2015-05-08 09:32-kor:
Wow, it was really 'low resolution'. Zooming in showed that there isn't any kind of UDP packet fragmentation happening (not surprising, the
That's what, why I asked a pcap file. It would required smaller attached file, and would gave us more info. I found a new theory, based on: 1 pic ~= 1 Mword 1 pcap ~= 1000 pic!
kernel would reassembele fragments transparently to syslog-ng) but the sender device actually splits the logs into multiple packets so syslog-ng does exactly what it should do. Yet another broken syslog implementation on Cisco's side :(
As basically all of their syslog implementation.
I'm not aware of how such logs could get concatenated without writing an app which postprocesses the logs.
That's another thing, I asked a pcap file. I gave up. Maybe there is a chance to do that with some patterndb magic, where we can "process" and "correlate", etc.
Kind regards, Gyu
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Hi, What kind of patch is this? It patches syslog-ng or it changes the file? How does that work? On the server side you can of course use filters to achieve the filtering you want, using something along the lines of: filter f_brokencisco { not message("<regexp>"); }; And then attaching this filter to your logpath. But it seems easier to fix the message earlier. On May 18, 2015 9:26 PM, "Alan Sam" <samsiu.a@gmail.com> wrote:
Hello Community,
Thank you all for your help regarding this issue reported.
We finally concluded that Cisco devide is sending the log in two different lines.
Now we have a new situation regarding the syslog-ng configuration file:
- A patch had to be created in order to concat the log.
- The logs that arrive to the server with syslog-ng come like this: Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1) Mar 13 10:33:14 PE06PVAL01 1182435: received in update for prefix XXX:XXX:XX.X.XXX.0/24 from A.B.C.D - The patch concats the log and generates a new line that is inserted into the same cisco log file: Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1) received in update for prefix XXX:XXX:XX.X.XXX.0/24 from A.B.C.D
- This new line that has the whole log line is sent to another server (let us call it Server X) with a syslog-ng tool running
- On server X, i get these two log lines: Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1) Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1) received in update for prefix XXX:XXX:XX.X.XXX.0/24 from A.B.C.D
The question is: Is there a way to configure the syslog-ng in Server X so that: - Discards the log line that contains "BGP-3-INVALID_MPLS: Invalid MPLS label (1)" - Accepts the log line that contains "BGP-3-INVALID_MPLS: Invalid MPLS label (1) received in update for prefix" - Accepts all other logs
The syslog-ng configuration file on Server X is the following:
cat /etc/syslog-ng.conf #@version: 3.0 # syslog-ng configuration file for the server. # # See syslog-ng(8) and syslog-ng.conf(8) for more information. #
options { flush_lines (0); time_reopen (10); log_fifo_size (10000); long_hostnames (off); use_dns (yes); create_dirs (yes); keep_hostname (yes); };
# Client Source source s_local { internal(); }; source s_syslog_udp { udp(port(514)); };
# Server Source source s_juniper_tcp { tcp(port(1001) keep-alive(yes)); }; source s_cisco_tcp { tcp(port(1002) keep-alive(yes)); };
# Client Destination destination d_local { file("/var/adm/syslog/syslog-ng.log"); }; destination d_juniper_tcp { file("/var/adm/syslog/juniper.log"); }; destination d_cisco_tcp { file("/var/adm/syslog/cisco.log"); };
# Server Destination destination d_syslog { file("/var/adm/syslog/syslog.log"); }; destination d_mail { file("/var/adm/syslog/mail.log"); };
# Server Filter filter f_mail { facility(mail) and level(debug .. emerg); }; filter f_syslog { level(info .. emerg) and not facility(mail) and not program(syslog-ng); }; filter f_syslog-ng { program(syslog-ng); };
# Client Log log { source(s_local); destination(d_local); destination(d_syslog); }; log { source(s_syslog_udp); destination(d_syslog); };
# Server Log log { source(s_local); filter(f_syslog-ng); destination(d_syslog); }; log { source(s_local); filter(f_mail); destination(d_mail); }; log { source(s_local); filter(f_syslog); destination(d_syslog); }; log { source(s_juniper_tcp); destination(d_juniper_tcp); }; log { source(s_cisco_tcp); destination(d_cisco_tcp); };
Thank you so much for your help.
Best regards, Alan
On Fri, May 8, 2015 at 5:37 AM, PÁSZTOR György < pasztor@linux.gyakg.u-szeged.hu> wrote:
Hi,
"Sandor Geller" <sandor.geller@ericsson.com> írta 2015-05-08 09:32-kor:
Wow, it was really 'low resolution'. Zooming in showed that there isn't any kind of UDP packet fragmentation happening (not surprising, the
That's what, why I asked a pcap file. It would required smaller attached file, and would gave us more info. I found a new theory, based on: 1 pic ~= 1 Mword 1 pcap ~= 1000 pic!
kernel would reassembele fragments transparently to syslog-ng) but the sender device actually splits the logs into multiple packets so syslog-ng does exactly what it should do. Yet another broken syslog implementation on Cisco's side :(
As basically all of their syslog implementation.
I'm not aware of how such logs could get concatenated without writing an app which postprocesses the logs.
That's another thing, I asked a pcap file. I gave up. Maybe there is a chance to do that with some patterndb magic, where we can "process" and "correlate", etc.
Kind regards, Gyu
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Hello Alan, "Alan Sam" <samsiu.a@gmail.com> írta 2015-05-18 16:26-kor:
Now we have a new situation regarding the syslog-ng configuration file:
- A patch had to be created in order to concat the log.
What would you patch? Do you think that is that neccessary? As I already wrote: I think, it can be solved with some smart patterndb rule. I already collected some types of cisco logs, since I worked with many Cisco devices earlier, and I know they are not to strict following any rule or rfc about logging. So, I think the ultimate weapon is patterndb, and as soon as I will have free time, I will create patterndb for cisco devices. But I can not promise you a deadline. How urgent is this log concatenation project for you? Some extra question: How extreme is the line breaking? Your log example was the first I saw. (However, I did not configured bgp on cisco yet, I usually worked with rip, when we needed dynamic routing. I worked with "internal" networks, and did not worked with border gateways) So, In your example the one log was splitted into two lines. Is that possible, that it can splitted into more lines? Kind regards, Gyu
Hello Gyu, *What would you patch?Do you think that is that neccessary?* The patch that has already been installed and what it does is the following: - Look for the logs that contain this String "%BGP-3-INVALID_MPLS: Invalid MPLS label (1)" in the cisco.log file. For example, this could be one match: "Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1)" - Look for the corresponding next line for the line found in the step before. For example, this is the log line for the log mentioned before: "Mar 13 10:33:14 PE06PVAL01 1182435: received in update for prefix 16629:1735:A.B.C.D/24 from X.X.X.X" - Generate a new line and print it in the cisco.log file. For the example, the new line would be: "Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1) received in update for prefix 16629:1735:A.B.C.D/24 from X.X.X.X" - The syslog-ng running on the Server A will send the complete line to another server (Server B) who is listening to all logs coming from Server A Yes, I do think it was necessary. *How urgent is this log concatenation project for you?* For the time being the patch is working well. However, i still need to implement the filter in syslog-ng on Server B so that the line is discarded: Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1) And this line is accepted: Mar 13 10:33:14 PE06PVAL01 1182434: Mar 13 10:33:13: %BGP-3-INVALID_MPLS: Invalid MPLS label (1) received in update for prefix 16629:1735:A.B.C.D/24 from X.X.X.X" It is not urgent. However, if you could tell me how to configure the filter in Syslog-ng; i would greatly appreciate it. *Some extra question: How extreme is the line breaking? Your log example wasthe first I saw. (However, I did not configured bgp on cisco yet, I usuallyworked with rip, when we needed dynamic routing. I worked with "internal"networks, and did not worked with border gateways)* I understand that the line breaking is NOT extreme. Besides, this problem happens for only ONE log out of all the logs that arrive to the Syslog-ng server *So, In your example the one log was splitted into two lines.Is that possible, that it can splitted into more lines?* It could be splitted into more lines. Nonetheless, what i need is to generate a single line which i was already able to do by running the patch we created. Thank you so much for your help and attention. Best regards, Alan On Tue, May 19, 2015 at 5:01 AM, PÁSZTOR György < pasztor@linux.gyakg.u-szeged.hu> wrote:
Hello Alan,
"Alan Sam" <samsiu.a@gmail.com> írta 2015-05-18 16:26-kor:
Now we have a new situation regarding the syslog-ng configuration file:
- A patch had to be created in order to concat the log.
What would you patch? Do you think that is that neccessary?
As I already wrote: I think, it can be solved with some smart patterndb rule. I already collected some types of cisco logs, since I worked with many Cisco devices earlier, and I know they are not to strict following any rule or rfc about logging. So, I think the ultimate weapon is patterndb, and as soon as I will have free time, I will create patterndb for cisco devices.
But I can not promise you a deadline.
How urgent is this log concatenation project for you?
Some extra question: How extreme is the line breaking? Your log example was the first I saw. (However, I did not configured bgp on cisco yet, I usually worked with rip, when we needed dynamic routing. I worked with "internal" networks, and did not worked with border gateways) So, In your example the one log was splitted into two lines. Is that possible, that it can splitted into more lines?
Kind regards, Gyu
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
participants (5)
-
Alan Sam
-
PÁSZTOR György
-
Sandor Geller
-
Scheidler, Balázs
-
VMI X