Look here for complete TelisSonera BGP Community: 

http://www.db.ripe.net/whois?searchtext=-a+-r+-T+aut-num+as1299

Communities of Tiscali International Network (TINet) - AS3257

---

This is the list of BGP communities that can be set by customers

(after engineering@ip.tiscali.net approval):

• 3257:1030 do not announce to upstream.
• 3257:1031 prepend 1x to upstream.
• 3257:1032 prepend 2x to upstream.
• 3257:1033 prepend 3x to upstream.

• 3257:2490 do not announce in Europe.
• 3257:2491 prepend 1x in Europe.
• 3257:2492 prepend 2x in Europe.
• 3257:2493 prepend 3x in Europe.

• 3257:2990 do not announce in the US.
• 3257:2991 prepend 1x in the US.
• 3257:2992 prepend 2x in the US.
• 3257:2993 prepend 3x in the US.

• 3257:1980 - give routes localpref below normal customer route.
• 3257:1970 - give routes localpref below normal peer route.
• 3257:1960 - give routes localpref below transit route.

Communities that are sent on customer BGP sessions:

• 3257:1xxx and 3257:2xxx control route behaviour in our network, for customer to steer incoming traffic (see above).
• 3257:3xxx tags private peerings, for customer to steer outbound traffic.
• 3257:4000 tags TINet customer route.
• 3257:4010-4499 tags EU exchanges (detailed list available on request).
• 3257:4500-4999 tags US exchanges (detailed list available on request).

the 3257:50xx communities are used to tag the geographic region of route
entrance into our network (where xx represents the country code) e.g.:

• 3257:5010 route originated in the US
• 3257:5030 route originated in GR
• 3257:5031 route originated in NL
• 3257:5032 route originated in BE
• 3257:5033 route originated in FR
• 3257:5034 route originated in ES
• 3257:5352 route originated in LU
• 3257:5353 route originated in IE
• 3257:5039 route originated in IT
• 3257:5041 route originated in CH
• 3257:5042 route originated in CZ
• 3257:5043 route originated in AT
• 3257:5044 route originated in UK
• 3257:5045 route originated in DK
• 3257:5046 route originated in SE
• 3257:5047 route originated in NO
• 3257:5049 route originated in DE
• 3257:5852 route originated in HK (Hong Kong)
• 3257:5099 multi-national prefix

Customer Setup Information

Multi-homing with BGP (Border Gateway Protocol) is the practice of connecting to multiple service providers and having simultaneous external BGP peering sessions with each provider. A Multi-homed customer typically owns an Autonomous System Number and exchanges routing table information with two or more upstream Internet
Service Providers (ISPs).

How will AT&T assist a BGP Multi-homing customer?

1. AT&T Provisioning will assist the customer in bringing up the BGP peering session between AT&T and the customer. AT&T's Networking Professional Services Group is available to assist with complex network consulting beyond the scope of standard implementation tasks. To obtain this type of consulting support, please contact your AT&T Sales Representative.

2. AT&T offers a managed router solution with BGP4 (BGP Version 4) for multiple connections to AT&T only.

3. The customer must assume responsibility for any iBGP (internal BGP) configuration or customer controlled backup scenarios.

4. The customer must assume responsibility for any other provider configurations that exist.

What do you need to run BGP with AT&T?

1. AT&T runs only BGP4. Earlier versions of BGP are not supported.

2. AT&T filters BGP sessions based on network address space. This is called Source Address Assurance and is a security practice designed to help protect the network from address "spoofing".

3. Customer Route announcements must be at least /24 in size and either belong to the customer or be under the authority of the customer.

4. Customers must have their own Autonomous System Number (ASN) for any multi-vendor solution. If the customer wishes to run BGP4 with AT&T as the ONLY provider, a private ASN will be used.

5. Customers must apply for their own ASN through the American Registry for Internet Numbers (ARIN). Information provided below will be needed for the ASN request form. Autonomous System Numbers can be applied for at http://www.arin.net.

6. A customer must have, or be in the process of gaining, connectivity to two different ISPs or be ready to prove that they have a vastly different routing policy than their single ISP in order to qualify for an ASN.

Autonomous System Number Request Template Information:

