[syslog-ng] syslog-ng multiple VRF

[PÁSZTOR György]

Hi,

"Alexandre Santos" <alexandre.rosas.santos at gmail.com> írta 2020-08-06 21:00-kor:
> 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.

>From this I was thinking a totally different thing.

> Currently, syslog-ng does not support the binding of interfaces in both
> VRFs.

This will be the key for your requested feature. At least, I think.

> >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.

And this + reply from Bazsi helped me to understand what you really want:
Not cisco has two vrfs and sending logs specially crafter, like I was
originally thinking. But you want to use the linux's vrfs where you are
running syslog-ng. Am I right?
Practically in your use-case, what you want:
a source where its socket is bound to the default vrf,
while a destination should bind its socket to the mgmt vrf.

Am I right?

Well, this is a nice interim workaround what you've already did.
On linux's side I've never used vrf earlier. I simple created several
routing table and used policy based routing.
I assume, this is not an option in your case, that's why you are using vrf.

Replying to Bazsi's concern:
Baed on this document:
https://www.kernel.org/doc/Documentation/networking/vrf.txt
"
Design
------
A VRF device is created with an associated route table. Network interfaces
are then enslaved to a VRF device:
"

If my understanding is correct, using vrfs on linux is possible this way: a
network interface belongs to a specific vrf.
So if I'm right, Alexandre's eth1 is in the mgmt vrf, all we have to do to
provide an option to the network destination and source drivers, which
allow the user to define a network interace. After the socket() call /
creation the only thing is needed to call a setsockopt() with the right
arguments.
Though it doesn't specify the vrf but the interface. On the other hand,
this is what kernel.org's design document suggests.

Cheers,
Gyu