Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Multiple voice VLANs

Status
Not open for further replies.

dot1q

Vendor
Jun 24, 2008
3
NO
Hello,

We have a scenario where the following configuration is requested:

1 shared, untagged DATA vlan
10 tagged VOICE vlans on 10 IP subnets

In this setup, DHCP Option 43 cannnot be used, as it can only distribute 3 VLAN IDs

Apparently the VLAN IDs must be distributed from different configuration files organized in a tree structure on the SW-server. This can be done using domain-names or IP-subnet + netmask as the folder name. Ie: 0.1.100-24 etc.

All the L2 switches has one native and one tagged VLAN per port. They are connected to a L3 switch configured with a DHCP Relay. The DHCP-server has several scopes, all with Option 43 with SW-server IP address. The infrastructure is verified. Ie: A device already configured in VLAN 100, will get DHCP offer from from 10.1.100.0-scope, VLAN 101 from 10.1.101.0-scope etc.


The problem is: How to make the phone genereate the correct URI to the folder that contains the config file for this particular VLAN?

Is it at all possible to have +3 Voice VLANS without having to manually set the VLAND ID on the phones?

Thank you for any ideas on this!
 
With Ericsson IP Phones what you are asking is impossible to do with DHCP and you will have to configure the phones manually. You should really have each Data VLAN with a 'following' Voice VLAN - i.e. switch 1 with Data VLAN 10 and Voice VLAN 100, switch 2 with Data VLAN 11 and Voice VLAN 101 etc.
Because of the way the Ericsson IP Phones boot what you want to do won't work with DHCP; The initial boot is on the Access VLAN (no 802.1q tag) and since this is common all the IP Phones will receive the same DHCP Option 43 and so the same VLAN list). You can then forget the rest of the boot process as it won't work.

What you are suggesting is completely at the other end of best practise - 10 Access switches sharing the same VLAN? Unless you aren't running IP I see no real reason not to start splitting this into separate VLAN's/IP Subnets, believe me it will make your life easier.

Andy
 
Thanks for answering, ADB100.

I don't claim the solution is good, but it's what a customer requests. They have several locations and many projects that imply close cooperation with partners. They want the IPT-networks to be separate.

Technically it is possible for a device to detect the tagged Vlan on a swicthport (by probing), but AFAIK Ericsson's IP-Phones do not support that.

Dynamic VLAN (external MAC-table) would solve the problem.
Multiple DHCP-servers combined with use of ACLs on ports may do it too. But the solution will not be clean, not easy to maintain and nothing to be proud of.


 
Cisco IP Phones use CDP to detect the Voice VLAN, there is now a 'standardised' CDP-like protocol for inter-vendor operation of things like Voice VLANs, PoE etc. This is LLDP (Link Layer Discovery Protocol) and is supported in the latest code for Cisco Catalyst 2960 & later switches. Currently Ericsson IP Phones don't support LLDP, however you could query your Ericsson supplier when (and if?) this feature will be available in the IP Phone code?
LLDP is already in Nortel & Mitel IP Phones, so you have to assume Ericsson will add it?

You are right, it's nothing to be proud of... I would attempt to pursuade the customer what they want to do is just wrong and the benefits of moving to a more structured LAN outweigh the 'flat' approach. Usually with very little work - assuming it's IP and DHCP is used they are unlikely to see any changes.

Andy
 
Thank you for very helpful answers, Andy!

 

Now, here is an idea that might sound horrible, but which I am sure can work:
ALL the phones get VOICE VLAN 100 in their config file, OK?
So, EVERY L2 switch has to be confdigured with VLAN100 as the tagged VLAN to the phones.

OK, here's where it gets weird:
Instead of your trunk back to the core having DataVLAN10 & VoiceVLAN100 both tagged, UNTAG the voice (Keep the Data tagged as 10).
THEN, on the core, configure the trunks to the edge with the DataVLAN10 tagged, BUT WITH A NATIVE VLAN OF YOUR CHOICE (100, 101, 102, etc... depending on the switch).

If you have 3500 edge switches, the switch would detect native VLAN mismatch and disable the trunk interface.
3750s however, log a VLAN mismatch but pass the traffic.

Effectively, the VLAN mismatch can translate the VLAN100 (on all the edges) to the multiple voice VLANs on the core.

Try it, you'll see what I mean.

 
Incidentally, their idea of having 10 separate Voice subnets is deeply stupid.

Non-technical people unfortunately make decisions like this based on no understanding of IP networking.
They don't understand that Voice needs very little bandwidth - it just needs no congestion on the bottlenecks.

The bottlenecks here are the trunks from core to edge -
(say you have a 2Gb Etherchannel - this means you can have 25,000 phones in simultaneous use before congestion occurs) having a separate VLAN on each edge has no effect on this congestion.
As far as the Core goes, it has to handle all this traffic regardless of whether it is split up into different VLANs or not.
So their requirement is pointless and non-constructive.
Tell them to get a properly qualified Network Architect to make the design decisions for them.
 
Incidentally - when you say "...they have several locations", do they have L2 links back to HQ, or routed links?

If they are routed links then their idea of "separate VLANs" is even more technically illiterate than I first thought....
 
Incidentally, their idea of having 10 separate Voice subnets is deeply stupid.

They have ten separate layer-2 switches/switch stacks. If you want to keep your Layer-2 broadcast domains simple and easy to troubleshoot then this is exactly how you would do it. Spanning VLAN's between access switches is NOT recommended. Keeping your network structured makes it easy to manage and troubleshoot. Having flat VLAN's spread over lots of switches just makes fault footprints that much bigger. I have seen many entire networks wiped out due to Layer-2 issues.

I agree VoIP is not bandwidth hungry but it is delay & jitter intollerant. Your comment about it taking 25000 VoIP calls to saturate a 2Gb EtherChannal is correct, assuming only VoIP traffic was on the network. However a few machines transferring files can easily saturate 2Gbps and destroy any VoIP quality, hence the need for differential services - QoS.

Your idea of 'fooling' the switches with mismatching Native VLANs will work, however it might be a pain to troubleshoot and any 'green' engineers will simply assume it is configured wrong and try and 'fix' it. You could turn off CDP on the trunks to remove the logged errors instead of living with them.

Andy
 
1/ FLat VLANs - Completely agree with you, BUT, in this silly scenario, they are happy with 1 single Data VLAN "flat" spread over their switches, BUT want 10 different Voice VLANs.
That's what's really amazingly stupid.
The flat Data VLAN will be about 100x more problematic (for exactly the reasons you list) than the flat Voice VLAN, and in the process of getting their priorities wrong, they are introducing a needlessly difficult requirement on the design.
A proper design would be a separate pair of Voice/Data VLANs for each "edge". Or, less good, both "flat".
We don't know if it is 10x 2-person offices, or 10x 200-person offices. (well, I don't, at any rate).

2/ Saturating links - I wasn't suggesting the OP was going to provision a 2Gb link for 25,000 phones! Just giving some idea of the tiny-weeny scale of VoIP bandwidth requirements compared with Data.

3/ Glad you agree, and agreed - you would want to think up a foolproof way of documenting this in such a way as to ensure successor engineers understand, but not in such a way as to advertise your horrible bodge to any potentially meddlesome management....
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top