AT&T's Autonomous System Number: 7018
AT&T Technical Contact for Autonomous System Number Request form:
Contact Name: MIS Tier2 Bridgeton, MO
Email Address: MIS_bgp@ems.att.com This e-mail address is being protected from spambots. You need JavaScript enabled to view it This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
ASN Registration Guidelines - http://www.arin.net
Autonomous System Numbers are globally unique numbers that are used to identify an Autonomous System (AS), and which enable an AS to exchange exterior routing information between neighboring ASes. An AS is a connected group of IP networks that adhere to a single and clearly defined routing policy.
There are a limited number of available ASNs, therefore, it is important to determine which sites require unique ASNs and which do not. Sites that do not require a unique ASN should use one or more of the ASNs reserved for private use. Those numbers are:
64512 through 65535.
In order to be assigned an ASN, each requesting organization must provide ARIN with verification that it has:

1. A unique routing policy (its policy differs from its border gateway peers)
2. A multi-homed site

An ASN Request Template is available for requesting the assignment of an ASN. Please visit http://www.arin.net for additional ASN registration guidelines. AT&T does not provide registered Autonomous System Numbers or obtain AS Numbers for customers.

AT&T Route Advertisement to Customer AT&T will advertise one of the following sets of routes, at the option of the customer, over each connection.
• Default Route (0.0.0.0)
• Candidate Default Networks (12/8 and 192.205.31.0/24) (see explanation below)
• AT&T Routes (including Candidate Networks) - To receive these, the customer’s router will require a minimum 16 MB Memory
• Full Internet Routes - To receive these, the customer’s router will require a minimum of 64MB Memory On Candidate Default Networks:
Additionally, a route will be originated by the AT&T IP Backbone to its customers to indicate that the AT&T IP Backbone is reachable. This is useful for customers requiring a dynamic indication of reach-ability but find the 12.0.0.0/8 announcement is too coarse.
The route originated is 12.127.255.255/32 and carries a BGP community of 7018:1000.

Policy for AT&T Route Announcements
AT&T will announce the following routes to the Internet:

Address Space	Announcement Policy
AT&T's Class A: 12/8	• Announce 12/8 and Announce nothing longer than 12.x.x.x/24 routes. The 12.x.x.x/24 and shorter specific routes will be announced only if the customer requests AT&T to announce the more specific route.
AT&T's CIDR Class C address blocks	• Announce nothing longer than the CIDR block prefix • Announce nothing longer than /24 routes. The /24 and shorter specific routes will be announced only if the customer requests AT&T to announce the route.
Customer-provided prefixes that are valid (i.e., registered)	• Announce aggregate prefix(es) when appropriate • Announce customer-owned individual network prefixes only when the individual customer prefixes cannot be combined • Announce nothing longer than /24 routes. Announce the /24 and shorter specific routes only at customer request
RFC1918 Address Space	• AT&T will not announce RFC1918 address space
Loopback Addresses	• AT&T will not announce RFC1918 address space

Dynamic Customer Control: RFC1998

If multiple connections exist to dual ISPs where BGP4 is the routing protocol, the primary/backup link specification will be under the control of the customer. Thus, load splitting is also under control of the customer. Customers may affect routing control by using a variety of methods. AT&T will honor all customer MED (Multi-Exit
Discriminator) settings.
Customer may also use AS Path Padding to prefer or de-prefer a particular path. The customer may choose to signal AT&T by appending the BGP community attribute to a route to specify the local preference of the route (see RFC 1998). The following table lists the signaled BGP community values and the corresponding local preference values attached to the route by AT&T.

BGP Community Received	AT&T IP Backbone Function
None, 7018:100	Local Preference of 100 (Default) Assigned - Used for Primary Routes
7018 : 90	Local Preference of 90 Assigned - Used for Customer Backup Routes (INTRA - AT&T)
7018 : 80	Local Preference of 80 Assigned - Used for Routes Equal to Peer Routes
7018 : 70	Local Preference of 70 Assigned - Used for Customer Provided Backup (INTER-AT&T + OTHER ISP)
7018 : 20 (Default)	Assign BGP community 7018:2000 to routes. BGP Community 7018:2000 routes are announced to peers and customers. This BGP community needs to be present on more specific routes from within AT&T-owned address blocks. This community need not appear on routes for customer-owned addresses and for addresses owned by a customer's other provider, as these routes will normally be advertised to peers and customers. No harm is done if BGP community 7018:20 appears on such routes.
7018 : 25	Assign BGP community 7018:2500 to routes. BGP Community 7018:2500 routes are announced only to other customers, not to peers. This is appropriate when customers do not want AT&T to provide global Internet transit service for this route.
7018 : 21	Assign BGP community of 7018:2010 to routes. BGP Community 7018:2010 routes are to be used within the AT&T IP Backbone, but not advertised to peers or customers. Typically the customer will simultaneously announce a shorter prefix covering this route, with the shorter prefix being announced to peers and/or customers. Prefix lengths on such routes will frequently be longer than /24.

