ASTF mode & IPv6 with pcap file replay

dtod...@gmail.com

unread,

Sep 27, 2019, 4:44:28 AM9/27/19

to TRex Traffic Generator

Hello - quick question on TRex with IPv6; setup as per following:

TRex v2.61
ASTF mode - traffic being pushed through DUT which acts as a TCP proxy
IPv6 being used here; replaying content from PCAP file

On the DUT (Linux node) I have setup neighbor table mappings for TRex port MACs & the IPv6 routing on top of this.

Python profile nice and simple:

class Prof1():
def __init__(self):
pass # tunables

def create_profile(self, kwargs):
# get the default time to wait before responding; in seconds
pcap_file = kwargs.get('pcap','test.pcap')

# ip generator
ip_gen_c = ASTFIPGenDist(ip_range=["16.0.0.1", "16.0.255.255"], distribution="seq")
ip_gen_s = ASTFIPGenDist(ip_range=["48.0.0.0", "48.0.255.255"], distribution="seq")
ip_gen = ASTFIPGen(glob=ASTFIPGenGlobal(ip_offset="1.0.0.0"),
dist_client=ip_gen_c,
dist_server=ip_gen_s)

# profile
profile = ASTFProfile(default_ip_gen=ip_gen,
cap_list=[
ASTFCapInfo(file=pcap_file, cps=1),
]
)
return profile

def get_profile(self,**kwargs):
return self.create_profile(kwargs)

So running this up with a PCAP file in IPv4 mode; no problem - no errors and all is good.

trex>start -f owm/dt_pcap_from_file.py -t pcap=path/to/my/file.pcap

But when I run up in IPv6 mode:

trex>start -f owm/dt_pcap_from_file.py -t pcap=path/to/my/file.pcap --ipv6

I see drop_rate != 0 & TCP errors; taking a network capture I see the flows are not well formed - the flows are started ok but then I see TRex sending TCP packets with payload data of somewhere in the middle of the original pcap.. For example pulling out a broken flow:

No. Time Source Destination Protocol Length Stream index Info

9885 4.991254072 ::16.0.1.9 ::48.0.1.8 TCP 94 1876 48917 → 80 [SYN] Seq=0 Win=43200 Len=0 MSS=1440 SACK_PERM=1 TSval=1492156744 TSecr=0 WS=4096

9887 4.992000780 ::48.0.1.8 ::16.0.1.9 TCP 94 1876 80 → 48917 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460 WS=1 TSval=278725489 TSecr=1492156744

9890 4.992015173 ::16.0.1.9 ::48.0.1.8 TCP 86 1876 48917 → 80 [ACK] Seq=1 Ack=1 Win=45056 Len=0 TSval=1492156745 TSecr=278725489

9892 4.992042924 ::16.0.1.9 ::48.0.1.8 HTTP 881 1876 GET http://www.mit.edu/campus-life HTTP/1.1

9894 4.993001305 ::48.0.1.8 ::16.0.1.9 HTTP 781 1876 HTTP/1.1 301 Moved Permanently (text/html)

9897 4.993011356 ::16.0.1.9 ::48.0.1.8 TCP 86 1876 48917 → 80 [ACK] Seq=796 Ack=696 Win=45056 Len=0 TSval=1492156746 TSecr=278725489

9907 4.994159372 ::16.0.1.9 ::48.0.1.8 HTTP 882 1876 GET http://www.mit.edu/campus-life/ HTTP/1.1

9908 4.995000499 ::48.0.1.8 ::16.0.1.9 HTTP 583 1876 [TCP Previous segment not captured] Continuation

9909 4.995012372 ::16.0.1.9 ::48.0.1.8 TCP 86 1876 [TCP Window Update] 48917 → 80 [ACK] Seq=1592 Ack=696 Win=49152 Len=0 TSval=1492156748 TSecr=278725489

13653 6.784027882 ::48.0.1.8 ::16.0.1.9 TCP 98 1876 [TCP Retransmission] 80 → 48917 [ACK] Seq=2144 Ack=1592 Win=32768 Len=12 TSval=278725493 TSecr=1492156747

