[j-nsp] Generating routes from inactive/hidden contributors

[Alexander Arseniev]

Hello,

Have You tried putting all routes from that peer in a routing-instance?

Then configure aggregate|generate in that instance and leak it into 
inet.0|whereever the other peers sit.

You can leak the whole table from that peer as well, but that amounts to 
2x route memory consumption by that peer.

HTH

Thx

Alex


On 03/03/2017 15:07, Tore Anderson wrote:
> Hi,
>
> * adamv0025 at netconsultings.com
>
>> Interesting,
>> There appears to be no cmd to override the default, "contributing route has
>> to be active", requirement. (the "from state inactive" attachment point is
>> only the export policy).
>> I'm just thinking whether it's not working simply because the inactive
>> routes wouldn't be advertised anyways -so why to bother aggregating them
>> right?
> True, but this is a generated route, not an aggregated route. They're
> quite similar, but the generated routes can have next-hops (copied from
> a contributing route), which means you don't really need the
> contributing routes themselves to be active or even non-hidden to
> actually forward packets somewhere useful.
>
> Aggregated routes are on the other hand discard only, so then you need
> the more-specific contributing routes with their next-hops to avoid
> blackholing traffic.
>
> (AIUI, anyway.)
>
>> But maybe if you enable "advertise-inactive" towards your iBGP -maybe
>> then the aggregation starts to work?
> Perhaps, but if both the generated route and its contributors are
> indeed inactive in the RIB and thus not found in the FIB, then I don't
> think the router would be able to forward the packets it attracts to
> where it should.
>
>> Alternatively, I'm thinking of something along the lines of making the
>> prefixes active (to allow the aggregate to be advertised), but use
>> them only for routing not for forwarding -so that FIB on a local
>> router is not skewed.
> Yep, something like that would probably do the trick. I was hoping to
> keep them out of the RIB in the first place though, to avoid having to
> explicitly filter them on export to the FIB and iBGP peers, but maybe
> there's no way around it.
>
> Tore
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp