Solved: IPv6

jorogers · ‎06-29-2017

I am very new to using Trex and have a question regarding configuration for IPv6 stateful testing. First of all, I want to say Trex is an amazing tool. It has been perfect for the testing I'm performing. Thanks for all of the hard work creating it!

So, I've read through the documentation pages as well as the Cisco Communities discussions and blog posting and am not finding an answer to my issue. I'm running version 2.27 using Mellanox Connect-X4 100Gps NICs

I ran stateful tests against a firewall with IPv4 very successfully. My trex_cfg.yaml file contains:

- port_limit: 2

version: 2

interfaces: ['03:00.0', '03:00.1']

port_info:

- ip: 131.247.125.10

default_gw: 131.247.125.11

- ip: 131.247.126.10

default_gw: 131.247.126.11

platform:

master_thread_id: 0

latency_thread_id: 1

dual_if:

- socket: 0

threads: [2,4,6,8,10,12,14,16,18]

And I was using the stock cap2/sfr_agg_tcp14_udp11_http200msec_new_high_new_nir_profile_ipg_mix.yaml file with only the client and server addresses modified to:

	clients_start : "16.0.0.1"
	clients_end : "16.14.255.255"
	servers_start : "48.0.0.1"
	servers_end : "48.14.255.255"

The cli used for the tests was:

# ./t-rex-64 -f cap2/sfr_agg_tcp14_udp11_http200msec_new_high_new_nir_profile_ipg_mix.yaml -m 55 -d 600 -e -c 9

My next set of tests involved IPv6, so I modified the cap2/sfr_agg_tcp14_udp11_http200msec_new_high_new_nir_profile_ipg_mix.yaml with these additional lines:

src_ipv6 : [0x2607,0xfe50,0x0000,0xf802,0x0000,0x0000]

dst_ipv6 : [0x2607,0xfe50,0x0000,0xf803,0x0000,0x0000]

And the cli used was:

# ./t-rex-64 -f cap2/sfr_agg_tcp14_udp11_http200msec_new_high_new_nir_profile_ipg_mix.yaml -m 55 -d 600 -e -c 9 --ipv6

