Home page logo

nanog logo nanog mailing list archives

Re: invisible
From: Ed Kern <ejk () nitrous digex net>
Date: Mon, 25 Sep 1995 01:40:59 -0400

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

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 () 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 ;)


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]