VLAN + DHCP + VoIP = Cisco
In continuation of the topic of setting up DHCP on Cisco equipment with regard to VLAN, I propose to consider the matter further: let's cross the described functionality with VoIP technology. What if we decided to integrate 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, briefly about the Cisco VoIP architecture shown here. Let's start with the phones. Cisco's VoIP phones have a built-in two-port miniswitch that allows you to connect the phone to an outlet, and the computer to the phone. By this we save sockets and ports on the switch, but we also create an additional problem for ourselves: VoIP traffic must be isolated from the traffic intended for the computer. In the name of prioritization, which is critical for VoIP, and security.
')
To solve this problem, Cisco uses, using abstruse words, 802.1q trunk technology, and simpler, VLAN. The VoIP phone adds a tag to its traffic, according to which the switch recognizes that the frame belongs to VoIP traffic, and it needs to be given special attention.
There is a separate command on the ports of the switch to set the VLAN for the phone that is connected to it. Now the port setting will look like this:
After that, a CDP switch will transfer the phone number of its VLAN to the phone and it will be able to tag the frames with the correct tag.
“Aha,” the attentive and cunning reader will say, “but you see, all VoIP traffic of the entire network is concentrated in one VLAN?” So our computer can turn off the phone, pretend to it and listen to all conversations on the network? ”
“And why is this crutch at all with switchport voice vlan? - the attentive and intelligent reader will ask, - because you can configure the port on the switch as a trunk, pointing it to allowed vlan 10 and native vlan 50? ”
The answer to both these questions is one: Cisco has provided a mechanism that prevents a foreign device from pretending to be a VoIP phone. This mechanism is enabled by the switchport voice vlan command. The second attentive reader is right, its configuration is correct and will work, but it will make the first attentive reader to the right. And this we absolutely do not need.
A detailed story about the mechanism of Voice VLAN is a topic for a separate post. Those who are interested and want to find out about it right now can read about it on the Cisco website and, who knows, maybe in the process of becoming interested in something else from 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 to do phones?
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 on the router with two pools:
The network command in configuring DHCP on Cisco is one of the few where we can specify a subnet mask using 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 the dns-server, respectively, the DNS server. 4.2.2.2 is the address of the public NDS server, which is maintained 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 DHCP feature in VoIP: with its help, telephones get the address of the TFTP server on which the operating system image for them is stored. This functionality is known as option 150 and is given by the command:
If you go deeper into DHCP even more, then all the functions of this wonderful protocol are options. So, the default gateway can be set as default-router, or you can as option 3. Under these options you can find a lot of interesting additional functionality, which, unfortunately, will not fit in one post either.
All-all, I'm already finishing my distractions: in the same way we will configure a pool of IP addresses for workstations:
Then we go to the CME router subinterfaces (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 calls for help and to die - in VLAN 10 there is no DHCP server - but this is not an option. The output is the 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 give it to the one who sent you the request.
“Wait,” our attentive readers will say, “but the phones transmit with broadcast packets“ hey, give us the IP address ”just like computers - all these devices have no addresses. How does the DHCP server find out that it is necessary for the phones to give out addresses 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 don’t know who you are. All your requests came to me through the interface 172.16.2.5, so I will give you all the addresses from the network to which this interface belongs, that is, 172.16.2.0/24. ”
But we used helper-address! See how it works now: computers send the request “hey, give me an IP address”. The request goes to the DHCP server through 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 arrive at 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 sends phone requests, it does not send them as broadcast. He sends them as unicast. A unicast IP packet has the source and destination addresses. And in our case, the IP address of the source of the DHCP request will be the address of the Fa0 / 0.10 subinterface, because there these frames first reached the third level, there they learned for the first time that there are IP addresses in the world!
So, the DHCP server receives a unicast request, the source address of which is 172.16.1.1. “Yeah,” says the server, “then the source of the request has a connection to this address. So, it is necessary to give him an IP address from the network to which this address belongs. ” And 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 required subnet, they are isolated from the data VLAN and only communicate with the CME, which can connect them to other phones via PSTN or VoIP via the Internet. Computers also received addresses from another network, they can now exchange data with company branches, server farm or anything else. We got a flexible network configuration, the ability to prioritize traffic at the second and third levels, and bandwidth and resource savings by using a single 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 forgive too loosely the tone of the story.
First, briefly about the Cisco VoIP architecture shown here. Let's start with the phones. Cisco's VoIP phones have a built-in two-port miniswitch that allows you to connect the phone to an outlet, and the computer to the phone. By this we save sockets and ports on the switch, but we also create an additional problem for ourselves: VoIP traffic must be isolated from the traffic intended for the computer. In the name of prioritization, which is critical for VoIP, and security.
')
To solve this problem, Cisco uses, using abstruse words, 802.1q trunk technology, and simpler, VLAN. The VoIP phone adds a tag to its traffic, according to which the switch recognizes that the frame belongs to VoIP traffic, and it needs to be given special attention.
There is a separate command on the ports of the switch to set the VLAN for the phone that is connected to it. Now the port setting will look like this:
interface FastEthernet0/1 switchport mode access switchport access vlan 50 switchport voice vlan 10 After that, a CDP switch will transfer the phone number of its VLAN to the phone and it will be able to tag the frames with the correct tag.
“Aha,” the attentive and cunning reader will say, “but you see, all VoIP traffic of the entire network is concentrated in one VLAN?” So our computer can turn off the phone, pretend to it and listen to all conversations on the network? ”
“And why is this crutch at all with switchport voice vlan? - the attentive and intelligent reader will ask, - because you can configure the port on the switch as a trunk, pointing it to allowed vlan 10 and native vlan 50? ”
The answer to both these questions is one: Cisco has provided a mechanism that prevents a foreign device from pretending to be a VoIP phone. This mechanism is enabled by the switchport voice vlan command. The second attentive reader is right, its configuration is correct and will work, but it will make the first attentive reader to the right. And this we absolutely do not need.
A detailed story about the mechanism of Voice VLAN is a topic for a separate post. Those who are interested and want to find out about it right now can read about it on the Cisco website and, who knows, maybe in the process of becoming interested in something else from 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 to do phones?
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 on the 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.2
The network command in configuring DHCP on Cisco is one of the few where we can specify a subnet mask using 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 the dns-server, respectively, the DNS server. 4.2.2.2 is the address of the public NDS server, which is maintained 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 DHCP feature in VoIP: with its help, telephones get the address of the TFTP server on which the operating system image for them is stored. This functionality is known as option 150 and is given by the command:
option 150 ip 'TFTP server IP address'
If you go deeper into DHCP even more, then all the functions of this wonderful protocol are options. So, the default gateway can be set as default-router, or you can as option 3. Under these options you can find a lot of interesting additional functionality, which, unfortunately, will not fit in one post either.
All-all, I'm already finishing my distractions: in the same way we will configure a 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.2
Then we go to the CME router subinterfaces (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 calls for help and to die - in VLAN 10 there is no DHCP server - but this is not an option. The output is the ip helper-address command:
interface FastEthernet0/0.10 ip helper-address 172.16.2.5
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 give it to the one who sent you the request.
“Wait,” our attentive readers will say, “but the phones transmit with broadcast packets“ hey, give us the IP address ”just like computers - all these devices have no addresses. How does the DHCP server find out that it is necessary for the phones to give out addresses 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 don’t know who you are. All your requests came to me through the interface 172.16.2.5, so I will give you all the addresses from the network to which this interface belongs, that is, 172.16.2.0/24. ”
But we used helper-address! See how it works now: computers send the request “hey, give me an IP address”. The request goes to the DHCP server through 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 arrive at 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 sends phone requests, it does not send them as broadcast. He sends them as unicast. A unicast IP packet has the source and destination addresses. And in our case, the IP address of the source of the DHCP request will be the address of the Fa0 / 0.10 subinterface, because there these frames first reached the third level, there they learned for the first time that there are IP addresses in the world!
So, the DHCP server receives a unicast request, the source address of which is 172.16.1.1. “Yeah,” says the server, “then the source of the request has a connection to this address. So, it is necessary to give him an IP address from the network to which this address belongs. ” And 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 required subnet, they are isolated from the data VLAN and only communicate with the CME, which can connect them to other phones via PSTN or VoIP via the Internet. Computers also received addresses from another network, they can now exchange data with company branches, server farm or anything else. We got a flexible network configuration, the ability to prioritize traffic at the second and third levels, and bandwidth and resource savings by using a single 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 forgive too loosely the tone of the story.
Source: https://habr.com/ru/post/113514/
All Articles