<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">The first is almost trivial. The second is a bit more involved.</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 6, 2020, 22:00 Alexandre Santos <<a href="mailto:alexandre.rosas.santos@gmail.com">alexandre.rosas.santos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div>Hi,</div><div><br></div><div>The problem that I am facing in a VRF aware system (which is working as syslog-ng relay) is the following:</div><div>- I have two network interfaces eth0 and eth1. <br></div><div> - eth0 is bound to internal/default VRF, and it must receive log messages from an "Internal network" where some syslog-ng clients are connected.<br></div><div> - eth1 is bound to MGMT VRF, and it must send log messages to an external syslog-ng server.</div><div><br></div><div>Currently, syslog-ng does not support the binding of interfaces in both VRFs.</div><div>From the information I gathered:<br></div><div><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif"> - Application can talk
     across VRF, for this to happen it has to bind the socket to the
     specific INTERFACE belonging to the different VRF.<span></span></span></font></span><span><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif"><br></span></font></span></span></div><div><span><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif">- If Application want use
     INTERFACE_ANY option they have to assign to specific VRF and there
     connectivity will be limited to that VRF.</span></font></span></span></div><div><br></div><div>Right now, I overcome this problem by using an architecture composed of 2 syslog-ng services:</div><div>- 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.<br></div><div>- the other syslog-ng service is running in the MGMT VRF: <br></div><div>  /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</div><div>  This service reads log messages from the unix domain socket and sends it to the external syslog-ng server via eth1.<br></div><div><br></div><div>Some documentation on VRF:</div><div><a href="https://cumulusnetworks.com/blog/vrf-for-linux/" target="_blank" rel="noreferrer">https://cumulusnetworks.com/blog/vrf-for-linux/</a></div><div><br></div><div>Cheers,</div><div>Alex<br></div><div><span><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif"></span></font></span><span></span></span><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif"></span></font></span>





</div><div><br></div>

</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 5, 2020 at 11:08 PM PÁSZTOR György <<a href="mailto:pasztor@linux.gyakg.u-szeged.hu" target="_blank" rel="noreferrer">pasztor@linux.gyakg.u-szeged.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
"Alexandre Santos" <<a href="mailto:alexandre.rosas.santos@gmail.com" target="_blank" rel="noreferrer">alexandre.rosas.santos@gmail.com</a>> írta 2020-07-24 11:03-kor:<br>
> Any plans to make syslog-ng VRF aware?<br>
<br>
Can you define your expectations as vrf-aware?<br>
<br>
To make things clear, I suggest to provide a pcap from two different vrfs,<br>
or one pcap with two syslog packet in it, and an example what gots into the<br>
logfile in both case, and what would be your exepctation.<br>
Or if they should not get to a logfile, than define that.<br>
This kind of approach helps a lot:<br>
- describe what is your current input (with examples from two different vrfs)<br>
- describe the behaviour what you are experiencing now (two logfile part,<br>
  what you got out of the example messages)<br>
- define the behaviour what you expect. (eg. another two txt files, but now<br>
  with the content you would see in them)<br>
This is defining behaviour.<br>
<br>
If you copy message parts into the body of the message, that will be<br>
displayed in various ways depending on the mailer.<br>
I suggest for this few exceptions to use attachments.<br>
I'm not aware of the mailinglist would filter attachments out.<br>
A don't think one or two small pcap and txt attachment would violate coc<br>
here.<br>
<br>
Or if you don't want to "spam" mailinglist with attachments, that is still<br>
an option that you open an issue on github and attach the files there<br>
Than we discuss the subject here, in that case you only have to shere the<br>
link to your issue here.<br>
<br>
I worked with ciscos earlier, though not that deep that I had to use vrfs,<br>
but still don't understand, what is your expectation here.<br>
Also, if you can openly share what models / ios versions you are using, it<br>
could help a lot. Eg. if that model supports ietf syslog protocol, maybe we<br>
don't even need to hack an old legacy format (rfc 3164), what cisco<br>
implements in so creative ways that it isn't even consistent with<br>
themselves.<br>
<br>
Cheers,<br>
Gyu<br>
______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" rel="noreferrer noreferrer" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" rel="noreferrer noreferrer" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" rel="noreferrer noreferrer" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
<br>
</blockquote></div>
______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" rel="noreferrer noreferrer" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" rel="noreferrer noreferrer" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" rel="noreferrer noreferrer" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
<br>
</blockquote></div>