VLANs and VoIP phones

I'm trying to find some good web reading that gives a brief intro/tutorial to VLANs and various techniques used to tag the frames. I thought that the frames were tagged by which physical port switch port they entered.

We are looking at upgrading our infrastructure to support VoIP, and am trying to grasp all the new tagging info for VLAN. Currently have older cisco 2501 routers and HP switches. Moving to 2801 routers and ?? switches.

Are there different ways of tagging frames today basaed upon different standards, that were not around a few years ago ?

Can switches from different vendors all play nice together ?

What happens to tagged frames vs un-tagged frames ? What if a frame doesn't have the extra 4-bytes for VLANs, what about a tagged frame going thru an old legacy switch that doesn't know about the extra bytes ?

How does a frame obtain the VLAN ID - where does it come from ? Only from physically connecting to a specific switch port ? I've read abotu DHCP handing out VLAN ID - How ?

And lastly - and most important - How does a VoIP phone, with it's internal 2-port switch create a VLAN ID for the phone's ethernet port, and a different one (or just untagged ?) for the connected PC ?

How does it all work when the phone is just physically moved, and plugged into a different wall jack - hence a different switch port ?

How does DHCP enter into this picture ?

Reply to
Phil Schuman
Loading thread data ...

Hi Phil,

You may wish to investigate Cisco's Configuring Ports to Carry Voice Traffic in 802.1P Priority-Tagged Frames:

formatting link
Hope this helps.

Brad Reese BradReese.Com - Cisco Power Supply Headquarters

formatting link
Hendersonville Road, Suite 17 Asheville, North Carolina USA 28803 USA & Canada: 877-549-2680 International: 828-277-7272 Fax: 775-254-3558 AIM: R2MGrant BradReese.Com - Cisco Jobs
formatting link

Reply to
www.BradReese.Com

I'm trying to find some good web reading that gives a brief intro/tutorial to VLANs and various techniques used to tag the frames. I thought that the frames were tagged by which physical port switch port they entered.

We are looking at upgrading our infrastructure to support VoIP, and am trying to grasp all the new tagging info for VLAN. Currently have older cisco 2501 routers and HP switches. Moving to 2801 routers and ?? switches.

Are there different ways of tagging frames today basaed upon different standards, that were not around a few years ago ?

Can switches from different vendors all play nice together ?

What happens to tagged frames vs un-tagged frames ? What if a frame doesn't have the extra 4-bytes for VLANs, what about a tagged frame going thru an old legacy switch that doesn't know about the extra bytes ?

How does a frame obtain the VLAN ID - where does it come from ? Only from physically connecting to a specific switch port ? I've read abotu DHCP handing out VLAN ID - How ?

And lastly - and most important - How does a VoIP phone, with it's internal 2-port switch create a VLAN ID for the phone's ethernet port, and a different one (or just untagged ?) for the connected PC ?

How does it all work when the phone is just physically moved, and plugged into a different wall jack - hence a different switch port ?

How does DHCP enter into this picture ?

formatting link

tnx - I'll have to read thru the Cisco pages, and all the associated links.

The details seem to be creating a larger list.... vs making it smaller. ie - What about NAC for the phone vs attached PC - how to tell the difference ? I'm still hung up on the switch port assigning the VLAN ID, and the rest is all new to me :) I'll also have to research the HP Procurve switches, as that is what some of the remote offices have installed...

Phil -

Reply to
Phil Schuman

a lot depends on the device. 1 v common "feature" is to have access ports, with untagged access, allocate the port to an internal VLAN, and tag "stuff" associated with that vlan if it leaves the switch on a port set for tagging.

the tags are standardised (ieee 802.1Q?), but how a device decides what to tag and how is config / device dependent

yes.

the more complicated issues i have had issues with are around multiple spanning trees / single spanning tree, and whether the "native" untagged vlan gets treated differently.

if you have a tagged port 802.1Q mentions that untagged frames can be associated with a sort of notional vlan and treated as such once they get to a device that uses vlans, like a switch.

it might let it thru, but some frames are going to be over max "native" ethernet frame length...

part of the network design - you have a 12 bit field to play with. Avoid 0 and 4095, and Cisco in particular have some reserved numbers between 1000 and 1023.

