multiple Layer 2 switches having brown outs, unidentified network, dhcp failures, 169 addresses etc

[markm75]

I have a series of switches installed, with fiber interconnects.

At the top most switch is this switch: HP V1810-48G (a layer 2 switch that doesnt support spanning tree although the spec seemed to say it did, but does support storm control)..

Then a newer Dlink/Dell DGS-1248T also a layer2 switch (supports spanning tree)

Then there are about 4 other DGS-12848T's which are pretty old, dating back to 2005-2008. The lowest of these from top to bottom on the rack all goto servers, though there are a few servers on the topmost one.

Randomly over the last year or so I have had ports that wont get an ip address despite lighting up on the other end of the switch. On the windows side, they show "unidentified network".. if i move the port to another one of the switches it works.

For awhile I had assumed it was just the "bad/older" switches with issues.. but recently almost half of all ports went dead on one switch, this time the newer HP switch.. I lost DHCP, many servers went to unidentified network as well as workstations.

So i'm at a loss as to whats going on here. I'm not sure if maybe this is spanning tree related, or lack of spanning tree ability on the HP at least.

My plan was to add another switch and try to isolate these one by one.. in this case adding a layer3 switch like the Cisco SG 300-52

Any thoughts as to what could be going on or how to troubleshoot this?

Thanks in advance

 

[XavierMace]

My first question is why you have your servers using DHCP addresses. Second question is what's handing out your DHCP addresses? Secondly clarify the ports "going dead". Are they actually dead, meaning no connectivity or are you just not pulling a DHCP address? Those are two very different issues.

 

[markm75]

My first question is why you have your servers using DHCP addresses. Second question is what's handing out your DHCP addresses? Secondly clarify the ports "going dead". Are they actually dead, meaning no connectivity or are you just not pulling a DHCP address? Those are two very different issues.

Sorry, maybe that post was misleading... We run a domain, the windows 2012 domain controller runs DHCP, DNS.. the servers and hardware are all static ip's (even some of the physical hardware with static ip addresses seemed to be affected as well)..

We have about 40 workstations, three hyperv servers and many VMs.. the workstations are dynamic.

But again, for some reason this "glitch" affects even static ip machines/hardware.. i guess it wasnt just DHCP.. For machines where i can view the network status this is where i see "unidentified network".. so the top HP (newest switch) seemed to have the most affected. Moving a plug from there to a lower tier one fixed the issue for now.


Going from top down its really like this..

POE switches for our IP Phones (4 of them)
Then the workstation / server switches

HP
Dlink
Dlink
Dlink
Dlink

All interconnected with fiber connects.

I dont think i have spanning tree enabled on any of the dlinks (which do support it).. technically the HP should too, but i cant find the area in the web configuration to set it, never could.

 

[Genx87]

I have a series of switches installed, with fiber interconnects.

At the top most switch is this switch: HP V1810-48G (a layer 2 switch that doesnt support spanning tree although the spec seemed to say it did, but does support storm control)..

Then a newer Dlink/Dell DGS-1248T also a layer2 switch (supports spanning tree)

Then there are about 4 other DGS-12848T's which are pretty old, dating back to 2005-2008. The lowest of these from top to bottom on the rack all goto servers, though there are a few servers on the topmost one.

Randomly over the last year or so I have had ports that wont get an ip address despite lighting up on the other end of the switch. On the windows side, they show "unidentified network".. if i move the port to another one of the switches it works.

For awhile I had assumed it was just the "bad/older" switches with issues.. but recently almost half of all ports went dead on one switch, this time the newer HP switch.. I lost DHCP, many servers went to unidentified network as well as workstations.

So i'm at a loss as to whats going on here. I'm not sure if maybe this is spanning tree related, or lack of spanning tree ability on the HP at least.

My plan was to add another switch and try to isolate these one by one.. in this case adding a layer3 switch like the Cisco SG 300-52

Any thoughts as to what could be going on or how to troubleshoot this?

