TRex and multicast in Stateless mode

970 views
Skip to first unread message

ech...@gmail.com

unread,
Mar 12, 2018, 11:03:30 AM3/12/18
to TRex Traffic Generator
Hi,

I am currently working on L2/L3 network equipment qualifications and I'm studying TRex for a week now, to see if I can use this software tool for my situation, replacing Spirent to generate traffic.

I need to do UDP unicast and multicast streams, on L2 or L3, checking latency, bandwidth and convergence, with few or many clients simulated, and different packet sizes.

As far as I went in my tests, all my unicast tests can be made with TRex in stateless mode.
With multicast, I don't see any reference in the documentation or any example.

For my qualifications, I need to stress the DUT by simulating many multicast groups (1000+) with many clients subscribed, for several minutes (need to re-send IGMP during streams).

On my Spirent, I can create multicast groups and subscribe any client to any multicast group, then generate streams on those groups.

Do you think those kind of tests can be made using TRex? (Without creating 1000 groups by hand)

Is there a possibility to make a multicast example script?

Is there any plan to add multicast support on the stateless GUI?


Many thanks,

Emile

hanoh haim

unread,
Mar 12, 2018, 12:34:48 PM3/12/18
to ech...@gmail.com, TRex Traffic Generator
A few questions:
1) Is it possible not to answer to IGMP just resending? 
2) is it possible to setup everything with answering and enlarge the timeout 
3) What is the performance requirement?

--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To post to this group, send email to trex...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/29cc95db-8908-489f-a7fe-723986b8ec07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Hanoh
Sent from my iPhone

ech...@gmail.com

unread,
Mar 14, 2018, 10:16:20 AM3/14/18
to TRex Traffic Generator
Hi,

1. Resending IGMPv2/v3 Membership Report each <IGMP query interval> is not welcome due to the following reasons :

- IGMP Max Response Time provided by the IGMP querier into General queries won't be considered by the subscribers (TRex) and our network implement different values.
- On some networks we use a special feature which helps the network to rebuild mcast control plane as soon as a network failure occurs. Basically, the IGMP querier sends an IGMP query when a switch goes down, that helps the network to rebuild IGMP snooping entries on the new data path. If the querier goes down, the backup querier sends the query on behalf the querier. This is an Extreme Networks feature.

2. Unfortunately not because we cannot change any network configuration during the validation step of the V-model.

3. Regarding mcast performance requirements, our infrastructure hosts real-time applications with 90% of mcast flow, ~1000 > ~10000 (S,G) mcast streams depending on the project. Moreover, we have to test the maximum capacity of the network with mcast streams, therefore we must reach to maximum bit rate of uplinks -> 10Gbps with packet length = 64 bytes. But, we are well informed that it depends on the server CPU capacity (pps capacity).

we try to understand the control plane features provided by TRex. For instance, with Spirent or Ixia we use ARP control plane of each simulated IP endpoint in order to inform network devices about the location of each mac addr. When the traffic is sent, the network dataplane is ready to switch the traffic in hardware. With mcast traffic, we use IGMP control plane in order to provide information needed to the network to build IGMP snooping/PIM tables.

It seems that TRex does not really simulate IP endpoint, it just sends traffic. We would like to know if you plan to implement IGMP/ARP control plane or not ?

Thank you for considering this,

Emile


hanoh haim

unread,
Mar 14, 2018, 2:13:33 PM3/14/18
to ech...@gmail.com, TRex Traffic Generator
Hi Emil,
Thanks for the elaborated answer.
I’ve looked into IGMP RFC and you are right.
The service mode was for testing CP at scale in more low-level way (e.g setting up 100K dhcp clients in different mode).
It does not answer your need, just to make the client implement IGMP.

There is another idea we plan to implement soon that might answer your need.

We could connect full Linux stack using veth and network namespace.
This way you would be able to configure any *host* with IPv4/6/vlan/multicast/802.1x as if it was a separate Linux machine.

The pros of this method is that you have a full Linux CP stack in low speed (TCP/UDP will be @100Gb )
The Cons is that it will be limited to ~10k clients/servers and there would be a setup time.

Any thought on this?


Thanks,
Hanoh

--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To post to this group, send email to trex...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Andreas Bourges

unread,
Mar 14, 2018, 3:33:35 PM3/14/18
to TRex Traffic Generator
Hi,

I thought there will be one core dedicated to cp for server-side services like ARP,igmp,... Was really looking forward to this feature since we always have problems in network testing during failover scenarios when switches start to ARP while the STL tests are running. Worse for long-running ipv6 streams...

Regards,

Andreas

hanoh haim

unread,
Mar 15, 2018, 1:17:44 AM3/15/18
to Andreas Bourges, TRex Traffic Generator
Hi Andreas, 
thanks for the input. Are you referring to the single TRex port ip? 
in not what is the scale of clients in your case? because setup time is not high (~30 network/sec) using Linux

attaching TRex CP ports to linux will definitely solve all the timers issues that you mention and there is no scale issue there. 


thanks,
Hanoh



--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+unsubscribe@googlegroups.com.

To post to this group, send email to trex...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Andreas Bourges

unread,
Mar 15, 2018, 1:54:31 AM3/15/18
to TRex Traffic Generator
Hi Hanoch,


our use-case is still L2 STL streams using qinq.

- ~ 500 Streams
- each stream having distinct IP/IPv6 and mac addresses (running in promisc mode)
- packets sent/received with double-tagging (qinq)
- throughput is not an issue here, since each stream is only 1000 pps (size 100 bytes)

