Re: [j-nsp] Many contributing routes
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
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
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] /31 support on SRX tunnel interfaces
Is there any reason a /31 address would not work on a SRX tunnel interface (i.e. st0.1) The VPN is up, ping is allowed and both sides show outbound traffic but neither sides shows any inbound traffic. Jonathan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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