Thanks in advance

Assuming you are using STP. I ran into this issue a month ago on a a set of Meraki switches. One of our switches the uplink fiber links were being tossed out of the LAG group. Kept saying they were broadcasting. And it would be random including sometimes tossing both ports. Which caused it to disconnect and throw an error. After some troubleshooting determined somehow a Sonos had taken over as the STP root. I have no idea how this happened nor it was possible. So to the other switches the root was the Sonos, this problem switch thought itself was the root. I learned a lesson to set an RSTP root on meraki switches. After a reboot of the trouble switch, it grabbed the right root(not the Sonos) and hasn't had a problem since.

Given you have different brands and models and versions of STP. I would look there. One way to test is to disable STP\RSTP on all the switches and see if it cleans up.

 

[markm75]

Assuming you are using STP. I ran into this issue a month ago on a a set of Meraki switches. One of our switches the uplink fiber links were being tossed out of the LAG group. Kept saying they were broadcasting. And it would be random including sometimes tossing both ports. Which caused it to disconnect and throw an error. After some troubleshooting determined somehow a Sonos had taken over as the STP root. I have no idea how this happened nor it was possible. So to the other switches the root was the Sonos, this problem switch thought itself was the root. I learned a lesson to set an RSTP root on meraki switches. After a reboot of the trouble switch, it grabbed the right root(not the Sonos) and hasn't had a problem since.

Given you have different brands and models and versions of STP. I would look there. One way to test is to disable STP\RSTP on all the switches and see if it cleans up.

I dont believe i ever set spanning tree on these, since the one HP didnt seem to have it. I have the two new Cisco 300 series switches coming which support spanning tree.. i may swap out the HP one for them.

I hadnt ever fully read into how to configure spanning tree.. i assumed though, that say my lowest switch i'd set as the root and then just set values up from there (not sure how this is configured exactly as of yet).. on up the tree in some manner.

 

[markm75]

Currently this is my layout, i may be begging to see possible issues with series configuration, as maybe i have issues on lower level switch ports and then it trickles up the chain or blocks the others from working at all.

Unsure the best route to take here.. i always thought it was best to use those fiber connections between them, but on these 48 port + 4 fiber switches, all you have avail is 4 ports.. not 5 or more..

I've seen diagrams for star topology and ring, unsure if those apply to switches like this situation. Note below.. where i mention these workstation ports go to random switch spots.. i mean all 6 switches, not just to the ones at the ends of the blue arrows

 

[Genx87]

Did you turn off STP and see if the issue continues?

 

[JoeBleed]

looking at this drawing, it doesn't look like you have a core switch. well, it looks like the HP V1910 is your "core" and then the rest are daisy chained down the line. this isn't the best way. It should work, but not ideal. I don't know your physical layout, but would it be possible to run a fiber cable from the HP v1910 to 4 of the closest switches and then jump from those switches to your next? How close are these switches? they're not physically stacked like this in a rack are they?

in my example, while i don't know you physical layout, i would connect something like this on a while guess at your physical layout.

HP v1910 - fiber- dlink switch A
HP v1910 - fiber- dlink switch B
HP v1910 - fiber- HPv1810
HP v1910 - fiber- dlink switch D

then from there connect the other switches to one of the other dlinks or hpv1810. unless of coarse any of these switches are close enough to be within reach of cat5/6 100 meter cable run. if they are, skip fiber to them and connect them via cat5/6 to the HPv1910.

This would potentially provide you with better performance, but that really depends on how your clients are spread out amongst the switches and the number of clients and workload. I'm only making the HPv1910 the core in my example because that's how it appears in your drawing. I'm also guessing at my proposed connection scheme just following the daisy chain in your drawing. pending physical layout and distance would/could change how i would do it.

Oh, i just caught the 500 IP phone gateway at the bottom of your chain before posting. this REALLY needs to be connected to the HP v1910 based on how you have your POE switches for your phones. And, not sure why i didn't mention this before, your servers need to be connected at the top of the chain. I'm really starting to think your problems may be stemming from your servers and phone gateway being at the bottom of your chain. At the very least that dlink switch E needs to have a direct link to the HP v1910 if it isn't possible to directly connect the servers and IP phone gateway.

 

[markm75]

Did you turn off STP and see if the issue continues?

I did, i think it is still going on at least to some degree.. biggest issue is.. i cant figure out the ip of one of the hp's and one of the dlinks, despite the fact i had it logged but it wont bring a page up on either.. i tried to find via the dlink software but nothing was found.

 

[markm75]

looking at this drawing, it doesn't look like you have a core switch. well, it looks like the HP V1910 is your "core" and then the rest are daisy chained down the line. this isn't the best way. It should work, but not ideal. I don't know your physical layout, but would it be possible to run a fiber cable from the HP v1910 to 4 of the closest switches and then jump from those switches to your next? How close are these switches? they're not physically stacked like this in a rack are they?

in my example, while i don't know you physical layout, i would connect something like this on a while guess at your physical layout.

HP v1910 - fiber- dlink switch A
HP v1910 - fiber- dlink switch B
HP v1910 - fiber- HPv1810
HP v1910 - fiber- dlink switch D

then from there connect the other switches to one of the other dlinks or hpv1810. unless of coarse any of these switches are close enough to be within reach of cat5/6 100 meter cable run. if they are, skip fiber to them and connect them via cat5/6 to the HPv1910.

This would potentially provide you with better performance, but that really depends on how your clients are spread out amongst the switches and the number of clients and workload. I'm only making the HPv1910 the core in my example because that's how it appears in your drawing. I'm also guessing at my proposed connection scheme just following the daisy chain in your drawing. pending physical layout and distance would/could change how i would do it.

Oh, i just caught the 500 IP phone gateway at the bottom of your chain before posting. this REALLY needs to be connected to the HP v1910 based on how you have your POE switches for your phones. And, not sure why i didn't mention this before, your servers need to be connected at the top of the chain. I'm really starting to think your problems may be stemming from your servers and phone gateway being at the bottom of your chain. At the very least that dlink switch E needs to have a direct link to the HP v1910 if it isn't possible to directly connect the servers and IP phone gateway.

This makes sense.. more of a star topology.. any reason why you chose the HP over the dell being in the center? As far as physical layout, yeah this is pretty much how they are in the rack.. i have the patch panel above all this.. then a few cable organizers (two of them) one a few switches down, then another a few switches below that.. along with a vertical cable organizer to the right (10 foot tall etc)..

I have some longer cables to go from the patch panel down if need be, so i could work with this, i think.

Would this layout end up being the better bet? Biggest issue being having one central switch that could fail (perhaps the need for some sort of beefy redundant switch in the middle? or just a spare?)..

 

[JoeBleed]

when you asked why i picked the HP for the core over the "dell" did you mean one of your other dlinks? I'm just going to assume yes. the only reason i did that was because it currently looked like the existing core and i wasn't sure of the physical layout. Being that they're all in the same rack, it probably doesn't matter. I'd just use which ever one has the most manageability as the core pending usage needs.

For the PoE switches, what you have is probably ok, but if which ever switch you pick to be your core has enough copper ports, i'd attach them all to the core switch with the IP phone gateway. Being layer 2 switches, as long as you don't have more than one pathway to the next/daisy chained switched and you're not stretching it too far, it should be ok. Which comes back to spanning tree. If i remember right, it was an old/early method to setup and allow redundant links. but you had to have some sort of manageability in the switch to work. which is why some switches support it and others don't. As for your use case and redundant switch pathway, it depends on the desired up-time and the cost that comes with setting it up.

the manufacturing plant i work for, our local setup is really only setup to deal with port failure connecting buildings. outside of that, we have a couple of spare switches in storage to replace one when they die. the downtime is acceptable to us. I've had to replace 2 switches after we went to HP. they come with a lifetime warranty and it was handy. no questions asked. In those cases, i get a call about some computers aren't working, i check my phone to see if i have any alerts i didn't hear and if the only computers that are down are on one switch and i can't communicate to it or i have an alert about it being down. Then i drive out, pull the old switch and stick the replacement switch in place. using it's already pre-configured "spare" config (that we load on it before storing) i can upload the saved config from my office. it reboots and everything works after that. Similar process when we had layer2 SMC switches.

 

[markm75]

when you asked why i picked the HP for the core over the "dell" did you mean one of your other dlinks? I'm just going to assume yes. the only reason i did that was because it currently looked like the existing core and i wasn't sure of the physical layout. Being that they're all in the same rack, it probably doesn't matter. I'd just use which ever one has the most manageability as the core pending usage needs.

For the PoE switches, what you have is probably ok, but if which ever switch you pick to be your core has enough copper ports, i'd attach them all to the core switch with the IP phone gateway. Being layer 2 switches, as long as you don't have more than one pathway to the next/daisy chained switched and you're not stretching it too far, it should be ok. Which comes back to spanning tree. If i remember right, it was an old/early method to setup and allow redundant links. but you had to have some sort of manageability in the switch to work. which is why some switches support it and others don't. As for your use case and redundant switch pathway, it depends on the desired up-time and the cost that comes with setting it up.

the manufacturing plant i work for, our local setup is really only setup to deal with port failure connecting buildings. outside of that, we have a couple of spare switches in storage to replace one when they die. the downtime is acceptable to us. I've had to replace 2 switches after we went to HP. they come with a lifetime warranty and it was handy. no questions asked. In those cases, i get a call about some computers aren't working, i check my phone to see if i have any alerts i didn't hear and if the only computers that are down are on one switch and i can't communicate to it or i have an alert about it being down. Then i drive out, pull the old switch and stick the replacement switch in place. using it's already pre-configured "spare" config (that we load on it before storing) i can upload the saved config from my office. it reboots and everything works after that. Similar process when we had layer2 SMC switches.

I'd share a pic of the rack, which is a huge mess right now, but its embarrassing.. it wasnt like this back in the beginning.. only since the fiasco of ports dying has it gotten unweildy looking etc.

So i guess i go with this plan, attach all servers to the core, the ip office and the sonicwall devices.. any spare room is just empty for now.. put all other workstations on the rest in that diagram.

I guess going with a spare is a better bet.. by preconfig.. you mean you gave it the exact same ip address, so if the other died you just pull it and plug it in.

The poe switches, i believe, i have those on their own vlan (at least their own vlan in the poe switches themselves.. meaning, i dont think i segregated them into a seperate vlan on the main switches.. not sure i need that or not as well.. but voice should be separated from data, but the ip office does need to talk to servers (exchange for email) at least and to the poe ports i think

 

[JoeBleed]

I under stand the shame of a messy rack. many are. it doesn't take much to screw up what was once clean but it's a challenge to fix it again. But it happens.

by preconfig, we pull it out of the box and but a bare minimum config on it that puts it in our IP address ranges and make the fiber ports work. out of the box, it's not easy to get going. well, not as easy as the preconfig works. if i didn't have a preconfig setup on it first, i'd have to configure it in my office with a console cable to my computer. with the preconfig setup, all i need to do is go swap it out and then load which ever config file that was from the switch it replaced. It makes swapping eaiser/quicker and it gives us a good opportunity to test the switch before it sits in storage to make sure it isn't DOA. Also keep in mind, the HP switches we're using are Layer 3 and take about 2-3 minutes to boot. so rebooting a few times takes more time. which is what would have to happen if i had to configure it at my desk.

As for the PoE switches and IP phone controller, we have them separated using vlans and a hybrid port the controller is connected to so the controller can talk to both without potentially flooding the data and other vlans. If you're using vlan separation or tagging, you might want to check the switch configs to make sure you can move them like you drew above compared to how they're connected currently.

 

[markm75]

I under stand the shame of a messy rack. many are. it doesn't take much to screw up what was once clean but it's a challenge to fix it again. But it happens.

by preconfig, we pull it out of the box and but a bare minimum config on it that puts it in our IP address ranges and make the fiber ports work. out of the box, it's not easy to get going. well, not as easy as the preconfig works. if i didn't have a preconfig setup on it first, i'd have to configure it in my office with a console cable to my computer. with the preconfig setup, all i need to do is go swap it out and then load which ever config file that was from the switch it replaced. It makes swapping eaiser/quicker and it gives us a good opportunity to test the switch before it sits in storage to make sure it isn't DOA. Also keep in mind, the HP switches we're using are Layer 3 and take about 2-3 minutes to boot. so rebooting a few times takes more time. which is what would have to happen if i had to configure it at my desk.

As for the PoE switches and IP phone controller, we have them separated using vlans and a hybrid port the controller is connected to so the controller can talk to both without potentially flooding the data and other vlans. If you're using vlan separation or tagging, you might want to check the switch configs to make sure you can move them like you drew above compared to how they're connected currently.

Well, ok, here is a pic.. prior to the down time 10 days ago (i wasnt here) it was tied up and neat, now its a disaster for now.. we have another rack to the right with servers and a giant UPS system on the right is a vertical organizational box

That cisco 300 level, layer3 switch x 3 is still on the way.. i still have one dlink that is dark, so it will go away.. along with two others, maybe buy one more as the spare.. that still leaves 3 "old" switches which are still layer2

 

[JoeBleed]

http://www.cisco.com/c/en/us/products/switches/small-business-300-series-managed-switches/index.html

Are these the switches you're getting? If so, am i reading that right in that the main rj45 ports are only 10/100?? If so, did you catch that? Are they PoE?

 

[markm75]

http://www.cisco.com/c/en/us/products/switches/small-business-300-series-managed-switches/index.html

Are these the switches you're getting? If so, am i reading that right in that the main rj45 ports are only 10/100?? If so, did you catch that? Are they PoE?

Not quite.. maybe same line, but specifically these.. 52 gigabit: (300-52)

https://www.amazon.com/Cisco-SG-300-52-SRW2048-K9-NA-52-Port/dp/B0041ORNCY/ref=cm_cd_al_qh_dp_t#Ask

 

[JoeBleed]

yea, i kept looking through the many different models of that line and did find some that where 10/100/1000. I'm surprised so many of them are only 10/100.

Do let us know how changing them out goes. Or the rewiring if you do that first.

 

[markm75]

yea, i kept looking through the many different models of that line and did find some that where 10/100/1000. I'm surprised so many of them are only 10/100.

Do let us know how changing them out goes. Or the rewiring if you do that first.

Will do.. definitely rewiring, pulling all wires and reorganizing the mess.

One other sub note here.. i read that maybe i could take two of these cisco switches and turn it into one big virtual switch via trunking somehow? In doing this, say you call the core E1 and E2.. if E1 goes down, then the whole thing continues to function.. only thing is, i dont see how, if E1 is dead and most servers are there and its dark, how does the physical wire get a signal if the port is dead.. unclear on that route

 

[JoeBleed]

i forget what it's called for HP, but it has that option and that's how our cores are setup. for the fail over for the servers to work, you have to have a cable to both switches from the server. For everything you want to stay up. Like i said, doing this can get expensive. Granted, the extra network cable isn't that much. It comes down to how much uptime do you need and how important is that uptime. we're only setup for failover for building links. Corporate office didn't even want to bother setting it up for our local VM host. it really would only take an extra cable because the host has a 4 port nic. The more uptime you want the more duplication you need. Cables, cards, ports, power supplies, different power sources, VM Hosts, SANs, Locations and such.

Edit: ~knock on wood~ i have yet to replace a core switch though. they're the ones that get the decent climate controlled environment vrs the others that get the manufacturing floor. And keep in mind, with our HPs, not sure about Cisco, they required a special cable/card for the back of the switches to set them up like this. I don't think you could do it with just the gbic or copper ports. i don't think.

 

[markm75]

i forget what it's called for HP, but it has that option and that's how our cores are setup. for the fail over for the servers to work, you have to have a cable to both switches from the server. For everything you want to stay up. Like i said, doing this can get expensive. Granted, the extra network cable isn't that much. It comes down to how much uptime do you need and how important is that uptime. we're only setup for failover for building links. Corporate office didn't even want to bother setting it up for our local VM host. it really would only take an extra cable because the host has a 4 port nic. The more uptime you want the more duplication you need. Cables, cards, ports, power supplies, different power sources, VM Hosts, SANs, Locations and such.

Edit: ~knock on wood~ i have yet to replace a core switch though. they're the ones that get the decent climate controlled environment vrs the others that get the manufacturing floor. And keep in mind, with our HPs, not sure about Cisco, they required a special cable/card for the back of the switches to set them up like this. I don't think you could do it with just the gbic or copper ports. i don't think.

Ah that makes perfect sense the dual cables.. however.. not sure how your virtualization is setup, ours.. we use hyperv.. i believe i have roughly 3 ports or 4 available for ethernet on each.. two are bonded together as a managed port while the others go as hyperv virtual switch ports.. i think they are bonded too, maybe i have more than 4 i forget.. so if this is the case.. i'm not sure how it would help.. ie: the VM's only can chose one virtual port at a time.. so if i had 2 going to switch E1 and 2 going to E2, it would be a one or other situation.. or maybe there is a way to arrange this so it would in fact work, unsure.. to me sounds like far more work than just having that hot spare E2 switch ready to go if E1 goes belly up, ever

also.. i tried digging into the dlink switches for log info to help sort why some ports are bombing out or lagging behind like they are.. there is no relevant info here to even have a glimpse of an idea why.. i hate not knowing what truly caused this, but i still suspect daisy chained cascading failure.

 

[MushyNAT]

I ran into a very similar problem in one of our offices just a few months ago, but with a Dell Poweredge switch and VLAN tagging. Ports were dropping VLAN tags for voip traffic, random ports would just stop functioning altogether, etc despite the features we were using being "supported" in the product documentation. This thing just would not play nice with our Cisco switches no matter what we did, the implementation of the protocol being used must have been different in some way where it refused to work properly.

Ultimately the only way to solve the issue was to return the switch and buy another Cisco switch. Thus is the trouble with mismatched network hardware sometimes.

Have you looked into the simpler solutions yet? Maybe a known bug that a firmware update will eliminate? God knows I've wasted enough hours jumping into an assumption that an issue is complex and technical when the solution was super simple.

 

[markm75]

I expanded my horizons instead of jumping on the cisco for now..
I thought i had a better solution but now unsure..

I had found awesome pricing on hp J9050A procurve 2900 series switches (roughly $200 - $290 each, with 1 year vendor warranty and lifetime hp)..

Advantages.. act as one single management ip and can do all the vlans over 7 of these switches and still point to the existing 3 POE switches for that vlan..
however.. turns out its not a true stack solution.. not sure that if one goes out the rest can still communicate to servers on the dead switch(es).. seems only the 2920 can do that..

There is the hp 2920 series, but the price ends up being close to $6k which wont fly here.. $3k for the 2900 with its connections would be ok..

Alternatively there is the 500 series from cisco.. stackable.. but too pricey as well.

So its either i go for the 2900 series refurbs (which are dated back as far as 2008 i think too) and have better management and maybe better performance.. or stick with the hodge podge plan of a cisco as the center of a star setup as the core switch with one on the backburner.

 

[markm75]

So given the financial difficulty of doing a truly stackable switch like the cisco 500 or hp 2920.. leads me back to square one using 3 new ciscos and 1 hot spare in a star configuration and dealing with multiple configs and vlans on each one.. (EDIT: looks like it may be possible to get a 500 series cisco for $529 refurbished unsure what the difference is between sf and sg? scratch that, it was only 10/100 on most ports)

I did have vlans working at some point, but havent had a real need till now and never this complicated... i had a general understanding on how to link the vlans.. not sure if its 100% accurate..

Lets say I had workstations plugged into a cisco and dlink satellite switches off the cisco at the core.. so 48 ports x2 available for vlanning..

Would I set cisco satellite E1 ports 1-48 say VLAN ID #2.. then the dlink 1-48 would also be VLAN ID #2 (even though a different vendor).. then at the cisco at the core.. I would have two ports going to each of those satellite switches and assign a tagged vlan ID of #2 to each one of those?

then the question is.. if I have say vlan id #1 for servers on the core switch on say ports 1-30, how do I make sure vlan id #1 (servers) can route to vlan id #2 (workstations), not shown are the other forks of the core.. or the POE1-3 that would go into 3 of the satellites as well.

 

[JoeBleed]

If possible, I'd use either the Cisco switches as your core and try and make any of the others more or less dub switches that branch off of the Cisco switches. that means disabling features on them. But this only works if things you're plugging into the branched switches are all on the same vlan. I'd say vlaning between venders should work, but who knows. doesn't look like spanning tree works too well between venders.

If you set say port 2 on Cisco E1 to vlan2 and you disable all features on Dlink D1 to make it nearly a dumb switch, everything you pug into it should be on vlan2. maybe. It works this way with real dumb switches, not sure if vlan capable switches would work in this manner or if they'll default to vlan1. I've never actually tried this. If it doesn't work, you can try replicating the vlan config on them to see if that works.

As for how do things on different vlans talk to each other, that's where you'll have to setup routing in the cisco switches. assuming they're layer3 and have routing. I think i read they did last week. You'll probably have to manually setup the routes.

I must say i'm also not sure how connecting different vender fiber ports will work out. I've had bad results when we were trying to keep an old SMC switch section around for a little longer. they didn't like talking to the HP. Could have been a simple config error we missed or just incompatibility. we were in a hurry and made use of the old fiber run and one of the SMC switches we pulled from another location.

 

[markm75]

If possible, I'd use either the Cisco switches as your core and try and make any of the others more or less dub switches that branch off of the Cisco switches. that means disabling features on them. But this only works if things you're plugging into the branched switches are all on the same vlan. I'd say vlaning between venders should work, but who knows. doesn't look like spanning tree works too well between venders.

If you set say port 2 on Cisco E1 to vlan2 and you disable all features on Dlink D1 to make it nearly a dumb switch, everything you pug into it should be on vlan2. maybe. It works this way with real dumb switches, not sure if vlan capable switches would work in this manner or if they'll default to vlan1. I've never actually tried this. If it doesn't work, you can try replicating the vlan config on them to see if that works.

As for how do things on different vlans talk to each other, that's where you'll have to setup routing in the cisco switches. assuming they're layer3 and have routing. I think i read they did last week. You'll probably have to manually setup the routes.

I must say i'm also not sure how connecting different vender fiber ports will work out. I've had bad results when we were trying to keep an old SMC switch section around for a little longer. they didn't like talking to the HP. Could have been a simple config error we missed or just incompatibility. we were in a hurry and made use of the old fiber run and one of the SMC switches we pulled from another location.

I think its too much of (another) nightmare to try to mix all these together.

I think all paths lead to one of three options here.. (to get to at least 7 switches and then patch in the old 3 poe switches for now)

Either cisco SG500's (max of 6 in a stack, $755 refurb price, $999 new), the 2960-x-48TS-L (new $1094, no real refurb prices) which can do 9 in a stack, the hp 2920 (New $1291, refurb $793) which can do 4 in a stack (but has expensive 2 port stacking modules needed x 2?), or the dell 6248 which also has POE and seems to only be $899 refurbed (unsure if lifetime warranty on the dell?)