[j-nsp] local summary route advertisement in JNCIP BOOK EBGP Export policy
devang patel
devangnp at gmail.com
Mon May 10 15:47:19 EDT 2010
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?
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
More information about the juniper-nsp
mailing list