Getting to know MPLS

By Jeremy Stretch

I've been reasonably familiar with MPLS ever since studying for the CCNP ISCW exam, but haven't bothered to lab it out until today. I set up a modest lab containing two each of CE, PE, and P routers, with an IS-IS core, IBGP between the PEs and EBGP to the CEs.

My goal wasn't to become more familiar with MPLS itself, but rather to examine what benefits (if any) it provides to vanilla routing. Obviously MPLS is popular for its ability to implement VPNs and for traffic engineering, but implementing MPLS for plain IP routing alone seemed unnecessary. Why add labels when prefix-based packet switching works just fine?

Take another look at the lab topology. Notice that although IS-IS is running on all P and PE routers, IBGP is only running between the two PE routers. Traffic between the BGP routers must traverse a non-BGP router. This presents a problem: the P routers (which ultimately provide transit between the CE routers) have no knowledge of the customer routes (192.168.*.0/24).

P1# show ip route
...
 10.0.0.0/30 is subnetted, 6 subnets
i L2    10.0.0.8 [115/20] via 10.0.0.1, FastEthernet0/0
i L2    10.0.0.12 [115/20] via 10.0.0.5, FastEthernet0/1
i L2    10.0.2.0 [115/20] via 10.0.0.5, FastEthernet0/1
C       10.0.0.0 is directly connected, FastEthernet0/0
i L2    10.0.1.0 [115/20] via 10.0.0.1, FastEthernet0/0
C       10.0.0.4 is directly connected, FastEthernet0/1

Although disabling synchronization and using next-hop-self allows the IBGP routers to successfully peer and exchange customer routes, the P routers will not know how to forward packets destined for a customer network. Even after verifying full route convergence, a ping from 192.168.10.1 on CE1 to 192.168.40.1 on CE2 fails.

CE1# ping 192.168.40.1 source 192.168.10.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.40.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1 
.....
Success rate is 0 percent (0/5)

To remedy this situation, we could redistribute customer routes into our IGP, but that's messy. Another option is to include the P routers in BGP, but that might not be workable. Alternatively, we can implement MPLS to provide a wrapper for the IP traffic.

MPLS assigns labels to forwarding equivalence classes (FECs) based on IP prefixes, and attaches one or more tangible labels to each packet. This gives the P routers an alternate destination address to work with, eliminating the need to maintain IP routes for destinations outside the MPLS domain. This point should become clearer after an example.

Configuring MPLS is simply a matter of choosing a distribution protocol (Label Distribution Protocol (LDP) in modern configurations) and designating MPLS interfaces:

PE1(config)# mpls label protocol ldp
PE1(config)# int <interface>
PE1(config-if)# mpls ip

After MPLS has been enabled on all P and PE routers, labels will be dynamically assigned for all internal (10...*) prefixes. The LFIB entries can be examined on MPLS routers with show mpls forwarding-table:

P1# show mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
16     Pop tag     10.0.0.8/30       0          Fa0/0      10.0.0.1     
17     Pop tag     10.0.0.12/30      0          Fa0/1      10.0.0.5     
18     Pop tag     10.0.2.0/30       9452       Fa0/1      10.0.0.5     
19     Pop tag     10.0.1.0/30       0          Fa0/0      10.0.0.1     

After deploying MPLS, we can try the ping from CE1 to CE2 again. Here's a rundown of the process from end to end:

1. PE1 receives the packet and performs a CEF lookup for 192.168.40.1. The route (learned via IBGP) indicates 10.0.2.1 as the next hop. CEF also indicates an MPLS label should be added, since the outbound interface is MPLS enabled.
2. PE1 inserts an MPLS header with the appropriate label between the layer 2 and layer 3 headers of the packet and sends it toward the next hop.
3. Depending on the load balancing in use, the next hop will be either P1 or P2; for demonstration purposes we'll assume P1 is chosen.
4. P1 receives the packet and performs a lookup on the label instead of the destination IP address. As the P routers have labels for all IGP-learned routes, P1 is able to make an intelligent decision on how to forward the packet.
5. P1 consults its LFIB and determines that the label should be popped because the next hop is the end of the label-switched path (LSP); this is known as penultimate hop popping (PHP). If there were additional hops in the LSP, the label would instead be swapped for another.
6. PE2 receives the unlabeled packet and normal IP routing occurs to route the packet to CE2.

To recap, MPLS enables P routers to bear transit traffic between IBGP peers not directly connected. Instead of relying on the destination IP address to determine a next hop, an intermediate label is used within the MPLS domain to designate a label-switched path (LSP) between the IBGP peers.

GNS3: Add Qemu Host (MicroCore)

December 14th, 2010 by http://www.brainbump.net

This write-up will explain Qemu Image use in GNS3 . Qemu Host image can be either CLI ( Microcore ) or GUI (Tinycore).Its basically a small linux image which can be used for performing some basic connectivity tasks e.g telnet, ssh, iptables, route, tcpdump and IPv6 support.

This tutorial will walk you through step by step for setting up Qemu Host image in GNS3

MicroCore Setup Instructions:


1.Set Qemu Host in GNS3 Preferences.
Edit -> Preferences -> Qemu -> Qemu Host

2.Setup Network Topology

3. Start & Configure R1 for Basic Connectivity (IP address etc.)

4. Start & Configure Qemu Host for Basic Connectivity (IP address etc.)

5. Test Connectivity between R1 & Qemu1

6. Enable R1 for telnet & ssh connections:

7. Remotely manage Router from Qemu Host :

8. Add Default Route / Gateway to  Qemu Host :

9. Use Qemu Host built-in tools e.g tcpdump & iptables for advanced testing:
tcpdump

IPtables

10. Finally , save all your configs  :

In order to make your configuration changes persistent so that they get automatically loaded upon reboot, use following commands:
vi /opt/bootlocal.sh
Add your configuration line by line & save the file (:wq!)

hostname Qemu1
ifconfig eth0 192.1.12.2 netmask 255.255.255.0 up
route add default gw 192.1.12.1
iptables -A INPUT -p tcp –dport telnet -j ACCEPT
iptables -A INPUT -j DROP

/usr/bin/filetool.sh backup
That’s all !
Software Version Used:

• GNS3 Version : v 0.7.3
• Microcore Version : 2.11.5
• Tinycore Version : 2.11.5
• IOS Image : c3745-adventerprisek9-mz.124-15.T13.bin

->For help using IPtables , refer to this guide
->Download Qemu Microcore / Tinycore Linux binary images from the following link: http://www.gns3.net/download

The Evolved Packet Core (EPC model)

By Frédéric Firmin, 3GPP MCC

This article looks at the Evolved Packet Core (EPC), the core network of the LTE system, giving an overview of the architecture of the core network, describing some of its key elements.
The EPC is the latest evolution of the 3GPP core network architecture.
In GSM, the architecture relies on circuit-switching (CS). This means that circuits are established between the calling and called parties throughout the telecommunication network (radio, core network of the mobile operator, fixed network). This circuit-switching mode can be seen as an evolution of the "two cans and a string". In GSM, all services are transported over circuit-switches telephony principally, but short messages (SMS) and some data is also seen.

In GPRS, packet-switching (PS) is added to the circuit-switching. With this technology, data is transported in packets without the establishment of dedicated circuits. This offers more flexibility and efficiency. In GPRS, the circuits still transport voice and SMS (in most cases). Therefore, the core network is composed of two domains: circuit and packet.
In UMTS (3G), this dual-domain concept is kept on the core network side. Some network elements have evolved but the concept remains very similar.
When designing the evolution of the 3G system, the 3GPP community decided to use IP (Internet Protocol) as the key protocol to transport all services. It was therefore agreed that the EPC would not have a circuit-switched domain anymore and that the EPC should be an evolution of the packet-switched architecture used in GPRS/UMTS.
This decision had consequences on the architecture itself but also on the way that the services were provided. Traditional use of circuits to carry voice and short messages needed to be replaced by IP-based solutions in the long term.

Architecture of the EPC

EPC was first introduced by 3GPP in Release 8 of the standard.
It was decided to have a "flat architecture". The idea is to handle the payload (the data traffic) efficiently from performance and costs perspective. Few network nodes are involved in the handling of the traffic and protocol conversion is avoided.
It was also decided to separate the user data (also known as the user plane) and the signalling (also know as the control plane) to make the scaling independent. Thanks to this functional split, the operators can dimension and adapt their network easily.
Figure 2 shows a very basic architecture of the EPS when the User Equipment (UE) is connected to the EPC over E-UTRAN (LTE access network). The Evolved NodeB (eNodeB) is the base station for LTE radio. In this figure, the EPC is composed of four network elements: the Serving Gateway (Serving GW), the PDN Gateway (PDN GW), the MME and the HSS. The EPC is connected to the external networks, which can include the IP Multimedia Core Network Subsystem (IMS).

