This is obviously help us in moving forward to our next step.
Since we have to load-balance udp packets to multiple Nifi servers for that
we use F5 BigIP load balancer. This adds one more problem to solve for us.
However, we have solved that problem in our custom Java application which
listens to UDP requests and sends acknowledgment responses in UDP back to
the calling/sender application servers.
Current approach is explained in detail below how we do it.
Currently without nifi, we have our custom Java application which is
> behind F5 Loadbalancer VIP. We use stateful and performance-based
> configuration for F5 Virtual IP. In this, we receive different SNAT IPs
> (increase count based on traffic) are sources in java application.
>
> F5 LB VIP (port 1814). -> 1st SNAT IP. -> Application servers. (port
> 1814)
-> 2nd SNAT IP -> Application
> servers. (port 1814)
-> 3rd SNAT IP -> Application
> servers. (port 1814)
>
> In this flow, our java backend sends back UDP-based acknowledgment
> response to SNAT IP and port using the same DatagramSocket (receiver port)
> . And This F5 Loadbalancer is configured in stateful mode then it knows
> where to forward out UDP response back. It means F5 LB stores the
> mapping of the calling server to our backend java application.
Below are things required to implement this approach with Nifi
1. For PutUDP processor to work for us, we need support for evaluating
expression language using the flow files attributes. ListenUDP adds the
sender IP and port to the flow file attributes. In our case, those are SNAT
ip of Loadbalancer. We need to send udp as response SNAT ip which will then
forward respective calling source applications using its stateful feature.
2. Also we are not aware of how PutUDP sends packets. As before sending
UDP, we have to bind datagram socket to one of Operating System port. Since
we were currently sending UDP responses using same port/socket that we have
received udp from F5 Load balancer. We need to figure out a similar
solution for Nifi too.
Thus, having the capability to evaluate expression language using the flow
file attributes is a plus for us.
Thanks and Regards,
Atul Saroha
Ph.No. 8447784271
On Wed, Jun 5, 2024 at 12:50 AM Jim Steinebrey <jrsteineb...@gmail.com>
wrote:
> Hi Atul,
> To clarify, would your user case work if Hostname and Port properties were
> enhanced to support evaluating expression language using the flow files?
>
> Regards,
> Jim
>
> On Jun 4, 2024, at 8:41 AM, Atul Saroha <atul...@gmail.com> wrote:
>
> Hi All,
>
> We recently started using nifi for the last 6 months. We are trying to
> figure out an approach to one of our problems.
>
> Our application receives UDP packets which are RADIUS packets
> <https://networkradius.com/doc/3.0.10/concepts/introduction/AAA.html> .
> Our flow is to receive such packets through UDP and send response in UDP
> for every packet we receive. For receiving, we are using ListenUDP and then
> put these records to Kafka.
> However to send responses, we need to use attributes which are set by the
> ListenUdp processor, i.e. udp.sender and udp.post. As There multiple
> source system who are sending such UDP packets and we have to revert
> acknowledgement responses to the sender server only using UDP.
>
>
> Nifi has a PutUdp processor which supports Expression Language. However
> as per doc it supports only variable registry.
> *Hostname*
> Destination hostname or IP address
> *Supports Expression Language: true (will be evaluated using variable
> registry only)*
> *Port*
> Destination port number
> *Supports Expression Language: true (will be evaluated using variable
> registry only)*
>
>
> Is there a way to use attributes to post back udp on sender ip address.
>
>
>
> Thanks and Regards,
> Atul Saroha
> Ph.No. 8447784271
>
>
>