I'm not sure if I undestand the proposed feature completely - which packets would be passed to the linux CP and which ones would be handled by TRex directly? Or would all packets be sent to the linux kernel? Currently we're setting up ARP/ND Caches on our devices using the services framework. Once traffic is running and we're doing failover tests, the devices will send ARP/ND packets to discover our stream endpoints (again). This is currentl solved by having a separate stream of GARP packets, that refresh the ARP-cache on the devices, but when looking at convergence times, it always depends on the timing (when is the next GARP packets sent towards the NUT). And we can't send a high rate, since Control-Plane policing on the switches will drop too much arp traffic.

Would be great to have a solution for this problem - gave us some headache last weekend during a migration, where TRex showed a longer outage than actually happened in the network due to ARP resolution...


Thanks,

Andreas

hanoh haim

unread,
Mar 15, 2018, 3:42:53 AM3/15/18
to Andreas Bourges, TRex Traffic Generator
Hi Andreas,
Understood. The Linux veth solution started from ASTF which all the Rx packets are processed and non-TCP/UDP are forwarded anyway to CP processing (most are dropped there). In this case there is no issue.

In case of high scale STL we can configure the HW to *count* only TCP/UDP and others to forward to CP.


In your STL case, all the packets are Rx so we can do the filter forwarding to CP in SW.

To be more flexible in STL we have a more long term plan to RSS/Rx all the packets with all the cores and run eBPF filter for forwarding to CP. this way you can have scale of Rx and SW flexibility.


In your case there would be 500 veth simulating 500 clients  machines so ARP/IPv6 will work out of the box.

Setup time would be (500/30) sec,limited by the kernel.

Thanks,
Hanoh

--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.

To post to this group, send email to trex...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Andreas Bourges

unread,
Mar 15, 2018, 4:42:25 AM3/15/18
to TRex Traffic Generator
Hi Hanoch,


...sounds very promising! BTW - since we're using older VIC cards at this customer, we're running in SW mode anyway.
I have another question, but will open a new thread later on.

Thanks,

Andreas

ech...@gmail.com

unread,
Mar 15, 2018, 11:35:10 AM3/15/18
to TRex Traffic Generator
Hi Hanoh,

For now, I consider that TRex does not simulate the control plan ARP/IGMP like Spirent or IXia does. But I'll try a script to send ARP and IGMP before starting the mcast streams.
This will not sustain the IGMP membership, so I can consider configuring static Mrouter port IGMP snooping (Even if it's not recommended when performing tests).

Finally, using namespaces with TRex can be worthwile, and I'll look towards it.


Thanks for answering my questions,

Emile

ech...@gmail.com

unread,
Mar 16, 2018, 11:12:34 AM3/16/18
to TRex Traffic Generator
Hi,

I'm trying to send IGMP packets to the DUT with a pcap file containing only the IGMP membership report, but I don't know how to modify the group address in the IGMP header.
Using a vm, I can write in the IPv4 header to change the source address, but how can I reach the IGMP header with the field engine?

Emile

hanoh haim

unread,
Mar 17, 2018, 12:42:43 PM3/17/18
to ech...@gmail.com, TRex Traffic Generator
You should build the IGMP stream using Scapy.
FE can work by field name or offset.
Another option is to write a service plugin to simulate many clients register to multicast address.

Hanoh

--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To post to this group, send email to trex...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Chử Bá Duy

unread,
Aug 9, 2019, 12:52:56 AM8/9/19
to TRex Traffic Generator
Hi Hanoh,

regarding to IGMPv2 packet, we need to re-calculate the checksum of IGMP header
But it looks like that t-rex does not have this feature.
Can we add this feature to t-rex
Now I can use FE to change gaddr in IGMP header but checksum is not correct




On Saturday, March 17, 2018 at 11:42:43 PM UTC+7, Hanoch Haim wrote:
You should build the IGMP stream using Scapy.
FE can work by field name or offset.
Another option is to write a service plugin to simulate many clients register to multicast address.

Hanoh

On Fri, 16 Mar 2018 at 17:12 <ech...@gmail.com> wrote:
Hi,

I'm trying to send IGMP packets to the DUT with a pcap file containing only the IGMP membership report, but I don't know how to modify the group address in the IGMP header.
Using a vm, I can write in the IPv4 header to change the source address, but how can I reach the IGMP header with the field engine?

Emile

--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex...@googlegroups.com.

To post to this group, send email to trex...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/c4019700-83e1-4fc7-aa6e-404eeafe817f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
igmp.jpg

hanoh haim

unread,
Aug 9, 2019, 3:05:58 AM8/9/19
to Chử Bá Duy, TRex Traffic Generator
Hi,
Yes, we can do that for you. 
How many groups are required by your test?

Thanks
Hanoh

To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/d310a687-2526-43f4-9b78-d5bb4689bf64%40googlegroups.com.

Chử Bá Duy

unread,
Aug 9, 2019, 6:21:43 AM8/9/19
to TRex Traffic Generator
Thanks a lot for your help
I would like to test with 500 group addresses

Duy,
To unsubscribe from this group and stop receiving emails from it, send an email to trex...@googlegroups.com.

hanoh haim

unread,
Aug 9, 2019, 6:26:03 AM8/9/19
to Chử Bá Duy, TRex Traffic Generator
In that case you can add a profile with a few static streams of IGMPv3 without FE (Scapy will do the checksum calculation)  
TRex supports multi profile now so you can add the IGMP profile before the real traffic profile.

Thanks,
Hanoh

To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/37603168-c2c6-472e-955d-ec495a6a668b%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages