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

[Dragan Jovicic]

>
> I'm looking to generate a route, and do so even if the contributing
> routes are inactive or hidden.
>

I believe "passive" option will keep generate/aggregate route in RIB in the
absence of contrib. routes (with NH discard/reject).
Maybe I misunderstood what you want.

Regard

Dragan

On Sun, Mar 5, 2017 at 4:32 PM, Alexander Arseniev 
wrote:

> They will be - in .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 +, 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,

 * adamv0...@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.

>>>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Alexander Arseniev]

They will be - in .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 +, 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,

* adamv0...@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.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Chuck Anderson]

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 +, 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,
> >
> >* adamv0...@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.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [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,

* adamv0...@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Tore Anderson]

Hi,

* adamv0...@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[adamv0025]

> Tore Anderson
> Sent: Friday, March 03, 2017 11:33 AM
> 
> Hi,
> 
> I'm looking to generate a route, and do so even if the contributing routes
are
> inactive or hidden.
> 
> The use case is to receive a full feed from an upstream provider and
> generate a default route pointing to that provider IFF I've received at
least
> one route from them that proves that they are in turn receiving routes
from
> their upstream(s). The point of having this generated default route is of
> course to be able to optimise away all the (now
> redundant) contributing routes.
> 
> I've tried the following as a proof of concept:
> 
> set routing-options rib inet.0 generate route 1.1.0.0/19 policy testpol
set
> policy-options policy-statement testpol term 1 from as-path teliatest set
> policy-options policy-statement testpol term 1 then accept set
policy-options
> policy-statement testpol term 2 then reject set policy-options as-path
> teliatest .*1299.*
> 
> While I do have contributing routes within 1.1.0.0/19 matching the
as-path,
> they are all inactive, and thus the generated route does not go active
either.
> Furthermore, it makes no difference to add:
> 
> set policy-options policy-statement testpol term 1 from state inactive
> 
> I also get the same results if I filter out the contributing routes in my
> upstream's import policy (i.e., making them hidden rather than inactive).
> 
> Anyone know of a clever trick to get the behaviour I'd like?
> 

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? 
But maybe if you enable "advertise-inactive" towards your iBGP -maybe then
the aggregation starts to work? 

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.

 


adam


netconsultings.com
::carrier-class solutions for the telecommunications industry::

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Tore Anderson]

Hi,

I'm looking to generate a route, and do so even if the contributing
routes are inactive or hidden.

The use case is to receive a full feed from an upstream provider and
generate a default route pointing to that provider IFF I've received at
least one route from them that proves that they are in turn receiving
routes from their upstream(s). The point of having this generated
default route is of course to be able to optimise away all the (now
redundant) contributing routes.

I've tried the following as a proof of concept:

set routing-options rib inet.0 generate route 1.1.0.0/19 policy testpol
set policy-options policy-statement testpol term 1 from as-path teliatest
set policy-options policy-statement testpol term 1 then accept
set policy-options policy-statement testpol term 2 then reject
set policy-options as-path teliatest .*1299.*

While I do have contributing routes within 1.1.0.0/19 matching the
as-path, they are all inactive, and thus the generated route does not
go active either. Furthermore, it makes no difference to add:

set policy-options policy-statement testpol term 1 from state inactive

I also get the same results if I filter out the contributing routes in
my upstream's import policy (i.e., making them hidden rather than
inactive).

Anyone know of a clever trick to get the behaviour I'd like?

Tore
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp