The purpose of this free GNS3 CCNP lab is to help understand BGP implementation and configuration in Cisco IOS routers. In this lab we will explore some additional technologies including peer groups, route reflection community attributes, and path control.
Learning Objectives:
BGP Peer Groups:
You can group BGP neighbors who share the same outbound policies together in what is called a BGP peer group. Instead of configuring each neighbor with the same policy individually, a peer group allows you to group the policies which can be applied to individual peers thus making efficient update calculation along with simplified configuration.
The major benefit you achieve when you specify a BGP peer group is that a BGP peer group reduces the amount of system resources (CPU and memory) necessary in an update generation. In addition, a BGP peer group also simplifies the BGP configuration. A BGP peer group reduces the load on system resources by allowing the routing table to be checked only once, and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group. Based on the number of peer group members, the number of prefixes in the table, and the number of prefixes advertised, this can significantly reduce the load. It is recommended that you group together peers with identical outbound announcement policies.
Requirements of Peer Groups:
- Peer groups have these requirements:
- All members of a peer group must share identical outbound announcement policies (such as distribute-list, filter-list, and route-map), except for default-originate, which is handled on a per-peer basis even for peer group members.
- You can customize the inbound update policy for any member of a peer group.
- A peer group must be either internal (with internal BGP (iBGP) members) or external (with external BGP (eBGP) members). Members of an external peer group have different autonomous system (AS) numbers.
How to Use Peer Groups:
Typically BGP peers on a router can be grouped into peer groups based on their outbound update policies. A list of peer-groups used commonly by ISPs are listed here:
- Normal iBGP peer group for normal iBGP peers
- iBGP client peer group for reflection peers on a route reflector
- eBGP full-routes for peers to receive full Internet routes
- eBGP customer-routes for peers to receive only routes from direct customers of the ISP. (You can configure some members with default-originate to receive the default route in addition to the customer routes.
- eBGP default-routes for peers to receive the default route, and possibly a few other routes.
Route reflector:
A route reflector (RR) is a network routing component. It offers an alternative to the logical full-mesh requirement of internal border gateway protocol (IBGP). A RR acts as a focal point for IBGP sessions. The purpose of the RR is concentration. Multiple BGP routers can peer with a central point, the RR – acting as a route reflector server – rather than peer with every other router in a full mesh. All the other IBGP routers become route reflector clients.
This approach, similar to OSPF’s DR/BDR feature, provides large networks with added IBGP scalability. In a fully meshed IBGP network of 10 routers, 100 individual statements (spread throughout all routers in the topology) are needed just to define the remote-AS of each peer: this quickly becomes a headache to administer. A RR topology could cut these 100 statements down to 20, offering a viable solution for the larger networks administered by ISPs.
A route reflector is a single point of failure, therefore (at least) a second route reflector should be configured in order to provide redundancy.
Rules:
- RR servers propagate routes inside the AS based on the following rules:
- If a route is received from nonclient peer, reflect to clients only.
- If a route is received from a client peer, reflect to all nonclient peers and also to client peers, except the originator of the route.
- If a route is received from an EBGP peer, reflect to all client and nonclient peers.
BGP communities:
BGP communities attribute is widely used for implementing policy routing. Network operators can manipulate BGP communities attribute based on their network policy. BGP communities attribute is defined in RFC1997, BGP Communities Attribute and RFC1998, An Application of the BGP Community Attribute in Multi-home Routing. It is an optional transitive attribute; therefore local policy can travel through different autonomous system.
Communities attribute is a set of communities values. Each communities value is 4 octet long. The following format is used to define communities value.
- AS:VALThis format represents 4 octet communities value. AS is high order 2 octet in digit format. VAL is low order 2 octet in digit format. This format is useful to define AS oriented policy value. For example, 7675:80 can be used when AS 7675 wants to pass local policy value 80 to neighboring peer.
- internetinternet represents well-known communities value 0.
- no-exportno-export represents well-known communities value NO_EXPORT
- (0xFFFFFF01). All routes carry this value must not be advertised to outside a BGP confederation boundary. If neighboring BGP peer is part of BGP confederation, the peer is considered as inside a BGP confederation boundary, so the route will be announced to the peer.
- no-advertiseno-advertise represents well-known communities value NO_ADVERTISE
- (0xFFFFFF02). All routes carry this value must not be advertise to other BGP peers.
- local-ASlocal-AS represents well-known communities value NO_EXPORT_SUBCONFED (0xFFFFFF03). All routes carry this value must not be advertised to external BGP peers. Even if the neighboring router is part of confederation, it is considered as external BGP peer, so the route will not be announced to the peer.
Download this lab now to see more:
CCNP BGP Lab-2 (219.0 KiB, 1,816 hits)
Posted in 
Tags: 
