Hi, "Alexandre Santos" <alexandre.rosas.santos@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

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@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@linux.gyakg.u-szeged.hu> wrote:

...

Hi,

"Alexandre Santos" <alexandre.rosas.santos@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

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@linux.gyakg.u-szeged.hu> wrote:

> Hi,
>
> "Alexandre Santos" <alexandre.rosas.santos@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
>
>