School me- different speed nic’s on network….

Dreamerbydesign

Supreme [H]ardness
Joined
Feb 3, 2008
Messages
6,382
*edit* may have answered my own question.
It looks like since my switch is a multi gig unit, it will negotiate the speeds with each individual nic. And it does support all of the speeds my nic’s have. So in the end theoretically each connection should negotiate its max speed with the switch.

That is the answer but I will leave this up for anyone else with the same question.

I have multiple switches that have 2.5gbe and 10gb SFP+ ports.

My SFP+ nic’s support only 10gb/1gb

Let’s say I have a computer with 1gbe nic one with 10gb sfp+ nic, and one with 2.5 gbe all plugged into the same switch.

If I am on the computer with the 2.5 gbe nic, will it be able to connect to the 10gb sfp+ computer at 2.5 or will it default to 1 gb because it’s not capable of 10 gb?

I’ve never had network cards that weren’t backward compatible. The 10gb SFP+ cards I have are not.
 
Last edited:
*edit* may have answered my own question.
It looks like since my switch is a multi gig unit, it will negotiate the speeds with each individual nic. And it does support all of the speeds my nic’s have. So in the end theoretically each connection should negotiate its max speed with the switch.

school me on this…

I have multiple switches that have 2.5gbe and 10gb SFP+ ports.

My SFP+ nic’s support only 10gb/1gb

Let’s say I have a computer with 1gbe nic one with 10gb sfp+ nic, and one with 2.5 gbe all plugged into the same switch.

If I am on the computer with the 2.5 gbe nic, will it be able to connect to the 10gb sfp+ computer at 2.5 or will it default to 1 gb because it’s not capable of 10 gb?

I’ve never had network cards that weren’t backward compatible. The 10gb SFP+ cards I have are not.
With auto-negotiation, the switch port and NIC should run at the highest speed the slower of the two is capable of.
 
Yep, you solved it. You'll get the highest bandwidth between the two points through the switch and the switch will auto negotiate the highest speed possible.

So for your example when you're on the computer with the 2.5Gb, you'll get 2.5Gb to anything 2.5Gb or higher and 1Gb to those that are only 1Gb.
 
Yep, you solved it. You'll get the highest bandwidth between the two points through the switch and the switch will auto negotiate the highest speed possible.

So for your example when you're on the computer with the 2.5Gb, you'll get 2.5Gb to anything 2.5Gb or higher and 1Gb to those that are only 1Gb.
Makes sense. I had forgot the role the switch had in the negotiation. But it all makes sense now thank you.
 
It's a packet switch, not a circuit switch. So the switch negotiates each wired connection to the best mutually supported speed on that port, and then packets come in and go out at the speed of the port involved.

So your 10g box can send 10gbps to the switch, and it'll distribute it to the rest of your network at the appropriate speeds, and vice versa. Kind of magic, you can have a 10m device hooked up to the same switch with the same wiring as a 10g-baseT device. Not great if you have more than 10mbps of broadcast garbage on your network though (not usually a problem, but could be).
 
Not great if you have more than 10mbps of broadcast garbage on your network though (not usually a problem, but could be).
But wouldn't a switch generally prevent a broadcast hitting each port since that's the whole point of a switch--independent broadcast domains? Or is it more multi-cast packets vs pure broadcast packets?
 
The point of a switch is to not flood all packets to all ports. Broadcasts have to go everywhere by design (unless you've got vlans), some switches might do multicast stuff, but I think unmanaged switches will tend to flood those too.
 
I thought that one of the things switches did was create individual broadcast domains so collisions become a thing of the past? The old school hubs used to have a collision led so you knew when it was happening and things were getting throttled. I could see multicast packets flooding but that's more a product of tcp/ip vs switching, no?
 
Switches do eliminate collisions, if everything is full duplex, and limit the scope if some ports are running at half, but it the average unmanaged switch gets a broadcast packet or a multicast packet, it's going to queue it to all ports. Otherwise, broadcast doesn't work, so you can't send a dhcp request or an arp request, and mDNS and all sorts of local discovery won't work either.

By spec, if the low bit of the first byte of the destination mac address is 1, an unmanaged switch sends it to all ports.

Implementation might be as simple as not letting those addresses into the learned address to port mapping, so it's always the case that broadcast destinations aren't a learned mac, so they get flooded.

Ethernet flow control messages are sent to a broadcast mac, which is one of the reasons it's terrible on unmanaged switches (but there's lots of other reasons).

Smarter switches can do different things for an all ones broadcast vs other broadcasts, to limit multicast to ports that are interested.
 
Let’s say I have a computer with 1gbe nic one with 10gb sfp+ nic, and one with 2.5 gbe all plugged into the same switch.

If I am on the computer with the 2.5 gbe nic, will it be able to connect to the 10gb sfp+ computer at 2.5 or will it default to 1 gb because it’s not capable of 10 gb?
TCP will figure it out unless something disables the Nagle algorithm. The Nagle algorithm figures out how fast a connection between 2 points is and limits the send rate to what the slower end can handle. That's the basic explanation. Outside of financial trading and a few other uses the Nagle algorithm is generally left on. Not using it on the Internet is basically suicide. UDP can be a lot more messy. There it's up to the application to figure out how fast to send. No help from the OS at all. There aren't a lot of apps that use UDP for full rate sends and the few that do tend to be coded with this problem in mind.

Short version is a 2.5Gb or 1Gb and 10Gb host talking to each other generally won't be a problem unless something is bugged. Like my router.
 
TCP will figure it out unless something disables the Nagle algorithm. The Nagle algorithm figures out how fast a connection between 2 points is and limits the send rate to what the slower end can handle.

TCP does that, and TCP often uses Nagle's algorithm, but Nagle's algorithm is something else. Nagle's algorithm says don't send tiny data packets unless you peer has acked everything you sent. That ends up not being great if your peer has delayed acks, which is also common; TCP_CORK/UNCORK is your friend if you can't avoid lots of syscalls to send stuff.

Generally bandwidth adaptation is part of TCP Congestion Control, if you want a nice keyword to start... Lots of improvements over time there.
 
Back
Top