ccip_bgp_ch9_controlling_large_scale_ASes.pdf

8/10/2019 ccip_bgp_ch9_controlling_large_scale_ASes.pdf

1/17

Chapter 9: Controlling Large-Scale ASes

I. Route Reflectors - See CH12 Page 411. When - Use Route Reflectors on large scale IBGP full mesh networks

2. Benefits -

1. Less peering clients onl! nee" to peer with the local RR2. RR coul" #e optimi$e" to cop! UP%&'( messages when sen"ing to multiple

peers rather than generating uni)ue messages per peer.*. %raw#acks -

1. +ore processing o,erhea" for the RR

2. If configure" incorrectl! coul" cause loops.

2. Internal Peers !ithout Route Reflectors1. (ample of full IBGP mesh re)uire" for R'& to a",ertise an (BGP originating

up"ate to R'/0 otherwise R'B woul" not forwar" the up"ate to R'/ "ue to the

IBGP rules.

". f


2/17

4. Internal Peers #ith Route Reflectors1. 'he #elow is a simple RR "esign with R'B #eing the RR. Up"ates from R'& an"

processe" #! R'B an" also reflecte" to R'/. R'& an" R'/ shoul" not ha,e apeering session with one another.


3/17

. $a%ing Con&entions an' Rules of (peration1. & RR an" clients make a cluster. /lients an" non-clients ha,e no notion of #eing

clients or non-clients for a route reflector the! are assigne" from the prospecti,eof the Route Reflector onl!. on-clients that peer with a route reflector must

a#i"e #! normal IBGP rules an" therefore nee" to form a full mesh in or"er to

a",ertise all routes to each other.

2. /lients shoul" onl! peer with the route reflector.*. on-clients shoul" onl! peer with the RR of the cluster an" not the clients.

2. Rules of peration

1. If the route is recei,e" from a nonclient peer0 reflect to clients onl!.2. If the route is recei,e" from a client peer0 reflect to all nonclient peers an" also to

client peers.

*. If the route is recei,e" from an (BGP peer0 reflect to all client an" nonclientpeers.

). f


4/17

*. Re'un'anc+ Issues an' ,ultiple Route Reflectors in an AS1. Below shows that if RR1 goes "own or the link to RR1 from R'& goes "own

then R'& #ecomes isolate" if there3s no ph!sical re"un"anc! to compliment thelogical re"un"anc!... Logical re"un"anc! must compliment ph!sical

re"un"anc!.

. f


5/17

9. Route Reflection opolog+ ,o'els1. Below is an eample of how one shoul" "esign an RR topolog! #ase" on the

ph!sical topolog!.1. Route Reflectors shoul" #e the routers interconnecting sites4clusters.

2. Route Reflectors shoul" #e the routers that also ha,e at least one ph!sical

connection to each client if choosing one RR. If using two RR3s per cluster

than a client shoul" ha,e at least one connection to at least one RR.*. Route Reflectors shoul"0 if possi#le0 #e IBGP onl! routers. 'his will allow

the (BGP e"ge routers to concentrate processing an" memor! on the routing

ta#le0 while the IBGP route reflectors can concentrate on processing an"memor! on Route Reflection an" peering.


6/17

2. he Route Reflector Preser&es I/0P Attriutes

1. Route Reflectors shoul"n3t change IBGP attri#utes. &s shown #elow0 R'B is

acting as the Route Reflector for clients R'/ an" R'&. 'he "efault "esire"

#eha,ior is that route 152.21*.11.6427 from R'/ will #e reflecte" to R'& withthe original net hop of 1.1.1.1. 8owe,er what if R'B change" the net hop that

of it3s own IP a""ress of 2.2.2.29 & loop woul" #e create" for a couple reasons.

:irst R'B is not in the ph!sical path that traffic will flow so R'B a",ertises thenet hop of itself0 so when traffic reaches R'B it sen"s it #ack to R'& as R'& is

the one an" onl! router in the path of traffic going to R'/.

2. &lwa!s #uil" !our RR topolog! #ase" on the ph!sical topolog! an" tr! not tochange the "efault #eha,ior of Route Reflection unless necessar!.

".

4. A&oi'ing Loops

1. Loop a,oi"ance #etween &;es uses the &;


7/17

1.Route Reflectors an' Peer 0roups1. Recall from /hapter ?0 @'uning BGP /apa#ilities0A that a peer group is a group

of BGP neigh#ors that share similar routing policies. Pre,iousl!0 route reflectorscoul" #e use" onl! in conunction with peer groups when all route reflector

clients within a cluster were full! meshe". 'he reason can #est #e "escri#e"

through the following eample. In a t!pical route reflection situation0 Router &

learns a prefi from Router B. ;u#se)uentl!0 Router & sen"s an UP%&'(message containing WI'8%R&W RU'(; information #ack to Router B to

poison that route. In other wor"s0 Router & informs Router B that this prefi is

unreacha#le ,ia &. 'his pre,ents a route loop situation in which & claims that aprefi is reacha#le ,ia B0 an" B claims it is reacha#le ,ia &. In a peer group0 the

same UP%&'( message =with su#se)uent WI'8%R&W RU'(;

information> is sent to all mem#ers of the group. In a peer group4route reflectorsituation0 a route reflector that learns a prefi from one of the clients an"

attempts to poison that route en"s up with"rawing that prefi from all the other

clients. Because the clients are not talking to one another ,ia BGP0 that prefi is

lost. 'herefore0 an IBGP mesh #etween the clients of a route reflector is

necessar! so that other clients will learn the prefi "irectl! from the originator.(,en with this "esign0 the network a"ministrator a,oi"s #uil"ing a full IBGP

mesh #etween all IBGP routers in the &; #! concentrating the mesh #etweenroute reflectors an" clients =,ersus #etween clients within a cluster>. :ortunatel!0

I; has remo,e" the full-mesh re)uirement on route reflector clients. /urrentl!0

clients of a route reflector configure" un"er a peer group are not re)uire" to #efull! meshe". With the use of peer groups0 the &; "esign woul" look like rings

of full! meshe" BGP speakers. Route reflectors are full! meshe" among each

other0 an" clients are onl! re)uire" to peer with the route reflectors. :igure 5-Cillustrates such an en,ironment each circle" area represents a "istinct peer group

an" route reflector cluster. In contrast0 :igure 5-D "emonstrates what woul" #e

re)uire" without the use of route reflectors.


8/17

11.f


9/17

12.f


10/17

1".Confe'erations - See CH12 Page 4191. When an &; is ma"e into a confe"eration0 this means that groups of routers are

ma"e into ;u#-&;es0 an" are interconnecte" with the &; ,ia (BGP. (,enthough the! are interconnecte" ,ia (BGP0 routing within the confe"eration still

#eha,es the same as IBGP0 meaning net-hop0 +(% an" local preference

information is preser,e" when crossing the su#-&; #oun"aries.

2. Within each su#-&;0 the routers must #e an IBGP full mesh0 =otherwise allrouters won3t get all routes "ue to IBGP rules>.

*. 'he outsi"e worl" ,iews the confe"eration as a single &;.

7. Loop a,oi"ance is eas! with confe"erations0 as the &;


11/17

1.Confe'eration 3ra#acs1. Within a confe"eration0 the &;


12/17

1.Reco%%en'e' Confe'eration 3esign1. Best "esign is to use a /entral ;u#-&; #ack#one this will make it so each su#-

&; onl! interacts with one other su#-&; =central>.

19.

2.Confe'erations 7ersus Route Reflectors1. /isco recommen"s the use of RRs to sol,e the full IBGP mesh issue... 8owe,er

1. RR3s are flei#le an" scala#le0 an" can #e implemente" into an eisting

"esign easil!.2. /onfe"erations can #e use" to run an IGP in one su#-&; in"epen"entl! of

IGPs in other su#-&;es to control the insta#ilit! of large IGPs.

*. RR3s coul" #e run within a confe"eration insi"e each su#-&;.


13/17

II.Controlling I0P 56pansion1. Seg%enting the AS #ith ,ultiple Regions Separate' + I/0P

1. Below !ou will see each region separate" #! IBGP. (ach regional IBGP routerinects a "efault into the IGP =region>. nl! pro#lem here is internet

connecti,it!.


14/17

2. Below is an eample of a #a" "esign for internet connecti,it!. Reason it3s #a" is

#ecause internet connecti,it! is #ase" on a "efault route sent #! the I;P which is

sent to an internal =non-#gp> router within region 2. 'his same router also

recei,es a "efault inecte" #! the IBGP router for region 2... 'wo "efaults willnot workF ou /UL% use this "esign0 #ut !ou woul" ha,e to stop inecting a

"efault from the IBGP router into region 20 an" inect IBGP routes into the IGP

for region 2 possi#le some aggregate routes from the other regions to minimi$ethe inection from IBGP to IGP.


15/17


16/17

". Seg%enting the AS #ith ,ultiple Regions Separate' + 5/0P1. Below is the #est wa! to segregate an IGP into multiple regions. Because we are

using separate &;es for each region0 we can use (BGP #etween regions an"easil! configure policies. Pro#lem is that it is net to impossi#le to o#tain more

than a single &; num#er as &; num#ers are #eing "eplete" an" an RIR will most

likel! ne,er allow !ou more than one.

4. f


17/17

1. 8sing Pri&ate AS $u%ers

1. 'he #elow is a wa! to use pri,ate &; num#ers to allow (BGP #etween regions0

an" to ha,e multi-pro,i"er internet connecti,it! while ena#ling the a"ministrator

to strip the pri,ate-&;es from the &;

ccip_bgp_ch9_controlling_large_scale_ASes.pdf

Documents

Transcript of ccip_bgp_ch9_controlling_large_scale_ASes.pdf