13.2 -- No. I came across the same error in Cisco documentation when I was studying. You only need "bgp confederation peers" on routers that are peering with other sub-as' and you need not include your own. The example in the documentation is ridiculous.
13.3 -- If you go through the task you will find a problem with the BGP next-hop. One way to solve this problem would be by using "neighbor next-hop-self". In this case, that is prohibited 13.4 -- I'm not sure what problem you are looking to solve? The task is simply to advertise in some network into BGP. On Sun, Apr 11, 2010 at 9:14 PM, RAragon <[email protected]> wrote: > I created my answers based on research and experience of going through the > lab. Some of them I need help with. > > 13.2 (please comment: IPX) > 13.3 (I need Help) > 13.4 (I need help) > > ============== > *13.2* Do we need to include all confederation AS numbers in the command: > "bgp confederation peers" ? >>>*13.2 Answer*: Documentation seems to say put all confederation peers into >>> the statement including your own Confederation ID: putting your own Confed >>> IFD in the command elicits an error message from IOS. > > *13.3* What does this mean "no 'neighbor' commands may be used to assist any > of these networks."? >>>*13.3 Answer*: > > > *13.4* What would be the best debug command on r1 to see what the problem > is? >>>*13.4 Answer*: > > > *13.9* Wouldn't a prefix-list be a better way to specify to he 6 subnets > (200.11.0.0/21 ge 24 le 24)? Otherwise we could match other routes outside > of the 200.1.1-6.0/24 range. >>>*13.9 Answer*: As of 13.9 the prefix list would have worked fine but as >>> you read further along you will see that there are other issues related to >>> the loopback on SW2 and ultimately the Access-list (standard) will work with >>> the new aggregate prefix whereas the prefix-filter will be too constrained. > > *13.10* What happened tot he caveat outlined in 13.10? Specifically, "The AS > Path must remain intact." I interpreted this as meaning, that task 13.9 > manipulations of AS Path (11111, 11222, 11333, 11444) would need to remain > on the aggregate address. >>>*13.10 Answer*: this was handled during task 13.13 of SG. It was not >>> applied on SW1 until then. Also, see previous question(above. > > > errata: 13.12 (page 330) solution guide. it states "… the same would be seen > on SW2 and SW3…" This is not correct. At that stage SW3 would be similar > to SW4, but since SW2 is the originator it will have a different IP BGP > Table (i.e. summary from Cat1 has no effect on CAT2). > > > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > -- Regards, Joe Astorino - CCIE #24347 Sr. Technical Instructor - IPexpert Mailto: [email protected] Telephone: +1.810.326.1444 Live Assistance, Please visit: www.ipexpert.com/chat eFax: +1.810.454.0130 IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, Audio Tools, Online Hardware Rental and Classroom Training for the Cisco CCIE (R&S, Voice, Security & Service Provider) certification(s) with training locations throughout the United States, Europe, South Asia and Australia. Be sure to visit our online communities at www.ipexpert.com/communities and our public website at www.ipexpert.com _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
