Sunday, August 30, 2009

NAT Load Balancing with multiple ADSL


Recently, we switched ISP and migrated 3 x ADSL links for an Internet LAN. The above diagram is a simplistic diagram The route to the Internet was load-balancing among the 3 links. We were happy about the result until some users complained of slow Internet access at peak hours. I investigated (sh ip nat translation on EXEC mode) and realised that all the PAT (Port Address Translation) entries were only overloading on the first outside interface (Dialer 1) instead of all 3 dialer interfaces. In other words, all traffics were taking on the public IP of the first link, which the return traffic must be returned via that link only (main bottleneck).

To workaround this, I used route-map classification instead of just ACL for NAT target. After configurating, the "sh ip nat translation" would show that the entries were taking on the 3 different public IP addresses evenly.

#load balancing default routes
ip route 0.0.0.0 0.0.0.0 dialer 1
ip route 0.0.0.0 0.0.0.0 dialer 2
ip route 0.0.0.0 0.0.0.0 dialer 3

#cause outgoing packets to overload on its outgoing interface
route-map d1-nat permit 10
match ip address 88
match interface Dialer1

route-map d2-nat permit 10
match ip address 88
match interface Dialer2

route-map d3-nat permit 10
match ip address 88
match interface Dialer3

# User LAN inside address
access-list 88 permit 192.168.1.0 0.0.0.255

# NAT operations
ip nat inside source route-map d1-nat interface Dialer1 overload
ip nat inside source route-map d2-nat interface Dialer2 overload
ip nat inside source route-map d3-nat interface Dialer3 overload

#Bringing load-balancing PAT to effect
interface fa0/0
ip nat inside

interface dialer 1
ip nat outside

interface dialer 2
ip nat outside

interface dialer 3
ip nat outside

Reference: IOS NAT Load-Balancing for Two ISP Connections

Bandwidth Measurement using Cisco Netflow

Netflow is great and handy to measure the amount of resources used in a typical Cisco network. Netflow comes with 3 versions: v1, v5 and v9. The most common version is v5. Recently, I have to justify for the amount of bandwidth upgrade for our Internet access - with a breakdown of the Internet application usage e.g. http, ftp, p2p etc. I configured the Internet router to keep pumping netflow data to a Netflow collector. I used an eval copy of PRTG network monitor (http://www.paessler.com/prtg)

The setup is amazingly simple:
On the router,
interface [WAN]
ip route-cache flow
ip flow-export version 5 peer-as
ip flow-export destination [Server IP] [UDP port]


Make sure that the Netflow collector is also configured with the matching server IP address and UDP port number. Few days later, I presented this chart to get my boss to agree on the bandwidth upgrade.

Calculating number of voice calls


How many voice calls can a WAN link support given the amount of bandwidth, codec, packet header, payload and cRTP? This is a sample CCDA question on voice. Well, I have come up with a simple calculation. See below sample questions:

Q1) Given a VoIP network with these attributes:
Codec: G.728, Bit rate: 16 Kbps, WAN Bandwidth: 256 Kbps, Packet Header: 6 bytes, Payload: 40 bytes, CRTP: Yes

How many calls can be made? Ans: 13
Amount of b/w per call = [voice overhead + packet header + payload] * 50 pps * 8
= [ 2(cRTP)+ 6 + 40 ] * 50 * 8 = 19,200 bps
Number of calls supported = Total bandwidth / bandwidth per call
= 256,000 / 19,200 = 13 (round-down)

Q2) Given a VoIP network with these attributes:
Codec: G.711, WAN bandwidth: 768Kbps, Packet Header: 6 bytes, Payload: 160 bytes, CRTP: No

How many calls can be made? Ans: 9
Using the same formula,
Amount of b/w per call = [voice overhead + packet header + payload] * 50 pps * 8
= [ 40 (no cRTP) + 6 + 160 ] * 50 * 8 = 82,400 bps
Number of calls supported = Total bandwidth / bandwidth per call
= 768,000 / 82,400 = 9 (round-down)