In a previous, article we tried to build a very simple VoIP system in Packet Tracer with IP phones, soft phones and analog devices. The calls controlled by a router with Call Manager Express. In this article, we’ll go further. First, we’ll use separate VLANs for data and voice then expand our network and build a system capable to place remote calls to remote IP networks.

In the first lab in this session, we’ll use a practical feature of IP phones, namely the possibility to provide connection to a PC and conserve ports on the switch in this way. Internally, the IP phone is a switch with three ports: one for the outer switch, one for a PC and one for the ASICs (Application Specific IC) of the phone. So if we connect a PC to the proper port, we spare one port on the main switch and a cable also. Moreover, we can do another trick: the PC can get an IP address from a completely different pool than the phone and can be in a totally different VLAN too. This is especially important if we want some security. And because VoIP packets are very sensitive about the delay, jitter and another annoying things that can occur in a packet switched network, we need to treat them differently compared to other data. This is where Quality of Service (QoS) will come into play, and if we use separate voice VLAN, the configuration of QoS can be much simpler (see Cisco’s AutoQoS feature).

The initial topology will look like this (the PCs connected to the “PC” slot on the phones):

First, we configure the multilayer switch. We need to define the data and voice VLANs, and because on all the switch ports the traffic can be from either one, we need to define the switch ports as trunks. The 3560 type switch supports ISL and 802.1q trunks, therefore, we need to exactly define one of them (we’ll use 802.1q, which uses the method of tagging to mark the frames from different VLANs). It’s important to define it before we set the ports to trunk mode, or else we’ll receive an error message states:

An interface whose trunk encapsulation is “Auto” can not be configured to “trunk” mode

Setting of the native VLAN is as important as the setting of the voice VLAN. Native VLAN is special: in this the frames are not tagged even if they’re going through the trunk lines. In our example, the native VLAN will be the data VLAN, because PCs doesn’t handle 802.1q frames, therefore, the frames holding their traffic must remain untagged throughout the network.

The complete configuration of ML_switch will be as follows:

Next device we set up will be the CMERouter. Because we’ll have to separate networks for PCs and phones, we need to define to DHCP pools also (keeping in mind that the voice pool needs the option 150 parameter). The configuration is on the next figure:

As we see on the topology, the router connects with one port to the switch, but it’s clear that we need two IP addresses to handle the two pools. The solution is that we’ll use logical subinterfaces on the physical Fa0/0 port, each of them assigned to a specific VLAN. Here, we don’t assign an IP address to the physical port, just enable it. In order to successfully communicate with the trunk port on the other side, we need to define the trunk protocol also, and set the native VLAN (the router also needs to know which the native VLAN is). After we define this information with the encapsulation command, we can assign IP addresses to the subinterfaces. This method is called “router-on-a-stick”. The necessary commands are:

Now move into the stage of setting up the telephony service. We’ll use the automated method described in the previous article, with the help of the auto-reg-ephone and auto assign commands. We’ll define no more than two ephones and the same number of DNs for them. The CME will be in the address space of the voice VLAN. Don’t forget to generate the necessary configuration files as the final command!

The final step is to define the DNs (the extension numbers) of the phones:

As can be seen on the above figure, the phones successfully registered. If we look at their GUI, we must see the extension number and we can do a test call. If we go to the IP configuration on the PCs and set them to DHCP mode, they should get their IP address from the data pool, and if we check the IP address of any phone, it must be from the voice pool. From now on the two flows will be separated from each other, and it’s harder to capture a voice conversation by a cracker.

This topology can be perfect for home or for a little office, but it has a deficiency: we can’t place calls to a phone on a remote network, because all of our phones are on the same subnet. Let’s build another lab, in which we can simulate a bigger network, for example a firm with two sites (named MainSite and RemoteSite) connected by a WAN.

In order to use a leased line WAN connection between the two sites, we need to place a WIC-2T (WAN Interface Card with 2 ports of T1 speed) module into the routers. This can be achieved on the Physical tab, but before we put the module in, we need to switch off the router. Another way to use the proper devices in PT is using the “Custom made devices” category: the routers in this are already contain the necessary WAN modules. Make sure that each 2811 type router has a WIC-2T module in the lower right slot, so we can connect the Serial0/0/0 ports together. In the simulator one of them will be the DCE device, another one is the DTE. To connect them, use the Serial DCE cable from the “Connections” category: the first device we choose will be the DCE; another will be the DTE automatically. In the Main site, we’ll have a multilayer switch with two VLANs as in the previous example. In the remote site, they use a single-VLAN system but they have analog phones too.

The topology will look like this:

The IP addressing scheme is as follows:

  • in the Main site the data VLAN uses the subnet
  • in the Main site the voice VLAN uses the subnet
  • in the Remote site the LAN uses the subnet
  • the WAN connection uses the subnet (this is a special reserved address block for documentation purposes, see:

Let’s start with the simpler configuration in the Remote site. On the switch, we just need to define the voice VLAN, in this example we’ll use VLAN 1:

The basic configuration on the Remote router:

Test it by looking at the IP addresses of the devices. On the VoIP device, set the Server address to

Continuing on the router, we set up the telephony service and the DNs (one for each device):

Some things need to mention here. First, I didn’t use the auto-reg-ephone command, as it is a default setting. Second, I suppressed the console error messages with the no logging console command, because while entering the telephony-service commands the devices are trying to register but there are no DNs for them yet. And lastly, we can observe the phone numbering scheme.

Let’s leave the Remote site and enter to Main. Here, we need to define the voice and data VLAN on MLS1in the very same way we did in the previous lab. On the Main router, the basic configuration is also the same except the slight modification of IP addressing and with an additional configuration of the serial interface:

The configuration of the CME is similar, except that we want to use the extension numbers 101 and 102 – set up the DNs according to this. If all is well, then at this stage the calls are working within the sites, but we want to dial any phones from the remote site in the Main and vice versa.

The first thing we need to configure is routing between the sites. For the sake of this lab, we don’t want to bother with NAT as in the real world we should because of the private address spaces, but we simply use a routing protocol to advertise our networks. Let’s use EIGRP for example and check if the routing table contains all of the remote networks. If we want, we could check the availability of a remote address by pinging it.

Now comes the tricky part: teach the routers and how to reach a device with extension number in a remote network. The name of this magic is: dial peer. A dial peer is a concept to describe a service either on a remote network, either on our network but not in the scope of the basic VoIP system. I mean that if we want to handle an analog phone directly in the router’s FXS port, then this device will be a dial peer also, although in PT we cannot use this. But here, we need to use dial peers to reach our remote VoIP devices. In the configuration of a dial peer, we need to define the remote router which provides the VoIP service for specific extension numbers and these numbers too.

In our example, if we take the Main router first, it knows how to handle extension numbers 101-102, as it is the registrar of these numbers. But if we dial a number on IP Phone0 which is not in this range, the router cannot handle that call as the number is unknown to it. So we need to define a dial peer which describes the missing information. Namely, how the router can reach these numbers.

Let’s begin our work on router Main. The command to define dial peers is dial-peer voice, which has an ID as first parameter and voip as second parameter (on a real router this can be vofr for example, for Voice over Frame Relay). Then we enter the dial-peer configuration submode. Here, we need to define the remote router first which will be our dial peer with the IP address of it visible to us. Then, we need to tell our router which extension numbers can be reached with the help of this dial peer. The whole configuration is this:

As can be seen, the session target command needs an IP address as parameter, but we need to prefix it by the ipv4 tag. The purpose of the destination-pattern command is to describe the extension numbers and it can use special characters for this purpose. In the example above, the “20.” pattern means that this dial peer handles every number which begins with 20 and the third digit is anything between 0 and 9. So the period behaves like a joker character. In the real world, we can use other method if we want to be more specific. The next example describes all the extension numbers that are beginning with 20 and then contains 1, 2 or 3 as the value of the third digit:

destination-pattern 20[1-3]

Note: this form is accepted by PT, but doesn’t work!

Now go to the Remote router, and define its dial peer also:

Finally, go to IP Phone0 and dial the number of IP Phone2 on the remote network. The call should be successful. Try some calls from each site to the other!

In a big network, it’s not a good practice to use the routers as DHCP servers. We should use a dedicated server instead. Let’s modify our topology slightly: add a Server into the Main site to be the DHCP server. In order to do this, connect it to the MLS1 switch on the Fa0/4 port. Because the interface in the server doesn’t support trunking, we need to place it into an access VLAN. For example, into the voice VLAN with the command switchport access vlan 10 on MLS1. In the Server’s Config tab, search for the DHCP service and turn it on then define the serverPoo, such that, TFTP server will be Save it and define another pool named datapool for the PCs. The final configuration is like this:

Add an IP address of to the server then go to the Main router. First, disable the two DHCP pools there with the no ip dhcp pool name command. Now, IP phones can already use the server but the PCs can’t find any on their subnet. So we need to issue the ip helper-address command on the Fa0/0.10 subinterface to set up a DHCP relay towards the server. After this, everything should work as before.

I hope that with these labs, it’ll be easier to learn the base concepts of VoIP. Packet Tracer is a great tool to use so that you could try even more difficult scenarios – have fun!

Useful links:

Voice VLANs and configuration:

Understanding dial peers:

Description of the destination-pattern command: