445 reputation
49
bio website
location Germany
age
visits member for 2 years
seen Mar 19 at 10:44

In the networking business since 2002. IPv6 enthusiast. I let machines talk to each other, sometimes over long distances. I'm also interested in programming (mostly Python these days), I like git, I run my own servers and do a lot of other IT stuff.

JNCIAJNCIS-SP


Mar
19
awarded  Yearling
Dec
1
awarded  Caucus
Dec
1
awarded  Constituent
Sep
24
awarded  Autobiographer
Mar
19
awarded  Yearling
May
20
awarded  Constituent
May
20
awarded  Caucus
May
3
comment What is the right way to temporarily disable/enable PMTU Discovery on a Linux box?
I didn't write that it would not change the MTU, I said that it will not use a bigger MTU. Linux will only lower the MTU if it detects a lower MTU on a link somewhere on the path. It will never go over the maximum MTU. Regarding the VM: Yes there is a difference. The client doesn't handle the packet segmentation etc., instead it hands it off to the VM host. It's completely normal to see very big packets on a VM. You would be better off sniffing on the host or even better on the receiving side.
May
2
answered What is the right way to temporarily disable/enable PMTU Discovery on a Linux box?
Apr
19
comment How to interpret findings on TCP Send/Recv Buffers
No, not lost. The Data is saved to the receive buffer and not read by the application. Then the receive window gets set to 0 as the data fills the receive buffer. That's what I suspect.
Apr
19
comment How to interpret findings on TCP Send/Recv Buffers
Hi, so I looked closer at the TCP implementation under Linux and I think an empty Recv-Q does not mean that the data was read by the application. It just means that it was passed from the IP layer to the TCP layer. The RWIN is calculated after the data is stored in the receive buffer so the Recv-Q would be empty. Here is (kind of) short summary: ece.virginia.edu/cheetah/documents/papers/TCPlinux.pdf So you would still need to debug your application to see why the data is not removed from the receive buffer...
Apr
18
comment Is TCP RWIN set by application or OS?
Yes to the first part. To be correct, it's just signalling the sender that the receiving buffer is full and that it can't accept more data on the connection at the moment. So it's not really "preventing bad thing" more "preventing useless data transmission".
Apr
18
answered Is TCP RWIN set by application or OS?
Apr
18
comment How to diagnose why a port is broadcasting a “ZeroWindow” status
If the Recv-Q changes (decreases and then increases again) it would suggest that the application is still receiving/processing data, but not fast enough. If the Recv-Q is stable at a high value it would suggest that the application is "frozen", whatever that means in regards to the application, here it just means it's not collecting any more data from the TCP socket at all.
Apr
18
answered Juniper Router - Load Balancing
Apr
18
comment How to diagnose why a port is broadcasting a “ZeroWindow” status
Kind of. It's part of the TCP specification. Makes no sense to send data when the receiver can't handle it. TCP will throttle itself and not waste bandwidth. UDP on the contrary will just keep sending data because it makes no promise to deliver the data anyway.
Apr
18
answered How to diagnose why a port is broadcasting a “ZeroWindow” status
Apr
16
answered BGP can I specify using the backup link for some network
Apr
16
answered NOQUEUE: reject, Helo command rejected: need fully-qualified hostname
Apr
16
answered Ping on Linux with Bind produces a round robin effect?