VLAN + DHCP + VoIP = Cisco
Continuing the topic of configuring DHCP on Cisco equipment with VLAN in mind, I propose to consider the issue in depth: let's cross the described functionality with VoIP technology. What if we decided to introduce VoIP into our network with all the ensuing consequences: a separate device with Communication Manager Express, VoIP phones and the need to prioritize traffic?
First, a brief introduction to the Cisco VoIP architecture depicted here. Let's start with the phones. Cisco VoIP Phones have a dual-port miniswitch that allows you to connect the phone to a wall outlet, and the computer to the phone. In this way we save sockets and ports on the switch, but we create an additional problem for ourselves: VoIP traffic must be isolated from traffic destined for the computer. In the name of prioritization, which is critical for VoIP, and security.
To solve this problem, Cisco uses, in abstruse words, the technology of 802.1q trunks, and more simply - VLAN. A VoIP phone adds a tag to its traffic, by which the switch recognizes that the frame belongs to VoIP traffic, and it needs special attention.
A separate command is provided on the switch ports to set the VLAN for the phone that is connected to it. Now the port setup will look like this:
After that, the switch via CDP will send the phone its VLAN number and he will be able to mark the frames with the correct tag.
“Yeah,” the attentive and cunning reader will say, “but all the VoIP traffic of the entire network is concentrated in one VLAN?” So, our computer can turn off the phone, pretend to be and listen to all conversations on the network? ”
“And why all this crutch with switchport voice vlan? - the attentive and smart reader will ask, “can you configure the port on the switch as trunk by specifying allowed vlan 10 and native vlan 50?”
The answer to both of these questions is the same: Cisco has provided a mechanism that prevents a foreign device from pretending to be a VoIP phone. It is this mechanism that is enabled by the switchport voice vlan command. The second attentive reader is right, his configuration is correct and will work, but it will make the first attentive reader right. And this we absolutely do not need.
A detailed story about the Voice VLAN mechanism is a topic for a separate post. Those who are interested and want to find out about him right now can read about it on the Cisco website and, who knows, maybe in the process get interested in something else from the Tsiskovsky VoIP.
But back to our task. Not only workstations need an IP address, but also IP phones. However, only devices from VLAN 50, that is, computers, have access to the DHCP server. What do the phones do?
And for phones, we use two interesting DHCP mechanisms: the helper-address command and the principle by which DHCP allocates addresses.
Configure the DHCP server itself on a router with two pools:
The network command in configuring DHCP on Cisco is one of the few where we can set the subnet mask through a slash. And we can not ask at all, then it will be determined automatically, depending on the class of the network.
The default-router command sets the default gateway for the network, and dns-server - respectively, the DNS server. 4.2.2.2 is the address of the public NDS server, which is supported by the University of Berkeley, and is a reliable alternative if for some reason you do not trust your provider's DNS.
Just a couple of sentences about another feature of DHCP in VoIP: with it, phones get the address of the TFTP server, which stores the image of the operating system for them. This functionality is known as option 150 and is specified by the command:
If you delve even deeper into DHCP, then all the functions of this wonderful protocol are options. So, the default gateway can be set as default-router, or it can be set as option 3. Under such options are hidden a lot of interesting additional functionality, which, unfortunately, also does not fit in one post.
That's it, I’m already finishing my distractions: in the same way we’ll configure the pool of IP addresses for workstations:
Next we go to the subinterfaces of the CME router (I assume that you are familiar with routing between VLANs and have already configured them yourself). All broadcast packets with which our phones will reach the general public: “hey, who is the DHCP server here, I need an IP address” will come to the Fa0 / 0.10 subinterface - because the phones are in VLAN 10. There would be these cries for help and to die - in VLAN 10 there is no DHCP server - but this is not an option. Exit - ip helper-address command:
With this command, we tell the CME router: when you receive a broadcast DHCP packet, send it to the DHCP server at 172.16.2.5. This server will answer you, and then you will transfer it to the one who sent you the request.
“Wait,” our attentive readers will say, “but the phones broadcast in broadcast packets,“ hey, give us an IP address ”in the same way as computers - all these devices have no addresses. How does the DHCP server find out that it should be reported to phones from the VOICE pool, and to computers from the DATA pool? ”
Here we come to the second interesting point: in fact, the DHCP server does not know. If all the phones and computers were in the same VLAN, he would say: “I do not know who you are. All your requests came to me through the interface 172.16.2.5, so I will give all of you addresses from the network to which this interface belongs, that is 172.16.2.0/24. "
But we used helper-address! Watch how it works now: computers send a request “hey, give me an IP address”. The request goes to the DHCP server through the interface 172.16.2.5 - the server is in the same VLAN as the computers. And he gives them addresses from the network 172.16.2.0/24 - our DATA pool. But the broadcast packets of the phones go in a different VLAN. They come to the Fa0 / 0.10 subinterface, which is the default gateway for them, and the CME sends them to ip helper-address - 172.16.2.5.
And when the CME forwards telephone requests, it does not send them as broadcast. He sends them as unicast. A unicast IP packet has source and destination addresses. And in our case, the IP address of the DHCP request source will be the Fa0 / 0.10 subinterface address, because there these frames first reached the third level, there they first learned that IP addresses exist in the world!
So, the DHCP server receives a unicast request, the source address of which is 172.16.1.1. “Yeah,” the server says, “then the request source has a link to this address. So, we need to give him an IP address from the network to which this address belongs. ” And it responds to the request by issuing an address from the network 172.16.1.1/24 - our VOICE pool!
Thus, we get exactly what we wanted: all our phones received IP addresses from the desired subnet, they are isolated from VLAN with data and have only CME connection, which can connect them to other phones via PSTN or VoIP via the Internet. Computers received addresses from another network, they can now exchange data with company branches, server farm or anything else. We got a flexible network to configure, the ability to prioritize traffic at the second and third levels and save bandwidth and resources by using one DHCP server for several isolated VLANs.
PS I want to express my gratitude for the inspiration for this post and a significant layer of my telecom knowledge to the incomparable Jeremy Cioara. I hope you will forgive the tone of the story that is too loose in places.
First, a brief introduction to the Cisco VoIP architecture depicted here. Let's start with the phones. Cisco VoIP Phones have a dual-port miniswitch that allows you to connect the phone to a wall outlet, and the computer to the phone. In this way we save sockets and ports on the switch, but we create an additional problem for ourselves: VoIP traffic must be isolated from traffic destined for the computer. In the name of prioritization, which is critical for VoIP, and security.
To solve this problem, Cisco uses, in abstruse words, the technology of 802.1q trunks, and more simply - VLAN. A VoIP phone adds a tag to its traffic, by which the switch recognizes that the frame belongs to VoIP traffic, and it needs special attention.
A separate command is provided on the switch ports to set the VLAN for the phone that is connected to it. Now the port setup will look like this:
interface FastEthernet0/1
switchport mode access
switchport access vlan 50
switchport voice vlan 10After that, the switch via CDP will send the phone its VLAN number and he will be able to mark the frames with the correct tag.
“Yeah,” the attentive and cunning reader will say, “but all the VoIP traffic of the entire network is concentrated in one VLAN?” So, our computer can turn off the phone, pretend to be and listen to all conversations on the network? ”
“And why all this crutch with switchport voice vlan? - the attentive and smart reader will ask, “can you configure the port on the switch as trunk by specifying allowed vlan 10 and native vlan 50?”
The answer to both of these questions is the same: Cisco has provided a mechanism that prevents a foreign device from pretending to be a VoIP phone. It is this mechanism that is enabled by the switchport voice vlan command. The second attentive reader is right, his configuration is correct and will work, but it will make the first attentive reader right. And this we absolutely do not need.
A detailed story about the Voice VLAN mechanism is a topic for a separate post. Those who are interested and want to find out about him right now can read about it on the Cisco website and, who knows, maybe in the process get interested in something else from the Tsiskovsky VoIP.
But back to our task. Not only workstations need an IP address, but also IP phones. However, only devices from VLAN 50, that is, computers, have access to the DHCP server. What do the phones do?
And for phones, we use two interesting DHCP mechanisms: the helper-address command and the principle by which DHCP allocates addresses.
Configure the DHCP server itself on a router with two pools:
ip dhcp pool VOICE
network 172.16.1.0 /24
default-router 172.16.1.1
dns-server 4.2.2.2The network command in configuring DHCP on Cisco is one of the few where we can set the subnet mask through a slash. And we can not ask at all, then it will be determined automatically, depending on the class of the network.
The default-router command sets the default gateway for the network, and dns-server - respectively, the DNS server. 4.2.2.2 is the address of the public NDS server, which is supported by the University of Berkeley, and is a reliable alternative if for some reason you do not trust your provider's DNS.
Just a couple of sentences about another feature of DHCP in VoIP: with it, phones get the address of the TFTP server, which stores the image of the operating system for them. This functionality is known as option 150 and is specified by the command:
option 150 ip 'TFTP server IP address'If you delve even deeper into DHCP, then all the functions of this wonderful protocol are options. So, the default gateway can be set as default-router, or it can be set as option 3. Under such options are hidden a lot of interesting additional functionality, which, unfortunately, also does not fit in one post.
That's it, I’m already finishing my distractions: in the same way we’ll configure the pool of IP addresses for workstations:
ip dhcp pool DATA
network 172.16.2.0 /24
default-router 172.16.2.1
dns-server 4.2.2.2Next we go to the subinterfaces of the CME router (I assume that you are familiar with routing between VLANs and have already configured them yourself). All broadcast packets with which our phones will reach the general public: “hey, who is the DHCP server here, I need an IP address” will come to the Fa0 / 0.10 subinterface - because the phones are in VLAN 10. There would be these cries for help and to die - in VLAN 10 there is no DHCP server - but this is not an option. Exit - ip helper-address command:
interface FastEthernet0/0.10
ip helper-address 172.16.2.5With this command, we tell the CME router: when you receive a broadcast DHCP packet, send it to the DHCP server at 172.16.2.5. This server will answer you, and then you will transfer it to the one who sent you the request.
“Wait,” our attentive readers will say, “but the phones broadcast in broadcast packets,“ hey, give us an IP address ”in the same way as computers - all these devices have no addresses. How does the DHCP server find out that it should be reported to phones from the VOICE pool, and to computers from the DATA pool? ”
Here we come to the second interesting point: in fact, the DHCP server does not know. If all the phones and computers were in the same VLAN, he would say: “I do not know who you are. All your requests came to me through the interface 172.16.2.5, so I will give all of you addresses from the network to which this interface belongs, that is 172.16.2.0/24. "
But we used helper-address! Watch how it works now: computers send a request “hey, give me an IP address”. The request goes to the DHCP server through the interface 172.16.2.5 - the server is in the same VLAN as the computers. And he gives them addresses from the network 172.16.2.0/24 - our DATA pool. But the broadcast packets of the phones go in a different VLAN. They come to the Fa0 / 0.10 subinterface, which is the default gateway for them, and the CME sends them to ip helper-address - 172.16.2.5.
And when the CME forwards telephone requests, it does not send them as broadcast. He sends them as unicast. A unicast IP packet has source and destination addresses. And in our case, the IP address of the DHCP request source will be the Fa0 / 0.10 subinterface address, because there these frames first reached the third level, there they first learned that IP addresses exist in the world!
So, the DHCP server receives a unicast request, the source address of which is 172.16.1.1. “Yeah,” the server says, “then the request source has a link to this address. So, we need to give him an IP address from the network to which this address belongs. ” And it responds to the request by issuing an address from the network 172.16.1.1/24 - our VOICE pool!
Thus, we get exactly what we wanted: all our phones received IP addresses from the desired subnet, they are isolated from VLAN with data and have only CME connection, which can connect them to other phones via PSTN or VoIP via the Internet. Computers received addresses from another network, they can now exchange data with company branches, server farm or anything else. We got a flexible network to configure, the ability to prioritize traffic at the second and third levels and save bandwidth and resources by using one DHCP server for several isolated VLANs.
PS I want to express my gratitude for the inspiration for this post and a significant layer of my telecom knowledge to the incomparable Jeremy Cioara. I hope you will forgive the tone of the story that is too loose in places.