Re: [j-nsp] Many contributing routes

2017-08-09 Thread Thomas Bellman 
On 2017-08-09 09:05, Vincent Bernat wrote:

> I am generating a default route to distribute with a policy statement
> like that:
> 
> #v+
> policy-statement v4-DEFAULT-ROUTE-GENERATE {
[...]
> }
> #v-
> 
> This works just fine but there are a lot of contributing routes (about
> 400k) to the generated route. Is it harmless or will I run into trouble
> for that?

That is a pretty common thing to do when you inject a default
route into your IGP (OSPF or ISIS) from your BGP-talking border
routers.  At least for those of us who are end-users, and not
ISPs ourselves, since our internal routers often do not handle
a full Internet table.  If you have a full Internet BGP feed
in your border router, you will of course then get hundreds of
thousands of contributing routes.  If this was problematic,
lots of people would complain...

Usually, you would use an 'aggregate' route for that (i.e. 'edit
routing-options aggregate'), or a 'generate' route ('edit routing-
options generate') with an explicit discard or reject target, not
retaining the nexthop from any of the contributing routes.  My
understanding is that if you use a generate route that keeps the
nexthop from some contributing route, you usually have fairly few
contributors, but I would not expect it to be a problem having
400k contributing routes.


/Bellman



signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] /31 support on SRX tunnel interfaces

2017-08-09 Thread Hugo Slabbert 
Is there any reason a /31 address would not work on a SRX tunnel interface 
(i.e. st0.1)


Shouldn't be; I've done /31s and /127s on GRE and st interfaces without 
issues on various SRXs.


The VPN is up, ping is allowed and both sides show outbound traffic but 
neither sides shows any inbound traffic.


Are the st interfaces in a security zone?  Are you pinging _to_ the remote 
SRX or _through_ it?  If the former, do you have host-inbound-traffic 
configured to permit it?  If the latter, do you have security policies 
configured to permit the traffic?


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] Many contributing routes

2017-08-09 Thread Alexander Marhold 
Hi !

No problem as the generated route gets its info and next-hop address from
exactly one contributing route, that is okay

If you would use an aggregated route with 100k of routes instead then you
would have the problem of aggregation of all AS numbers which lead to an
overflow
Regards

Alexander Marhold
Consultant and Trainer

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Vincent Bernat
Gesendet: Mittwoch, 9. August 2017 09:06
An: juniper-nsp@puck.nether.net
Betreff: [j-nsp] Many contributing routes

Hey!

I am generating a default route to distribute with a policy statement like
that:

#v+
policy-statement v4-DEFAULT-ROUTE-GENERATE {
term v4-TRANSIT-ASX {
from {
family inet;
protocol bgp;
neighbor xx.yy.zz.ww;
as-path LONG-AS-PATH;
}
then accept;
}
term v4-TRANSIT-ASY {
from {
family inet;
protocol bgp;
neighbor xx.yy.zz.ww;
as-path LONG-AS-PATH;
}
then accept;
}
then reject;
}
#v-

This works just fine but there are a lot of contributing routes (about
400k) to the generated route. Is it harmless or will I run into trouble for
that?

Thanks!
--
A classic is something that everyone wants to have read and nobody wants to
read.
-- Mark Twain, "The Disappearance of Literature"
___
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

[j-nsp] Many contributing routes

2017-08-09 Thread Vincent Bernat 
Hey!

I am generating a default route to distribute with a policy statement
like that:

#v+
policy-statement v4-DEFAULT-ROUTE-GENERATE {
term v4-TRANSIT-ASX {
from {
family inet;
protocol bgp;
neighbor xx.yy.zz.ww;
as-path LONG-AS-PATH;
}
then accept;
}
term v4-TRANSIT-ASY {
from {
family inet;
protocol bgp;
neighbor xx.yy.zz.ww;
as-path LONG-AS-PATH;
}
then accept;
}
then reject;
}
#v-

This works just fine but there are a lot of contributing routes (about
400k) to the generated route. Is it harmless or will I run into trouble
for that?

Thanks!
-- 
A classic is something that everyone wants to have read
and nobody wants to read.
-- Mark Twain, "The Disappearance of Literature"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp