Time to gut the network - thoughts?

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

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?

scottalanmiller

@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.

Dashrender

@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.

scottalanmiller

@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.

Dashrender

@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.

scottalanmiller

@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.

scottalanmiller

@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.

JaredBusch

@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.

JaredBusch

@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.

scottalanmiller

@JaredBusch said in Time to gut the network - thoughts?:

We do not know that. QoS at the VLAN level exists and is what most people assume is working.

I thought that the issue was that he did not have QoS hitting the WAN. But he has no VoIP to the WAN, I had missed that part.

scottalanmiller

@JaredBusch said in Time to gut the network - thoughts?:

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.

Not on A LAN, on the meaning "this" LAN. He and I had discussed offline that he has no traffic that ever would trigger the QoS system.

JaredBusch

@scottalanmiller said in Time to gut the network - thoughts?:

@JaredBusch said in Time to gut the network - thoughts?:

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.

Not on A LAN, on the meaning "this" LAN. He and I had discussed offline that he has no traffic that ever would trigger the QoS system.

In that case I agree that it is not needed in any fashion.

JaredBusch

@Dashrender said in Time to gut the network - thoughts?:

@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.

A point of note here is that DSCP is at the IP level and 802.1Q is at the VLAN level.

These are totally different processes.

Dashrender

@scottalanmiller said in Time to gut the network - thoughts?:

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.

I want to make sure I fully understand why we can say without a doubt that QoS wasn't setup properly, or at least not optimally.

Here's the current config

 hostname "Main Backbone HP 2824"
 snmp-server contact "Dash"
 snmp-server location "Building 1"
 ip default-gateway 192.168.1.1
ip routing
 ip zero-broadcast
 vlan 1
    name "DEFAULT_VLAN"
    untagged 2-17,19-23
    ip address 192.168.1.2 255.255.255.0
    no untagged 1,18,24
    exit
 vlan 2
    name "VOICE"
    untagged 1
    ip address 192.168.150.2 255.255.255.0
    qos priority 7
    tagged 3-20,24
    exit
 vlan 105
    name "WIRELESS"
    ip address 192.168.105.2 255.255.255.0
    tagged 2-21
    exit
 vlan 17
    name "IMAGING"
    untagged 18
    ip address 10.10.10.1 255.255.255.240
    tagged 24
    exit
 fault-finder bad-driver sensitivity high
 fault-finder bad-transceiver sensitivity high
 fault-finder bad-cable sensitivity high
 fault-finder too-long-cable sensitivity high
 fault-finder over-bandwidth sensitivity high
 fault-finder broadcast-storm sensitivity high
 fault-finder loss-of-link sensitivity high
 fault-finder duplex-mismatch-HDx sensitivity high
 fault-finder duplex-mismatch-FDx sensitivity high

I read the QoS under VLAN 2 to mean that all VLAN 2 traffic will have higher priority than any other VLAN. Considering only phones and the PBX are on VLAN 2, wouldn't this accomplish the goal of my vendor? If I'm correct in my understanding, it's not optimal, but it works.

JaredBusch

@Dashrender said in Time to gut the network - thoughts?:

@scottalanmiller said in Time to gut the network - thoughts?:

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.

I want to make sure I fully understand why we can say without a doubt that QoS wasn't setup properly, or at least not optimally.

Here's the current config
 hostname "Main Backbone HP 2824"
 snmp-server contact "Dash"
 snmp-server location "Building 1"
 ip default-gateway 192.168.1.1
ip routing
 ip zero-broadcast
 vlan 1
    name "DEFAULT_VLAN"
    untagged 2-17,19-23
    ip address 192.168.1.2 255.255.255.0
    no untagged 1,18,24
    exit
 vlan 2
    name "VOICE"
    untagged 1
    ip address 192.168.150.2 255.255.255.0
    qos priority 7
    tagged 3-20,24
    exit
 vlan 105
    name "WIRELESS"
    ip address 192.168.105.2 255.255.255.0
    tagged 2-21
    exit
 vlan 17
    name "IMAGING"
    untagged 18
    ip address 10.10.10.1 255.255.255.240
    tagged 24
    exit
 fault-finder bad-driver sensitivity high
 fault-finder bad-transceiver sensitivity high
 fault-finder bad-cable sensitivity high
 fault-finder too-long-cable sensitivity high
 fault-finder over-bandwidth sensitivity high
 fault-finder broadcast-storm sensitivity high
 fault-finder loss-of-link sensitivity high
 fault-finder duplex-mismatch-HDx sensitivity high
 fault-finder duplex-mismatch-FDx sensitivity high
I read the QoS under VLAN 2 to mean that all VLAN 2 traffic will have higher priority than any other VLAN. Considering only phones and the PBX are on VLAN 2, wouldn't this accomplish the goal of my vendor? If I'm correct in my understanding, it's not optimal, but it works.

Correct you do have QoS. It is on the VLAN, that contains the voice devices.

Dashrender

@JaredBusch said in Time to gut the network - thoughts?:

Correct you do have QoS. It is on the VLAN, that contains the voice devices.

So the following is an incorrect assumption.

@scottalanmiller said in Time to gut the network - thoughts?:

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.

JaredBusch

@Dashrender said in Time to gut the network - thoughts?:

@JaredBusch said in Time to gut the network - thoughts?:

Correct you do have QoS. It is on the VLAN, that contains the voice devices.

So the following is an incorrect assumption.

@scottalanmiller said in Time to gut the network - thoughts?:

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.

Correct. You have proper VLAN QoS setup. You do not technically have proper QoS on your voice traffic though. It is a distinction, but one that is honestly irrelevant.

scottalanmiller

@Dashrender said in Time to gut the network - thoughts?:

I read the QoS under VLAN 2 to mean that all VLAN 2 traffic will have higher priority than any other VLAN. Considering only phones and the PBX are on VLAN 2, wouldn't this accomplish the goal of my vendor? If I'm correct in my understanding, it's not optimal, but it works.

Isn't the goal to prioritize voice traffic, not just "any" traffic on a voice network?

scottalanmiller

@JaredBusch said in Time to gut the network - thoughts?:

Correct. You have proper VLAN QoS setup. You do not technically have proper QoS on your voice traffic though. It is a distinction, but one that is honestly irrelevant.

Right. It's QoS, just not the right QoS. And it doesn't matter because you have no need for QoS at all.

scottalanmiller

@Dashrender said in Time to gut the network - thoughts?:

@JaredBusch said in Time to gut the network - thoughts?:

Correct you do have QoS. It is on the VLAN, that contains the voice devices.

So the following is an incorrect assumption.

@scottalanmiller said in Time to gut the network - thoughts?:

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.

No, it's correct. They didn't do their jobs properly. They neither did the sensible, cost effective thing for the business, which would have been to not have a VLAN at all. Nor did they properly do QoS for your VoIP traffic.

So no matter what, they didn't set up QoS correctly for you.