Archive for January, 2009
The depletion of the public IPv4 address space has forced the internet community to think about alternative ways of addressing networked hosts. Network Address Translation (NAT) therefore was introduced to overcome these addressing problems that occurred with the rapid expansion of the Internet. Even if NAT was suggested as a temporary solution, it has been adopted by all network hardware manufacturers, and it is considered a very useful technology, not only for IP address conservation, but also for many other purposes including security. Basically NAT allows a single network device (e.g a router, firewall etc) to act as an agent between a private local area network and a public network such as the Internet. The purpose of this NAT device is to translate the source IP addresses of the internal network hosts into public routable IP addresses in order to communicate with the Internet.
Some of the advantages of using NAT in IP networks are the following:
- NAT helps to mitigate the depletion of the global public IP address space
- Networks can now use the RFC 1918 private address space internally and still have a way to access the Internet using NAT.
- NAT increases security by hiding the internal network topology and addressing scheme.
Cisco IOS routers support different types of NAT as will be explained below. NAT has many forms and can work in several ways, but in this post I will explain the four most important types of NAT:
1. Overloading or Port Address Translation (PAT)
This is the most frequently used form of NAT in IP networks. It uses the concept of “many-to-one” translation where multiple connections from different internal hosts are “multiplexed” into a single registered (public) IP address using different source port numbers. This type of NAT allows a maximum of 65,536 internal connections to be translated into a single public IP. This type of NAT is very useful in situations where our ISP has assigned us only a single public IP address, as shown below.

In our scenario above, our internal network range is 192.168.32.0/24 and our assigned public IP address is 213.18.123.100. All internal hosts will be translated to the public address using different port numbers.
Configuration:
Router(config)# interface ethernet 0
Router(config-if )# ip address 192.168.32.1 255.255.255.0
Router(config-if )# ip nat inside
Router(config)# interface serial 0
Router(config-if )# ip address 213.18.123.100 255.255.255.0
Router(config-if )# ip nat outside
Router(config)# ip nat pool overloadpool 213.18.123.100 213.18.123.100 prefix-length 24
Router(config)# ip nat inside source list 1 pool overloadpool overload
Router(config)# access-list 1 permit 192.168.32.0 0.0.0.255
2. Dynamic NAT
Dynamic NAT translates internal private IP addresses to public addresses from a range (pool) of public addresses assigned to our network from an ISP.

In our example scenario above, assume that we own the range of public IP addresses 213.18.123.0/24. Any internal host accessing the internet, will be translated by the NAT router to the first available public IP in the public pool range. In our example above, internal host 192.168.32.10 is translated to 213.18.123.116 (one-to-one mapping). Similarly, 192.168.32.12 is translated to 213.18.123.112 etc.
Configuration:
Router(config)# interface ethernet 0
Router(config-if )# ip address 192.168.32.1 255.255.255.0
Router(config-if )# ip nat inside
Router(config)# interface serial 0
Router(config-if )# ip address 100.100.100.1 255.255.255.252
Router(config-if )# ip nat outside
Router(config)# ip nat pool dynamicpool 213.18.123.0 213.18.123.255 prefix-length 24
Router(config)# ip nat inside source list 1 pool dynamicpool
Router(config)# access-list 1 permit 192.168.32.0 0.0.0.255
3. Static NAT
This form of NAT creates a permanent one-to-one static mapping of a public IP address with a private IP address. It is particularly useful in cases where an internal host needs to be accessible from the outside public internet.

In our example diagram above, the internal host with private IP address 192.168.32.10 will always be translated to 213.18.123.110. Hosts from the outside public internet will be able to directly access the statically nated internal hosts by accessing their mapped public IP address. This scenario is useful to provide access to public company servers such as Web Server, Email Server etc.
Configuration:
Router(config)# interface ethernet 0
Router(config-if )# ip address 192.168.32.1 255.255.255.0
Router(config-if )# ip nat inside
Router(config)# interface serial 0
Router(config-if )# ip address 100.100.100.1 255.255.255.252
Router(config-if )# ip nat outside
Router(config)# ip nat inside source static 192.168.32.10 213.18.123.110
Router(config)# ip nat inside source static 192.168.32.12 213.18.123.111
Router(config)# ip nat inside source static 192.168.32.15 213.18.123.112
4. Port Redirection
This is useful in situations where we have a single public IP address and we need to use it for accessing two or more internal servers from outside. Assume that we have a Web and Email servers that we need to provide access from outside using only a single public IP address. Assume that our public address is 100.100.100.1. Inbound traffic coming towards address 100.100.100.1 port 80 will be redirected to our internal Web Server 192.168.32.10, and inbound traffic coming towards address 100.100.100.1 port 25 will be redirected to our internal Email Server 192.168.32.20.
Configuration:
Router(config)# interface ethernet 0
Router(config-if )# ip address 192.168.32.1 255.255.255.0
Router(config-if )# ip nat inside
Router(config)# interface serial 0
Router(config-if )# ip address 100.100.100.1 255.255.255.252
Router(config-if )# ip nat outside
Router(config)# ip nat inside source static tcp 192.168.32.10 80 100.100.100.1 80
Router(config)# ip nat inside source static tcp 192.168.32.20 25 100.100.100.1 25
The Cisco Call Manager Express (CME) software (its new name is Cisco Unified Communications Manager Express) provides IP Telephony services that run on Cisco Integrated Services routers (such as 1800, 2800, 3800 family series). I will start a series of posts in this blog about IP Telephony, starting today with the installation of CME on a supported Cisco router.
The CME software can be downloaded from http://www.cisco.com/cgi-bin/tablebuild.pl/ip-iostsp (login required) and you can install it on the router flash. You need to download the CME software (comes as a single .zip compressed file) that is appropriate for the specific router IOS image you are intended to use. The ZIP file contains several individual files and several TAR archives. The individual files can be copied to flash using the regular “copy tftp flash” command and the TAR archives can be copied and extracted to flash using the “archive tar” command (more details later).
The recommended files that you need to install are the following:
- Basic Files: This is a TAR archive containing the basic files you need to run the Cisco Unified Call Manager express. This archive contains also the phone firmware files required, although additional individual phone firmware files may be needed sometimes. The filename for this tar archive is “cme-basic-x.x.x.tar“.
- GUI Files: This is again a TAR archive containing only the files of the GUI management tool, which is a mouse-driven interface for provisioning phones and for general CME management after basic installation is complete. The filename for this tar archive is “cme-gui-x.x.x.tar“.
- Phone Firmware Files: Although the required phone firmware files are included in the Basic tar archive, you may need to add phone firmware files to support individual phone models that are not included in the basic package. Each firmware file is specific for each phone model and for the protocol it uses (i.e SCCP or SIP protocol). By default, new IP phones are shipped with an SCCP firmware image. If the firmware installed on an IP phone is older than the firmware loaded on the Call Manager router flash, the IP phone automatically upgrades its firmware and then registers with the Callmanager. The filename conventions used for phone firmware images are:
- SCCP firmware: P003xxyyzzww or SCCPxxyyzzww
- SIP firmware: P0S3-xx-y-zz or SIPxxyyzzww
- For Java-based IP phones, such as the Cisco Unified IP Phone 7911, 7941, 7941GE, 7961, 796GE, 7970, and 7971, the firmware consists of multiple files including JAR and tone files.
Installation of CME software
After you download the .zip CME software file from Cisco, uncompress the file on a local TFTP server. You will get several individual files and several TAR archives. We assume the TFTP server is at 192.168.10.1 and has access to the CallManager router.
For individual files:
Use the regular copy command to transfer the file from TFTP to the router’s flash:
Example:
Router# copy tftp://192.168.10.1/P00307020300.sbn flash:
For TAR archive files:
Use the archive command to transfer the files and extract them at the same time to the router’s flash:
Example:
To transfer the Basic Files tar archive (cme-basic-3.0.3.tar) to callmanager router:
Router# archive tar /xtract tftp://192.168.10.1/cme-basic-3.0.3.tar flash:
After all required files are installed, use the “show flash” command to list the files installed on flash memory.
A PVDM (Packet Voice DSP Module) is a router hardware module that looks like a computer memory chip and is used to provide Digital Signal Processing voice services to routers working as voice gateways or as Call Manager Express devices. The high-density PVDM2 module enables Integrated services routers (such as 2800, 3800 models) to provide high-density voice services such as transcoding, hardware conferencing and voice encoding in IP communications solutions.
The following configuration example is about a cisco 2801 router working as Call Manager Express version 4.1 with both local IP phones and IP Phones located in remote branches over IPSEC VPN. The remote phones work with G729 codec and the local phones use normal G711 voice encoding. The requirement is to enable hardware ad-hoc conferencing between remote G729 and local G711 phones.
Here is the configuration snapshot (only commands related to hardware conferencing are shown):
voice-card 0
dsp services dspfarm
!
voice class custom-cptone leavetone
dualtone conference
frequency 400 800
cadence 400 50 200 50 200 50
!
voice class custom-cptone jointone
dualtone conference
frequency 600 900
cadence 300 150 300 100 300 50
!
interface FastEthernet0/0
ip address 192.168.10.1 255.255.255.0sccp local FastEthernet0/0
sccp ccm 192.168.10.1 identifier 100 priority 1 version 4.1
sccp
!
sccp ccm group 2
bind interface FastEthernet0/0
associate ccm 100 priority 1
associate profile 2 register DSPprofile2
keepalive retries 5
!
dspfarm profile 2 conference
! Configure codecs allowed to participate in conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
codec g729br8
maximum sessions 2
conference-join custom-cptone jointone
conference-leave custom-cptone leavetone
associate application SCCPtelephony-service
sdspfarm units 2
sdspfarm tag 2 DSPprofile2
conference hardware
max-ephones 24
max-dn 48
ip source-address 192.168.10.1 port 2000 strict-match
max-conferences 4 gain -6!
ephone-dn 43 dual-line
number A000
description Ad-Hoc Conference
conference ad-hoc
no huntstop
!
!
ephone-dn 44 dual-line
number A000
description Ad-Hoc Conference
conference ad-hoc
preference 1
no huntstop
!
!
ephone-dn 45 dual-line
number A000
description Ad-Hoc Conference
conference ad-hoc
preference 2
!
!
ephone-dn 46 dual-line
number A000
description Ad-Hoc Conference
conference ad-hoc
preference 3
Notice on the configuration above that we have to create some dummy phone directory numbers (ephone-dn 43 to 46) to facilitate the ad-hoc conference operation. An Ad-hoc conference is an unscheduled conference. It occurs when a third party is added into any conversation by the participants. The ad-hoc initiators can add/delete/drop participants to/from the conference.
CME hardware conferencing supports a maximum of 8 participants in an ad-hoc conference.
Each DSP can support a maximum of 64 G.711 participants only (single-mode), this translates to:
- 8 conferences of 8 participants each.
Each DSP can support a maximum of 16 G.711/G.729A/G.729 participants (mixed-mode), so this translates to:
- 2 conferences of 8 participants each.
Verify DSP registration
If your DSPfarm is not registered to CME, you will not be able to use the DSP resources to initiate a conference call. To check if the dspfarm is registered, perform the following command – “show dspfarm all”
Example: Registered – good example
Router#show dspfarm all
<output omitted>
Profile Operation State : ACTIVE
Application : SCCP Status : ASSOCIATED
<output omitted>
Example: Unregistered – bad example
<output omitted>
Profile Operation State : ACTIVE IN PROGRESS
Application : SCCP Status : ASSOCIATION IN PROGRESS
<output omitted>



