Using STLVmFlowVar on inner IP header for SRv6

[Luc Lemieux]

When using STLVmFlowVar to randomize IPs for Load Balancing the generated traffic, if you are in a SRv6 scenario you need to randomize the inner IP header since the outer header contains addresses for the current service being chained.

Also when defining STLVmFlowVar you must give the "name" of the target you want to randomize. It seems both IPv6 and IPv4 are hooked to name "ip_src", so no way to distinguish which one you want to affect (in a IPv6()/SRH()/IPv4 scenario).

We have found a work around when the outer IP header is IPv6 and inner is IPv4 because it seems that when you apply the randomization on the next step with "STLVmWrFlowVar(fv_name="ip_src", pkt_offset= ip_src_offset ))" the type of offset that you use (IPv6.src or IP.src) determines which header type it is going to find to apply the randomization. If you use the IPv6 offset it will find the header that matches the type IPv6 and then randomize, if you use the IPv4 offset it will find that one.

Problem being that in a IPv6/SRH()/IPv6() scenario, there is no way to tell STLVmFlowVar to affect the second IPv6 header. They both have the same "name" and the same type.

STLVmFlowVar does not let you apply a second model with the same "name".

A good way to do this could be to have the ability to mention the type of the previous and next headers around the one you want to randomize in order to locate it in the packet.

Is there a way that I have not seen?

The "next_var" option of STLVmFlowVar does not seem to do this, it is more to wait on this Vm to have done it's job before moving to the one defined in "next_var".

Thank you!

[hanoh haim]

Hi Luc, 

You can always use the offset for exception like this. the name works for most common use-cases

[hem...@mnkcg.com]

Just like you use IPv6.src, can you not use SRH() header?  Then, you define an offset for inner IPv6 off of SRH().  Offset_fixup allows where in inner IPv6.src you want to randomize.

 

Hemant

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/a7a45f2a-ace9-41e7-9554-b9738ffbd29en%40googlegroups.com.

[Luc Lemieux]

The solution of offsetting starting from the SRH, do you mean to use "name" as the one for SRH and then use an offset_fixup when applying with "STLVmWrFlowVar"?

Is there an easy way to get the list of available "names" to use? Is that from the Scapy classes or from some internal TRex classes?

Luc

[hem...@mnkcg.com]

Trex can’t possibly define every protocol header in its classes so that you’d look for SRH() in a Trex class.  The SRH header should be Scapy header.  Write some code and test.

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/4d23cd52-6146-4037-881d-bcf4168415cen%40googlegroups.com.

[Luc Lemieux]

Ok, that escalated quickly...

"name" is a property defined in a TRex class, sorry for not knowing your whole code and how the mapping is done... 

"ip_src" is a name for IP class and IPv6 class. ip is the class, src is a property, joined by an underscore...

In the scapy IPv6 class, the "name" is "IPv6" and the IP class for ipv4 has the name "IP". Now when you put "name" in your class STLVmFlowVar it's "ip_src" and that will target the first IPv6 packet if you put the IPv6 offset...

So how is name making any sense, where does it come from, who does the concat with "_" between some alias for the header type and it's property?

I can't start guessing names in code if I don't what format is used to end up with the name.... Pretty surprising that's it's not exactly the name from Scapy "_" the property from Scapy, that would of made things too easy.

Also if you don't want to answer, just don't answer....

I'm trying to get help to write some code, not get somebody to write it for me..

Thank you,

Luc

[hem...@mnkcg.com]

Ah, I was simply asking to change script code and test to answer your question yourself – it takes few seconds to change a python script for field engine.   I changed my field engine script to use UDP.dst instead of IPv6.dst.

 

vm.write(fv_name="mac_src", pkt_offset="UDP.dst", offset_fixup=14)

 

trex-console fails which indicates the field engine does not support Scapy and just supports few layers (e.g., IP, IPv6) and field offsets off of these headers.

 

File "/opt/trex-core-2.86/scripts/automation/trex_control_plane/interactive/trex/stl/trex_stl_packet_builder_scapy.py", line 468, in get_field_offet

    raise CTRexPacketBuildException(-11, "No layer %s-%d." % (field_name, layer_cnt))

CTRexPacketBuildException: [errcode:-11] 'No layer dst-0.'

 

We should add a wish-list feature request to trex to support Scapy.

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/43bda299-ab61-4257-b293-814a2589f7b0n%40googlegroups.com.

[Luc Lemieux]

Thank you, sorry if I misinterpreted your previous message.

I will try to figure out the offset from start.

SRH is actually class "IPv6ExtHdrSegmentRouting" and like I said before I am having a hard time figuring out the "names" that are valid for STLVmFlowVar.

Like you just mentioned maybe that's because not much of them are supported. 

It's normal that you would not be able to know where every variable format comes from, so no problem if you cannot give me more information on where the "name" comes from.

The solution with using custom offset is already very helpful.

Thank you again,

Luc Lemieux

[hem...@mnkcg.com]

No apologies needed.  Sorry if I wasn’t clear.

 

Yes, it makes sense to use offset from a start such as “mac_src”. 

 

I poked around the trex github repo and only found this code which initializes mac_src, ip_src, etc.  All other code is used in a stl script and not very relevant to finding out  what all fv_names are supported.

 

https://github.com/cisco-system-traffic-generator/trex-core/blob/6376fbdd3b26074cbb22fd4b3f7d230a5817c7d8/scripts/automation/regression/hltapi_playground.py#L45

 

I also filed this new issue today.

 

https://github.com/cisco-system-traffic-generator/trex-core/issues/669

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/2fcb5967-6be7-4265-836d-aa984b8e7968n%40googlegroups.com.

[Luc Lemieux]

Great, thank you for your help.

I will keep searching the code. What i did was look in trex-core for name=" and that gave me all the ones used in your examples of STLVmFlowVar, but there are not many.

Best regards,

Luc Lemieux