HSS
Basically, the HSS (for Home Subscriber Server) is a database that contains user-related and subscriber-related information. It also provides support functions in mobility management, call and session setup, user authentication and access authorization.
It is based on the pre-3GPP Release 4 - Home Location Register (HLR) and Authentication Centre (AuC).
Serving GW
The gateways (Serving GW and PDN GW) deal with the user plane. They transport the IP data traffic between the User Equipment (UE) and the external networks.
The Serving GW is the point of interconnect between the radio-side and the EPC. As its name indicates, this gateway serves the UE by routing the incoming and outgoing IP packets.
It is the anchor point for the intra-LTE mobility (i.e. in case of handover between eNodeBs) and between LTE and other 3GPP accesses.
It is logically connected to the other gateway, the PDN GW.
PDN GW
The PDN GW is the point of interconnect between the EPC and the external IP networks. These networks are called PDN (Packet Data Network), hence the name. The PDN GW routes packets to and from the PDNs.
The PDN GW also performs various functions such as IP address / IP prefix allocation or policy control and charging.
3GPP specifies these gateways independently but in practice they may be combined in a single "box" by network vendors.
MME
The MME (for Mobility Management Entity) deals with the control plane. It handles the signalling related to mobility and security for E-UTRAN access.
The MME is responsible for the tracking and the paging of UE in idle-mode. It is the termination point of the Non-Access Stratum (NAS).

Support of multiple access technologies

As seen in figure 2, the UE can reach the EPC using E-UTRAN however this is not the only access technology supported.
3GPP specified support of multiple access technologies and also the handover between these accesses. The idea was to bring convergence using a unique core network providing various IP-based services over multiple access technologies.
Existing 3GPP radio access networks are supported. 3GPP specifications define how the interworking is achieved between an E-UTRAN (LTE and LTE-Advanced), GERAN (radio access network of GSM/GPRS) and UTRAN (radio access network of UMTS-based technologies WCDMA and HSPA).
The EPS also allows non-3GPP technologies to interconnect the UE and the EPC. Non-3GPP means that these accesses were not specified in the 3GPP. These technologies includes e.g. WiMAX, cdma2000®, WLAN or fixed networks.
Non-3GPP accesses can be split into two categories: the "trusted" ones and the "untrusted":

• Trusted non-3GPP accesses can interact directly with the EPC.
• Untrusted non-3GPP accesses interwork with the EPC via a network entity called the ePDG (for Evolved Packet Data Gateway). The main role of the ePDG is to provide security mechanisms such as IPsec tunnelling of connections with the UE over an untrusted non-3GPP access.

3GPP does not specify which non-3GPP technologies should be considered trusted or untrusted. This decision is made by the operator.

Upgrading Cisco Router IOS

Today I upgraded the flash and system RAM in my Cisco 2651XM router.

Before upgrading the router memory, I had this in place:

C2600 platform with 65536 Kbytes of main memory

16384K bytes of processor board System flash (Read/Write)

I bought 64 MB extra main memory and 16 MB extra flash memory. When I opened up the router, the insides looked like this diagram:

I had a single 64 MB DRAM DIMM in the "Primary memory" slot with one free. I had no memory in the "System-code SIMM (Flash memory)" slot, since the 2651XM must ship with 16 MB on the motherboard. Once I snapped in the extra memory, my router recognized it without any trouble, as will be seen later.

I also decided to upgrade from a 12.2 release to 12.3. My old IOS was 12.2(11)T10, which corresponded to the c2600-ik9s-mz.122-11.T10.bin image. The 'show flash' command showed this after the memory upgrades:

gill#sh flash

System flash directory:
File  Length   Name/status
  1   14962584  c2600-ik9s-mz.122-11.T10.bin
[14962648 bytes used, 18591784 available, 33554432 total]
32768K bytes of processor board System flash (Read/Write)

First I searched for a suitable IOS from the Cisco IOS Feature Navigator and Upgrade Planner tools. I located a version of IOS which offered NetFlow and SSH v2 in the 12.3 train, 12.3(4)T4 (image c2600-a3jk9s-mz.123-4.T4.bin). I downloaded it to a TFTP server on the same network as the router, into the TFTP server's /tftpboot directory.

I did not make a copy of the existing router flash image as I already had it elsewhere for safekeeping.

Next I copied my startup-config to the TFTP server:

gill#copy startup-config tftp://172.27.20.5/gill-startup-config
Address or name of remote host [172.27.20.5]?
Destination filename [gill-startup-config]?
!!
2200 bytes copied in 0.072 secs (30556 bytes/sec)

Now I was ready to copy my new flash image to the router:

gill#copy tftp flash
Address or name of remote host []? 172.27.20.5
Source filename []? c2600-a3jk9s-mz.123-4.T4.bin
Destination filename [c2600-a3jk9s-mz.123-4.T4.bin]?
Accessing tftp://172.27.20.5/c2600-a3jk9s-mz.123-4.T4.bin...
Erase flash: before copying? [confirm]
Erasing the flash filesystem will remove all files! Continue? [confirm]
Erasing device... eeeeeeeeeeeeeeee
...edited...
Erase of flash: complete
Loading c2600-a3jk9s-mz.123-4.T4.bin from 172.27.20.5 (via FastEthernet0/1):!!!!
!!!
...edited...
[OK - 24299960 bytes]
Verifying checksum...  OK (0x5193)
24299960 bytes copied in 182.832 secs (132909 bytes/sec)

Next I checked to see if it was loaded:

gill#sh flash

System flash directory:
File  Length   Name/status
  1   24299960  c2600-a3jk9s-mz.123-4.T4.bin
[24300024 bytes used, 8730120 available, 33030144 total]
32768K bytes of processor board System flash (Read/Write)

This looked fine, so I changed the system boot parameters to use the new image, copied the running-config to startup-config, and reloaded the router:

gill#conf term
Enter configuration commands, one per line.  End with CNTL/Z.
gill(config)#no boot system flash c2600-ik9s-mz.122-11.T10.bin
gill(config)#boot system flash  c2600-a3jk9s-mz.123-4.T4.bin
gill(config)#exit
gill#
01:21:28: %SYS-5-CONFIG_I: Configured from console by console
gill#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
gill#reload
Proceed with reload? [confirm]

01:22:32: %SYS-5-RELOAD: Reload requested by console.

I then watched the router come up:

System Bootstrap, Version 12.2(7r) [cmong 7r], RELEASE SOFTWARE (fc1)
Copyright (c) 2002 by cisco Systems, Inc.
C2600 platform with 131072 Kbytes of main memory

program load complete, entry point: 0x80008000, size: 0x172c840
Self decompressing the image : ###########
...edited...
############ [OK]

Smart Init is enabled
smart init is sizing iomem
  ID            MEMORY_REQ                 TYPE
00036F          0X00103980 C2651XM Dual Fast Ethernet
                0X000F3BB0 public buffer pools
                0X00211000 public particle pools
TOTAL:          0X00408530

If any of the above Memory Requirements are
"UNKNOWN", you may be using an unsupported
configuration or there is a software problem and
system operation may be compromised.
Rounded IOMEM up to: 5Mb.
Using 3 percent iomem. [5Mb/128Mb]
...edited...
program load complete, entry point: 0x80008000, size: 0x172c840
Self decompressing the image : ###########
...edited...
############ [OK]

Smart Init is enabled
smart init is sizing iomem
  ID            MEMORY_REQ                 TYPE
00036F          0X00103980 C2651XM Dual Fast Ethernet
                0X000F3BB0 public buffer pools
                0X00211000 public particle pools
TOTAL:          0X00408530

If any of the above Memory Requirements are
"UNKNOWN", you may be using an unsupported
configuration or there is a software problem and
system operation may be compromised.
Rounded IOMEM up to: 5Mb.
Using 3 percent iomem. [5Mb/128Mb]
...edited...
Cisco IOS Software, C2600 Software (C2600-A3JK9S-M), Version 12.3(4)T4, 
 RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2004 by Cisco Systems, Inc.
Compiled Thu 11-Mar-04 19:57 by eaarmas
Image text-base: 0x80008098, data-base: 0x8243BC1C
...edited...
Cisco 2651XM (MPC860P) processor (revision 0x100) with 125952K/5120K bytes of me
mory.
Processor board ID JAE071601DV (2514262155)
M860 processor: part number 5, mask 2
2 FastEthernet interfaces
32K bytes of NVRAM.
32768K bytes of processor board System flash (Read/Write)

Press RETURN to get started!

*Mar  1 00:00:04.695: %LINEPROTO-5-UPDOWN: Line protocol on Interface VoIP-Null0,
 changed state to up
