CCIE lab - how to handle backbone routes

Unanswered Question
Dec 15th, 2007

This question is prompted by a practice lab I was just doing. In it, I had a backbone router that was generating a load of /24 routes that were to be propagated throughout the BGP.

Part of the exercise was to filter certain specific routes from being propagated in certain parts of the network. But one of the side-effects of the filter in the answer book was that it would block anything that wasn't /24. So in a sense, the filter blocked more than was required, although in this case it did not make any difference because all the routes were /24. But in a certain sense, the solution was not "future proof". If the backbone decided to inject a /16 sometime in the future, it would not be propagated.

Question: when approaching such an exercise in the CCIE, should we assume that the routes we are getting from the backbone are the only ones we will ever receive, or should our solutions allow for other routes that might be injected in the future?

Kevin Dorrell


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
jcrussell Sat, 12/15/2007 - 06:04

When I did the lab, I got as specific as possible. If a question said to block all /24 routes, then I would ONLY block /24 routes, nothing else. Also, I have seen plenty of answers in workbooks that were just not right. So maybe you could bring it up with the workbook vendor.

Edison Ortiz Sat, 12/15/2007 - 08:48


This is a typical "Ask the Proctor" question or read the entire workbook for any future requirements.

The backbone routes aren't essential for the CCIE Lab completion. End-to-End reachability is only required within the interfaces you have to configure, and even within those interfaces, there are times when you don't have to ping every single interface, for instance frame-relay interfaces.

The CCIE Lab is not a design lab. Don't think about how to optimize the network but just to complete the task based on what they asked.

With that said, you can create a prefix-list to block only routes with subnet equal /24 and allow routes with subnet equal to /16.

Hope this answers your question.

Kevin Dorrell Sun, 12/16/2007 - 06:10

Thank you both of you for giving your approach to this question. I appreciate that this is an "Ask the Proctor" situation, and that is what I would probably do if faced with that situation in a real exam.

In this particular case, the answer book had a solution that blocked rather more than was required, although with the limited set of routes coming form the backbone, the two answers were equivalent.

I guess for the moment I gotta concentrate on getting the technologies right. I hope that in the process I shall get a better feel for how to interpret the requirements.

Thanks again.

Kevin Dorrell


Kevin Dorrell Sun, 12/16/2007 - 21:37

Thank you Scott. I shall have to move to a different mindset for the duration of the exam! My main worry is the stuff that is implicit in the requirements rather than being stated in black-and-white. And cryptic answers from the proctor.

BTW, I got the IPExpert pack in the post on Friday, and have been looking through the labs, which are pretty impressive. I'm looking forward to trying them out, but I shall have to re-cable my lab first and work out how to adapt the exercises to my 2600XMs. I think I am going to benefit from using labs from more than one vendor because I have gotten too used to the presentation style of the one I have been using so far.

Kevin Dorrell


swmorris Mon, 12/17/2007 - 03:52

The implied tasks versus the "I think these are implied tasks" is truly the hard part.

Everything will be spelled out in the labs though. Pay close attention to the very beginning. It will give you the requirements such that all interfaces must reach all other interfaces, or all routers must reach loopbacks of all other routers, or things like that.

That's what sets up your "implied tasks". And you will use ping/trace/whatever along the way to make sure you didn't miss anything.



ccbootcamp Tue, 12/18/2007 - 12:17


The long and short of it is you need to answer the questions that are being asked of you in the lab. You do not need to make it "future proof" just make sure you can handle whatever backbone routes are being injected into your network while you are working on the lab. Ultimately, you can, of course, always ask the proctor for help on their interpretation of the question. Some proctors are more helpful than others.


(please rate the post if this helps!)


This Discussion