Cisco router can be used as VPN server, using L2TP and IPSec, for client from internet accesing private network.

Below are steps for configuring L2TP IPSec on Cisco router,
1. Enable aaa authentication and create user,

aaa new-model

aaa authentication login default local
aaa authentication ppp default local
aaa authorization exec default local

user cisco password cisco

2. Enable VPDN and configure VPDN group

vpdn enable
!
vpdn-group L2TP
! Default L2TP VPDN group
 accept-dialin
  protocol l2tp
  virtual-template 1
 no l2tp tunnel authentication

3. Configure authentication methode.  Using pre-shared key is the best and simple methode.

crypto isakmp policy 10
 encr 3des
 authentication pre-share
 group 2
 lifetime 3600
crypto isakmp key cisco address 0.0.0.0 0.0.0.0 no-xauth
crypto isakmp keepalive 3600

4. Configure IPSec

crypto ipsec transform-set ipnetconfig esp-3des esp-sha-hmac
 mode transport
!
crypto dynamic-map ipnetconfig-map 10
 set nat demux
 set transform-set ipnetconfig
!
!
crypto map cisco 10 ipsec-isakmp dynamic ipnetconfig-map

interface FastEthernet0/0
 ip address 192.168.1.254 255.255.255.0
 duplex auto
 speed auto
 crypto map cisco

5. Create Vitrual_Template

interface Virtual-Template1
 ip unnumbered FastEthernet0/0
 peer default ip address pool poolipnetconfig
 ppp encrypt mppe 40
 ppp authentication ms-chap-v2

6. Create IP Pool for user

ip local pool poolipnetconfig 172.31.1.1 172.31.1.6

7. Test your configuration

Complete configuration on Cisco router:

L2TP-Server#sh run
Building configuration...

Current configuration : 5669 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname L2TP-Server
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$WMq0$BZpIxsWnzmEI0fCvWADGd0
!
aaa new-model
!
!
aaa authentication login default local
aaa authentication ppp default local
aaa authorization exec default local
!
aaa session-id common
!
resource policy
!
ip cef
!
!
!
!
ip domain name ipnetconfigs.com
ip name-server 192.168.0.1
ip ssh version 2
vpdn enable
!
vpdn-group L2TP
! Default L2TP VPDN group
 accept-dialin
  protocol l2tp
  virtual-template 1
 no l2tp tunnel authentication
!
!
!
!
crypto pki trustpoint TP-self-signed-417945430
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-417945430
 revocation-check none
 rsakeypair TP-self-signed-417945430
!
!
crypto pki certificate chain TP-self-signed-417945430
 certificate self-signed 01
  30820257 308201C0 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
  30312E30 2C060355 04031325 494F532D 53656C66 2D536967 6E65642D 43657274
  69666963 6174652D 34313739 34353433 30301E17 0D313030 33313331 30303434
  375A170D 32303031 30313030 30303030 5A303031 2E302C06 03550403 1325494F
  532D5365 6C662D53 69676E65 642D4365 72746966 69636174 652D3431 37393435
  34333030 819F300D 06092A86 4886F70D 01010105 0003818D 00308189 02818100
  CBB11B58 6E347C78 1FB62626 0FD03CCB 5AA26CC3 A0E17634 B905978F DF0FCA60
  2A8CD0EE 1BF4428A 53F23038 7BF8C209 B0FEF57B 08233D2C F49826BB 938113DE
  C6D25DD0 E8AA51B0 F4BAE931 0C4C19A6 7657EB6F 4A0CF980 92C54B48 F927BF00
  1E3F25E1 A28EA8F6 B941BC0A E6F2FA20 6A73F969 A8B523F0 0B25C927 85C649BD
  02030100 01A38180 307E300F 0603551D 130101FF 04053003 0101FF30 2B060355
  1D110424 30228220 50504A2D 47572E6C 61646F6D 61696E2E 6C696E74 61736172
  74612E63 6F2E6964 301F0603 551D2304 18301680 14167006 97518BA4 E4F9BA7A
  82A17511 CE1A4870 8B301D06 03551D0E 04160414 16700697 518BA4E4 F9BA7A82
  A17511CE 1A48708B 300D0609 2A864886 F70D0101 04050003 8181006B D63609D0
  F61D11FF FB4CC38C 231FA679 B6A3AD68 DF7BEDC3 CCE85778 5D7E4FE7 ADFA6A8B
  4BBDED0F 20137B37 C445F0D9 14E55313 2553284B DCB49472 3E56BF3D 140F3E58
  047833BD 4F6D0719 29233D33 8F681B69 613FF4A5 B527E059 06B655E3 06BBFA37
  B3F43E6B 67DF84DF 5D3B0FC9 ECFB16E3 9AB4E1F1 D61D0523 A95A44
  quit
username root privilege 15 secret 5 $1$E1t3$.GKaPz1xFuph9r/fRqxTO.
!
!
!
crypto isakmp policy 10
 encr 3des
 authentication pre-share
 group 2
 lifetime 3600
crypto isakmp key cisco address 0.0.0.0 0.0.0.0 no-xauth
crypto isakmp keepalive 3600
!
!
crypto ipsec transform-set ipnetconfig esp-3des esp-sha-hmac
 mode transport
!
crypto dynamic-map ipnetconfig-map 10
 set nat demux
 set transform-set ipnetconfig
!
!
crypto map cisco 10 ipsec-isakmp dynamic ipnetconfig-map
!
!
!
!
!
interface FastEthernet0/0
 ip address 192.168.1.254 255.255.255.0
 duplex auto
 speed auto
 crypto map cisco
!
interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
!
!
interface Virtual-Template1
 ip unnumbered FastEthernet0/0
 peer default ip address pool poolipnetconfig
 ppp encrypt mppe 40
 ppp authentication ms-chap-v2
!
!
ip local pool poolipnetconfig 172.31.1.1 172.31.1.6
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
!
ip http server
ip http secure-server
!
!
!
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
!
scheduler allocate 20000 1000
end

L2TP-Server#

 For configuring L2TP IPSec on Windows 7, see my other post on this blog.

This post will describe how to create VPN Client using L2TP and IPSec on Windows 7.


1. Go to Control Panel --> Network and Sharing Center.  Choose Set up new connection or network.  Click Next.

2. Choose Connect to a workplace

3. Choose create new connection. Click Next.

4. Choose Use My Internet Connection (VPN).

5. Fill IP Address of your VPN Server and the name of connection.  Click Next.

6. Fill user name and password of your connection.  Click Connect.

After this point, you still cannot connect to your VPN Server.  You need to configure pre-shared key for IPSec.

7. Open Control Panel --> Network and Sharing Center.  Choose Change Adapter Setting

8. Right click your VPN connection, choose Properties.

9. On your VPN Properties, click Security Tab, on Type of VPN, choose Layer 2 Tunneling Protocol With IPSec (L2TP/IPSec).  On Data Encryption, choose Require encryption.  Click Advanced settings.

10. On Advanced Properties, L2TP section, choose Used preshared key for authentication.  Click OK.

11. Click OK again.  You can now test your connection using L2TP and IPSec VPN.

This post will describe how to create VPN Client using PPTP on Windows 7.

1. Go to Control Panel --> Network and Sharing Center.  Choose Set up new connection or network.  Click Next.

2. Choose Connect to a workplace

3. Choose create new connection. Click Next.

4. Choose Use My Internet Connection (VPN).

5. Fill IP Address of your VPN Server and the name of connection.  Click Next.

6. Fill user name and password of your connection.  Click Connect.

If you cannot connect to VPN PPTP Server, then maybe you need to adjust encryption.

7. Open Control Panel --> Network and Sharing Center.  Choose Change Adapter Setting

8. Right click your VPN connection, choose Properties.

9. On your VPN Properties, click Security Tab, on Data Encryption, choose No encryption allowed.  Click OK.

