Forum Discussion

Joe_B_41386's avatar
Joe_B_41386
Icon for Nimbostratus rankNimbostratus
Oct 24, 2013

iRule for UDP Netflow Duplication

I need to duplicate netflow packets to multiple destinations. The UDP Packet Duplication iApp does not work properly for me on 11.3. It seems to create a VIP listening on port 514 despite me specifying 9995 and my pool is always red/down. If i turn off strict updates, it will allow me to change it to 9995 but it still doesn't work according to packet captures.

 

Anyone have a simple solution to this?

 

Thank you,

 

Joe

 

application delivery
devops
iApps
iRules
  • Joe_B_41386's avatar
    Joe_B_41386
    Icon for Nimbostratus rankNimbostratus
    Oct 24, 2013

    I need to do this with our brand new LTMs - i have no budget for additional tools in our environment. I didn't know this was a forum for pitching third party products, but I appreciate it. Anyone else?

     

    • khamlat_316003's avatar
      khamlat_316003
      Icon for Nimbostratus rankNimbostratus
      Jun 09, 2017

      Hi Joe,

       

      We are trying to do the same thing. Did you ever get the iAPP to work or find a valuable solution for spraying and distributing all traffic to all your pool members for netflow?

       

      Please let me know!! If you can provide your rules, that would be great.

       

  • Tod_Martinsen_1's avatar
    Tod_Martinsen_1
    Icon for Nimbostratus rankNimbostratus
    Oct 24, 2013

    I'm currently working with this iAPP in an 11.4 lab environment. The iAPP works by using a unique local IPv6 address (FDF5::{vip_address}) as a sort of "loopback" for the packet replication. If you haven't configured unique local IPv6 networking in your environment, you'll experience the symptoms you describe as the first iRule doesn't have a valid IPv6 network to forward the "distribution" packet through.

     

    As a work-around, try adding an arbitrary address in (FDF5::/64) to the same interface as the primary application VIP. It worked to resolve similar issues in my lab environment, both the second VS node monitoring, and the actual forwarding of packets.

     

    I'm considering updating the iAPP to change the "distribution" VS to the link-local range as a potential fix, rather than having to add an address from the designated unique local range.

     

    The port problem on the second "distribution" VS you describe might be only cosmetic, as long as the pool member of the primary VS pool matches the address&port of the secondary VS VIP, AND the F5 has a valid way to forward the IPv6 packet, you should be able to monitor the VS and get forwarding working.

     

    Look at the Virtual Server statistics to verify that the traffic is making it from the first VS to the Second VS. You should see input traffic for both VS objects if the IPv6 forwarding is working.

     

    Let me know if adding an arbitrary IPv6 address works for you in test.