usually vlan IDs are the same as tag numbers, and only high end devices understnad translating tag numbers, so tag numbers need to be consistently used across a campus.

Also some older cisco vlan features such as ISL dont operate with tag numbers above 1024.

i have seen this for IP phones - it used manufacturer specific tags to set up phones

The PC traffic is untagged from the PC. The phone embedded switch just passes the frames thru, and they become "members" of the native vlan on that switch port once they get to the wiring closet.

DHCP.

Some phones boot initially to use DHCP on the native VLAN, get their info such as tag numbers, then reboot and DHCP again in the right vlan. If you have the vlan number already in the config of the phone, then the reboot isnt needed.

like it always does :)

Reply to
stephen

That's the default behavior. If an untagged frame arrives at a switch, it gets tagged with the PVID of that port. This was the behavior defined in the original 802.1Q spec (802.1Q-1998).

802.1Q was enhanced to support port+protocol classification. Now the VLAN can be assigned to an untagged frame based on a protocol table that sits on the port. If the frame doesn't match any of the protocols specified in that table, then it gets the PVID. Here the frame's "protocol" is what is contained in the Ethertype field if the frame is Ethertype-encapsulated, or the protocol type if the frame is of some other encapsulation (e.g. a frame with a SNAP-encapsulated protocol type).

There are other non-standard ways of assigning the VID to untagged frames; e.g. subnet based, MAC address-based, etc. I wouldn't bother with these if you really care about interoperability.

Usually they can, as long as you make sure you're using standards-based protocols for communicating between them. In other words, if you were using PVST (per-VLAN spanning tree) on Cisco switches, you won't be able to talk to most other switches unless you turned off PVST.

switch will do to an incoming frame is assign it to a VLAN. It does this based on the VID in the tag if the frame was tagged, or if it is untagged it will assign a VID based on either the port or port+protocol.

See above.

This is usually not a problem except for, potentially, the frame length, as pointed out by another poster.

See above.

DHCP cannot handle VLAN IDs! A VLAN defines a broadcast domain and you have to know what VLAN you're in before you can used DHCP. There may be protocols whereby a switch identifies a device as being a phone (based on a protocol such as LLDP or CDP) and configures that port to automatically be on a certain VLAN.

I'm not conversant with the way VOIP phones work so I don't have answers to the rest of the questions.

Anoop

Reply to
anoop

You can use .1x to specify a VLAN though. The process of logging in, and getting the data from your ACS (or whatever) server can have the switch reset you onto the proper VLAN. The whole process, could be confused with DHCP being one part of the .1x negotiation.

Reply to
Doug McIntyre

And can VLANs be used to separate security domains, so (for instance) any computer plugged into a port (on a phone or switch) that's not 'known' or 'authorized' in some way only gets (say) Internet access, and can't see internal LAN file servers, print servers or other LAN PCs?

Or is that too easily spoofed by having the client PC pretend to be on VLAN #7, which is where all the good stuff is?

Thanks!

Reply to
William P.N. Smith

A post that cross-posted _almost_ correctly, but forgot to set a Followup-to: destination :) So, I've picked comp.dcom.lans.ethernet...

These days, the end-stations are able to tag frames, and participate in multiple VLANs simultaneously. Port-based VLANs are still there too IIRC.

I suspect that the current crop of HP ProCurves are fully (?) VLAN aware.

Generally.

I'm not certain, but suspect it could be dropped. May depend on frame size.

Depends on the country/culture - VLAN ID's are generally patromymic :) Seriously though - they can either be based on the port, or if the host is VLAN aware can be set by the host, with the switch likely still knowing if a given VLAN ID is "legal" on a given port so hosts cannot join arbitrary VLANs.

Nope.

By putting it somewhere in the replies for use by a VLAN-aware client I would suspect.

rick jones

Reply to
Rick Jones

[snip]

Although it's not "web reading", there is a complete explanation of the entire range of VLAN tagging possibilities, along with the behavior of VLAN-compatible and non-VLAN compatible switches, in Chapters 11 and 12 of "The Switch Book" [shameless plug admitted].

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

Here is another source of info on that --

formatting link

Reply to
TexasMirty

thanks to all for the ongoing education... the initial posting was x-posted across relavent groups, but then was un-x-posted by a followup user for the HP hardware group.

