[j-nsp] Stealing from MX firewall jtree space

[Krasimir Avramski]

Yep, and the reason is that they are hidden in primary rib, so as secondary
routes (which primary routing table is inet.0) in secondary rib they are
inherently hidden.

The policy itself is working correctly - secondary routes are in the rib but
marked as hidden.

Unfortunately we should give up...

Regards,
Krasi

> -----Original Message-----
> From: Richard A Steenbergen [mailto:ras at e-gerbil.net]
> Sent: 18.12.2009 9:21 AM
> To: Krasimir Avramski
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] Stealing from MX firewall jtree space
> 
> On Wed, Dec 16, 2009 at 11:37:06PM +0200, Krasimir Avramski wrote:
> > What about terminating bgp neighbor in inet.0 with bgp operating over
> > a rib-group under family inet:
> >
> > protocols bgp
> > group xy {
> >     neighbor x.x.x.x {
> >         import xy;
> >         family inet {
> >             unicast {
> >                 rib-group xy;
> >             }
> >         }
> >     }
> > }
> >
> > Then import routing-policy "xy" states:
> >
> > policy-statement xy
> > term 1 {
> >     from community to_inet_0;
> >     to rib inet.0;
> >     then accept;
> > }
> > term 2 {
> >     to rib inet.0;
> >     then reject;
> > }
> > term 3 {
> >     from community to_vrf;
> >     to rib vrf.inet.0;
> >     then accept;
> > }
> > term 4 {
> >     to rib vrf.inet.0;
> >     then reject;
> > }
> 
> Hrm so I was testing this, and noticed an odd behavior... When you
> reject the route from inet.0 (for example, like you're doing in term 2)
> it also rejects the route in all other ribs, even if you explicitly
> accept them (like in your term 3). Term order doesn't seem to matter
> (putting term 3 before term 2 doesn't help), and it only happens to
> routes that you reject to inet.0 (rejecting the routes to another rib
> doesn't reject it from inet.0). Other attribute modifications appear to
> work as expected, I only see this problem when you reject the route, but
> setting localpref to 0 doesn't help if this is a more specific route so
> it isn't a true replacement for a working reject into inet.0.
> 
> The multi-topology routing features are much closer to what I'm actually
> trying to accomplish, but unfortunately it is missing pretty much every
> feature that would be needed to do anything useful with it (ability to
> import from another topology, ability to use policy-statements to
> control your protocol import, etc). Sigh, no way to win. :)
> 
> --
> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)