SEAN at SDG.DRA.COM
Fri May 29 01:36:56 UTC 1998
>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 18.104.22.168 (which also has a /8), 22.214.171.124
>(which has no /8), 126.96.36.199, 188.8.131.52, 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 184.108.40.206/23 (without a /16
>anywhere), 220.127.116.11/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
More information about the NANOG