[168574] in North American Network Operators' Group
Re: Are specific "route" objects in RIR databases needed?
daemon@ATHENA.MIT.EDU (Job Snijders)
Thu Jan 30 12:02:05 2014
Date: Thu, 30 Jan 2014 18:01:30 +0100
From: Job Snijders <job.snijders@hibernianetworks.com>
To: Martin T <m4rtntns@gmail.com>
In-Reply-To: <CAJx5YvGYY=2MXrkSY4z0ZtLFqMZ=R1HCxuSuTChM62MZXXWRAA@mail.gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--L/Qt9NZ8t00Dhfad
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.=20
Some providers will create filters solely based on existing route
objects, others will create filters based on all route objects, AND=20
allow up to a /24 regardless. I would err to the safe side.=20
Kind regards,
Job
ps. Can you please send 20 dollarcent per /24 to my paypal account
(job@instituut.net) with the reference "deaggregation fee"?
--L/Qt9NZ8t00Dhfad
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJS6oVqAAoJEHBa78u36uLzOjUQAJnmeO1YtP2AVsY2gNpDiiyx
g0bFiglxmdmgi9p+/rtd2ZDmDq7CetnmZh5+HLH/2FuX1cwvxKsEJcCUOQrTLHjD
ATGPIUDyQARfiCpTS4ePKwfXc6haGK0cmDZ5B0vInP0Zz7eFhbdVa0ys4IZW5sl1
O80hopMpzNZfon+B3gD3FTT/dvDxNsfh3+Te1V9dWvKtSFavPpmppDjOgk1keUXc
JTsYvbw9sFu9gcGEABYMsvv6ETZD9j/u+Ow5Z6bIjtpQKnCvTEpSclAEQT61tkma
PT/EUHBQR/Sa7lI5yuweJc9+X/OZ+eDq4fcXMF8BDRHadf37AT2oZo4H5itHuzt8
/BUFBeh4bbHhnW5MsuPlgcMZd/XuTVroXTAcXSiLMgkN40wd7em8Fj9gGteJG5rE
6HvOATiUbluy2wLWBah0QlcMYloymhtxqke4rVrET5MX9pyRogUXUKXMgWuvQGbH
2BnhKqqdORhm8gk35kHPh5JWSm6x5Ozu3xl1k3QmtSyQk3wyy3HGQZBjCHj5x5cg
nj0Y6lFKBNocwDLQ0qJql3TICp8Hs2iRipUbAuVZxpIeuexdpJwLiTMbGS3eEtAK
jkCffj30r4Kc7ZkY5EanlMjxliJR+2XHZ8vuQi840KOkc/QP9DksTfLyJqsiuV32
WKHx2nsceZAtZ8cxf6N4
=BF/6
-----END PGP SIGNATURE-----
--L/Qt9NZ8t00Dhfad--