So - I just stumbled across this Avaya doc -

formatting link
and now was wondering even more about the initial traffic flow from a IP phone as it gets attached to the network. DHCP TFTP DNS data exchange

How does a DHCP request and response get satisified for the phone, and yet maybe respond differently to a computer device ? ie - the phone (Avaya) wants to receive DHCP info + option 176. the PC connected to the phone doesn't want to receive the option 176 How is that accomplished ? What about even telling the phone apart from the PC for handing out IP addresses ?

I can see how the phone + PC would be on the same default port defined as "data" VLAN until the phone gets booted up and configured. But then - it needs to find it's TFTP & DNS server, and the other "voice" servers.

It just seems pretty mind boggling trying to map out where these servers need to exist, and on which subnets, and VLAN's.

The more info I find, the more confused...

Phil -

Reply to
Phil Schuman

DHCP data:- My understnding is that this is not in practise an issue. The various devices ignore the options that they do not care about.

Clearly you could in principle get a collision and indeed I would like to hear of examples from the field but I think that in practise

Phone vs PC on same wire.

The Cisco recommended solution is to configure the switch such that the phone and the PC are on different VLANS and to use a proprietary protocol to allow the phone to tell the switch that it is a phone and the switch to tell the phone what VLAN to use.

interface FastEthernet3/11

switchport access vlan 123 ! PC VLAN switchport mode access switchport voice vlan 234 ! Phone VLAN service-policy output autoqos-voip-policy qos trust device cisco-phone qos trust cos auto qos voip cisco-phone tx-queue 3 priority high shape percent 33 spanning-tree portfast

The phone chats to the switch using Cisco Discovery Protocol and gets told which VLAN it is in. I then knows how to encapsulate the frame in 802.1Q.

It sends the DHCP request which is in the "phone" VLAN so the DHCP relay know what network address range to pass to the DHCP server.

Bob's your uncle.

Not really too much to it and certainly no mystery.

Reply to
anybody43

i did some tracing to sort this out a couple of years back with Avaya phones on a Foundry switch.

the PC just ignores that "tag" in the DHCP response - that is the way the protocol is supposed to work....

1st time a phone boots it "looks" like a PC - on the same default VLAN.

it gets an IP, then pulls a config file via TFTP (where the option 176 gives it the TFTP detail).

it then boots again, but uses the VLAN info from the config file.

DHCP then gives it an IP if the phone specific VLAN - and we are off (well - download the config again etc AFAIR)

DHCP requests can be forwarded via a "helper" in a router, so they can serve adr from a large number of different subnets. The helper adds a tag to the request to flag the source subnet so the DHCP server can infer which range of addresses to use.

Once the device has an IP address, traffic can flow across a router.

so it is the other way around, you need to build the data / voice converged network so that the relevent servers are accessible from both the data VLANs and the voice VLANs.

The one thing i couldnt find when i had to do this "cold" was an Avaya worked example of how it should work (or at least one that didnt say - just buy our switches) - i got the impression that even their engineers struggled with this stuff.

Reply to
stephen

Yeah - we have that now on our routers - helper address - to forward the remote DHCP requests to 2 different mirrored DHCP servers. Each remote location is a different subnet, so that is how we handle the scope issue.

Having never seen or played with a VLAN config, don't really know what that will look like... ie - do the phone and PC live on the same subnet ?

DHCP server address = 192.168.12.200 + default port vlan=??

PC -> boot -> DHCP req -> reply with 192.168.12.101 + default port vlan=??

phone -> boot -> DHCP req -> reply with 192.168.12.102 + default port vlan=?? then what ??

do all the IP phones work in a similar fashion ? Cisco - Avaya - Nortel - Shoretel - etc

Reply to
Phil Schuman

Cisco recommend separate VLANs for the voice and data subnets - so if you dont have softphones on PCs you can then segregate traffic into different subnet setsby function (although this doenst seem to get put in place all that often).

Cisco has some docs for "best practice" based on their Call Manager IP Telephony system - see:

formatting link

try here is you dont want to wade thru the whole thing:

formatting link

There seems to a common network model for the ones i have seen from Cisco, and Avaya that support cascading a device off theback of the phone. Several other makes seem to be similar.

Reply to
stephen

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.