How would one extract the following information from the IRR: the list of AS's which are non-transit customers of a given backbone provider Peter Francis Sr. Network Engineer SoftAware Inc.
At 6/19/00 -0700, Peter Francis wrote:
How would one extract the following information from the IRR:
the list of AS's which are non-transit customers of a given backbone provider
Peter Francis Sr. Network Engineer SoftAware Inc.
Is the backbone provider registered with IRR? Many of them don't. ---------------------------------------------------------------------- Paul Froutan Email: pfroutan@rackspace.com Rackspace, Ltd <http://www.rackspace.com>
Peter, I guess the only answer I can give to this is "nice try". If determining other people's peering arrangements was this easy, everyone would be doing it. While in theory, folks can register objects describing a peering relationship, very few folks (if any) actually do so. Daniel Golding Director, Network Evaluation and Design NetRail, Inc. 1-888-NetRail On Mon, 19 Jun 2000, Peter Francis wrote:
How would one extract the following information from the IRR:
the list of AS's which are non-transit customers of a given backbone provider
Peter Francis Sr. Network Engineer SoftAware Inc.
On Tue, Jun 20, 2000 at 12:29:08AM -0400, Daniel L. Golding wrote:
I guess the only answer I can give to this is "nice try". If determining other people's peering arrangements was this easy, everyone would be doing it. While in theory, folks can register objects describing a peering relationship, very few folks (if any) actually do so.
And even for providers which are willing to publicly register their policy the most data you'll usually get is adjacencies via the aut-num objects. For the tier-1 providers, even this information (visible in the global BGP) would make for a hideously huge object. At the moment, IRR filtering technologies make the most sense at the edges of your network, not near the Internet core. When deployed at the core, pair-wise peering requires both parties to register policy (and verify it!) before IRR filtering makes sense. Otherwise it simply leads to further routing outages. Filter at the edges and work your way inwards. This will solve many routing outage issues.
Daniel Golding
-- Jeffrey Haas - Merit RSng project - jeffhaas@merit.edu
participants (4)
-
Daniel L. Golding -
Jeff Haas -
Paul Froutan -
Peter Francis