Iperf 2 / Tickets / #29 Merge Noushi iperf-ssm code into next release

Robert McMahon - 2017-11-03

Ok, let me take a look. There does seem to be many users of iperf2 who need to test ip multicast.

Bob

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Beau Williamson - 2017-11-13
  
  Robert,
  
  Is this your correct email address?
  
  Beau Williamson
  
  From: Robert McMahon [mailto:rjmcmahon@users.sf.net]
  Sent: Thursday, November 2, 2017 8:54 PM
  To: [iperf2:tickets] 29@tickets.iperf2.p.re.sf.net
  Subject: [iperf2:tickets] #29 Merge Noushi iperf-ssm code into next release
  
  Ok, let me take a look. There does seem to be many users of iperf2 who need
  to test ip multicast.
  
  Bob
  
  [tickets:#29] https://sourceforge.net/p/iperf2/tickets/29/ Merge Noushi
  iperf-ssm code into next release
  
  Status: open
  Milestone: 1.0
  Labels: Multicast SSM IGMPv3 MLDv2
  Created: Wed Nov 01, 2017 02:57 PM UTC by Beau Williamson
  Last Updated: Wed Nov 01, 2017 02:57 PM UTC
  Owner: Robert McMahon
  
  Bob,
  First, thanks for your efforts keeping iperf2 going.
  
  I'd like to see you or someone merge the noushi/iperf-ssm
  http://https:/github.com/noushi/iperf-ssm code into the code base here.
  We are still trying to get SSM Multicast to have a wider adoption and the
  basic iperf2 Multicast support only does ASM Multicast. Lack of good test
  tools like iperf2 to help test SSM deployments is a further "speed-bump" to
  the adoption and use of IGMPv3/MLDv2/SSM. Given that it seems that iperf2 is
  the only good OpenSource Multicast test tool we really need to be able to
  test SSM Multicast.
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/iperf2/tickets/29/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Robert McMahon - 2017-11-27

Ok, I think I have some time to take a look at this now. Sorry for the delay. I looked at the patches and it seems fairly straight forward.

As as side note, is there an interest in integrating an IGMP/MLD querier on the client? This is needed sometimes for things like IGMP snooping. I have a very crude version that only supports an IGMPv2 querier. Adding v3 and MLD v1/2 would take a bit more work.

Bob

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Beau Williamson - 2017-11-28
  
  Bob,
  
  Yes, that would be really helpful to have full IGMPv2v3 and MLDv1v2
  functions available in iperf2. There is a general lack of test tools around
  these protocols (as far as I know of) and being able to setup performance
  tests as either the host (sending membership reports of all kinds) or the
  router (sending IGMP/MLD queries) would be awesome.
  
  For now, having full function host side IGMPv2v3 and MLDv1v2 capabilities
  would suffice. You could add the query functions later. (I know you are
  quite busy with other iperf2 work.)
  
  Thanks again for extending and keeping iperf2 going.
  
  Beau
  
  From: Robert McMahon [mailto:rjmcmahon@users.sf.net]
  Sent: Monday, November 27, 2017 5:36 PM
  To: [iperf2:tickets] 29@tickets.iperf2.p.re.sf.net
  Subject: [iperf2:tickets] #29 Merge Noushi iperf-ssm code into next release
  
  Ok, I think I have some time to take a look at this now. Sorry for the
  delay. I looked at the patches and it seems fairly straight forward.
  
  As as side note, is there an interest in integrating an IGMP/MLD querier on
  the client? This is needed sometimes for things like IGMP snooping. I have a
  very crude version that only supports an IGMPv2 querier. Adding v3 and MLD
  v1/2 would take a bit more work.
  
  Bob
  
  [tickets:#29] https://sourceforge.net/p/iperf2/tickets/29/ Merge Noushi
  iperf-ssm code into next release
  
  Status: open
  Milestone: 1.0
  Labels: Multicast SSM IGMPv3 MLDv2
  Created: Wed Nov 01, 2017 02:57 PM UTC by Beau Williamson
  Last Updated: Fri Nov 03, 2017 01:54 AM UTC
  Owner: Robert McMahon
  
  Bob,
  First, thanks for your efforts keeping iperf2 going.
  
  I'd like to see you or someone merge the noushi/iperf-ssm
  http://https:/github.com/noushi/iperf-ssm code into the code base here.
  We are still trying to get SSM Multicast to have a wider adoption and the
  basic iperf2 Multicast support only does ASM Multicast. Lack of good test
  tools like iperf2 to help test SSM deployments is a further "speed-bump" to
  the adoption and use of IGMPv3/MLDv2/SSM. Given that it seems that iperf2 is
  the only good OpenSource Multicast test tool we really need to be able to
  test SSM Multicast.
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/iperf2/tickets/29/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  Related
  
  Tickets: ~~#29~~
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Robert McMahon - 2017-11-28

on the command line interface, how does

** --ssm-source <host>%<dev>** </dev></host>

work for the long option?

on the short option, the patch used -O. Not sure if this is intuitive. Thoughts on only supporting the long option and not supporting -O?

Also, -X is being used already (for peer version exchange) and Apple uses it as well so probably best to avoid it. My thoughts are just to couple it to the --ssm-source option using the percent as shown above.

Feedback appreciated.
Bob

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Beau Williamson - 2017-11-28
  
  Bob,
  
  That long option looks good. As for a short option, it would be nice to
  have some sort of short option if there is a letter that can be used. Is
  "h" or "H" available for the source Host?
  
  Beau
  
  From: Robert McMahon [mailto:rjmcmahon@users.sf.net]
  Sent: Monday, November 27, 2017 7:12 PM
  To: [iperf2:tickets] 29@tickets.iperf2.p.re.sf.net
  Subject: [iperf2:tickets] #29 Merge Noushi iperf-ssm code into next release
  
  on the command line interface, how does
  
  --ssm-source <host>%<dev> </dev></host>
  
  work for the long option?
  
  on the short option, the patch used -O. Not sure if this is intuitive.
  Thoughts on only supporting the long option and not supporting -O?
  
  Also, -X is being used already (for peer version exchange) and Apple uses it
  as well so probably best to avoid it. My thoughts are just to couple it to
  the --ssm-source option using the percent as shown above.
  
  Feedback appreciated.
  Bob
  
  [tickets:#29] https://sourceforge.net/p/iperf2/tickets/29/ Merge Noushi
  iperf-ssm code into next release
  
  Status: open
  Milestone: 1.0
  Labels: Multicast SSM IGMPv3 MLDv2
  Created: Wed Nov 01, 2017 02:57 PM UTC by Beau Williamson
  Last Updated: Mon Nov 27, 2017 11:35 PM UTC
  Owner: Robert McMahon
  
  Bob,
  First, thanks for your efforts keeping iperf2 going.
  
  I'd like to see you or someone merge the noushi/iperf-ssm
  http://https:/github.com/noushi/iperf-ssm code into the code base here.
  We are still trying to get SSM Multicast to have a wider adoption and the
  basic iperf2 Multicast support only does ASM Multicast. Lack of good test
  tools like iperf2 to help test SSM deployments is a further "speed-bump" to
  the adoption and use of IGMPv3/MLDv2/SSM. Given that it seems that iperf2 is
  the only good OpenSource Multicast test tool we really need to be able to
  test SSM Multicast.
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/iperf2/tickets/29/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  Related
  
  Tickets: ~~#29~~
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Robert McMahon - 2017-11-28
    
    Yes, -H is available. I'll use that for the short option.
    
    The cli, supporting the device as an option, is then
    
    -B <group> -H <host>[%<dev>]</dev></host></group>
    
    This only supports joining a single group which I think is an ok limitation.
    
    If, in the future, multiple groups are needed on a per socket basis, I think we could use a comma separated list for the groups. This still assumes a single source:
    
    -H <host>[%<dev>,<group1>,<group2>, ... <groupn>]</groupn></group2></group1></dev></host>
    
    Thoughts?
    Bob
    
    Last edit: Robert McMahon 2017-11-28
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Beau Williamson - 2017-11-28
      
      Bob,
      
      We really need the ability to somehow join multiple Source,Group pairs on a
      "host" basis. This is particularly true when testing IGMPv2v3/MLDv1v2
      functionality. IGMPv3 Membership Reports (aka IGMP Joins) can contain
      multiple entries for S,G pairs. I think doing each flow on a socket basis
      is the usual method and should be sufficient as the OS will (should) handle
      keeping track of all the Joins across all the sockets and generate the
      correct IGMP/MLD packets.
      
      Beau
      
      alternate
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - Robert McMahon - 2017-11-28
        
        Hi Beau,
        
        Ok, makes sense. Then the proposal is to require an iperf server/receiver per each S,G where multiple iperf servers will be needed to meet the "multiple S,G per host" requirement. We can add script support for the "multiple S,Gs per host," i.e. multiple iperf servers, using the flows python code.
        
        Does this work?
        
        Bob
        
        Last edit: Robert McMahon 2017-11-28
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Beau Williamson - 2017-11-28
        
        Bob,
        
        Yes, as long as a single physical host can join multiple *,G or S,G
        multicast streams (via multiple iperf2 instances running under the same OS
        in the host), then we have a tool that should meet the needs of IP Multicast
        testers and experimenters. I'm not an experienced user of iperf2 so I don't
        know if there is a need to accomplish this multiple streams task via a
        "single" iperf instance or if launching multiple instances within the
        host/OS is sufficient for others. Maybe others can add their $0.02 worth.
        Otherwise, I think you have it.
        
        alternate
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Robert McMahon - 2017-11-28
        
        The only advantage I percieve to a single iperf instance is that the summing of multiple traffic threads could be done by that instance, .e.g. the aggregate traffic for all *,G and S,G to the host would be summed. If there is a script controlling multiple instances, such summing can be done by the script. From a coding perspective, it's easiest to use a controlling script and multiple iperf instances where each iperf server listens on a single *,G or a S,G.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Beau Williamson - 2017-11-28
        
        Works for me.
        
        alternate
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Robert McMahon - 2017-11-29
      
      Ok, looking a bit more at the code, it might more sense to use:
      
      -B <group>[%<dev>]</dev> [-H <ssm-host>]</ssm-host></group>
      
      this way one can still specify the receiving interface for the *,G
      
      Bob
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Robert McMahon - 2017-12-04

Ok, seems to be working for v4 and v6 on linux, supporting *,G and S,G with the optional interface specifier. Examples below (note, don't forget the -V for v6): Diff is here:

ipv4:

[rjmcmahon@rjm-fedora iperf2-code]$ src/iperf -s -u -B 239.1.1.2 -H 192.168.100.33 ------------------------------------------------------------ Server listening on UDP port 5001 Binding to local address 239.1.1.2 Joining multicast (S,G)=192.168.100.33,239.1.1.2 Receiving 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------ ^C[rjmcmahon@rjm-fedora iperf2-code]src/iperf -s -u -B 239.1.1.2%eno1 -H 192.168.100.33 ------------------------------------------------------------ Server listening on UDP port 5001 Binding to local address 239.1.1.2 Joining multicast (S,G)=192.168.100.33,239.1.1.2 w/iface eno1 Receiving 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------ ^C[rjmcmahon@rjm-fedora iperf2-code]$ src/iperf -s -u -B 239.1.1.2 -H 192.168.100.33 ------------------------------------------------------------ Server listening on UDP port 5001 Binding to local address 239.1.1.2 Joining multicast (S,G)=192.168.100.33,239.1.1.2 Receiving 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------ ^C[rjmcmahon@rjm-fedora iperf2-code]$ src/iperf -s -u -B 239.1.1.2%eno1 ------------------------------------------------------------ Server listening on UDP port 5001 Binding to local address 239.1.1.2 Joining multicast (*,G)=*,239.1.1.2 w/iface eno1 Receiving 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------ ^C[rjmcmahon@rjm-fedora iperf2-code]$ src/iperf -s -u -B 239.1.1.2 ------------------------------------------------------------ Server listening on UDP port 5001 Binding to local address 239.1.1.2 Joining multicast group 239.1.1.2 Receiving 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------

ipv6

^C[rjmcmahon@rjm-fedora iperf2-code]$ src/iperf -s -V -u -B ff1e::1%eno1 -H 2001:db8:0:f102::2 ------------------------------------------------------------ Server listening on UDP port 5001 Binding to local address ff1e::1 Joining multicast (S,G)=2001:db8:0:f102::2,ff1e::1 w/iface eno1 Receiving 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------ ^C[rjmcmahon@rjm-fedora iperf2-code]$ src/iperf -s -V -u -B ff1e::1 -H 2001:db8:0:f102::2 ------------------------------------------------------------ Server listening on UDP port 5001 Binding to local address ff1e::1 Joining multicast (S,G)=2001:db8:0:f102::2,ff1e::1 Receiving 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------ ^C[rjmcmahon@rjm-fedora iperf2-code]$ src/iperf -s -V -u -B ff1e::1%eno1 ------------------------------------------------------------ Server listening on UDP port 5001 Binding to local address ff1e::1 Joining multicast (*,G)=*,ff1e::1 w/iface eno1 Receiving 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------ ^C[rjmcmahon@rjm-fedora iperf2-code]$ src/iperf -s -V -u -B ff1e::1 ------------------------------------------------------------ Server listening on UDP port 5001 Binding to local address ff1e::1 Joining multicast group ff1e::1 Receiving 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------ ^C[rjmcmahon@rjm-fedora iperf2-code]$

Last edit: Robert McMahon 2017-12-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Beau Williamson - 2017-12-04
  
  Bob,
  
  That is awesome! There are users of Multicast rejoicing around the world as
  we speak! Now they have a good test tool for Multicast. I'm tied up with
  another project at the moment but I hope to test this out soon.
  
  Thank you.
  
  Beau Williamson
  
  aka Mr. Multicast
  
  From: Robert McMahon [mailto:rjmcmahon@users.sf.net]
  Sent: Monday, December 4, 2017 5:00 PM
  To: [iperf2:tickets] 29@tickets.iperf2.p.re.sf.net
  Subject: [iperf2:tickets] #29 Merge Noushi iperf-ssm code into next release
  
  Ok, seems to be working for v4 and v6 on linux, supporting *,G and S,G with
  the optional interface specifier. Examples below (note, don't forget the -V
  for v6):
  
  . . .
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Robert McMahon - 2017-12-04
    
    Hi Beau,
    
    Please inform me of any bugs you may hit. I did some very sparse testing and haven't run it through full testing cycles.
    
    Bob
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Beau Williamson - 2018-07-27
      
      Bob,
      
      I finally now have some time to look at iperf2 to see if the SSM code is
      working. I've downloaded the latest version (2.0.12) from SourceForge and
      it doesn't seem to have the ssm code merged into it. The help file doesn't
      show the "-O" option which is needed to specify the source of the SSM
      Multicast stream. Additionally, the code in src/Listener.cpp doesn't appear
      to have the necessary code to set the IP_ADD_SOURCE_MEMBERSHIP option needed
      to join an SSM Multicast stream. (Also, the Ticket shows pending.)
      
      What happened? I see that you sent me a private email saying you had it
      working but unfortunately at the time I was unable to do any testing. Now I
      am.
      
      Beau Williamson
      
      From: Robert McMahon rjmcmahon@users.sf.net
      Sent: Monday, December 4, 2017 5:18 PM
      To: [iperf2:tickets] 29@tickets.iperf2.p.re.sf.net
      Subject: [iperf2:tickets] Re: #29 Merge Noushi iperf-ssm code into next
      release
      
      Hi Beau,
      
      Please inform me of any bugs you may hit. I did some very sparse testing and
      haven't run it through full testing cycles.
      
      Bob
      
      [tickets:#29] https://sourceforge.net/p/iperf2/tickets/29/ Merge Noushi
      iperf-ssm code into next release
      
      Status: pending
      Milestone: 1.0
      Labels: Multicast SSM IGMPv3 MLDv2
      Created: Wed Nov 01, 2017 02:57 PM UTC by Beau Williamson
      Last Updated: Mon Dec 04, 2017 11:02 PM UTC
      Owner: Robert McMahon
      
      Bob,
      First, thanks for your efforts keeping iperf2 going.
      
      I'd like to see you or someone merge the noushi/iperf-ssm
      http://https:/github.com/noushi/iperf-ssm code into the code base here.
      We are still trying to get SSM Multicast to have a wider adoption and the
      basic iperf2 Multicast support only does ASM Multicast. Lack of good test
      tools like iperf2 to help test SSM deployments is a further "speed-bump" to
      the adoption and use of IGMPv3/MLDv2/SSM. Given that it seems that iperf2 is
      the only good OpenSource Multicast test tool we really need to be able to
      test SSM Multicast.
      
      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/iperf2/tickets/29/
      
      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/
      
      Related
      
      Tickets: ~~#29~~
      
      alternate
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - Robert McMahon - 2018-07-27
        
        Hi Beau,
        
        This wasn't a direct merge. The command line, using -H (not -O), for SSM is:
        
        -B <group>[%<dev>]</dev> [-H <ssm-host>]</ssm-host></group>
        
        this way one can still specify the receiving interface for the *,G
        
        The code uses the protocol independent MCAST_JOIN_SOURCE_GROUP (and not IP_ADD_SOURCE_MEMBERSHIP) because it is available on more platforms. This was tested on Linux, FreeBSD, Windows and OS X. Example of usage are in a previous message in this thread.
        
        I'll move the ticket to closed.
        
        Bob
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Beau Williamson - 2018-07-28
        
        Robert,
        
        I tested iperf2 on my Windows 10 machine and it is not sending the correct
        IGMPv3 message. I also did a quick test with VLC to join an SSM stream and
        it sends the correct IGMPv3 Membership Report so it doesn't appear to be an
        issue on my machine or Windows 10.
        
        I sent you a direct email about this. I'm hoping your old email address is
        still good. If you don't get the email with all the details, let me know and
        I'll send all the details here. Can you move the status back to pending
        until we get this working?
        
        Thanks.
        
        Beau
        
        From: Robert McMahon rjmcmahon@users.sourceforge.net
        Sent: Friday, July 27, 2018 6:16 PM
        To: [iperf2:tickets] 29@tickets.iperf2.p.re.sourceforge.net
        Subject: [iperf2:tickets] Re: #29 Merge Noushi iperf-ssm code into next
        release
        
        Hi Beau,
        
        This wasn't a direct merge. The command line, using -H (not -O), for SSM is:
        
        -B <group>[%<dev>]</dev> [-H <ssm-host>]</ssm-host></group>
        
        this way one can still specify the receiving interface for the *,G
        
        The code uses the protocol independent MCAST_JOIN_SOURCE_GROUP (and not
        IP_ADD_SOURCE_MEMBERSHIP) because it is available on more platforms. This
        was tested on Linux, FreeBSD, Windows and OS X. Example of usage are in a
        previous message in this thread.
        
        I'll move the ticket to closed.
        
        Bob
        
        [tickets:#29] https://sourceforge.net/p/iperf2/tickets/29/ Merge Noushi
        iperf-ssm code into next release
        
        Status: pending
        Milestone: 1.0
        Labels: Multicast SSM IGMPv3 MLDv2
        Created: Wed Nov 01, 2017 02:57 PM UTC by Beau Williamson
        Last Updated: Mon Dec 04, 2017 11:02 PM UTC
        Owner: Robert McMahon
        
        Bob,
        First, thanks for your efforts keeping iperf2 going.
        
        I'd like to see you or someone merge the noushi/iperf-ssm
        http://https:/github.com/noushi/iperf-ssm code into the code base here.
        We are still trying to get SSM Multicast to have a wider adoption and the
        basic iperf2 Multicast support only does ASM Multicast. Lack of good test
        tools like iperf2 to help test SSM deployments is a further "speed-bump" to
        the adoption and use of IGMPv3/MLDv2/SSM. Given that it seems that iperf2 is
        the only good OpenSource Multicast test tool we really need to be able to
        test SSM Multicast.
        
        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/iperf2/tickets/29/
        
        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/
        
        Related
        
        Tickets: ~~#29~~
        
        alternate
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Chance Whaley - 2019-07-27
        
        Did the issue w/ Windows not sending the correct IGMPv3 message on join ever get addressed? Running into this issue w/ 2.0.14a under Windows, confirmed with packet captures.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Robert McMahon - 2017-12-04

status: open --> pending
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Robert McMahon - 2018-07-27

status: pending --> closed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Robert McMahon - 2018-07-29

status: closed --> pending
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Robert McMahon - 2018-07-29

Need to test on windows 10 using igmp v3

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Robert McMahon - 2018-08-02

I've been able to reproduce this and am looking at possible solutions. It looks related to the linux cross compile for windows using mingw

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Merge Noushi iperf-ssm code into next release

A means to measure network responsiveness and throughput

Milestone

Searches

Help

#29 Merge Noushi iperf-ssm code into next release

Related

Discussion

Related

Related

Related

Related