Re: IP telephony, VLANs - stupid? [7:67672] posted 04/18/2003
- Subject: Re: IP telephony, VLANs - stupid? [7:67672]
- From: "Tom Martin" <tmartin@xxxxxxxxxxxxx>
- Date: Fri, 18 Apr 2003 12:44:56 GMT
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.
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.
> Lesly Verdier
Message Posted at:
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to abuse@xxxxxxxxxxxxxx