- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: IP telephony, VLANs - stupid? [7:67672] posted 04/18/2003
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


1.  IP Telephony benefits from an isolated VLAN for a variety of 
reasons, but the biggest reason is layer-2 QoS.  IP Phones can be 
prioritized over data traffic via 802.1p, which is why all the ports are 
being configured as trunk.  Another common reason is for security (for 
example you used to be able to make phones reboot at will by flooding 
them with data from a PC).  Since all ports are getting set to trunk 
(having an IP phone or not) there will be little additional security 
since PCs can be easily configured to trunk (esp. Linux PCs), bypassing 
routers, access lists, and allowing the PCs to set their own CoS.  Other 
switches, including the 3548, support automatic trunking when an IP 
phone is detected and disabling trunking when an IP phone is not 
detected, which forces the use of the correct VLAN actually offers some 

2.  I'm not sure what you're getting at, but the answer is no. 
Intentionally introducing hubs into a switched network is generally a 
bad idea.  Neither QoS nor security is a job for a hub, or even a 
half-duplex switch.  Cisco recommends avoiding Gigastack (1000-Mbps 
half-duplex) for this very reason.  The proposed design is very normal, 
with multiple VLANs (usually 2) on each switch port, and allows for 
ad-hoc moves and changes without additional network configuration.

3.  With 802.1p prioritization voice traffic will always get priority 
over data traffic (assuming it is configured as such), so the data 
packets associated with a PC broadcast storm will get bumped in favor of 
voice traffic.  In this case your data network would go down (just as it 
would do now) but the voice network will stay up.  If your voice 
hardware goes "gaga", you're pretty well toasted.  In my experience it's 
been relatively easy to take IP phones offline and reboot themselves 
(flood pings, malformed service XML, etc) but the phones themselves have 
never generated detrimental traffic -- including when there are problems 
out of the box.

For what it's worth IP phones will set their L2 CoS to 5 and can be 
configured to re-prioritize data traffic coming from the PC to CoS 0. 
  Assuming that all of your switches support it (it sounds like they 
do), this will be enough to make sure that shared links (such as gigabit 
links interconnecting switches) continue to prioritize voice traffic 
correctly, resulting in end-to-end QoS even during a broadcast/multicast 

4.  You didn't actually ask this question, but it was identified that 
"they" are working on this issue.  DHCP server-side is configured 
exactly like it would be for any other subnet.  Create the appropriate 
scopes, with DNS, a default gateway and with the IP address of the 
default CallManager (as option 66 or 150).  PCs will automatically 
communicate on the native VLAN (and can be forced to do so based on the 
switch configuration) and will therefore use VLAN 100.  Their DHCP 
requests will originate from VLAN 100 (probably the same VLAN as the 
DHCP server) and will get treated from the correct DHCP scope.

The IP phones will learn their VLAN from the switch (again, assuming 
correct switch configuration) and will use a 802.1q header to identify 
their traffic as such.  IP phone traffic will need to cross a router to 
get to the DHCP server.  Assuing the router has been configured properly 
with IP helper-addresses, the DHCP server will recognize that the IP 
phones are on a different subnet and hand out IP addresses accordingly.

There's obviously more to implementing correct QoS than configuring 
VLANs and trunking, but all in all the design as you described it sounds 
exactly like I would expect it to.

- Tom

Lesly Verdier wrote:
> Hi Group,
> I'm a programmer studying for CCNP so my knowledge of 
> networking is strictly theoretical.
> The company I work for has 40 Cat 3524s and 4 Cat 6500s. 
> The switches are hardly configured; it is one broadcast 
> domain. In the coming weeks they will introduce 
> IP-telephones and the external gurus suggested the 
> following solution:
> Every PC will be connected to an IP-telephone which in 
> its turn will be connected to a switch port. (The 
> telephone has an internal hub or switch). They want 
> the PC's in one VLAN (say VLAN 100) and the telephones 
> in another VLAN (VLAN 150). Because both are connected 
> with one wire to the switch, EVERY port on all switches 
> will be configured as a trunk. 
> In my books it is stated that the main reason to 
> implement VLANs is to diminish the number of broadcast 
> domains. The suggested "solution" still makes the 
> network one broadcast domain. (Right now they also 
> have problems to figure out how to configure their 
> DHCP server to give the "right" IP-addresses to the 
> PCs and the telephones).
> 1. Does anybody has a clue what problem they are 
> trying to solve?
> 2. Isn't it a better idea to connect the PCs in a room 
> to a hub and then connect them to a switchport and to 
> do the same with the telephones and connect them to 
> another switchport? (So defining VLANs makes sense).
> 3. What happens if one of the phones or PCs goes gaga 
> and starts broadcasting 1000 times a second? Will the 
> telephones and PC's continue working (there are no 
> broadcast tresholds configured)?
> Before I'm going to tell the gurus what I think I 
> would like to know if I'm trying to solve a problem 
> that does not exist.
> Thanks,
> Lesly Verdier

Message Posted at:
FAQ, list archives, and subscription info:
Report misconduct and Nondisclosure violations to abuse@xxxxxxxxxxxxxx