I of course set up the firewall DUT with static routes and NDP entries for the IPv6 prefixes so that traffic would be properly forwarded (which it is based on captures I've done of the traffic). Under v4 the '-e' flag made sure that the traffic sourced from NIC0 was from the client IP range and the traffic sourced from NIC1 was from the server range (so the firewall was happy with outside and inside addresses it saw).

But, for the v6 testing, the source v6 addresses are keeping the 16.0.0.0/12 IPv4 encoded addresses coming from NIC0 as you can see below, but I'm seeing a mix of v6 prefixes coming from that NIC instead of just the 2607:fe50:0:f802::/64 prefix I have configured as the source (this is a capture of packets transmitted by NIC0):

62 0.205888089 2607:fe50:0:f802::1003:557a -> 2607:fe50:0:f803::3003:557a TCP 78 1025 > 443 [ACK] Seq=1 Ack=1 Win=32768 Len=0

63 0.205898872 2607:fe50:0:f803::1003:55b5 -> 2607:fe50:0:f802::3003:55b5 TCP 1538 [TCP segment of a reassembled PDU]

64 0.205903032 2607:fe50:0:f802::1006:aacc -> 2607:fe50:0:f803::3006:aacc TCP 78 [TCP Previous segment not captured] 1025 > 443 [ACK] Seq=517 Ack=3642 Win=32768 Len=0

65 0.205906902 2607:fe50:0:f803::1003:55b5 -> 2607:fe50:0:f802::3003:55b5 TCP 1512 [TCP Previous segment not captured] [TCP segment of a reassembled PDU]

66 0.205910349 2607:fe50:0:f803::100b:ab03 -> 2607:fe50:0:f802::300b:ab03 TCP 1538 [TCP segment of a reassembled PDU]

67 0.205914376 2607:fe50:0:f803::100d:5579 -> 2607:fe50:0:f802::300d:5579 UDP 1146 Source port: 16476 Destination port: 1024 [ILLEGAL CHECKSUM (0)]

68 0.205923219 2607:fe50:0:f803::1006:aad5 -> 2607:fe50:0:f802::3006:aad5 UDP 340 Source port: 16476 Destination port: 1024 [ILLEGAL CHECKSUM (0)]

69 0.205926516 2607:fe50:0:f803::1008:55b1 -> 2607:fe50:0:f802::3008:55b1 TCP 1538 [TCP Previous segment not captured] [TCP segment of a reassem

So, it seems like the -e flag isn't using the src_ipv6 prefix for NIC0 for source addresses and flipping that to the dst_ipv6 prefix as the source addresses for NIC1 like it does for IPv4 testing. But, perhaps I'm just missing some yaml configuration or CLI flag. Any help would be greatly appreciated.

Thanks

Joe Rogers

Associate Director, Network Engineering

University of South Florida, Information Technology

hhaim@cisco.com · ‎06-29-2017

Did you test without -e CLI?

Are your profile include UDP one packet? -e should not be use anymore given our Stateless support?

Can you test it with out cap2/simple_http.yaml

Thanks,

Hanoh

Sent from my iPhone

View solution in original post

hhaim@cisco.com · ‎06-29-2017

Did you test without -e CLI?

Are your profile include UDP one packet? -e should not be use anymore given our Stateless support?

Can you test it with out cap2/simple_http.yaml

Thanks,

Hanoh

Sent from my iPhone

jorogers · ‎06-29-2017

I tried the original cap2/sfr_agg_tcp14_udp11_http200msec_new_high_new_nir_profile_ipg_mix.yaml config without the '-e' option and still saw the mixing of source prefixes coming from NIC0:

753 0.038209464 2607:fe50:0:f802::1006:32d3 -> 2607:fe50:0:f803::3006:32d3 UDP 76 Source port: 1032 Destination port: 10000 [ILLEGAL CHECKSUM (0)]

754 0.038220503 2607:fe50:0:f803::3006:232e -> 2607:fe50:0:f802::1006:232e TCP 98 1494 > 1039 [PSH, ACK] Seq=1 Ack=1 Win=32768 Len=20

755 0.038229702 2607:fe50:0:f802::1006:1982 -> 2607:fe50:0:f803::3006:1982 UDP 94 Source port: 1032 Destination port: 10000 [ILLEGAL CHECKSUM (0)]

756 0.038245014 2607:fe50:0:f802::100b:1846 -> 2607:fe50:0:f803::300b:1846 UDP 94 Source port: 1032 Destination port: 10000 [ILLEGAL CHECKSUM (0)]

757 0.038253154 2607:fe50:0:f802::1004:8989 -> 2607:fe50:0:f803::3004:8989 DCERPC 270 Request: call_id: 67, Fragment: Single, opnum: 11, Ctx: 0

758 0.038263869 2607:fe50:0:f802::1007:e088 -> 2607:fe50:0:f803::3007:e088 TCP 1534 [TCP segment of a reassembled PDU]

I'm also seeing a mix of client (:1006:) and server (:3006:) IPv4 encoded hosts but that doesn't really matter since it's the host portion. The /64 prefix is the bigger issue since the firewall being tested sees the server-addressed prefix as a spoofed packet when coming from the client side of the firewall.

I didn't find a cap2/simple_http.yaml, but did find http_simple.yaml and tried that one (with the addition of these lines):

src_ipv6 : [0x2607,0xfe50,0x0000,0xf802,0x0000,0x0000]

dst_ipv6 : [0x2607,0xfe50,0x0000,0xf803,0x0000,0x0000]

Using this CLI I'm still seeing mixed source prefixes:

# ./t-rex-64 -f cap2/http_simple.yaml -m 55 -d 600 --ipv6 -c 9

763 2.826488587 2607:fe50:0:f803::3000:aaa9 -> 2607:fe50:0:f802::1000:ab TCP 1538 [TCP segment of a reassembled PDU]

764 2.826489107 2607:fe50:0:f802::1000:1f -> 2607:fe50:0:f803::3000:1c74 TCP 74 1024 > 80 [ACK] Seq=250 Ack=17521 Win=32768 Len=0

765 2.826490737 2607:fe50:0:f803::3000:aaa9 -> 2607:fe50:0:f802::1000:ab TCP 1538 [TCP segment of a reassembled PDU]

766 2.826490807 2607:fe50:0:f802::1000:1f -> 2607:fe50:0:f803::3000:1c74 TCP 74 1024 > 80 [ACK] Seq=250 Ack=20441 Win=32768 Len=0

767 2.826493064 2607:fe50:0:f803::3000:aaa9 -> 2607:fe50:0:f802::1000:ab TCP 1538 [TCP segment of a reassembled PDU]

768 2.826898669 2607:fe50:0:f803::3000:71c8 -> 2607:fe50:0:f802::1000:74 TCP 1538 [TCP segment of a reassembled PDU]

769 2.827479256 2607:fe50:0:f802::1000:5 -> 2607:fe50:0:f803::3000:5 TCP 78 1024 > 80 [SYN] Seq=0 Win=32768 Len=0 MSS=1460

770 2.828479635 2607:fe50:0:f802::1000:c6 -> 2607:fe50:0:f803::3000:c719 TCP 74 [TCP ACKed unseen segment] 1024 > 80 [ACK] Seq=250 Ack=23361 Win=32768 Len=0

So, still seeing the mixed prefixes as well as the mixed host addresses without the -e option.

You mentioned using a yaml file with UDP flows. So I modified cap2/imix_fast_1g_100k_flows.yaml to include the v6 addresses and ran it with ./t-rex-64 -f cap2/imix_fast_1g_100k_flows.yaml -m 55 -d 600 --ipv6 -c 9. That seemed to work just fine:

49 6.381512150 2607:fe50:0:f802::100b:d04d -> 2607:fe50:0:f803::300b:d04d UDP 1534 Source port: 1024 Destination port: 2001 [ILLEGAL CHECKSUM (0)]

50 6.381515094 2607:fe50:0:f802::1006:af15 -> 2607:fe50:0:f803::3006:af15 UDP 610 Source port: 1024 Destination port: 2002 [ILLEGAL CHECKSUM (0)]

51 6.381518196 2607:fe50:0:f802::1008:5aae -> 2607:fe50:0:f803::3008:5aae UDP 80 Source port: 1024 Destination port: 2001 [ILLEGAL CHECKSUM (0)]

52 6.381521162 2607:fe50:0:f802::1003:593b -> 2607:fe50:0:f803::3003:593b UDP 610 Source port: 1024 Destination port: 2002 [ILLEGAL CHECKSUM (0)]

53 6.381524404 2607:fe50:0:f802::100b:b0b2 -> 2607:fe50:0:f803::300b:b0b2 UDP 80 Source port: 1024 Destination port: 2001 [ILLEGAL CHECKSUM (0)]

54 6.381527569 2607:fe50:0:f802::100d:5740 -> 2607:fe50:0:f803::300d:5740 UDP 610 Source port: 1024 Destination port: 2002 [ILLEGAL CHECKSUM (0)]

55 6.381530433 2607:fe50:0:f802::100a:873 -> 2607:fe50:0:f803::300a:873 UDP 80 Source port: 1024 Destination port: 2001 [ILLEGAL CHECKSUM (0)]

56 6.381533735 2607:fe50:0:f802::1000:614 -> 2607:fe50:0:f803::3000:614 UDP 610 Source port: 1024 Destination port: 2002 [ILLEGAL CHECKSUM (0)]

Both the prefix and the IPv4 encoded host portions were correct. So is there a way to make this work for the TCP flows?

Thanks!

hhaim@cisco.com · ‎06-29-2017

Which version of TRex?

Hanoh

Sent from my iPhone

jorogers · ‎06-29-2017

# ./t-rex-64 -v

Version : v2.27

DPDK version : DPDK 17.02.0-rc3

User : hhaim

Date : Jun 18 2017 , 10:54:07

Uuid : 37c1c20c-53fb-11e7-8930-0006f62b3e88

Git SHA : 7d0fb503142103a36968206bf9727e55144bef9c

hhaim@cisco.com · ‎06-29-2017

Interesting this bug was fixed in v2.24 see here

https://trex-tgn.cisco.com/youtrack/issueMobile/trex-408

Will look into this

Thanks,

Hanoh

Sent from my iPhone

hhaim@cisco.com · ‎06-29-2017

Hi Joe,

Looking into the fix,

https://github.com/cisco-system-traffic-generator/trex-core/commit/0c40dbd93fe9d0aaed3af9b2a1fcd84c283c4aaf

Could you do one more last test?

Try cap2/http_simple_ipv6.yaml and change default ipv6 src/dst in the file to your need.

This file is used in our unit-test so it must work

Thanks,

Hanoh

Sent from my iPhone

jorogers · ‎06-29-2017

Ah, so it turns out the captures I did in my last reply weren't correct. I had a left over source-interface statement in the monitor configuration which caused me to see both sides of the traffic instead of just the traffic sourced from NIC0. Removing the '-e' from the cli was indeed the complete fix. With that removed, NIC0 is sourcing only the 2607:fe50:0:f802 prefix and NIC1 is sourcing only the :f803 prefix. It of course works with the prefixes in the stock cap2/http_simple_ipv6.yaml file as well.

Thanks for the help!

hhaim@cisco.com · ‎06-29-2017

Thanks.

Just for information our forum

https://groups.google.com/forum/m/#!forum/trex-tgn

Is more active with much more registered users, so you will probably get answer faster there.

We are using the devNet mainly for jive blogs

Thanks,

Hanoh

Sent from my iPhone

jorogers · ‎06-29-2017

Thanks...I guess my Google-fu failed me when searching for the correct forum. I'll use that in the future if I run into any other issues. So far so good!