Yes, that alternate solution is described on page 537.
On Mon, May 10, 2010 at 03:47:19PM -0400, devang patel wrote: > Chuck, > > How about advertising 10/8 from R3/R4 in IBGP with their physical interface > as a next-hop, as those physical interfaces are the links inside the area, > R1/R2 will have routes for that links as intra area or of same level and > that way it will not be an issue? Any comment? > > Thanks, > Devang > > On Mon, May 10, 2010 at 3:15 PM, Chuck Anderson <[email protected]> wrote: > > > R1 has no active local aggregate 10.0.0.0/8 route, nor any 10/8 route > > in IGP (due to being in a NSSA no-summaries area which only has a > > default route for reachability to other areas) or nor any 10/8 route > > in BGP, so it can't advertise 10/8 to EBGP peers as required. > > > > To rememdy this, one could: > > > > 1. define 10/8 as a local aggregate route on R1, as was done on R4 and > > R7. > > > > - but this has problems because a locally defined aggregate has a > > "reject" next-hop. Because R1 is in an NSSA no-summaries area you > > have no specific routes to your other routers. Since the 10/8 > > aggregate is more specific than the 0/0 you were relying on to reach > > other areas, you will reject (blackhole) traffic to your other areas > > in 10/8. Your IBGP will break among other things. > > > > 2. define 10/8 as a local aggregate route on R3, then let R3 advertise > > this via IBGP to R1. > > > > - this still doesn't work because R1 sees the 10/8 IBGP route from R3 > > with a BGP protocol next-hop of 10.0.3.3. When R1 tries to > > recursively resolve the protocol next hop, it finds that the best > > (longest) match for 10.0.3.3 is the 10/8 IBGP route itself. That > > isn't allowed because it can cause route recursion loops, so the route > > becomes hidden/unusable. > > > > 3. define 10/8 as a local "generated" route on R1. Because generated > > routes have next-hops other than "reject" this prevents the blackhole > > problem that solution #1 has. Note that generated routes show up as > > "aggregate" in the routing table, but they have a real next-hop > > instead of "reject". > > > > - this satisfies the requirement to advertise 10/8 to EBGP peers, but > > this causes suboptimal routing R1-R2-R3 instead of direct R1-R3. > > Generated routes take their next-hop from the primary contributing > > route. In this case, the only routes R1 has that can contribute to > > the 10/8 generated route are the ones in the OSPF NSSA area. Direct > > routes can't be used to contribute, so it picks the lowest OSPF route, > > which is 10.0.4.0/30, leading to the suboptimal routing. > > > > Now, I'm not entirely sure why the Direct routes can't contribute to > > the generated route. The book says "a route can only contribute to a > > generated route when it is associated with a forwarding next hop, > > which means that r1’s directly connected broadcast interfaces are not > > allowed to contribute". Why aren't Direct routes considered > > "forwarding next hops"? Is this a limitation of JUNOS, or is there > > some reason why this is? > > > > I tested this on 8.4, and aggregate/generated routes can use Direct > > routes as contributors in some cases but not others. Does anyone know > > what causes the Direct routes to be usable or not? > > > > For example, if I configure a generate route on an IS-IS L1/L2 > > attached router (R3 in the JNCIE book), I see IS-IS and Direct > > contributors: > > > > inet.0: 21555 destinations, 21565 routes (21555 active, 0 holddown, 0 > > hidden) > > 10.0.0.0/16 (1 entry, 1 announced) > > *Aggregate Preference: 130 > > Next hop type: Router, Next hop index: 1067 > > Next-hop reference count: 3 > > Next hop: via lt-1/3/0.10, selected > > State: <Active Int Ext> > > Local AS: 65412 > > Age: 5d 0:18:47 > > Task: Aggregate > > Announcement bits (3): 2-BGP RT Background 3-KRT 5-Resolve > > tree 1 > > AS path: I > > Flags: Generate Depth: 0 Active > > Contributing Routes (17): > > 10.0.2.4/30 proto Direct > > 10.0.4.4/30 proto IS-IS > > 10.0.4.8/30 proto IS-IS > > 10.0.4.16/30 proto IS-IS > > 10.0.5.0/24 proto IS-IS > > 10.0.6.1/32 proto IS-IS > > 10.0.6.2/32 proto IS-IS > > 10.0.2.8/30 proto IS-IS > > 10.0.2.16/30 proto IS-IS > > 10.0.3.4/32 proto IS-IS > > 10.0.3.5/32 proto IS-IS > > 10.0.8.0/30 proto IS-IS > > 10.0.8.4/30 proto IS-IS > > 10.0.8.8/30 proto IS-IS > > 10.0.8.12/30 proto IS-IS > > 10.0.9.6/32 proto IS-IS > > 10.0.9.7/32 proto IS-IS > > > > but if I configure a generate route on the IS-IS Level 1 router (R1 in > > the JNCIE book), I don't see any Direct routes, just IS-IS routes: > > > > inet.0: 21537 destinations, 21544 routes (21537 active, 0 holddown, 0 > > hidden) > > 10.0.0.0/16 (2 entries, 1 announced) > > *Aggregate Preference: 130 > > Next hop type: Router, Next hop index: 262142 > > Next-hop reference count: 21540 > > Next hop: 10.0.4.6 via lt-1/3/0.2 > > Next hop: 10.0.4.13 via lt-1/3/0.4, selected > > State: <Active Int Ext> > > Local AS: 65412 > > Age: 3:12 > > Task: Aggregate > > Announcement bits (3): 2-BGP RT Background 3-KRT 5-Resolve > > tree 1 > > AS path: I > > Flags: Generate Depth: 0 Active > > Contributing Routes (3): > > 10.0.4.0/30 proto IS-IS > > 10.0.4.8/30 proto IS-IS > > 10.0.6.2/32 proto IS-IS > > > > Actually, I think this is because the 10.0.2.4/30 Direct route is on a > > point-to-point interface rather than a broadcast interface. That > > might explain the difference in behavior. > > > > > > On Sun, May 09, 2010 at 10:46:03AM -0400, David water wrote: > > > Chris, Its Page 529. > > > > > > -- > > > David W. > > > > > > On Sun, May 9, 2010 at 10:16 AM, Chris Grundemann <[email protected] > > >wrote: > > > > > > > What pages in the study guide are you looking at? > > > > ~Chris > > > > > > > > My Android sent this message. > > > > > > > > On May 8, 2010 9:21 PM, "David water" <[email protected]> wrote: > > > > > > > > All, I was reading EBGP policy from JNCIP book and came across > > > > advertisement > > > > of local subnet summary to EBGP peer where you have IGP area where you > > are > > > > only receiving default. That part looks tricky. Can some one explain it > > to > > > > make it little easy? _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
