Namespaces with stl l2

[Andreas Bourges]

Hi team,

...first of all - congratulations for reaching this new milestone!! I'm very excited and willing to test the new features in our lab environment (...and hopefully get rid of my own ARP/ND/IGMP code) :-) But I'm not sure if my requirements can already be solved with the new features. What I need to do:

- STL L2 Mode (qinq, currently I'm using service_arp and service_IPv6ND to resolve GWs and respond to arp-requests from the NUT)

Somehow I'm not able to find an example on how to accomplish this setup using the new features. Is there any example?

Thanks and best regards,

Andreas

[hanoh haim]

Hi Andreas,

Yes, Qinq is supported in Linux network namespace.

You should add “—software” for STL.

I’m not sure that ASTF supports Qinq forwading but it simple to fix.

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/29ec47b3-4f45-4876-8994-04b74329dd83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Hanoh

Sent from my iPhone

[Andreas Bourges]

Hi Hanoch,

... are there any examples for using namespaces from the API?

Thanks,

Andreas
-- sent from mobile

[hanoh haim]

Hi Andreas,

The API is the same, the underlying stack will handle the configuration to the namespace.

Currently there is only *one* IPv4/6/Qinq/vlan per physical port.

SetVlan/L3/setIpv6 per port API

Thanks,

Hanoh

[Andreas Bourges]

Hi Hanoch,

Ok, I understand. Is the feature to have more namespaces/interfaces per port close or will it take longer to be implemented?

[hanoh haim]

Hi Andreas,

I hope soon now that we managed to consolidate Stateful and Stateless.

What is the required number per port?

Thanks,

Hanoh

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/872ee926-716b-498a-9703-566f0b7a360c%40googlemail.com.

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

[Andreas Bourges]

Hi Hanoch,

Rough estimate would be a few hundreds, not more than 1000...

Thanks,

Andreas
-- sent from mobile

[hanoh haim]

Hi Andreas, 

v2.50 was released with namespace API support. 

I've tested it with with 1000  (~100sec to setup). 

We have another optimization to do for cases of higher scale e.g. 10,000 name space. The issue is multicast/broadcast packets from outside to inside. 

In this case we need to send the packets to all the namespaces not in *one* burst 

let me know if you have any questions/problems 

 

thanks,

Hanoh

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/83088ff2-6d9b-440f-a45c-3584c7d53cc9%40googlemail.com.

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

[andyb...@googlemail.com]

Hi Hanoh,

 

 

…great news! Will be back in business next week and try to test this ASAP! Thanks so much for your efforts!

 

Best regards,

 

Andreas

[Andreas Bourges]

Hi,

...tried to get my feet wet using the namespaces feature. Unfortunately qinq behaves the same way as in services: only 802.1ad as outer encapsulation supported and not 802.1q:


trex(service)>capture monitor start --tx 0 --rx 0 -f "arp or (vlan and arp) or (vlan and arp)"


ARP FROM Nexus 7710:

#1 Port: 0 ◀── RX
Type: ARP, Size: 68 B, TS: 576.10 [sec]
Ether(dst='ff:ff:ff:ff:ff:ff',src='00:de:fb:1d:84:c5',type=33024)/Dot1Q(prio=0,id=0,vlan=500,type=33024)/Dot1Q(prio=0,id=0,vlan=22,type=2054)/ARP(hwtype=1,ptype=2048,hwlen=6,plen=4,o,hwdst='ff:ff:ff:ff:ff:ff',pdst='172.17.22.21')/Padding(load='\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')

--> received frame from nexus uses 802.1q/802.1q


Answer from trex namespace interface:

#2 Port: 0 ──▶ TX
Type: ARP, Size: 50 B, TS: 576.10 [sec]
Ether(dst='00:de:fb:1d:84:c5',src='00:33:33:33:00:01',type=34984)/Dot1AD(prio=0,id=0,vlan=500,type=33024)/Dot1Q(prio=0,id=0,vlan=22,type=2054)/ARP(hwtype=1,ptype=2048,hwlen=6,plen=4,1',hwdst='00:de:fb:1d:84:c5',pdst='172.17.22.5')

--> answer from linux-stack uses 802.1ad/802.1q encapsulation, which is ignored by the nexus :(


Didn't find any reference in the docs on how to influence the used encapsulation...


Thanks,

Andreas

[Yaroslav Brustinov]

Hi, Andreas.

It's very nice that you adopt our features so quickly.

QinQ should behave as you have recorded in TX (outer 0x88a8 and inner 0x8100)

https://en.wikipedia.org/wiki/QinQ

However, we have talked with Hanoch and will provide a way make it configurable.

Thanks,

Yaroslav.

--
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/6caaf2c4-706a-485b-a32e-3b21a2bfd65e%40googlegroups.com.

[andyb...@googlemail.com]

Hi Yaroslav,

 

It's very nice that you adopt our features so quickly.

QinQ should behave as you have recorded in TX (outer 0x88a8 and inner 0x8100)

https://en.wikipedia.org/wiki/QinQ

[AB] As far as I know only the Cisco-Metro-Switches are using 802.1ad – all catalysts and nexus Switches in our testlab use double 802.1q 😊 So I cannot change this requirement in my setup, since this is caused by the cisco gear 😉

 

However, we have talked with Hanoch and will provide a way make it configurable.

[AB] Great – thanks!

 

Andreas

 

Thanks,

Yaroslav.

 

 

 

[andyb...@googlemail.com]

Hi,

 

...I have some questions regarding the usage of the namespaces feature regarding stream-attachment. From my understanding the current namespace feature would resolve the problems where DUTs/NUTs are doing ARP requests towards TRex. Is there any functionality from TRex towards the DUTs as well  (performing ARPs, NDs)? My current implementation is relying on the services framework (use service_arp to discover default-gw MAC) and I would like to get rid of the services for ARP resolution.

 

When connecting to a namespace and do a ping to an ip address in another subnet I can see the arp-request for the default-gw:

 

root:/home/trex/v2.50 $ifconfig

trex-a-0-3-L Link encap:Ethernet  HWaddr 00:33:33:33:00:01

          inet addr:172.17.22.21  Bcast:0.0.0.0  Mask:255.255.255.255

          UP BROADCAST RUNNING MULTICAST  MTU:9280  Metric:1

          RX packets:1598 errors:0 dropped:472 overruns:0 frame:0

          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:195990 (191.3 KiB)  TX bytes:672 (672.0 B)

 

root:/home/trex/v2.50 $route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         172.17.22.1     0.0.0.0         UG    0      0        0 trex-a-0-3-L

172.17.22.1     0.0.0.0         255.255.255.255 UH    0      0        0 trex-a-0-3-L

root:/home/trex/v2.50 $ping 172.17.21.1

PING 172.17.21.1 (172.17.21.1) 56(84) bytes of data.

[...]

 

 

root:/home/trex/v2.50 $tshark -i trex-a-0-3-L

Running as user "root" and group "root". This could be dangerous.

Capturing on 'trex-a-0-3-L'

[...]

  4  19.127676 00:33:33:33:00:01 -> Broadcast    ARP 42 Who has 172.17.22.1?  Tell 172.17.22.21

 

 

So if everything would work correctly (qinq encapsulation fixed...), there would be an ARP entry for the default-gw in this namespace.

 

 

 

now my questions:

  - is there any way to make the namespace resolve the default-gw MAC via API (explicitly or implicitly by just sending traffic)?

  - what's the recommended way to attach stateless streams to the namespace interface – is it possible at all?

  - Do I need to rediscover the gateway MAC myself or can I just attach the streams without default-gw MAC to the namespace interface (how would I do that) ?

 

I’m trying to get an idea on what I have to modify in my existing script to make full use of the namespace feature. In the best case, I would just attach a stream to the namespace interface without any requirement to resolve L2 MACs?!

 

Thanks,

 

Andreas

 

Von: Yaroslav Brustinov <y.bru...@gmail.com>
Gesendet: Montag, 7. Januar 2019 08:49
An: Andreas Bourges <andyb...@googlemail.com>
Cc: TRex Traffic Generator <trex...@googlegroups.com>
Betreff: Re: [trex-tgn] Namespaces with stl l2

 

Hi, Andreas.

[hanoh haim]

Hi Andreas, 

In general namespaces and streams are seperate entities.

we just forward the relevant packets to/from the namespace nodes. 

by default namespace does not initiate traffic (e.g. gratuitous arp)  only if needed (IPV6 MD traffic)

 

to your question:

"now my questions:

  - is there any way to make the namespace resolve the default-gw MAC via API (explicitly or implicitly by just sending traffic)?

[hh] It is not possible today but it is duable. however we didn't do that beacuse it would be super slow to do that on 1000 namespace. (we need to run a arp command in each namespace only to send packet it about factor 1000 slower)

Faster way is to use the services infra to generate many arps and process the response in parallel  

 

 

  - what's the recommended way to attach stateless streams to the namespace interface – is it possible at all?

[hh] not possible. you can sent traffic on bealf of the namespace using streams but you need to build it yourself. namespace are *SLOW* and only for maintenance/slow/complex protocols.  

  - Do I need to rediscover the gateway MAC myself or can I just attach the streams without default-gw MAC to the namespace interface (how would I do that) ?

[hh] Yes, your need to discover the gateway MAC, this would be the fastest way to do that. namespace will maintain it,

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/004801d4a673%24bcdf55f0%24369e01d0%24%40googlemail.com.

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

[andyb...@googlemail.com]

Hi Hanoh,

 

…ok – thanks for your explanation, I understand. So I will keep using the services framework and add namespaces interfaces for ARP/ND handling from DUT during initialization. Two more things:

• Joining a multicast group from within namespaces is out of scope I guess. Will have to handle it myself, right?
• Having long-running setups, the ARP cache entry will eventually timeout on the DUT. DUT will proactively perform an ARP to refresh the entry in the cache, before it expires.
  would it be possible *in software mode* to redirect all ARP/NDs to the namespace interfaces?

 

Thanks for your prompt response,

 

Andreas

[hanoh haim]

The namespaces will answer the ARP request after DUT  timeout and IPv6 ND requests from the DUT (multicast)  You just need to perform query for the default gateway once for the streams sake. You don’t need to maintain the IPv4/IPv6 (which is more complex for IPv6)

In regards to multicast. The Linux API requires a process (in the context of the namespace) and socket to join the multicast. 

This won’t scale for many namespaces.

It would be better to do that using the services (send IGMP report/query) and send the multicast traffic (e.g. Video) using the streams.

Thanks,

Hanoh

[Andreas Bourges]

... Ok, but I thought I need to be in service-mode for the packets to reach the namespace interfaces in STL?
-- sent from mobile

[hanoh haim]

Understood. In case of software mode( single Rx/multi-rx)/ASTF there is no need for service mode enabled for namespace to work (we are doing the filter in software)

Thanks,

Hanoh

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/706417a3-e6cf-4ea1-b6c5-d0804cb4ecf5%40googlemail.com.

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

[Andreas Bourges]

That's great!

thanks,

Andreas

[Yaroslav Brustinov]

Hi,

Please try this branch:

https://github.com/ybrustin/trex-core/tree/tpids

Config TPID example (will be two Dot1Q with tag 123):

cmds.add_node("00:01:02:03:04:05")

cmds.set_vlan("00:01:02:03:04:05", [123, 123], [0x8100, 0x8100])

...

Thanks,

Yaroslav.

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/74b72c58-fba7-4454-a928-d2cd74748792%40googlemail.com.

[andyb...@googlemail.com]

Hi,

 

thanks for reacting so fast! In the meanwhile I already modified the local code to (hard-code) 8100/8100 somewhere in the TREX cpp/.h files and adjusted my script. From what I can tell till now, it looks *really* great!

 

Will checkout the new branch and use it for further testing!

[andyb...@googlemail.com]

Hi Yaroslav,

 

…unfortunately your branch seems not up-to-date with v2.50:

 

ansible:~/ansible-dc/scripts (namespace_support) $ ./trex_client.py --exc "(MC|IPv6|WA|OTV)"

Traceback (most recent call last):

  File "./trex_client.py", line 2491, in <module>

    curses.wrapper(sm.run, streamLog, duration, cli_args.transmit)

  File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper

    return func(stdscr, *args, **kwds)

  File "./trex_client.py", line 201, in run

    self.setupNamespaces()

  File "./trex_client.py", line 244, in setupNamespaces

    r=self.c.set_namespace(port, method='get_nodes')

AttributeError: 'STLClient' object has no attribute 'set_namespace'

ansible:~/ansible-dc/scripts (namespace_support) $

 

Works fine with v2.50 ?!

 

Thanks,

 

Andreas

 

 

Von: Yaroslav Brustinov <y.bru...@gmail.com>
Gesendet: Dienstag, 8. Januar 2019 15:55

[hanoh haim]

Make sure you have the right branch.

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/006e01d4a76f%24e9a4d810%24bcee8830%24%40googlemail.com.

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

[andyb...@googlemail.com]

…sorry – I had switched to the proper branch on the server machine, but forgot to do the same on my client machine, where the script runs ☹

 

Now it works – will have a more closer look tomorrow!

 

Thanks for your assistance,

[andyb...@googlemail.com]

 

Hi,

 

…the double-802.1q works as expected – great stuff! Tried IPv4 and IPv6 and both worked right out of the box. As expected, setting up the namespaces takes a while (almost 2s on my server per namespace), but since they’re kept until the next TRex-restart that’s fine for me. I will adjust and “optimize” my script and perform further tests with namespaces, but from what I can tell until now, this is a huge progress for my use-case and makes me very confident in using TRex for the next big project 😉

 

Thanks a lot for all your efforts!

 

Andreas

 

[hanoh haim]

Hi Andreas, 

Thanks for the fast feedback.As I wrote in the manual, the namespace API is a bit different than current other functionality. 

It will not clean by default with reset API and you need manually to "remove-all" to clean this out ( because it is slow to add/remove/change). 

It can be seems as a different entity that work aside to TRex and has different set of  API 

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/009001d4a7e6%248b6b2ac0%24a2418040%24%40googlemail.com.

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

[hanoh haim]

Hi Andreas, In regards to multicast IGMP (join requests)

Do you think that adding a small IGMP server that will handle the traffic will help?

the API will be something like this:

mc_add_member_ipv4(namespace-mac, ipv4)

mc_remove_member_ipv4(namespace-mac, ipv4)

mc_set_ttl_ipv4(namespace-mac)

The same for IPv6. 

The server will handle the IGMP traffic (responses to DUT requests) an generate the 

IGMP packets join requests.

The multicast traffic ( e.g. Video) will be generated by the streams 

thank

Hanoh

 

[andyb...@googlemail.com]

Hi Hanoh,

 

Hi Andreas, In regards to multicast IGMP (join requests)

Do you think that adding a small IGMP server that will handle the traffic will help?

 

the API will be something like this:

 

mc_add_member_ipv4(namespace-mac, ipv4)

mc_remove_member_ipv4(namespace-mac, ipv4)

mc_set_ttl_ipv4(namespace-mac)

 

The same for IPv6. 

 

The server will handle the IGMP traffic (responses to DUT requests) an generate the 

IGMP packets join requests.

 

The multicast traffic ( e.g. Video) will be generated by the streams 

[AB] This would certainly give the last polishing to the namespace feature 😉 I’m not sure how much effort this would mean to you?! For the time being, I could also live with periodic join requests sent via a low-speed stream, but having a mini-server that takes care of proper IGMP handling would be great!

 

Thanks,

Andreas