Re: [j-nsp] Many contributing routes
BTW, I personally think that even aggregate routes bring more headache than benefits, let alone generate. Classic case is using aggregate to generate your own public prefixes and at the same time having a loopback address out of this range. Or a static route. Or a connected subnet. Theoretically you can sort this out with policies, but it's very error-prone. These routes tend to be relatively stable, so NOCs never deal with the underlying dynamism and often forget to update policies, when adding static routes/whatever. Generate is even clumsier, all this "WTF if my next-hop?" tie-breaking stuff is the best way to the unmanageable mess. As of my opinion, static floating (preference 999) discard is your friend for this kind of aggregation. In addition, in the case of Internet, it's always a good idea to have a static floating discard, otherwise you have an implicit static floating REJECT as prescribed by RFC1812 (see your show route forwarding-table) and all the corresponding risks to DoS your uKernel MPC CPU. Regards, Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Many contributing routes
Yes, you are right the primary contributing route is the mathematically lowest 32-bit number of routes in that case "Show route x.x.x.x extensive" shows the primary contributing route at the end of the displayed output. Regards alexander -Ursprüngliche Nachricht- Von: Aaron Gould [mailto:aar...@gvtc.com] Gesendet: Samstag, 12. August 2017 02:03 An: alexander.marh...@gmx.at; 'Vincent Bernat'; juniper-nsp@puck.nether.net Betreff: RE: [j-nsp] Many contributing routes I have a note during a jncis-sp study I did... "generated routes receive the next hop of the primary contributing route. primary contributing route is the route with lowest preference of all the contributing routes falling within the aggregate range of prefixes. if there are multiple contributing routes with same preference, tie breaker is LOWEST prefix number... NOT lowest prefix length." Forgive me as I don't have much real-world experience with this topic, but is this note above accurate ? I'm wondering if he is getting lots of what appear to be ebgp learned prefixes I'm thinking they would all be Preference 170, with all that being tied at 170, would the tiebreaker go to the lowest prefix number ? like 1.0.0.0 or 3.0.0.0 or something low like that ? - Aaron Gould ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Many contributing routes
I have a note during a jncis-sp study I did... "generated routes receive the next hop of the primary contributing route. primary contributing route is the route with lowest preference of all the contributing routes falling within the aggregate range of prefixes. if there are multiple contributing routes with same preference, tie breaker is LOWEST prefix number... NOT lowest prefix length." Forgive me as I don't have much real-world experience with this topic, but is this note above accurate ? I'm wondering if he is getting lots of what appear to be ebgp learned prefixes I'm thinking they would all be Preference 170, with all that being tied at 170, would the tiebreaker go to the lowest prefix number ? like 1.0.0.0 or 3.0.0.0 or something low like that ? - Aaron Gould ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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] 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] 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