*Mar  1 00:00:15.280: %LINK-3-UPDOWN: Interface FastEthernet0/0,
 changed state to up
*Mar  1 00:00:15.280: %LINK-3-UPDOWN: Interface FastEthernet0/1,
 changed state to up
00:00:16: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0,
 changed state to up
00:00:16: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1,
 changed state to up
00:00:18: %SYS-5-CONFIG_I: Configured from memory by console
00:00:19: %SYS-5-RESTART: System restarted --

Cisco IOS Software, C2600 Software (C2600-A3JK9S-M), Version 12.3(4)T4,  RELEASE
 SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2004 by Cisco Systems, Inc.
Compiled Thu 11-Mar-04 19:57 by eaarmas
00:00:19: %SNMP-5-COLDSTART: SNMP agent on host gill is undergoing a cold start
00:00:19: %NTP-6-RESTART: NTP process starts
00:00:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0,
 changed state to down
00:00:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1,
 changed state to down
00:00:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1,
 changed state to up
00:00:27: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address edited,
 mask 255.255.254.0, hostname gill
00:00:30: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0,
 changed state to up
00:00:33: %NTP-5-PEERSYNC: NTP synced to peer 204.152.184.72
00:00:33: %NTP-6-PEERREACH: Peer 204.152.184.72 is reachable

Everything looks fine, including the time setting via NTP. I also looked again at the flash and then the filesystem:

gill>enable
Password:
gill#sh flash detailed

System flash directory:
File  Length   Name/status
        addr      fcksum  ccksum
  1   24299960  c2600-a3jk9s-mz.123-4.T4.bin
        0x40      0x5193  0x5193
[24300024 bytes used, 8730120 available, 33030144 total]
32768K bytes of processor board System flash (Read/Write)
gill#show file systems
File Systems:

     Size(b)     Free(b)      Type  Flags  Prefixes
           -           -    opaque     rw   system:
       29688       26383     nvram     rw   nvram:
           -           -    opaque     rw   null:
           -           -    opaque     ro   xmodem:
           -           -    opaque     ro   ymodem:
           -           -   network     rw   tftp:
*   33030144     8730120     flash     rw   flash:
           -           -   network     rw   pram:
           -           -   network     rw   rcp:
           -           -   network     rw   scp:
           -           -   network     ro   http:
           -           -   network     rw   ftp:
           -           -   network     ro   https:
           -           -    opaque     ro   cns:

My upgrade was complete!

Posted by Richard Bejtlich

How to run topologies in GNS3 without hitting %100 utilization

How to get Good Idle-PC Value in GNS3

One of the most difficult problems new users have to come to grips with when starting out with GNS3 is the concept of an Idle-PC.
Get it right, and you will have a great GNS3 experience. Try to ignore it, and you will be forever miserable.
Here is my tedious and time consuming method of finding a good idle-pc value.
REPEAT FOR EVERY DIFFERENT IOS IMAGE YOU WISH TO RUN ON YOUR SYSTEM:
Step 1:
Windows: Open the windows task manager and sort by %CPU
Linux: Open a console window and enter the command top
Mac OS X: Open a terminal window and enter the command top -o cpu
Keep this window visible for the entire process

Step 2:

In GNS3, start a new topology with 1 router ONLY
Start the router
Open the console. When when the router is fully up, configure the following:

line con 0
exec-timeout 0

NOTE: While writing this post, I observed this step alone dropped the CPU usage from 98% to 1% on a Windows 7 install (running in a VM on OS X)

Step 3:

Back at your task manager or console window:
Take note of the amount of CPU being chewed by dynamips

Step 4:

In GNS3, right-click on the router and choose idle-pc
If NO values appear marked with *, try again
When you find a value marked with a *, WRITE IT DOWN
If MULTIPLE values appear with *, WRITE THEM ALL DOWN (in a column)
… then choose one of them

Step 5:

Check the CPU utilisation for dynamips in the task manager or console window.
Estimate the average CPU consumption for dynamips over say 15-20 seconds
WRITE IT DOWN next to the Idle-pc value you wrote down in step 4
If you have an idle-pc vlaue that shows less than 10-15% CPU, you may want to go to step 6,
Else, go back to step 4

Step 6:

Now that you have a good idle-pc, you need to know how to use it well.
Firstly, check that GNS3 has recorded you best value against the image you are using
That’s in:
Edit->IOS Images and Hypervisors
Select the image you are using and check the IDLE PCs value
Now GNS3 will automatically use that value in any NEW topologies you create.

