There are multiple ways that a task can be interpreted, in addition, multiple ways that a solution can be determined.
"as-is" vs. "future-proof" Sample task - block all routes with an odd third octet, with routes received with 1,2,3,and 4 for third octet. "AS-IS" example solution configure based on current settings, "what is received" In this case blocking 1 and 3 is sufficient. "Future-proof" example solution configure irrespective of current state In this case, blocking any route with an odd third octet, regardless of what is currently being received. Referring specifically to task 4.3: In this particular case, the PG configures for an "as-is" solution, with the assumption that the aggregate counts as a route that came from AS 111, since all the more specific routes came from 111. Since there are no networks configured that originate in 112, setting lp to R6 for the summary is sufficient for the task. For additional clarification, this will be migrated to a "future proof" solution, with additional task rewording. In that case, the other route-maps that you mentioned would be more appropriate, with the possible exception of changing the _111$ to _111_, depending on the interpretation of "originating from" Additional items in this particular task, which can cause confusion: difference in interpretation between "originating from", "originating in", and "coming from" "originating from" and "coming from" are meant to be interpreted as "learned via", but some interpret "originating from" to be the same as "originating in". "Originating in" would mean that the AS is where the route was first brought into BGP. The aggregate There is some difference of opinion as to whether the aggregate should be considered as coming "from" the same location as the more specifics, or if it should be considered a separate route. 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 Louis S Sent: Monday, July 07, 2008 4:29 PM To: osl Subject: [OSL | CCIE_RS] Volume 2 Section 3 task 4.3 BGProute manipulation base on AS I'm venting a bit here but, I had major beef with the PG solution on this task. They didn't even address the requirement, unless I am missing something here. Task- "BGP AS 178 has two equal paths to AS 111 via R5 and R6. Configure R7 so R6 is the PRIMARY route for ALL ROUTES ORIGINATING FROM AS 111 and a BACKUP FOR ALL OTHER ROUTES. R5 should be the BACKUP FOR for ALL ROUTES ORIGINATING FROM AS 111 and the PRIMARY route for ALL OTHERS." The PG Solution was- ON R7 CONFIGURE: router bgp 178 no synchronization bgp log-neighbor-changes neighbor 110.99.6.6 route-map lp in route-map lp permit 10 set local-preference 200 ....So how does that address the requirement? Shouldn't the configuration address the ASpath requirement? The PG solution is simply modifing local pref on ALL routes, which is not what was asked for PLUS those routes that would be coming in .... the Aggregate we configured on R5 and R6 originate in AS112! which should take the path to R5 ! Even the output in the PG solution guide is incorrect, it shows 172.16.0.0/21 going to R6. Shouldn't the configuration be: ON R7 CONFIGURE: router bgp 178 neighbor 110.99.5.5 route-map BACKUP_R5_AS111 in neighbor 110.99.6.6 route-map PREFER_R6_AS111 in ip as-path access-list 1 permit ^_111$ route-map BACKUP_R5_AS111 permit 10 match as-path 1 set local-preference 100 route-map BACKUP_R5_AS111 permit 20 set local-preference 200 ! route-map PREFER_R6_AS111 permit 10 match as-path 1 set local-preference 200 route-map PREFER_R6_AS111 permit 20 set local-preference 100
