Language will always be an issue with the CCIE lab. You should get in the habit of thinking through different ways that sections could be configured, and be ready to ask the proctor for clarification.
Let me clarify the section a different way. I misread the section in my quick reply earlier, this is referring to the external peering to R6, not the internal peering. With a single peering statement between R5 and R6, there are a few possibilities. 1. Peer between the Ethernet networks. 2. Peer between the frame networks. 3. Peer between loopbacks. Peering between loopbacks will be the most stable, because the loss of a physical interface would not stop the peering from forming. Rather that stating "the peering should be as stable as possible", the section could have been written as: "ensure that the peering is still up even if a physical interface fails on R5 or R6" "do not peer between physical interfaces" "peer between loopback interfaces" As a CCIE candidate, it is CRITICAL to understand different methods that the same task can be worded. Throughout the workbook, tasks are written in different methods on purpose to highlight this. Given the three choices above, the statement asking for stability eliminates the first two, leaving the third as the valid option. In this case, the extra wording asking for stability is there as a hint as to which method is correct for the section, and which ones are not. Marvin Greenlee, CCIE #12237 (R&S, SP, Sec) Senior Technical Instructor - IPexpert, Inc. Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Mailto: [EMAIL PROTECTED] Progress or excuses, which one are you making? -----Original Message----- From: Suresh Mishra [mailto:[EMAIL PROTECTED] Sent: Saturday, June 28, 2008 7:29 PM To: [EMAIL PROTECTED] Cc: OSL CCIE Routing and Switching Lab Exam Subject: Re: [OSL | CCIE_RS] Vol2 -LAB8 - BGP task 4.1 I got your point. In that sense all the peering statements are single only. But the point is why to state "single peering statement" as a requirement to achive the stability. Its more of a lanuage issue then putting the technical point in perspective. I think the laguage has to be tuned correctly to avoid the confusion. Thanks Suresh On Sat, Jun 28, 2008 at 5:38 PM, <[EMAIL PROTECTED]> wrote: > "Neighbor x.x.x.x remote-as yyy" is a peering statement. If you are unclear > as what the proctor considers a "peering statement", that would be time to > get clarification. > > I would not consider setting route-maps, distribute-lists, update source, or > ebgp multihop as "peering statements" > > With multiple paths in the network, loopback peering will provide more > stability. > > The point of the section is to get you to not use a full mesh for the ibgp > peerings. > > > Marvin Greenlee, CCIE #12237 (R&S, SP, Sec) > Senior Technical Instructor - IPexpert, Inc. > Telephone: +1.810.326.1444 > Fax: +1.810.454.0130 > Mailto: [EMAIL PROTECTED] > > Progress or excuses, which one are you making? > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Suresh Mishra > Sent: Saturday, June 28, 2008 4:56 PM > To: OSL CCIE Routing and Switching Lab Exam > Subject: [OSL | CCIE_RS] Vol2 -LAB8 - BGP task 4.1 > > Hello all, > > There is question in this section that says "Configure R5 to peer to > R6. Use single peering statement. This peering should be as stable as > possible". > > The answer to this question in the proctor guide has peering > configured between the loopback addresses of the two ebgp peers which > requires three statements. > > I think that should be changed to include one statement by using the > physical link addresses between the two peers or change the question > to not have the requirement of stable connection. > > If there is a need for stable connection then we need to remove the > restriction of single statement as it is possible to peer in a single > statement in BGP using direct link addresses. > > Thanks > Suresh > >
