28.06.2014 Views

Discussion

Discussion

Discussion

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

To hide the keys when you are looking at the configuration contents, pipe the output:<br />

aviva@RouterF> show configuration protocols bgp | except SECRET-DATA<br />

group session-to-AS65505 {<br />

type external;<br />

description "EBGP to Customer A";<br />

peer-as 65505;<br />

neighbor 10.0.31.1 {<br />

...<br />

Notice that the entire authentication-key statement is not displayed because all the<br />

authentication information is on one line in the configuration.<br />

See Also<br />

RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option<br />

13.11 Setting Up Route Reflectors<br />

Problem<br />

Your local AS has a large number of IBGP routers, and you want to reduce the number<br />

of IBGP sessions that you need to configure and maintain.<br />

Solution<br />

Configure one of the IBGP routers to be the route reflector for a route reflection<br />

cluster:<br />

[edit protocols bgp]<br />

aviva@RouterG# set group internal-within-AS65500 cluster 192.168.19.1<br />

<strong>Discussion</strong><br />

The configuration in Recipe 13.2, in which all BGP systems within the AS are fully<br />

meshed, is a standard IBGP implementation. The full mesh results from listing all<br />

IBGP peers in a peering group rather than from having them all be physically connected<br />

and from using an IGP within the AS to distribute BGP routes. The full mesh<br />

is necessary so that external routing information can be redistributed among all routers<br />

within the AS with the help of the IGP running in the AS. As you can imagine, as<br />

the number of IBGP routers increases, you have to configure many BGP neighbor<br />

commands in each router’s configuration, and there is a lot of overhead because a<br />

large number of TCP connections need to be maintained for each IBGP peering.<br />

There are two common ways to deal with this scaling issue. One is route reflection,<br />

which provides one means of decreasing BGP control traffic and minimizing the<br />

number of update messages sent within the AS. The second method is confederations.<br />

With normal BGP route redistribution rules, IBGP peers are not allowed to advertise<br />

routes learned from IBGP rules. Route reflection works by bending this rule. Each<br />

452 | Chapter 13: BGP<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!