TCP RST for HTTP traffic

[Vijay Ram]

Hi,

TRex is running on two different VM machines. Based on documentation I used ASTF client/server mode.

TRex client on AWS VM -----> Router------>TRex server on Azure VM

Server:

./t-rex-64 -i --astf --cfg /etc/trex_cfg.yaml --astf-server-only

Client:

./t-rex-64 -i --astf --cfg /etc/trex_cfg.yaml --astf-client-mask 0x1

Server Cgf file:

  interfaces    : ["dummy", "eth1"]

  port_info       :  # Port IPs. Change to suit your needs. In case of loopback, you can leave as is.

          - ip         : 192.168.12.78

            default_gw : 192.168.12.65

Client Cfg file:

  interfaces    : ["eth1","dummy"]

  port_info       :  # Port IPs. Change to suit your needs. In case of loopback, you can leave as is.

          - ip         : 192.168.12.40

            default_gw : 192.168.12.33

Connected to trex-console in both client and server. 

Executed below script in server first and then client.

trex>start -f astf/http_simple_new.py

SYN packets from client successfully reached server but server responds with RST

I checked "netstat -tulpn" in server Ubuntu VM and I don't see port 80 to listen for incoming client requests which could be the reason for RST.

Shouldn't the script bind port 80 in server against the IP address

thx,

Vijayram

[Vijay Ram]

I modified /etc/trex_cfg.yaml" of server with dummy IP/GW for port 0. Port 1 has valid IP/GW. So this ensured server sending packets on port 1 and client sending packets on port 0

I have attached the "tui" stats of client and server. But still I see TCP RST from server towards client.

I don't see port service 80 binded to listen for incoming connections from "netstat" command. Hope that's the problem for server sending RST.

Kindly advice how to get this issue fixed? Shouldn't the ASTF program create socket and bind port 80 to listen for incoming request?

Do I miss any other config/script file to run here ?

thx,

Vijayram

[Vijay Ram]

Hi,

I triaged the issue further and could see that ICMP reachability between my Azure and AWS VM is incorrect and duplicate ICMP response were sent for each ICMP request. This network path issue should have cause TCP RST as well.

This duplication of ICMP reply happens only when I run "t-rex-64 -i --astf" is run from that impacted VM wherein ICMP response is sent.

If I stop the "t-rex-64" executable then PING and SSH succeeds.

I don't see changes in "ip route" in VM with and without "t-rex-64". Should this "t-rex-64" executable impact routing? Since am using client/server mode, I run "eth1", "dummy" in case of client side.  Similarly "dummy", "eth1" in server side. 

Can anyone help to fix this issue as I couldn't proceed further?

thx,

Vijayram

[Vijay Ram]

Hi, 

I'm seeing TCP RST from sever only when I start ASTF HTTP script as below

t-rex-64 -i --astf -cfg /etc/trex_cfg.yaml -astf/http_simple.py

This even affects SSH traffic or any TCP traffic. Does this script affect FW in linix? 

Your comments much appreciated

Thx, 

Vijayram

--
You received this message because you are subscribed to a topic in the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/trex-tgn/-CewQaVF6Cw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to trex-tgn+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/7046f7bf-e874-434f-a7e0-a292a518ba7cn%40googlegroups.com.

--
with regards
Vijayram.P

[Vijay Ram]

Hi,

Can someone share me your comments on TCP RST when TRex ASTF running in client/server mode?

thx,

Vijayram

To unsubscribe from this group and all its topics, 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/7046f7bf-e874-434f-a7e0-a292a518ba7cn%40googlegroups.com.

--
with regards
Vijayram.P

[Vijay Ram]

Hi,

Kindly request to share your comments for the issue I observed in initiating TCP connections when I run the "http_simple.py" ASTF script in client/server mode. I tried this script in other Ubuntu machines apart from AWS/Azure provided but still I observe TCP RST from server

Server:

./t-rex-64 -i --astf --cfg /etc/trex_cfg.yaml --astf-server-only

Client:

./t-rex-64 -i --astf --cfg /etc/trex_cfg.yaml --astf-client-mask 0x1

Server Cgf file:

  interfaces    : ["dummy", "eth1"]

  port_info       :  # Port IPs. Change to suit your needs. In case of loopback, you can leave as is.

          - ip         : 192.168.12.78

            default_gw : 192.168.12.65

Client Cfg file:

  interfaces    : ["eth1","dummy"]

  port_info       :  # Port IPs. Change to suit your needs. In case of loopback, you can leave as is.

          - ip         : 192.168.12.40

            default_gw : 192.168.12.33

Connected to trex-console in both client and server. 

Executed below script in server first and then client.

trex>start -f astf/http_simple_new.py

Do I miss any pre-requisites here? 

If I stop the script then my TCP connections between client and server are fine. So seems issue in TCP while running script.

thx,

Vijayram

[Bidhov Bizar]

Hi,

    I too faced the same issue. I solved it using the following way

1. Make sure there is no other interface active in your namespace that is connecting to the router.

    Do the following

    bash$ ip route

    and see how many interfaces are currently active and willing to connect to the same network. If you see more than one. Change your network such a way that there is just one interface eth1 in your case.

2 Your interface got swapped. Just do the following

1. In server cfg change from

interfaces    : ["dummy", "eth1"]

to

interfaces    : [ "eth1" , "dummy"]

2.

In client cfg side

interfaces    : [ "eth1" , "dummy"]

to

interfaces    : ["dummy", "eth1"]

3. Add some garbage ip and gateway in the configuration file if your interface order is

interfaces    : ["dummy", "eth1"]

eg:

interfaces    : ["dummy", "eth1"]

          - ip         : 192.168.12.78

            default_gw : 192.168.12.65

          - ip         : 192.168.12.78

            default_gw : 192.168.12.65

Even though first interface is dummy it will still look for some values.

Regards,

Bidhov Bizar