I have a 7100 series Arista passthrough switch. In my configuration, the switch takes as input 1G Ethernet, and routes it to a 10G output.
In this 1G to 10G configuration, is the Arista switch still acting as a cut-through switch, given that information can go out faster than it comes in?
I have a Windows 7 IPSec VPN setup. When inspecting the IPSec packets generated by Windows in Wireshark the corresponding payloads are, as expected, encrypted. Is there a way to inspect the non-encrypted payloads for debug?
I have a 10G XPF+ optical cable with market updates from a stock exchange. This cable goes into a switch, which then mirrors every packet to a couple of computers over two ports. The problem with using a switch for mirroring is that there is latency overhead, even with a pass-through switch (~200ns).
Are there "optical" solutions (I'm thinking of a beam splitter of some sort) which would allow for close to zero latency 10G mirroring?
Please find a small pcap file here illustrating my problem.
I have a three-way TCP handshake, followed by two FIX logons. (FIX is a protocol used in trading.) The first FIX logon (frame 4) is interpreted and parsed just fine by WireShark, but the second logon (frame 6) is interpreted as a TCP segment of a reassembled PDU.
However frame 6 is not a TCP segment of a reassembled PDU. It contains a full TCP PDU that should be interpreted and parsed as a FIX logon. I have checked that the sequence numbers, ACK numbers, IP total lengths, etc. are all good.
Why is frame 6 interpreted as a TCP segment of a reassembled PDU?
A quick WireShark scan of my network interface reveals a bunch of Ethernet packets which are less than 64 bytes in length. I know that WireShark strips off the trailing 4 byte CRC, but I still see some ARP packets with 42 bytes, some IGMPv3 with 54 bytes and some TCP with 54 bytes.
Is the 64-byte minimum Ethernet packet rule respected? What are the consequences of not respecting the rule?
From the Wikipedia page:
The checksum field is the 16 bit one's complement of the one's complement sum of all 16-bit words in the header and text.
Why, after summing the 16-bits in the header and text, is the one's complement taken to compute the TCP checksum?
The ifconfig command can change both the ip address and netmask of a network interface:
ifconfig eth0 10.10.10.10 netmask 255.255.255.0
Is it possible to change the netmask of the network interface eth0 without knowing (and changing) it's ip address?
I've tried
ifconfig eth0 netmask 255.255.255.0
but I get the error
ifconfig: ioctl (SIOCAIFADDR): Invalid argument
I know that the command ifconfig will give you ip, mask and gateway of a given network interface. I want to "programmatically" extract each of those paramaters separately. At the moment the best solution I can think of is to do some parsing by using grep.
Are there ifconfig flags to single out ip, mask or gateway? Are there other *nix commands that will extract just one parameter of a given network interface?
I have a DELL server running RedHat EL 6.3 with two 1G network interfaces, and two 10G network interfaces.
Following this note, I have successfully renamed the two 1G network interfaces that used to be called em1 and em2. However, I cannot rename the 10G network interfaces using this method. (Those are called p4p1 and p4p2, and do not start with em.)
How can I rename the network interface name of my 10G network interfaces on RedHat EL 6.3?
I have a Windows 7 host, with FileZilla. The client VM, a RedHat 6.3, has IP address 192.168.93.130 (determined using ifconfig).
I have tried using the "Quickconnect" feature of FileZilla, entering the IP address, port 22 and my shell login and username.
This is what I get:
What could be going wrong?
I need to get my NIC ID for a temporarily software license to be generated for me. How should I find my NIC ID?
I have found contradictory information on the web. Some suggested that I run getmac.exe:
C:\Windows\System32>getmac.exe
Physical Address Transport Name
=================== ==========================================================
D4-BE-D9-1C-4F-C7 \Device\Tcpip_{7E28ABA4-55A5-4ECC-9B9A-8A440CDB9B95}
24-77-03-3E-B2-9C Media disconnected
7C-E9-D3-FE-40-41 Media disconnected
24-77-03-3E-B2-9D Media disconnected
From that, I assume my NIC ID is {7E28ABA4-55A5-4ECC-9B9A-8A440CDB9B95}. But then others have suggested to go to Device Manager -> Network adapters -> [my NIC] -> Details but I get many IDs in the same format as above, not just one:
I was somehow convinced that the TCP checksum was a header checksum (similar to the IP checksum), but I'm now having doubts reading the Wikipedia article:
The checksum field is the 16 bit one's complement of the one's complement sum of all 16-bit words in the header and text.
This seems a little crazy to me that the TCP checksum, which is placed in the header (as opposed to a footer), depends upon bytes sent after the header. This is a hindrance to hardware optimised TCP. Essentially, this nullifies "cut-through" architectures that would start sending the TCP header before knowing the text of the TCP packet.
Why is the TCP checksum placed in the header when it depends on the text? Can this be mitigated for "cut-through" architectures?
Suppose that I want to send a very large chunk of data using IP, and that the data gets fragmented into 100 IP datagrams.
By the time I have sent the first 90 datagrams, I realise that I would like to tweak a few bits in the payload of the 3rd datagram. Is it possible to send an "amendment" to the 3rd datagram before sending the last 10 datagrams, avoiding me a resend of the initial 90 datagrams?
Part of the reason I ask is that this RCF says (see page 1):
[a new fragment] may overlap with existing fragments
Suppose that a given TCP fragment is fragmented into two IP datagrams, and that the first datagram arrives to the TCP server, but the second datagram never arrives.
After a certain amount of time the TCP server sends a keepalive, and determines that the client is alive. What does the TCP server then do with this first datagram? Does is wait for the second datagram to arrive, or does it discard the first datagram?
Application data sent over TCP experiences multiple encapsulations:
It turns out Ethernet frames are sent most-significant byte first, and within each byte, most-significant bit first. What about the multiple encapsulations? Are they performed MSB first or LSB first?
As I understand, TCP takes a chunk of data and cuts it into segments that are transmitted over a TCP session.
Now suppose that I, as a client, have two chunks A, B of data that I want sent to a server. Each chunk is cut into 3 segments, forming a total of 6 segments.
I will send those 6 segments over the Internet, but I cannot guaranty the order the server will receive them. Fortunately, the TCP server rearranges out-of-order segments for me.
However, for my application, chunks A and B are completely independent, so I don't want the server to be waiting for A segments if all B segments have been received, or vice versa. In effect, I want two independent TCP sessions for chunks A and B.
Is it possible for a client and a server to have parallel, independent TCP sessions? Looking at the TCP header entries, I see no "session number". I am forced to use different source or destination ports?
I'm interested specifically in implementations of the FIX protocol over TCP, but I'm happy to discuss the problem in more generality.
Suppose that a client sends TCP segments to a server, and some of the IP packets involved get lost. Then for the TCP segments that did not arrive fully, the client will not receive an ACK. Now normally this is a cue for the client to retransmit the TCP segments, after the timeout period has elapsed.
Now let's assume instead that the client decides not to send those missing TCP segments after all. What will then happen with the incomplete set of segments that the server has correctly received?
Does the server hope for the best and assume that eventually the missing segments will arrive? Is there a time-out whereby the server clears the incomplete information from his buffer? If so, generally how long is that timeout?
Looking at this switch datasheet, the concepts of "FX port", "FX switch" and "inline FX" crop up. (The obvious Google searches are not really helpful.)
What does FX mean in the context of a network switch?
As I understand, a 10Gb Ethernet card is capable of putting 10Gb every second on (say) a fibre optics cable. Now naively, for this to happen in hardware, one will need a 10GHz clock running the network card.
It is possible to half that frequency by clocking on both edges, but 5GHz is still awefully high for transistors to support. For 100Gb Ethernet, 50GHz seems completely unreasonable.
What is the clock frequency of clocks running (say) a 10Gb Ethernet card? Are there tricks used to cut down this frequency from the "naive" 10GHz frequency?
In the context of a network switch, what exactly is "serialisation delay"? (I've heard this term a few times.) I've also heard that 10Gb Ethernet (as opposed to 1Gb Ethernet) as a transport technology helps reduce serialisation delay even when the full 10Gb bandwidth is not used.
What is serialisation delay? Why does 10Gb Ethernet help reduce it?