Cisco router can be used as VPN server, using PPTP, for client from internet accesing private network.

Below are steps for configuring PPTP on Cisco router,
1. Enable aaa authentication and create user,

aaa new-model

aaa authentication login default local
aaa authentication ppp default local
aaa authorization exec default local

user cisco password cisco

2. Enable VPDN and configure VPDN group

vpdn enable
!
!
vpdn-group PPTP
! Default PPTP VPDN group
 accept-dialin
  protocol pptp
  virtual-template 2

3. Create Vitrual_Template

interface Virtual-Template2
 ip unnumbered FastEthernet0/0
 peer default ip address pool poolipnetconfig
 ppp encrypt mppe auto required
 ppp authentication ms-chap ms-chap-v2

4. Create IP Pool for user

ip local pool poolipnetconfig 172.31.1.1 172.31.1.6

5. Test your configuration

Complete configuration on Cisco router:

PPTP-Server#sh run
Building configuration...

Current configuration : 5669 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname PPTP-Server
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$WMq0$BZpIxsWnzmEI0fCvWADGd0
!
aaa new-model
!
!
aaa authentication login default local
aaa authentication ppp default local
aaa authorization exec default local
!
aaa session-id common
!
resource policy
!
ip cef
!
!
!
!
ip domain name ipnetconfig.com
ip name-server 192.168.0.1
ip ssh version 2
vpdn enable
!
!
vpdn-group PPTP
! Default PPTP VPDN group
 accept-dialin
  protocol pptp
  virtual-template 2
!
!
!
username root privilege 15 secret 5 $1$E1t3$.GKaPz1xFuph9r/fRqxTO.
!
!
!
!
interface FastEthernet0/0
 ip address 192.168.1.254 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
!
!
!
interface Virtual-Template2
 ip unnumbered FastEthernet0/0
 peer default ip address pool poolipnetconfig
 ppp encrypt mppe auto required
 ppp authentication ms-chap ms-chap-v2
!
ip local pool poolipnetconfig 172.31.1.1 172.31.1.6
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
!
ip http server
ip http secure-server
!
!
!
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
!
scheduler allocate 20000 1000
end

PPTP-Server#

To configure PPTP client on Windows 7, see my post How To Configure PPTP Client On Windows 7.

As using route reflector is a way simplifying and scaling iBGP configuration, it is recommended to use if you have many routers in your AS.

To configure route reflector in Cisco router is really simple.
1. Add command

neighbor <ip address client> route-reflector client

2. Ordinary BGP configuration in client router

BGP configuration template on route reflector will be:

router bgp xxxx
neighbor y.y.y.y remote-as zzzz
neighbor y.y.y.y route-reflector client

On the client side, BGP configuration will be as usual.

Example

Router 1 is route reflector, and will peer with router 2, route reflector client, and router 3, non client router.  The BGP configuration will be like this.

Router 1 Configuration:

router bgp 65535
neighbor 10.1.2.4 remote-as 65535
neighbor 10.1.2.4 update-source loopback0
neighbor 10.1.2.4 route-reflector client

neighbor 10.1.2.5 remote-as 65000
neighbor 10.1.2.5 update-source loopback0

Router 2 Configuration

router bgp 65535
neighbor 10.1.2.3 remote-as 65535
neighbor 10.1.2.3 update-source loopback0

Router 3 Configuration

router bgp 65000
neighbor 10.1.2.3 remote-as 65535
neighbor 10.1.2.3 update-source loopback0

IBGP require all BGP systems within the AS are a fully meshed, so that any external routing information is redistributed among all routers within the AS.  This implementation can present scalling issue when an AS have a large number of internal BGP system because of the amount of identical information that BGP systems must share with each other.  Imagine if an AS, for example, have 50 routers, administrator needs to create n(n - 1) / 2 = 50(50-1)/2=1225 BGP sessions.  Imagine the complexity to create and maintain 1225 connections.

Route reflector is used to simplify this.  Using a route reflector, routers are grouped into clusters, with a router in a cluster act as route reflector, and others as route reflector client. In a cluster, sessions occur between all clients and route reflector server.  Full mesh IBGP sessions occur between all route reflector in the network.  With this configuration, the IBGP full-mesh requirement is met.  This will simplify configuration than create full mesh session between all routers.

When the route reflector receives a route, it selects the best path. Then, if the route came from a nonclient peer, the route reflector sends the route to all client peers within the cluster. If the route came from a client peer, the route reflector sends it to all nonclient peers and to all client peers except the originator. In this process, none of the client peers send routes to other client peers. 

To configure route reflector, you specify a cluster identifier only on the BGP systems that are to be the route reflectors. These systems then determine, from the network reachability information they receive, which BGP systems are part of its cluster and are client peers, and which BGP systems are outside the cluster and are nonclient peers. 

To configure a router to be a route reflector, you must do the following:

• Configure multiple IBGP groups.
• Configure a cluster identifier (using the cluster statement) for groups that are members of the cluster.
• Configure all the groups with the same IBGP AS number.

To configure the route reflector, include the following statements in the configuration:

group group-name {

    type internal;

    peer-as autonomous-system;

    neighbor address1;

    neighbor address2;

}

group group-name {

    type internal;

    peer-as autonomous-system;

    cluster cluster-identifier;

    neighbor address3;

    neighbor address4;

}

By default, the BGP route reflector performs intracluster reflector because it assumes that all the client peers are not fully meshed. However, if the client peers are fully meshed, intracluster reflector results in the sending of redundant route advertisements. In this case, you can disable intracluster reflector by including the no-client-reflect statement within the group statement:

group group-name {

    type internal;

    peer-as autonomous-system;

    cluster cluster-identifier;

    no-client-reflect;

    neighbor address3;

    neighbor address4;

}

Examples: Configuring BGP Route Reflector
This example shows how to configure a simple route reflector. The configuration shown in Figure contains three routes: Router 1, which is the route reflector; Router 2, which is a client; and Router 3, which is a nonclient. 
The routers have the following loopback addresses:

• Router 1—10.1.2.3
• Router 2—10.1.2.4
• Router 3—10.1.2.5

You must configure all routers to run a common IGP or to have static configuration, so that they learn each other’s loopback addresses. 

Configure Router 1 to be a route reflector for Router 2 and a regular IBGP neighbor for Router 3:

[edit]
routing-options {
    autonomous-system 65534;
}
protocols {
    bgp {
        group 13 {
            type internal;
            local-address 10.1.2.3;
            neighbor 10.1.2.5;
        }
        group 12 {
            type internal;
            local-address 10.1.2.3;
            cluster 1.2.3.4;
            neighbor 10.1.2.4;
        }
    }
}

Configure Router 2 to be an IBGP neighbor to Router 1 and announce 16.0.0.0/8 to Router 1. Configure route 16.0.0.0/8 as a static route on Router 2.

[edit]
routing-options {
    static {
        route 16.0.0.0/8 nexthop 172.16.1.2;
    }
    autonomous-system 65534;
}
protocols {
    bgp {
        group 21 {
            type internal;
            local-address 10.1.2.4;
            export dist-static;
            neighbor 10.1.2.3;
        }
    }
}
policy-options {
    policy-statement dist-static {
        from protocol static;
        then accept;
    }
}

Configure Router 3 to be an IBGP neighbor to Router 1 and announce 15.0.0.0/8 to Router 1. Configure route 15.0.0.0/8 as a static route on Router 3.

[edit]
routing-options {
    static {
        route 15.0.0.0/8 nexthop 172.16.1.2;
    }
    autonomous-system 65534;
}
protocols {
    bgp {
        group 31 {
            type internal;
            local-address 10.1.2.5;
            export dist-static;
            neighbor 10.1.2.3;
        }
    }
}
policy-options {
    policy-statement dist-static {
        from protocol static;
        then accept;
    }
} 

Source: http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/config-guide-routing/routing-configuring-bgp-route-reflection.html

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