[syslog-ng] syslog-ng multiple VRF

[Balazs Scheidler]

With more reading all we would need to support vfrs is to support binding
via the name of the interface (eg. SO_BINDTODEVICE). Do you also have a
use-case where you want a source that listens in for all vrf? With that we
would need to support IP_PKTINFO and retrieve the vrf ifindex. We recently
merged support for DESTIP which has pretty similar needs so i would say the
infrastructure is already there.

The first is almost trivial. The second is a bit more involved.


On Thu, Aug 6, 2020, 22:00 Alexandre Santos <
alexandre.rosas.santos at gmail.com> wrote:

> Hi,
>
> The problem that I am facing in a VRF aware system (which is working as
> syslog-ng relay) is the following:
> - I have two network interfaces eth0 and eth1.
>  - eth0 is bound to internal/default VRF, and it must receive log messages
> from an "Internal network" where some syslog-ng clients are connected.
>  - eth1 is bound to MGMT VRF, and it must send log messages to an external
> syslog-ng server.
>
> Currently, syslog-ng does not support the binding of interfaces in both
> VRFs.
> From the information I gathered:
> - Application can talk across VRF, for this to happen it has to bind the
> socket to the specific INTERFACE belonging to the different VRF.
> - If Application want use INTERFACE_ANY option they have to assign to
> specific VRF and there connectivity will be limited to that VRF.
>
> Right now, I overcome this problem by using an architecture composed of 2
> syslog-ng services:
> - one working in the default VRF, which receives messages from eth0 and
> send the messages to an unix domain socket. Like a default Debian service.
> - the other syslog-ng service is running in the MGMT VRF:
>   /sbin/ip vrf exec MGMT /usr/bin/syslog-ng -F
> --cfgfile=/etc/syslog-ng/mgmt-syslog-ng.conf
> --pidfile=/var/lib/syslog-ng/mgmt-syslog-ng.pid
> --persist-file=/var/lib/syslog-ng/mgmt-syslog-ng.persist
> --control=/var/lib/syslog-ng/mgmt-syslog-ng.ctl
>   This service reads log messages from the unix domain socket and sends it
> to the external syslog-ng server via eth1.
>
> Some documentation on VRF:
> https://cumulusnetworks.com/blog/vrf-for-linux/
>
> Cheers,
> Alex
>
>
> On Wed, Aug 5, 2020 at 11:08 PM PÁSZTOR György <
> pasztor at linux.gyakg.u-szeged.hu> wrote:
>
>> Hi,
>>
>> "Alexandre Santos" <alexandre.rosas.santos at gmail.com> írta 2020-07-24
>> 11:03-kor:
>> > Any plans to make syslog-ng VRF aware?
>>
>> Can you define your expectations as vrf-aware?
>>
>> To make things clear, I suggest to provide a pcap from two different vrfs,
>> or one pcap with two syslog packet in it, and an example what gots into
>> the
>> logfile in both case, and what would be your exepctation.
>> Or if they should not get to a logfile, than define that.
>> This kind of approach helps a lot:
>> - describe what is your current input (with examples from two different
>> vrfs)
>> - describe the behaviour what you are experiencing now (two logfile part,
>>   what you got out of the example messages)
>> - define the behaviour what you expect. (eg. another two txt files, but
>> now
>>   with the content you would see in them)
>> This is defining behaviour.
>>
>> If you copy message parts into the body of the message, that will be
>> displayed in various ways depending on the mailer.
>> I suggest for this few exceptions to use attachments.
>> I'm not aware of the mailinglist would filter attachments out.
>> A don't think one or two small pcap and txt attachment would violate coc
>> here.
>>
>> Or if you don't want to "spam" mailinglist with attachments, that is still
>> an option that you open an issue on github and attach the files there
>> Than we discuss the subject here, in that case you only have to shere the
>> link to your issue here.
>>
>> I worked with ciscos earlier, though not that deep that I had to use vrfs,
>> but still don't understand, what is your expectation here.
>> Also, if you can openly share what models / ios versions you are using, it
>> could help a lot. Eg. if that model supports ietf syslog protocol, maybe
>> we
>> don't even need to hack an old legacy format (rfc 3164), what cisco
>> implements in so creative ways that it isn't even consistent with
>> themselves.
>>
>> Cheers,
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/syslog-ng/attachments/20200806/aa26e042/attachment.html>