for example there is a small company with /22 IPv4 allocation from
RIPE in European region. This company is dual-homed and would like to
announce 4x /24 prefixes to both ISPs. Both ISP's update their
prefix-lists automatically based on records in RIPE database. For
example Level3 uses this practice at least in Europe. If this small
company creates a "route" object for it's /22 allocation, then is it
enough? Theoretically this would cover all four /24 networks. Or in
which situation it is useful/needed to have "route" object for each
/24 prefix?
You should create a route object for each route that you announce, if
you announce 4 x /24 you should create a route: object for each /24.
Some providers will create filters solely based on existing route
objects, others will create filters based on all route objects, AND
allow up to a /24 regardless. I would err to the safe side.
Kind regards,
Job
ps. Can you please send 20 dollarcent per /24 to my paypal account
(job@instituut.net) with the reference "deaggregation fee"?
for example there is a small company with /22 IPv4 allocation from
RIPE in European region. This company is dual-homed and would like to
announce 4x /24 prefixes to both ISPs. Both ISP's update their
prefix-lists automatically based on records in RIPE database. For
example Level3 uses this practice at least in Europe. If this small
company creates a "route" object for it's /22 allocation, then is it
enough? Theoretically this would cover all four /24 networks. Or in
which situation it is useful/needed to have "route" object for each
/24 prefix?
You should create a route object for each route that you announce, if
you announce 4 x /24 you should create a route: object for each /24.
+1
ps. Can you please send 20 dollarcent per /24 to my paypal account
(job@instituut.net) with the reference "deaggregation fee"?
Indeed.
Martin, I'd suggest announcing the 4 x /24s to each ISP tagged with the
no-export community in order to achieve whatever you are trying to do,
*in addition* to the covering /22. That way you're not polluting Job,
my, and everyone else's routing tables more than necessary, only your
own ISPs', but then again you're actually paying them for the privilege.
Job, Tore: ok, I see. So "route" object in RIR routing registry database
for each announced prefix is needed only because some ISPs create filters
exactly the size of the "route" object in database? So for example if there
is a "route" object for 192.0.2.0/24 in RIR database, then ISP-A might
create a following strict prefix-filter entry:
policy-options {
policy-statement EXAMPLE {
term prefixes {
from {
route-filter 192.0.2.0/24 exact;
}
then next policy;
}
then reject;
}
}
On the other hand, ISP-B might create loose filter based on the same
"route" object like this:
policy-options {
policy-statement EXAMPLE {
term prefixes {
from {
route-filter 192.0.2.0/24 upto /32;
}
then next policy;
}
then reject;
}
}
PS: this is a theoretical question I'm also for keeping the BGP table as
short as possible.
tl;dr: rpsl itself is a mess => no point in fixing irrtoolset
There is some work in progress to try to create a new policy description
language which would be a replacement for rpsl. Very early stages so far,
though.
I'm also for keeping the BGP table as