Christian & NANOG in general: Our apologies for the BGP problem. We turned down our peering with UUNET today due to serious routing problems in Raleigh NC. When our NOC personnel reestablised the peering, they failed to utilize the peer-group that includes all of our outbound route filtering. Additional documentation and training will be implemented Monday - in the interim any BGP alterations will be performed by Backbone Engineering. We will audit our RA entries and verify that all of our routing data is present and correct. Tim McKee, Chief Technology Officer Info Avenue Internet Services, LLC
On Fri, 30 Apr 1999, Timothy R. McKee wrote:
We will audit our RA entries and verify that all of our routing data is present and correct.
And which every provider should do. We have seen many issues over the past couple of years where some provider had sent some type of incorrect route. This wasn't an attack on infowave we have seen bigger problems, ie 7007. This has been talked about at nanog so I am sure that everyone knows the pros/cons(?) on using the RA. Christian
On Fri, 30 Apr 1999, Christian Nielsen wrote:
This has been talked about at nanog so I am sure that everyone knows the pros/cons(?) on using the RA.
Are there any cons to it for a small multi-homed ISP? Also, I noticed Genuity does this on all their 'as-in' rules: aut-num: AS3847 as-name: ASN-GENUITY descr: Genuity Inc a Bechtel Company as-in: AS293 1 AS-ESNETUS AND NOT {0.0.0.0/0} as-in: AS568 1 AS568 AND NOT {0.0.0.0/0} as-in: AS1746 1 AS-DRANET AND NOT {0.0.0.0/0} as-in: AS2551 1 AS-NETCOM AND NOT {0.0.0.0/0} ^^^^^^^^^^^^^^^^^^^ I don't see any harm in it, yet I don't see lots of other people doing it in my random sampling. Also who actually uses the RA? What are the filter policies (in general) of those who don't? I ask as I'm going to bring some new space up next week and I'd be curious to see if I'll be invisible to anyone... Thanks, Charles
Christian
neighbor x.x.x.x shutdown will stop you from having to delete the neighbor completely therefore avoid risks like this.
Christian & NANOG in general:
Our apologies for the BGP problem. We turned down our peering with UUNET today due to serious routing problems in Raleigh NC. When our NOC personnel reestablised the peering, they failed to utilize the peer-group that includes all of our outbound route filtering. Additional documentation and training will be implemented Monday - in the interim any BGP alterations will be performed by Backbone Engineering.
We will audit our RA entries and verify that all of our routing data is present and correct.
Tim McKee, Chief Technology Officer Info Avenue Internet Services, LLC
-- Neil J. McRae - Alive and Kicking. neil@DOMINO.ORG
I've updated my entries in my nocs list with all the pending updates. If your update is not there, then it did not show up in my most recent check: select ikey,ispname from contact where valid="N"; Which means it's pending human intervention. Feel free to check out my nocs list, and add/update any incorrect or out of date information. http://puck.nether.net/netops/ As always, recommendations and/or feedback are welcome. - Jared On Fri, Apr 30, 1999 at 06:14:38PM -0400, Timothy R. McKee wrote:
Christian & NANOG in general:
Our apologies for the BGP problem. We turned down our peering with UUNET today due to serious routing problems in Raleigh NC. When our NOC personnel reestablised the peering, they failed to utilize the peer-group that includes all of our outbound route filtering. Additional documentation and training will be implemented Monday - in the interim any BGP alterations will be performed by Backbone Engineering.
We will audit our RA entries and verify that all of our routing data is present and correct.
Tim McKee, Chief Technology Officer Info Avenue Internet Services, LLC
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
participants (5)
-
Charles Sprickman -
Christian Nielsen -
Jared Mauch -
Neil J. McRae -
Timothy R. McKee