Time to gut the network - thoughts?
-
@Dashrender said in Time to gut the network - thoughts?:
Three of the switches are in one building, two are in the other. Do the stacked switches work over ethernet connections?
No, not really. It wouldn't be a functional stack if it did. You'd have a terrible backplane problem.
-
@scottalanmiller said in Time to gut the network - thoughts?:
If possible, I'd flatten the network
and stack the switchesas the first step. Simplicity is its own reward. Less to manage, better performance.Yes I'd like to do that.
current VLAN setup
VLAN 1 192.168.1.x/24 servers/PCs/printers VLAN 2 192.168.150.x/24 Phones (the phones are programmed to be on this VLAN VLAN 105 192.168.105.x/24 wireless VLAN 17 10.10.10.x/28 imaging Remote site 192.168.5.x/24 remote location (no VLAN tags)From this information, I believe that I can expand the VLAN1 (default VLAN) to 192.168.0.x/22 without affecting any of the other VLANs and move the laptops and phones into the expanded network at my own pace, but I would have to have the VLANs active while doing so.
Comments, concerns?
-
@Dashrender said in Time to gut the network - thoughts?:
VLAN 17 10.10.10.x/28 imagingThere is currently a plan being made to make VLAN 17 be completely independent, i.e. share no hardware with the rest of the network. This will require a ER with fiber GBIC/SFP in building 1 connected to a private MAN connection (copper based) to another client, and internally connected to the private fiber to building 2. In building two I'll have the smallest EdgeSwitch with an SFP port to plug in fiber. The devices for this network would be be plugged into this switch.
Should I use VLAN instead to deliver this of splitting it to it's own hardware? ensuring that NO traffic passes between this imaging network and my production network is critical. If the EdgeSwitch supports ACLs (which I read it does) then I should be able to do it completely with VLANs without risking my network.Thoughts?
-
@scottalanmiller said in Time to gut the network - thoughts?:
@Dashrender said in Time to gut the network - thoughts?:
Three of the switches are in one building, two are in the other. Do the stacked switches work over ethernet connections?
No, not really. It wouldn't be a functional stack if it did. You'd have a terrible backplane problem.
LOL, yeah if backplaning is a requirement of the stack, than yeah.. that would be bad! Though I'm pretty sure I read that HP switches in the past could be centrally managed through a master switch, but the backplanes would be all internal to each switch.
in any case, having them split mostly makes the need/desire for stacking not really desired/cared about.
-
@Dashrender said in Time to gut the network - thoughts?:
@scottalanmiller said in Time to gut the network - thoughts?:
If possible, I'd flatten the network
and stack the switchesas the first step. Simplicity is its own reward. Less to manage, better performance.Yes I'd like to do that.
current VLAN setup
VLAN 1 192.168.1.x/24 servers/PCs/printers VLAN 2 192.168.150.x/24 Phones (the phones are programmed to be on this VLAN VLAN 105 192.168.105.x/24 wireless VLAN 17 10.10.10.x/28 imaging Remote site 192.168.5.x/24 remote location (no VLAN tags)From this information, I believe that I can expand the VLAN1 (default VLAN) to 192.168.0.x/22 without affecting any of the other VLANs and move the laptops and phones into the expanded network at my own pace, but I would have to have the VLANs active while doing so.
Comments, concerns?
This is how I would handle a migration to a flat network.
-
Speaking about a flat switched network - OK so my phone vendor is adamant I need QoS to ensure I don't have phone quality issues. What respectable publications can I point to that say this isn't a typical concern anymore?
Looking at you mostly @scottalanmiller
-
@Dashrender said in Time to gut the network - thoughts?:
Speaking about a flat switched network - OK so my phone vendor is adamant I need QoS to ensure I don't have phone quality issues. What respectable publications can I point to that say this isn't a typical concern anymore?
Looking at you mostly @scottalanmiller
I would say every source would insist you have QoS enabled.
Not the other way around...
-
@DustinB3403 said in Time to gut the network - thoughts?:
@Dashrender said in Time to gut the network - thoughts?:
Speaking about a flat switched network - OK so my phone vendor is adamant I need QoS to ensure I don't have phone quality issues. What respectable publications can I point to that say this isn't a typical concern anymore?
Looking at you mostly @scottalanmiller
I would say every source would insist you have QoS enabled.
Not the other way around...
OK that's fine to - guides/recommendations for that setup? Focusing specifically on the switches.
-
@Dashrender said in Time to gut the network - thoughts?:
Speaking about a flat switched network - OK so my phone vendor is adamant I need QoS to ensure I don't have phone quality issues. What respectable publications can I point to that say this isn't a typical concern anymore?
Looking at you mostly @scottalanmiller
You vendor is 100% correct in that statement as you just typed it. You are required to use QoS on all switches and routers in your control to ensure quality.
The point you glossed here is that you need said QoS on the traffic not an entire VLAN. Every reputable SIP device uses DSCP tagging. So what you would do is set QoS on DSCP 46 (RTP the voice) and 26 (SIP the signaling) traffic.
Those examples are what my Yealink phones use by default to communicate to the FreePBX server and is the traffic going out my WAN.
You generally will never see QoS applied on your switch unless a port is saturated.
You will see the QoS applied all the time on your routers assuming you are decently normal. It gets hit in spikes most of the time, not consistently.
-
I guess I didn't quote it well enough, let me try to recreate the conversation.
ME: I want to make my whole network flat and put the phones on the same network as everything else.
Vendor: we don't advise this, you should put the phones on a VLAN so you can have QoS for calls, otherwise we have no assurances of voice quality. -
@Dashrender said in Time to gut the network - thoughts?:
I guess I didn't quote it well enough, let me try to recreate the conversation.
ME: I want to make my whole network flat and put the phones on the same network as everything else.
Vendor: we don't advise this, you should put the phones on a VLAN so you can have QoS for calls, otherwise we have no assurances of voice quality.That's nothing at all like you said in the last statement. QoS is good, VLANs don't do what they are claiming and, as you showed, the vendor implemented incorrectly and left you without any actual QoS.
-
@Dashrender said in Time to gut the network - thoughts?:
Speaking about a flat switched network - OK so my phone vendor is adamant I need QoS to ensure I don't have phone quality issues. What respectable publications can I point to that say this isn't a typical concern anymore?
Looking at you mostly @scottalanmiller
So the questions are...
-
Why do you need to ensure it? THis is a scare tactic. Start here. Say "ensure it"? Why do I need to ensure something that we've never needed to ensure before? What's the ACTUAL risk that you are trying to protect me against... because it's never come up and we have no reason to believe it could be a problem so why are we worried about "ensuring" anything?
-
If we need QoS, why haven't we had it all this time but had screwed up VLANs instead without QoS working? ANd if it is so important, how has it worked so long perfectly without it?
-
-
@JaredBusch said in Time to gut the network - thoughts?:
Every reputable SIP device uses DSCP tagging. So what you would do is set QoS on DSCP 46 (RTP the voice) and 26 (SIP the signaling) traffic.
Most shady ones too.
-
@scottalanmiller said in Time to gut the network - thoughts?:
@Dashrender said in Time to gut the network - thoughts?:
Speaking about a flat switched network - OK so my phone vendor is adamant I need QoS to ensure I don't have phone quality issues. What respectable publications can I point to that say this isn't a typical concern anymore?
Looking at you mostly @scottalanmiller
So the questions are...
-
Why do you need to ensure it? THis is a scare tactic. Start here. Say "ensure it"? Why do I need to ensure something that we've never needed to ensure before? What's the ACTUAL risk that you are trying to protect me against... because it's never come up and we have no reason to believe it could be a problem so why are we worried about "ensuring" anything?
-
If we need QoS, why haven't we had it all this time but had screwed up VLANs instead without QoS working? ANd if it is so important, how has it worked so long perfectly without it?
Well, as you said, this statement is/was wrong.
So I'm starting over by asking my vendor to reply to the following:I’m looking to redesign my network to get rid of the VLANs and make everything flat. In our previous discussions you cautioned against not putting the phones in their own VLAN – do I recall that correctly? Assuming I recall this correctly, what’s the reasoning behind that?
I'll let you know their response.
-
-
@Dashrender said in Time to gut the network - thoughts?:
I’m looking to redesign my network to get rid of the VLANs and make everything flat. In our previous discussions you cautioned against not putting the phones in their own VLAN – do I recall that correctly? Assuming I recall this correctly, what’s the reasoning behind that?
I'll let you know their response.
You might want to LEAD with.... since we discovered that QoS was not set up properly and has never been a problem we can assume that QoS and ensuring call quality cannot be the reason.
Let them come up with a reason if you head that off at the pass.
-
@scottalanmiller said in Time to gut the network - thoughts?:
@Dashrender said in Time to gut the network - thoughts?:
I’m looking to redesign my network to get rid of the VLANs and make everything flat. In our previous discussions you cautioned against not putting the phones in their own VLAN – do I recall that correctly? Assuming I recall this correctly, what’s the reasoning behind that?
I'll let you know their response.
You might want to LEAD with.... since we discovered that QoS was not set up properly and has never been a problem we can assume that QoS and ensuring call quality cannot be the reason.
Let them come up with a reason if you head that off at the pass.
Time out for a second...
JB says he doesn't do anything internal to the switches to setup/ensure, whatever you wanna call it, QoS. But that the handsets themselves set these tags themselves (and @scottalanmiller agreed with that).So my question is - do my switches honor those tags by default? Do VLANs make any difference in this? i.e. if a QoS tagged packet is on VLAN 2, and traffic on VLAN 1 is peaking the ports out, does the switch allow the QoS Tag on VLAN 2 to win out?
or is the switch ignoring these packets unless the switch is specifically setup to honor them?
Please keep in mind - I have ZERO SIP/DSCP traffic going out my WAN ports. All traffic is local on my network only.
-
@Dashrender said in Time to gut the network - thoughts?:
Time out for a second...
JB says he doesn't do anything internal to the switches to setup/ensure, whatever you wanna call it, QoS. But that the handsets themselves set these tags themselves (and @scottalanmiller agreed with that).All agreed. Doing internal QoS is 99% of the time just ridiculous. If a consultant is telling you that you need that without a very specific "your network is screwed royally and we aren't going to fix it" reason, it's a scam.
And yes, the handsets are prepared for proper QoS out of the gate.
-
@Dashrender said in Time to gut the network - thoughts?:
So my question is - do my switches honor those tags by default? Do VLANs make any difference in this? i.e. if a QoS tagged packet is on VLAN 2, and traffic on VLAN 1 is peaking the ports out, does the switch allow the QoS Tag on VLAN 2 to win out?
So a bunch of thoughts...
- It depends on the switch. Not likely, you need to tell the switches how you want the tagged traffic treated.
- VLANs break this, obvious, you'd prioritized something else explicitly.
- It doesn't matter on the LAN, that's a sales tactic.
-
@scottalanmiller said in Time to gut the network - thoughts?:
the vendor implemented incorrectly and left you without any actual QoS.
We do not know that. QoS at the VLAN level exists and is what most people assume is working. If implemented, he has perfectly working QoS. It is prioritizing more than just the RTP, that is true. But as long as only phones are on that VLAN, and proper IEEE 802.1Q is setup, there is QoS.
So please do not over simplify.
-
@scottalanmiller said in Time to gut the network - thoughts?:
@Dashrender said in Time to gut the network - thoughts?:
So my question is - do my switches honor those tags by default? Do VLANs make any difference in this? i.e. if a QoS tagged packet is on VLAN 2, and traffic on VLAN 1 is peaking the ports out, does the switch allow the QoS Tag on VLAN 2 to win out?
So a bunch of thoughts...
- It depends on the switch. Not likely, you need to tell the switches how you want the tagged traffic treated.
- VLANs break this, obvious, you'd prioritized something else explicitly.
- It doesn't matter on the LAN, that's a sales tactic.
- True it is not likely
- VLAN alone does nothing to break QoS. See previous post.
- It most certainly can matter in the LAN. An office can have bursts traffic that can cause degradation of voice quality. It is not common though.
