<div dir="ltr"><div>Hi Gyu,</div><div><br></div><div>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</div><div>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.</div><div><br></div><div>Cheers,</div><div>Alex<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 7, 2020 at 1:43 AM PÁSZTOR György <<a href="mailto:pasztor@linux.gyakg.u-szeged.hu">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">alexandre.rosas.santos@gmail.com</a>> írta 2020-08-06 21:00-kor:<br>
> The problem that I am facing in a VRF aware system (which is working as<br>
> syslog-ng relay) is the following:<br>
> - I have two network interfaces eth0 and eth1.<br>
>  - eth0 is bound to internal/default VRF, and it must receive log messages<br>
> from an "Internal network" where some syslog-ng clients are connected.<br>
>  - eth1 is bound to MGMT VRF, and it must send log messages to an external<br>
> syslog-ng server.<br>
<br>
>From this I was thinking a totally different thing.<br>
<br>
> Currently, syslog-ng does not support the binding of interfaces in both<br>
> VRFs.<br>
<br>
This will be the key for your requested feature. At least, I think.<br>
<br>
> >From the information I gathered:<br>
> - Application can talk across VRF, for this to happen it has to bind the<br>
> socket to the specific INTERFACE belonging to the different VRF.<br>
> - If Application want use INTERFACE_ANY option they have to assign to<br>
> specific VRF and there connectivity will be limited to that VRF.<br>
> <br>
> Right now, I overcome this problem by using an architecture composed of 2<br>
> syslog-ng services:<br>
> - one working in the default VRF, which receives messages from eth0 and<br>
> send the messages to an unix domain socket. Like a default Debian service.<br>
> - the other syslog-ng service is running in the MGMT VRF:<br>
>   /sbin/ip vrf exec MGMT /usr/bin/syslog-ng -F<br>
> --cfgfile=/etc/syslog-ng/mgmt-syslog-ng.conf<br>
> --pidfile=/var/lib/syslog-ng/mgmt-syslog-ng.pid<br>
> --persist-file=/var/lib/syslog-ng/mgmt-syslog-ng.persist<br>
> --control=/var/lib/syslog-ng/mgmt-syslog-ng.ctl<br>
>   This service reads log messages from the unix domain socket and sends it<br>
> to the external syslog-ng server via eth1.<br>
<br>
And this + reply from Bazsi helped me to understand what you really want:<br>
Not cisco has two vrfs and sending logs specially crafter, like I was<br>
originally thinking. But you want to use the linux's vrfs where you are<br>
running syslog-ng. Am I right?<br>
Practically in your use-case, what you want:<br>
a source where its socket is bound to the default vrf,<br>
while a destination should bind its socket to the mgmt vrf.<br>
<br>
Am I right?<br>
<br>
Well, this is a nice interim workaround what you've already did.<br>
On linux's side I've never used vrf earlier. I simple created several<br>
routing table and used policy based routing.<br>
I assume, this is not an option in your case, that's why you are using vrf.<br>
<br>
Replying to Bazsi's concern:<br>
Baed on this document:<br>
<a href="https://www.kernel.org/doc/Documentation/networking/vrf.txt" rel="noreferrer" target="_blank">https://www.kernel.org/doc/Documentation/networking/vrf.txt</a><br>
"<br>
Design<br>
------<br>
A VRF device is created with an associated route table. Network interfaces<br>
are then enslaved to a VRF device:<br>
"<br>
<br>
If my understanding is correct, using vrfs on linux is possible this way: a<br>
network interface belongs to a specific vrf.<br>
So if I'm right, Alexandre's eth1 is in the mgmt vrf, all we have to do to<br>
provide an option to the network destination and source drivers, which<br>
allow the user to define a network interace. After the socket() call /<br>
creation the only thing is needed to call a setsockopt() with the right<br>
arguments.<br>
Though it doesn't specify the vrf but the interface. On the other hand,<br>
this is what <a href="http://kernel.org" rel="noreferrer" target="_blank">kernel.org</a>'s design document suggests.<br>
<br>
Cheers,<br>
Gyu<br>
______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" rel="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" 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" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
<br>
</blockquote></div>