Using BGP community string the customer can transmit separate networks with varying preferences to achieve the routing policy and traffic flow desired. If the customer does not want to transmit BGP communities and wants to specify primary/backup status for routes on specific links, the customer can use a static route configuration.

Key BGP Attributes:

1. MED or Multi-Exit Discriminator is a value set by the customer on outbound route announcements to AT&T. This value is used to determine the best possible path when there are multiple paths from one AS to another. MED is a relative value for comparison between two connection points. The AT&T IP Backbone will listen to customer MED
settings. The AT&T IP Backbone does not send a MED to the customer. The AT&T IP Backbone does not send a MED to peers or other customers. A MED is absorbed and acted upon only within the AT&T IP Backbone.

2. AS PATH PADDING or PREPENDING is the process of stamping multiple instances of one's own AS to a route announcement to de-prefer that path for inbound traffic. Customers can use PATH PADDING to influence the routing behavior of external sources trying to reach the customer.  PATH PADDING may not affect the directly connected network. In other words, traffic that originates on the AT&T IP Backbone will use the direct connection to reach the customer regardless of the prepending that has been done to that route announcement.
This is because a directly connected customer has a higher local-preference (BGP attribute) than a peer route and local-preference is taken into account BEFORE AS PATH.

3. LOCAL PREFERENCE is a very powerful attribute in BGP route selection. Local preference settings cannot be sent from one AS to another. AT&T allows the customer to send BGP community strings according to RFC1998 (see Dynamic Customer Control) which trigger the setting of local preference for routes to the customer in the AT&T IP
Backbone. Customer's should take care when using Local Preference, as it can force traffic into taking a very indirect, and possibly high latency route to reach a directly connected customer. For example, a local Preference of 70 will cause AT&T to use a peer connection to reach a directly connected customer if a route to that customer
through the peer exists.

4. BGP COMMUNITY ATTRIBUTE is a transitive tag that is sent from one Autonomous System to another. The BGP community attribute is used by AT&T to allow customers to signal local preference settings for particular route advertisements. AT&T also accepts several well -known BGP community attributes such as "no-export" and "no-advertise".

In iBGP, there is a rule to avoid routing loop by not advertise any route receive from other iBGP neighbor.  The rule have consequence that every router in the AS needs peer with all router so every router have routing from other router in the AS.  This is called full mesh configuration. 

Imagine if an AS have 100 routers.  It needs to create 99 peers in every router, and there will be 99x100 peers in the network.  There are two mechanism as alternative of full mesh iBGP, BGP Confederations, and BGP Route Reflectors.  This post will describe route reflector.

How It Works
BGP route reflector is allowed to break iBGP loop avoidance rule, by advertising any route that received from its clients to other clients, other non client peers.  Clients is a router that connect to a BGP route reflector.  This mechanism eliminate needs for full mesh iBGP.
There are two types of router in an AS with route reflector, namely clients router, and non client router.  Client router peers only with route reflector, on no need for full mesh iBGP.  Non client peers with other non client routers, and need to be fully meshed.

Operation
1.  Routes receive from clients is reflected to other clients, and non peer client (or other BGP route reflectors)
2.  Routes receive from another non client peers (or route reflectors) is reflected to clients only
All the routes relected is the best path routes only.

Redundant RR
Usually a cluester of client have single RR, and cluester will be identified with ROUTER_ID of the RR.  It is possible to use redundant RR in a cluster to avoid single point of failure.  All RR in a cluster can be configured with 4-byte CLUSTER_ID so that RR can discard routes from other RRs in the same cluster.


To configure route reflector in Juniper router see Configuring Route Reflector in Juniper Router.

Reference:
http://www.faqs.org/rfcs/rfc2796.html

This post will shows applications of BGP Community.  It doesn't show deep description about BGP Community.  BGP communities are tags, or attributes that can be attached to BGP prefixes announcement.  Based on that community, policy can be define to do something to that routes.  BGP Communities are descibed in RFC 1997.  According to RFC 1997, BGP Communities describe as a group of destinations which share some common property.  Each autonomus system administrator may define which communities a destination belongs to.  By default, all destinations belong to the general Internet community.  BGP Community have 32 bit value.

