Are specific "route" objects in RIR databases needed?
Hi, 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? regards, Martin
On Thu, Jan 30, 2014 at 06:51:59PM +0200, Martin T wrote:
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"?
* Job Snijders
On Thu, Jan 30, 2014 at 06:51:59PM +0200, Martin T wrote:
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. Tore
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. regards, Martin On Thu, Jan 30, 2014 at 5:13 PM, Tore Anderson <tore@fud.no> wrote:
* Job Snijders
On Thu, Jan 30, 2014 at 06:51:59PM +0200, Martin T wrote:
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.
Tore
I can't say what everyone else does, but we only make exact matches from route object to prefix-list http://www.mellowd.co.uk/ccie
On 30 Jan 2014, at 21:48, "Martin T" <m4rtntns@gmail.com> wrote:
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.
regards, Martin
On Thu, Jan 30, 2014 at 5:13 PM, Tore Anderson <tore@fud.no> wrote:
* Job Snijders
On Thu, Jan 30, 2014 at 06:51:59PM +0200, Martin T wrote:
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.
Tore
IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty messy RPSL parse. After a few hours of research, it seems that its dead since 2009 :(. There is some effort at http://irrtoolset.isc.org to reboot development, its pretty dead since 2012-07-31. Beside home made solutions, there seems to be no commercial package. Any lead will be appreciated. ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
On Fri, Jan 31, 2014 at 08:58:06AM -0500, Alain Hebert wrote:
IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty messy RPSL parse.
After a few hours of research, it seems that its dead since 2009 :(.
There is some effort at http://irrtoolset.isc.org to reboot development, its pretty dead since 2012-07-31.
Beside home made solutions, there seems to be no commercial package.
Any lead will be appreciated.
I really like bgpq3 for prefix-filter generation. http://github.com/snar/bgpq3 http://snar.spb.ru/prog/bgpq3/ Kind regards, Job
+1 Easiest to use by far. Only thing I see as lacking for easy adoption is canned solution for managing the push to the routers. On 1/31/2014 9:04 AM, Job Snijders wrote:
On Fri, Jan 31, 2014 at 08:58:06AM -0500, Alain Hebert wrote:
IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty messy RPSL parse.
After a few hours of research, it seems that its dead since 2009 :(.
There is some effort at http://irrtoolset.isc.org to reboot development, its pretty dead since 2012-07-31.
Beside home made solutions, there seems to be no commercial package.
Any lead will be appreciated.
I really like bgpq3 for prefix-filter generation.
http://github.com/snar/bgpq3 http://snar.spb.ru/prog/bgpq3/
Kind regards,
Job
On 31/01/2014 13:58, Alain Hebert wrote:
IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty messy RPSL parse.
of direct relevance to this: https://lists.isc.org/pipermail/irrtoolset/2011-April/000736.html 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. Nick
On 01/31/14 10:02, Nick Hilliard wrote:
On 31/01/2014 13:58, Alain Hebert wrote:
IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty messy RPSL parse.
of direct relevance to this:
https://lists.isc.org/pipermail/irrtoolset/2011-April/000736.html
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.
Nick
Well, Thanks to all. Job: bgpq3 works great the as-set that was borking rtlookup generate a ~183k long prefix list =D. ML: as for auto-deploying / auto-push to routers... I still prefer to do that manually myself. Nick: Yes, I saw those tidbits while looking for a replacement. If you're talking about RPSLng, it does not seems to gain any traction. From what I could see... ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
On Fri, Jan 31, 2014 at 11:32:17AM -0500, Alain Hebert wrote:
bgpq3 works great the as-set that was borking rtlookup generate a ~183k long prefix list =D.
I recommend using it like this, to enable aggregation where possible: bgpq3 -A Kind regards, Job
Yes, its the first thing I tried. Iti's still ~82k =D The as-set included some of his peering as export too. We're both looking into it. ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 01/31/14 11:38, Job Snijders wrote:
On Fri, Jan 31, 2014 at 11:32:17AM -0500, Alain Hebert wrote:
bgpq3 works great the as-set that was borking rtlookup generate a ~183k long prefix list =D.
I recommend using it like this, to enable aggregation where possible: bgpq3 -A
Kind regards,
Job
participants (7)
-
Alain Hebert -
Darren O'Connor -
Job Snijders -
Martin T -
ML -
Nick Hilliard -
Tore Anderson