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