BGP communities can be used to influence routes.  Based on BGP Communities attached, administrator can prepend as-path, add local preference, or another policy, to prefix that received.  Also, if adminsitrator knows communities value, or have aggreement with upstream, administrator can set some communities value to influence routes at the upstream.

Applications of BGP Communities
If you want to define policy based on community value, the first thing to do is add community value to routes or prefixes.  Then in the receiver router, set policy for routes or prefixes that have community.  In IOS, you must set neighbor send-community in order BGP speaker include community in routes announcement.

Example

AS 65000 want set community for their customers prefixes to control routes advertisement.  Community value 65000:1 will be prepended twice when adevrtise to Telia, and community value 65000:2 will be prepended twice when advertised to Sprint.  Router A is router that connected to customer, and router B is router that connected to upstream.
In router A, you configure policy to set community 65000:1 or 65000:2.  In router B, you configure policy to prepend as-path based on community.

In Cisco router

Router A Configuration

router bgp 65000
neighbor 10.1.1.1 remote-as 65000
neighbor 10.1.1.1 description To_Border_Router_B
neighbor 10.1.1.1 send-community both
neighbor 10.1.1.1 update-source loopback0
neighbor 172.16.1.2 remote-as 65001
neighbor 172.16.1.2 description To_Cust_X
neighbor 172.16.1.2 route-map SET_COM_TELIA in
neighbor 172.16.1.4 remote-as 65002
neighbor 172.16.1.4 description To_Cust_Y
neighbor 172.16.1.2 route-map SET_COM_SPRINT in

route-map SET_COM_TELIA permit 10
set community 65000:1

route-map SET_COM_SPRINT permit 10
set community 65000:2

Router B Configuration

router bgp 65000
neighbor 10.1.1.2 remote-as 65000
neighbor 10.1.1.2 description To_Edge_Router_A
neighbor 10.1.1.2 send-community both
neighbor 10.1.1.2 update-source loopback0
neighbor 192.168.1.2 remote-as 1299
neighbor 192.168.1.2 description To_Telia
neighbor 192.168.1.2 send-community both
neighbor 192.168.1.2 route-map TO_TELIA out
neighbor 192.168.1.4 remote-as 1239
neighbor 192.168.1.4 description To_Sprint
neighbor 192.168.1.4 send-community both
neighbor 192.168.1.4 route-map TO_SPRINT out

route-map TO_TELIA permit 10
match community 65000:1
set as-path prepend 65000
route-map TO_TELIA permit 15

route-map TO_SPRINT permit 10
match community 65000:2
set as-path prepend 65000
route-map TO_SPRINT permit 15

In Juniper router

Router A

