204.82.160.0/22 invisible

Sean Doran smd at icp.net
Mon Sep 25 06:02:00 UTC 1995


Ed - 

  Excellent.  Thank-you.

	Sean.
- --
| From ejk at nitrous.digex.net Mon Sep 25 01:41:25 1995
| From:	Ed Kern <ejk at nitrous.digex.net>
| To:	asp at uunet.uu.net (Andrew Partan)
| Cc:	kai at belcom.net (Kai), dorian at CIC.Net, avg at sprintlink.net, baldwin at SDD.COMSAT.COM, bertolini at computel.com, concaj at belcom.net, donagm at belcom.net,
| 	ilya at phri.nyu.edu, insc at sprintlink.net, ken at belcom.net, khalfk at belcom.net, ladycom at computel.com, nanog at MERIT.EDU, noc at digex.net, smd at sprint.net,
| 	susan.evans at SPRINT.SPRINT.COM
| Subject: Re: 204.82.160.0/22 invisible
|
|
| Some additions
|
|
| On September 25, you wrote:
| > Poking at this futher, Sprint is announcing 204.82.160/22; Digex is
| > behind ANS; this route is not in the RADB; and since ANS insists on all
| > routes being in the RADB, they are not accepting it, so Digex is not
| > seeing it.
|
| Ive statically nailed up this route to sprintlink, for the week of
| this event.  It will be removed either when the week is up, or as soon
| as sprintlink/sean requests its removal.
|
|
| 206.82.160/22 for the record. 
| >
| > Fix: Either get ANS to not insist on all routes being in the RADB or
| > submit an update to the RADB & wait for ANS to regenerate their
| > configs.
|
| While the RADB is flawed (overloaded to the tune of about 30k routes
| and not including routes such as this one) I dont think ans is quite
| ready to hang it up...
|
| so those of us who rely on the RADB, or (in my case) rely on transit
| provider based on the radb, we'll have to take these one at a time.
|
|
| Hopefully without the "anti-trust, im going to sue you, guess I have
| to be the martyr" bullshit.
|
| > 
| > Kai: Please don't widly accuse folks before poking into the facts.
| > 	--asp at uunet.uu.net (Andrew Partan)
|
|
| and as to this
|
| >> Correct. I have other networks in 204, so above was a typo. Also correct:
| >> he (rather cryptically) said Sprint wouldn't filter outgoing (hence
| >> customer-owned) routes, but he encouraged OTHER providers to do it like
| >> Sprint: filter incoming routes by the rules anounced: this has the same
| >> effect, but now Sean could point at Digex (should they employ such a
| >> filter) "I didn't do it, man!"...
|
| Ill have you know that the filter list im working on looks nothing like
| the sprintlink one in any way..least not after I took those ugly comments
| out ;)
|
| Ed
|
|




More information about the NANOG mailing list