I am trying to stream a video between 2 hosts also I am trying to simulate changing IP scenario, the client started listening to the server then I moved the client to the new switch and it is got 192.168.2.5, I am using Mininet and Ryu controller. my topology is as follows:
ha-eth0<->s1-eth1 (OK OK)
hb-eth0<->s2-eth12 (OK OK)
hc-eth0<->s1-eth3 (OK OK)
s2-eth1<->s1-eth4 (OK OK)
s2-eth2<->s3-eth1 (OK OK)I am using vlc-wraper and HTTP protocol for streaminh. also, I installed the folwing flows to modify the clint's IP on switch 1 and 2:
cookie=0x0, duration=1012.669s, table=0, n_packets=2, n_bytes=1894, idle_age=1004, priority=3,ip,nw_src=192.168.2.2,nw_dst=192.168.2.3 actions=output:4 cookie=0x0, duration=1012.668s, table=0, n_packets=1, n_bytes=54, idle_age=1004, priority=3,ip,nw_src=192.168.2.3,nw_dst=192.168.2.2 actions=output:1 cookie=0x0, duration=1059.340s, table=0, n_packets=1, n_bytes=947, idle_age=1051, priority=3,ip,nw_src=192.168.2.2,nw_dst=192.168.2.3 actions=mod_nw_dst:192.168.2.5,output:12 cookie=0x0, duration=1059.340s, table=0, n_packets=1, n_bytes=54, idle_age=1051, priority=3,ip,nw_src=192.168.2.5,nw_dst=192.168.2.2 actions=mod_nw_src:192.168.2.3,output:1ha(Host A) IP is 192.168.2.2 (the client host)
hb(Host B) old IP is 192.168.2.3 and new IP is 192.168.2.5 (the server host)
when the stream stopped, I checked Wireshark and noticed that there were TCP RST but I do not know why? could someone take a look in the Wireshark files and tell me the reasons.
I attached the Wireshark output for both hosts
21 Answer
According to the TCP specifications, the identity of a TCP connection is determined by the combination of these four things:
- IP address of endpoint A
- TCP port number of endpoint A
- IP address of endpoint B
- TCP port number of endpoint B
If any of these four things changes, then by basic TCP protocol definition it is no longer the same connection.
When your Host B switched from its old IP to the new one, all the existing connections and the state associated with them were tied to the old IP address. The operating system is smart enough to know that once the IP address of an interface changes, any existing TCP connections cannot be continued as the old IP address can no longer be used.
Apparently the change of IP address was rather abrupt as far as Host B is concerned: there is no DHCPRELEASE nor any attempt for orderly termination of existing connections before tearing down the old IP address.
As a result, on host B's network interface, as the old IP address is torn down, so are any TCP connections that were associated with the old IP.
Your Software-Defined Networking apparently takes care of translating the destination addresses of the packets coming from host A to the new IP address - but the operating system of host B does not know it, and so it has no clue that in this specific case it would have been possible to keep the connection state and continue using it even with the new IP address.
So, once host B gets one of the re-transmitted packets from host A, it sees it is addressed from 192.168.2.2, port 1234 to 192.168.2.5, port 37186. There is no record of an existing TCP connection with those exact parameters - so the operating system can only send a TCP RST as a response.
(Even if the old connection information was kept, it had host B's side in IP address as 192.168.2.3, so as far as host B knows, this new packet to 192.168.2.5 has absolutely nothing to do with that old connection.)
When the RST response travels back to host A, the SDN will translate its source address to 192.168.2.3, so host A will recognize it as belonging to its existing connection. And so host A will get the message that the stream is dead.