[edit]
protocols {
bgp {
group Customer {
type external;
neighbor 172.16.1.1 {
description Cust_X;
import SET_TELIA
peer-as 65001;
}
neighbor 172.16.1.2 {
description Cust_Y;
import SET_TELIA
peer-as 65002;
}
}
policy-option {
policy-statement SET_TELIA {
then {
community add TELIA;
accept;
}
}
policy-option SET_SPRINT {
then {
community add SPRINT;
accept;
}
}
community TELIA members 65000:1;
community SPRINT members 65000:2;
}

Router B

[edit]
protocols {
bgp {
group Upstream {
type external;
neighbor 192.168.1.2 {
description Telia;
export TO_TELIA
peer-as 1299;
}
neighbor 192.168.1.4 {
description Sprint;
export TO_SPRINT
peer-as 1239;
}
}
policy-option {
policy-statement TO_TELIA {
term 2 {
from community TELIA;
then {
as-path-prepend "65000";
accept;
}
}
term 2 {
then accept;
}
}
policy-statement TO_SPRINT {
term 1 {
from community SPRINT;
then {
as-path-prepend "65000";
accept;
}
}
term 2 {
then accept;
}
}
community TELIA members 65000:1;
community SPRINT members 65000:2;
}

Reference:
http://tools.ietf.org/rfc/rfc1997.txt

Cisco has support EIGRP as PE CPE routing protocol in MPLS VPN.  It is just like another routing protocol using for PE CPE roituing protocol.  The mechanism is common.  EIGRP in PE talk with EIGRP in CPE to exchange routing, then routing receive from CPE is redistribute to MP BGP (multi protocol BGP) running under address family configuration.  EIGRP receive all VPN routing from reditributing form MP BGP (multi protocol BGP) running under address family configuration.


Example Configuration

BGP Configuration

router bgp 65000
no syncronization
neighbor 10.10.10.1 remote-as 65000
neighbor 10.10.10.1 update-source loopback0
address-family vpnv4
neighbor 10.10.10.1 activate
neighbor 10.10.10.1 send-community extended
exit-address-family
address-family ipv4 vrf TEST
reditribute eigrp 100
no syncronization
exit-address-family

EIGRP Configuration

router eigrp 1
address-family ipv4 vrf TEST
network 192.168.1.0 0.0.0.255
reditribute bgp 65000 metric 10000 100 255 1 1500
autonomous-system 100
exit address-family

EIGRP 100, EIGRP autonomus system running between PE and CPE, is reditribute into BGP so that the routing from PCE receive by EIGRP can be send across MPLS network and receive by another PE.  Also, routing form BGP AS 65000 is reditribute into EIGRP, so that it can send to CPE through EIGRP 100.  Autonomous system in EIGRP is that autonomous system running in CPE router.

Blogged with the Flock Browser

Peer group in a set of BGP neighbor that share some policy.  Policy that can be the same, for example, route-map, filter-list, prefix-list, update-source, route-reflector client.  Peer group can reduce cpu process consumption, also configuration effort.


Example

BGP Configuration Using Peer Group In Cisco Router

Before using Peer Group

router bgp 65000
neighbor 10.10.1.1 remote-as 65000
neighbor 10.10.1.1 update-source loopback0
neighbor 10.10.1.1 route-reflector client
neighbor 10.10.1.1 next-hop self
neighbor 10.10.1.2 remote-as 65000
neighbor 10.10.1.2 update-source loopback0
neighbor 10.10.1.2 route-reflector client
neighbor 10.10.1.2 next-hop self

After using Peer Group

router bgp 65000
neighbor INTERNAL-PEER peer-group
neighbor INTERNAL-PEER update-spurce loopback0
neighbor INTERNAL-PEER route-reflector client
neighbor INTERNAL-PEER next-hop self
neighbor 10.10.10.1 remote-as 65000
neighbor 10.10.10.1 peer-group INTERNAL-PEER
neighbor 10.10.10.2 remote-as 65000
neighbor 10.10.10.2 peer-group INTERNAL-PEER

BGP Configuration Using Peer Group in Juniper Router

In JunOS, by default neighbor is create under group, a.k.a peer group.  So, if you want share policy, just apply policy under group, not under specific neighbor.

This procedure will explain how to recover JunOS password.

1.  Login to machine using console port.  Restart the machine, when appear the boot screen, interrupt the boot process by pressing space.
2.  Go to singel user mode, by type boot -s
3.  System will do normal boot process.  When promped for "pathname", enter
/usr/libexec/ui/recovery-mode
4.  System will bring you to "root>"
5.  At this point, you can delete, or change the root-authentication.  I like change rather than delete it.  Type configure at root> prompt to enter configuration mode.
6.  Now you have been in JunOS configuration mode.  Set root-authentication to change root-authentication password, or delete root-authentication.
7.  Commit to save new root-authentication password.
8.  Reboot it to enter normal process again.

Olive is PC running JunOS not in Juniper machine. Not like Cisco IOS that have Dynamips as ready to use IOS simulator, there is no ready to use JunOS simulator yet.
Fortunately, JunOS runs on top of FreeBSD, so we can simulate by install it on FreeBSD, called as Olive.  To whom that want to learn JunOS, or want to take JNCIE :), but do not have Juniper machine, Olive is the solution.  This post will explains how to install JunOS in VMWare or called Olive.
Things that you need to prepare are, FreeBSD image, VMWare, and Junos image itself. Follow steps below for installing Olive.

1. Installing FreeBSD Using VMWare
Download FreeBSD here. Download JunOS image, just googling to find it, I recommend to use FileCrop, a file search engine, it's very easy to find any file using it.
Install FreeBSD in VMWare. I create 3 Gb as virtual disk.  You need this miminum space, cause later, we will upgrade to Junos 9.x that need 3 Gb minimum virtual harddisk.
Choose Skip Kernel Configuration

Choose Express
Choose A (Use Entire Disk). Choose Q (Quit).

Choose Standard

Choose C (create).

Fill 500M, FS (FIle System), fill / on partition.

Choose C.
Fill 500M, Swap.

Choose C, Fill 100M, fill /config on partition.

Choose C, use all rest of space, fill /var on partition.

Click Q (Finish).

Choose CD/DVD. Choose Yes on answer.

Choose Yes again.

Choose Root password. Fill with your root password.

Choose Networking, Choose Interfaces.

Choose Interfaces. Choose em0.

Choose No for IPv6

Choose No for DHCP if you plan to configure static IP.

Fill your network configuration.

Choose Yes.

Choose Exit.

Choose Exit Install.

2. Installing Junos image

a. Copy JunOS image to FreeBSD virtual machine. Setup your FTP server, then use FTP to copy Junos image from your FTP server to your virtual machine. One of recomended free FTP Server is Cesar FTP Server. It is easy to use. Although it has not been developed again, but it still can be downloaded. After setup your account and directory, do ftp from your virtual machine. Set your local directory to /var/tmp.

b. Installing JunOS image. Login to your FreeBSD virtual machine. Go to /var/tmp directory.
Do the following:

rm /dev/wd0c
ln -s /dev/ad0c /dev/wd0c
mkdir /var/etc
touch /var/etc
touch /var/etc/master.passwd
touch /var/etc/inetd.conf
touch /var/etc/group

Install JunOS
pkg_add /var/tmp/jinstall-7.4R1.7-export-signed.tgz

Reboot your machine to finish Junos installation.

3. Getting Access to Olive Using Virtual Serial Port.
Once you reboot your Olive after installing your Junos software, you won't get access to your Olive. To get access to your Olive, you need to use serial port and Virtual Serial Port Driver. You can get Virtual Serial Port Driver software from Eltima Software.
Accessing Olive using serial port:
a. Create serial port pair using Virtual Serial Port Driver software

b. Add serial port in Olive, using serial port have been made before in Virtual Serial Port Driver.
Click Add. Choose Serial Port. Use Physical Serial Port on the host. Choose serial port have been made using Virtual Serial Port Driver.

Use your favourite software to access to Junos through serial port.

4. Upgrade to Junos 8.x
In order the ethernet card detected by Junos, you need to upgrade to Junos 8.x. Because this time ethernet can not be detected, you can not use FTP to copy Junos image. You need to create other FreeBSD virtual machine, copy Junos image to that. Add your second virtual machine as second IDE in your Olive.
Mount your second drive. For example, if you copy Junos image in first partition of your second virtual machine, do the following

mount /dev/ad1s1a /mnt

Then copy Junos image to /var/tmp/ directory. Goto to /var/tmp/, then install new Junos image

pkg_add jinstall-8.3R2.8-export-signed.tgz

Reboot to complete upgrade.

shutdown -r now

After booting process, ethernet card can be detected, and you can start playing your Junos Olive with networking function.

5. Upgrade to Junos 9.x
Untill last procedure, Olive still can't be accessed from VMWare console.  In order to access Olive from VMWare console, you need to upgrade to Junos 9.x. To upgrade to Junos 9.x, set SCSI to FALSE (in VMWAre configuration file), then set memory to 512M minimum value. After upgrade, you can set memory back to 256 M or even 128M.  Do upgrade procedure as usual.

IPTables, combine with IP Forwarding feature of Linux, can be configured for creating static nat.  This post will give example configuration to have static nat in Linux machine.

1.  Load nat module.
     Execute this command., and add this command in /etc/rc.local file so that this command will be executed every reboot.

     modprobe iptable_nat

2.  Enable IP Forwarding.  This command will enable ip forwarding in Linux machine.

     echo 1 > /proc/sys/net/ipv4/ip_forward

     You can edit /etc/sysctl.conf and uncomment his line,

     #net.ipv4.ip_forward=1

     To be like this

     net.ipv4.ip_forward=1

     So that it will have value 1, mean that ip forwarding si enable.

3.  Creating IPTables rule. 
     There are two nat, nat for source address (your home server), using POSTROUTING, nat for destination address (internet server), using PREROUTING. 
     For example, if you want nat your local server,    192.168.1.1, with  public address 201.1.1.1, you have to configure POSTROUTING.

     Configure static nat for local server to public ip,

     iptables -t nat -A POSTROUTING -s 192.168.1.1 -o eth0 -j SNAT --to-source 201.1.1.1

     Allow forwarding snat connection from local server,

     iptables -A FORWARD -t filter -o eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT


Save your configuration in your iptables script.

Linux Home Networking (http://www.linuxhomenetworking.com/) can be your source for Linux networking related.