13654 6.784035388 ::16.0.1.9 ::48.0.1.8 TCP 86 1876 [TCP Dup ACK 9897#1] 48917 → 80 [ACK] Seq=1592 Ack=696 Win=49152 Len=0 TSval=1492158537 TSecr=278725489

22317 10.370006770 ::48.0.1.8 ::16.0.1.9 TCP 98 1876 [TCP Retransmission] 80 → 48917 [ACK] Seq=2144 Ack=1592 Win=32768 Len=12 TSval=278725500 TSecr=1492156747

22320 10.370014314 ::16.0.1.9 ::48.0.1.8 TCP 86 1876 [TCP Dup ACK 9897#2] 48917 → 80 [ACK] Seq=1592 Ack=696 Win=49152 Len=0 TSval=1492162123 TSecr=278725489

38101 16.345011520 ::48.0.1.8 ::16.0.1.9 TCP 98 1876 [TCP Retransmission] 80 → 48917 [ACK] Seq=2144 Ack=1592 Win=32768 Len=12 TSval=278725512 TSecr=1492156747

38103 16.345019119 ::16.0.1.9 ::48.0.1.8 TCP 86 1876 [TCP Dup ACK 9897#3] 48917 → 80 [ACK] Seq=1592 Ack=696 Win=49152 Len=0 TSval=1492168098 TSecr=278725489

38105 16.345021898 ::48.0.1.8 ::16.0.1.9 TCP 74 1876 80 → 48917 [ACK] Seq=695 Ack=1592 Win=32768 Len=0

38107 16.345025929 ::16.0.1.9 ::48.0.1.8 TCP 86 1876 [TCP Dup ACK 9897#4] 48917 → 80 [ACK] Seq=1592 Ack=696 Win=49152 Len=0 TSval=1492168098 TSecr=278725489

IP addresses here are ::16.0.1.9 is clientside; ::48.0.1.8 is serverside

Packet #9908 here is a response from TRex server port - out of sequence and is just 497 TCP bytes of data that breaks the flow here.

Are these any known issues here around IPv6 & ASTF mode?

Thanks,

Darren

Hanoch Haim

unread,

Sep 27, 2019, 5:22:37 AM9/27/19

to TRex Traffic Generator

Hi Daren,

IPv6 and IPv4 are using the same TCP + App Layer. There is a small diff in crafting the template packet.

IPv6 is simpler in a sense that there is no need to update checksums

I suggest to verify it by loopback the ports and test TRex against itself.

I would do another thing. I would capture both sides (server/client) into a pcap file on the TRex side (using the capture command)

Sending the pcaps and the tcp counters could give more information

thanks

Hanoh

dtod...@gmail.com

unread,

Sep 27, 2019, 6:39:45 AM9/27/19

to TRex Traffic Generator

Thanks for your timely help & pointers here Hanoh; I was able to troubleshoot & resolve the issue.

Looks like the problem here is the MSS/MTU being used in the IPv6 flows; the packet responses being sent by TRex were too big & hence being dropped.

The DUT talking server side to TRex sends SYN with MSS of 1440 here;

Frame 549: 94 bytes on wire (752 bits), 94 bytes captured (752 bits)

Ethernet II, Src: c2:e8:86:66:06:c0 (c2:e8:86:66:06:c0), Dst: IntelCor_20:99:28 (a0:36:9f:20:99:28)

Internet Protocol Version 6, Src: ::16.0.128.53, Dst: ::48.0.128.56

Transmission Control Protocol, Src Port: 17441, Dst Port: 80, Seq: 0, Len: 0

Source Port: 17441

Destination Port: 80

[Stream index: 44]

[TCP Segment Len: 0]

Sequence number: 0 (relative sequence number)

[Next sequence number: 0 (relative sequence number)]

Acknowledgment number: 0

1010 .... = Header Length: 40 bytes (10)

Flags: 0x002 (SYN)

Window size value: 43200

[Calculated window size: 43200]

Checksum: 0xad36 [unverified]

[Checksum Status: Unverified]

Urgent pointer: 0

Options: (20 bytes), Maximum segment size, SACK permitted, Timestamps, No-Operation (NOP), Window scale

TCP Option - Maximum segment size: 1440 bytes

Kind: Maximum Segment Size (2)

Length: 4

MSS Value: 1440

TCP Option - SACK permitted

TCP Option - Timestamps: TSval 1501722585, TSecr 0

TCP Option - No-Operation (NOP)

TCP Option - Window scale: 12 (multiply by 4096)

[Timestamps]

But data packets are being sent from TRex that are 1448 bytes in size:

Frame 556: 1534 bytes on wire (12272 bits), 1534 bytes captured (12272 bits)

Ethernet II, Src: IntelCor_20:99:28 (a0:36:9f:20:99:28), Dst: c2:e8:86:66:06:c0 (c2:e8:86:66:06:c0)

Internet Protocol Version 6, Src: ::48.0.128.56, Dst: ::16.0.128.53

Transmission Control Protocol, Src Port: 80, Dst Port: 17441, Seq: 696, Ack: 1592, Len: 1448

Source Port: 80

Destination Port: 17441

[Stream index: 44]

[TCP Segment Len: 1448]

Sequence number: 696 (relative sequence number)

[Next sequence number: 2144 (relative sequence number)]

Acknowledgment number: 1592 (relative ack number)

1000 .... = Header Length: 32 bytes (8)

Flags: 0x010 (ACK)

Window size value: 32768

[Calculated window size: 32768]

[Window size scaling factor: 1]

Checksum: 0x463c [unverified]

[Checksum Status: Unverified]

Urgent pointer: 0

Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps

[SEQ/ACK analysis]

[Timestamps]

TCP payload (1448 bytes)

[Reassembled PDU in frame: 564]

TCP segment data (1448 bytes)

I can work round this as you know; by dropping the MSS values down:

#set the MSS values lower

c_glob_info = ASTFGlobalInfo()

c_glob_info.tcp.mss = 1400

s_glob_info = ASTFGlobalInfo()

s_glob_info.tcp.mss = 1400

# profile

profile = ASTFProfile(default_ip_gen=ip_gen, default_c_glob_info=c_glob_info, default_s_glob_info=s_glob_info,

Now I can run my IPv6 traffic without seeing errors / drops.

Thanks,

Darren

hanoh haim

unread,

Sep 27, 2019, 7:20:12 AM9/27/19

to dtod...@gmail.com, TRex Traffic Generator

This is a known issue. You can set the MSS per template or globally.

See this example that set it 1

https://github.com/cisco-system-traffic-generator/trex-core/blob/master/scripts/astf/param_mss_err.py

Set the MSS to 1300

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 view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/e4706ab6-ae08-4848-80aa-801e2de24771%40googlegroups.com.

--

Hanoh

Sent from my iPhone

dtod...@gmail.com

unread,

Sep 27, 2019, 8:27:30 AM9/27/19

to TRex Traffic Generator

Yes have done so. I didn't see any issue at githut https://github.com/cisco-system-traffic-generator/trex-core/issues?utf8=✓&q=mss but maybe I missed it? Let me know if you want an issue tracked there.

Darren

On Friday, 27 September 2019 12:20:12 UTC+1, Hanoch Haim wrote:

This is a known issue. You can set the MSS per template or globally.
See this example that set it 1

https://github.com/cisco-system-traffic-generator/trex-core/blob/master/scripts/astf/param_mss_err.py

Set the MSS to 1300

Thanks
Hanoh

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

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/e4706ab6-ae08-4848-80aa-801e2de24771%40googlegroups.com.

hanoh haim

unread,

Sep 29, 2019, 3:43:29 AM9/29/19

to dtod...@gmail.com, TRex Traffic Generator

Hi Darren,

It was a known issue to me. Please add an issue in Github and we will change the default mss to the right value in case of IPv6

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/50391b9e-74b2-4736-913c-0dd3c4cb7992%40googlegroups.com.

Reply all

Reply to author

Forward