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

[Alexander Arseniev]

They will be - in <whatsthatppername>.inet.0 virtual router, where the 
BGP session terminates.


On 05/03/2017 14:53, Chuck Anderson wrote:
> Last time I checked the contributing routes have to be in the
> destination RIB for the aggregate/generate to go active.
>
> On Sun, Mar 05, 2017 at 11:26:18AM +0000, Alexander Arseniev wrote:
>> 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.