|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: 165.138.0.0
>Sean, when I look at a full BGP table from MCI/Sprint/UUnet/and ANS I see >a lot of /16 - /24's on the 12.0.0.0 (which also has a /8), 24.0.0.0 >(which has no /8), 53.0.0.0, 62.0.0.0, etc.....Some of these have the >classic /8 covering them and some don't. It's the same story for >several /16's (class b networks) I see 132.155.204.0/23 (without a /16 >anywhere), 134.128.52.0/24 (without a /16). Do you have problems >getting to all of these? The filters I use have existed for several years. I make lots of exceptions for networks which supply at least an interesting reason for doing it. We ask the person to contact their upstream NOC, and for most providers work something out quickly. There is one, and only one reason I won't make an exception. When someone says the policy doesn't apply to them because they are a sprint customer. After that happens they are directed to call the Sprint NOC for assistance. It would be nice if sprint accepted trouble reports directly from non-customers, then it would not be necessary to broadcast general appeals for help on lists like nanog. But when the Sprint network declines to contact the sprint NOC for assistance, it simply delays the whole problem resolution process. I'm sorry you had difficulty doing this. Contacting the Sprint NOC should put you in touch with someone to help you come up with a useful routing policy that meets the conditions Sprint says are good rules for controlling the growth of the global routing table. After all you are paying sprint, not me. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation |