[syslog-ng] syslog-ng multiple VRF

[Alexandre Santos]

Hi Gyu,

Yes you are right, what I want is a source where its socket is bound to the
default vrf, while a destination should bind its socket to the mgmt vrf
I think the solution that you describe: "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." is enough.

Cheers,
Alex

On Fri, Aug 7, 2020 at 1:43 AM PÁSZTOR György <
pasztor at linux.gyakg.u-szeged.hu> wrote:

> 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
>
> ______________________________________________________________________________
> 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/20200810/15dce9f6/attachment.html>