Step 7:

If you have any saved topologies (ie .net files) that have used this IOS, open the .net file and replace the idle-pc value found there with your new “good” idle-pc value.

Step 8:

Record the results you found (IOS & idle-pc values) in a spreadsheet and keep it!
Now go back to Step 1 and repeat for the next IOS image you use

General Tips for keeping CPU under control

Always use the same image for ALL routers in your topology if possible.
This means using the same router model as well. If this is not possible, use the same image for all routers of the same model.
ALWAYS set the exec-timeout 0 under line con 0
In GNS 0.7.3 and later, you can set a base config for each IOS image under Edit->IOS Images and Hypervisors. Make sure the base config has the exec-timeout 0 under line con 0

Reference: http://www.gns3.net/phpBB/topic2873.html

FACETIME_ANALYSIS

NAT traversal for the SIP protocol

By Diana Cionoiu;

NAT stands for Network Address Translation. It's the technology which allows most people to have more than one computer in their home and still use a single IP address. Most of the time, a router with NAT support gets data packets from the internal network (with internal IP addresses) and sends them to Internet, changing the internal IP address of each packet to the external one.

What's RTP?

RTP stands for Real-Time Transport Protocol. Its purpose is to pass voice data between a caller and the called. The problem is that when you call someone using the RTP protocol, you need to know his IP address and port. This makes RTP quite inconvenient when used alone, since the parts have no way to find one another. This is why people invented SIP.

What's SIP?

SIP (Session Initiation Protocol) looks in syntax like HTTP, human readable text. Its purpose is to help the caller find the IP address and port of the called. It also helps the negotiation of the media types and formats. For example, when you have a PC at home and you want to call your friend from Romania using Free World Dialup (which uses the SIP protocol):

SIP sends an INVITE packet with the caller IP address and port for RTP to the FWD server, and from there, FWD forwards the call to the intended destination. The called accepts the call and sends his own IP address and port for RTP back.

SIP + NAT, an unsolvable problem?

The problem with SIP and NAT is not actually a SIP problem, but the RTP problem. SIP announces the RTP address and port, but if the client is behind NAT, it announces the client's RTP port, which can be different from the port the NAT allocates externally.

Even if a lot of SIP implementations and carriers are based on the fact that NAT will always try to allocate the same port, that assumption is false. In a production environment, you can't tell grandma that she can't talk with her grandson because some router has allocated another number.

If you are a carrier, the solution is simple because you proxy all the data, anyway. The solution is to use a SIP Session Border Controller. The SIP SBC normally stays in front of the internal SIP network of the carrier, solving the NAT traversal problem and protecting the SIP network.

The solution for NAT traversal in this case is to use some tricks.
The first trick is to keep open the hole in the NAT from the SIP client to the server. This is normally done by making all SIP clients use a two byte packet which is sent more often than 30 seconds. Some routers remove apparently unused NAT mappings after 30 seconds; GNU/Linux typically does this after three minutes.
The second trick is one we've used for our project YATE, to figure out the RTP IP and port from the first packet that arrives on the local RTP IP and port of the server, and to use it instead of using the RTP IP and address declared in SDP. This trick solves the NAT traversal problem, no matter how many NATs the client is traversing. However, the main disadvantage is that, in some cases, the client will not receive early media (since at that point, it sends out no voice packets) and it will not hear the ringing.
If you are not a carrier and you are trying to make a peer-to-peer call and both sides are behind the NAT, you must use an external SIP proxy or gateway to pass the SIP between the two points, hoping that the NATs will open the proper ports, one to another, for the RTP connection. However, there is no ultimate solution for that. Two proposed solutions are STUN and ICE, but every solution that currently exists can get in your way sometimes. Skype has found a very simple and nice solution for this problem: They use the Skype clients that are not behind NAT to proxy all the data for clients that are behind NAT.

This solution, technically speaking, is very good. However, there are some moral and political reasons not to use Skype. One of them is that if you are a Skype client outside the NAT, you don't know whose data is passing through your computer. Another is that it is using your bandwidth; after all, someone has to pay one way or another for Internet bandwidth necessary to proxy the voice stream.
My personal hope is that in the near future, most SIP implementations will use the two tricks used by YATE. Skype will probably be around for a long time for home users, but enterprise seems to move slowly to VoIP providers. With a lot of work and a little bit of luck, they will become at least as reliable as PSTN providers, since the technology is better.