[j-nsp] local summary route advertisement in JNCIP BOOK EBGP Export policy
Chuck Anderson
cra at WPI.EDU
Tue May 11 08:25:26 EDT 2010
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 <cra at wpi.edu> 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 <cgrundemann at gmail.com
> > >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" <dwater2010 at gmail.com> 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?
More information about the juniper-nsp
mailing list