Personal computing discussed
Moderators: renee, Steel, notfred
UberGerbil wrote:What happens in 6 months when a new manager (or an old manager just back from a "retreat" / "training session" / whatever) decides to reorganize the cube-farm in a different layout, or do away with it entirely in favor of the alternative-du-jour?
|FN|Steel wrote:I have a friend suggesting, in a new building my company is moving to, that I assign IP addresses--on a per line basis--to the cube farm in the building. Setting up a grid of sorts so that we would just know which IP a cube had.
At the physical layer, I already have things mapped out from the previous owners, and simple need to connect new switches. I'm already thinking that knowing the switch port each Cube address is attached to is an excellent idea, but I'm struggling to find value in what my friend is suggesting. It seems to me like it would take considerable setup and I'm really unsure as to the actual payoff.
Thoughts?
SecretSquirrel wrote:Oh, and you do have managed switches all the way out to the perimeter, yes? Its necessary for the above to work well and it lets you determine when someone has brought in their own networking gear. You will see multiple active MAC addresses on a single port, where their shouldn't be.
SecretSquirrel:How would you assign the IPs to the cubes? DHCP works based on MAC addresses, which are tied to the machine. Static assignments mean touching every machine, and updating them every time someone moves. That sounds like a nightmare to me.
just brew it! wrote:I am not very familiar with managed switches, but it is normally the job of a DHCP server (not the switches) to hand out IP addresses. If the IPs are explicitly assigned (instead of being doled out from a pool), they are generally tied to MAC addresses, not switch ports. So the IPs follow machines around, instead of being tied to specific jacks.
|FN|Steel wrote:This is my thought as well. I think he's suggesting the DHCP server would hand out the IPs to the specific switch port. NO CLUE how.
|FN|Steel wrote:As for multiple wired devices at each cube, they're already wired that way for one connection, and I don't foresee any reason for multiple devices at cubes.
Convert wrote:Guess it depends on the company but there's always a few who end up with personal network printers for one reason or another. Just don't be the guy who puts a cheap 5 port gigabit switch in every office when you realize 1 port isn't enough.
|FN|Steel wrote:just brew it! wrote:I am not very familiar with managed switches, but it is normally the job of a DHCP server (not the switches) to hand out IP addresses. If the IPs are explicitly assigned (instead of being doled out from a pool), they are generally tied to MAC addresses, not switch ports. So the IPs follow machines around, instead of being tied to specific jacks.
This is my thought as well. I think he's suggesting the DHCP server would hand out the IPs to the specific switch port. NO CLUE how.
just brew it! wrote:What exactly does he think will be "made easier" by doing this? It is looking like the hassle setting up and maintaining it outweighs any potential benefit.
notfred wrote:As others have said, this sounds weird. Definitely have the switch port to cube mapping sorted and have managed switches so that you can sort out MAC address to cube mapping. Someone WILL do something bad on the network and being able to track it back to the cube is all you need.
notfred wrote:The classic scenario at out place is someone plugging in the LAN port of a WiFi router to run some WiFi tests. Suddenly you have a rogue DHCP server on your network and half the machines don't work. If you capture the DHCP packet exchange you can see the MAC address of the rogue server and then look in the managed switch MAC address to port mapping tables to determine which switch port it is on. Then a quick cross reference to the switch port to cube mapping and it is time to deploy the LART
SecretSquirrel wrote:Our best one was in a development lab. Someone plugged a switch into the wall. Later, they daisy-chained a second switch. At some point after that, a second person was trying to figure out why something wasn't working and looked at the second switch. "Oh, it's not connected to the corporate network, that must be it...", and plugged the second switch into a different wall jack. At the time, the datacenter and building shared the same core switches...
|FN|Steel wrote:I have a friend suggesting, in a new building my company is moving to, that I assign IP addresses--on a per line basis--to the cube farm in the building. Setting up a grid of sorts so that we would just know which IP a cube had.
just brew it! wrote:SecretSquirrel wrote:Our best one was in a development lab. Someone plugged a switch into the wall. Later, they daisy-chained a second switch. At some point after that, a second person was trying to figure out why something wasn't working and looked at the second switch. "Oh, it's not connected to the corporate network, that must be it...", and plugged the second switch into a different wall jack. At the time, the datacenter and building shared the same core switches...
A couple of jobs ago we had something similar happen. One of the electronics techs created a network loop by cross-connecting a couple of bench top switches in the hardware lab. Not only did it take out the entire office network, it killed one of the switches! This was back in the "capacitor plague" era; the failing switch had some marginal capacitors in it, and apparently the additional heat generated in the switch by the resulting packet storm (it was *very* warm to the touch) finally pushed it over the edge. I spent the next hour or two finding all of the switches of that make/model around the office, opening them up, and checking for bulging capacitors (and yes, there were several more that were ticking time bombs).
homerdog wrote:just brew it! wrote:A couple of jobs ago we had something similar happen. One of the electronics techs created a network loop by cross-connecting a couple of bench top switches in the hardware lab. Not only did it take out the entire office network, it killed one of the switches! This was back in the "capacitor plague" era; the failing switch had some marginal capacitors in it, and apparently the additional heat generated in the switch by the resulting packet storm (it was *very* warm to the touch) finally pushed it over the edge. I spent the next hour or two finding all of the switches of that make/model around the office, opening them up, and checking for bulging capacitors (and yes, there were several more that were ticking time bombs).
Loop detection or STP didn't stop this? Maybe this was in an era before all that fancy stuff.
STP can be a bitch to set up, but when it works it is very nice IMO.
just brew it! wrote:homerdog wrote:just brew it! wrote:A couple of jobs ago we had something similar happen. One of the electronics techs created a network loop by cross-connecting a couple of bench top switches in the hardware lab. Not only did it take out the entire office network, it killed one of the switches! This was back in the "capacitor plague" era; the failing switch had some marginal capacitors in it, and apparently the additional heat generated in the switch by the resulting packet storm (it was *very* warm to the touch) finally pushed it over the edge. I spent the next hour or two finding all of the switches of that make/model around the office, opening them up, and checking for bulging capacitors (and yes, there were several more that were ticking time bombs).
Loop detection or STP didn't stop this? Maybe this was in an era before all that fancy stuff.
STP can be a bitch to set up, but when it works it is very nice IMO.
The facility had been set up on a shoestring budget, and the network grew organically. I (only half) jokingly claimed that there should've been a sign on the wall of the lab that said "Powered by eBay". We were literally buying multiple used, half-dead, near-antique logic analyzers of the same model off the internet, in order to cobble together a smaller number of working units from the bits.
Working for start-ups is fun.