- Test - lists.nanog.org

Re: 204.82.160.0/22 invisible (fwd)
by Kai 25 Sep '95

25 Sep '95

>Just out of curiosity, why should Internic strap on more asbestos? >I thought the following would have been warning enough: > ***PLEASE READ THE FOLLOWING INFORMATION PRIOR TO REQUESTING AN >IP NUMBER FROM THE INTERNIC: >Due to technical and implementation constraints on the Internet routing >system and the possibility of routing overload, certain policies may >need to be enforced by the major transit providers in order to reduce >the number of globally advertised routes. These potential policies >may include setting limits on the size of CIDR prefixes added to the >routing tables, filtering of non-aggregated routes, etc. Therefore, >addresses obtained directly from the InterNIC (non-provider-based, >also known as portable) are not guaranteed to be routable on the Internet. this is from the internet-number-template.txt, which wasn't quite the template I dealt with (I submitted the isp-ip-template.txt), as the requirements for the assignment were clearly (and stated to the Internic): a.) portable, as a change in US domestic attachment point(s) is imminent b.) multi-homed across continents is foreseeable within 3-4 months c.) they were specifically named as networks that were in turn to be given out to our customers, and a provider-dependent IP range was not acceptable Given these conditions, it was gross neglience if not outright malicious for the Internic to give us an assignment that, according to obviously previously aired and announced policy of Sean Doran and others, would not be routed on major parts of the Internet just days later, a fact that was for sure not unknown to the IP registry. That's enough reason to be cautious and strap on more asbestos for the case I come back to them about this, I believe. --- Kai Schlichting Internet Project Manager, BelCom, Inc. 515 Madison Ave Suite 2100 NY,NY 10022 212-705-9500 (voice) 212-755-0864 (fax) kai(a)belcom.net Ask us about Internet service in the CIS! Bringing Internet, where there is none

1 0

Re: 204.82.160.0/22 invisible (fwd)
by Kai 25 Sep '95

25 Sep '95

Sean Doran wrote: >Thank-you Andrew. That matches my diagnosis. >Kai: computel, our customer, should be able to help you >prepare an entry for the RADB; failing that, please >feel free to turn to noc(a)ans.net or engineer(a)sprint.net >for assistance in updating the RADB so that your prefix >is heard by ANS. >See, ANS has an inbound route-filter too... and it's MUCH older than Sprint's. > Sean. >- -- >Sean Doran <smd(a)sprint.net> >- -- In lieu of Computel knowing what the RADB is, I will handle the RADB entry myself, if I don't decide to recycle the assignment altogether and start from scratch, which is likely by now, after analyzing and evaluating the situation a bit more. The Internic should strap on more asbestos now. Is it preferable for Sprint to announce/act under my (future) ASN rather than take the route into one of their own ASNs ? Computel is kinda a like dark tunnel between us at this time... THANKS to all for the response and fix for now. bye, Kai "don't filter my route" Schlichting ps: some NANOG readers wrote back that my route is looping overseas: yes, there is some trouble this hour...the evil of default routes. --- Kai Schlichting Internet Project Manager, BelCom, Inc. 515 Madison Ave Suite 2100 NY,NY 10022 212-705-9500 (voice) 212-755-0864 (fax) kai(a)belcom.net Ask us about Internet service in the CIS! Bringing Internet, where there is none

2 1

Re: 204.82.160.0/22 invisible (fwd)
by Sean Doran 25 Sep '95

25 Sep '95

Alan - This is an excellent idea, and I shall try to make time tomorrow to explain in easily-understood terms what all this means. Sean.

1 0

Re: 204.82.160.0/22 invisible
by Sean Doran 25 Sep '95

25 Sep '95

Ed - Excellent. Thank-you. Sean. - -- | From ejk(a)nitrous.digex.net Mon Sep 25 01:41:25 1995 | From: Ed Kern <ejk(a)nitrous.digex.net> | To: asp(a)uunet.uu.net (Andrew Partan) | Cc: kai(a)belcom.net (Kai), dorian(a)CIC.Net, avg(a)sprintlink.net, baldwin(a)SDD.COMSAT.COM, bertolini(a)computel.com, concaj(a)belcom.net, donagm(a)belcom.net, | ilya(a)phri.nyu.edu, insc(a)sprintlink.net, ken(a)belcom.net, khalfk(a)belcom.net, ladycom(a)computel.com, nanog(a)MERIT.EDU, noc(a)digex.net, smd(a)sprint.net, | susan.evans(a)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(a)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 | |

1 0

Re: 204.82.160.0/22 invisible
by Sean Doran 25 Sep '95

25 Sep '95

Thank-you Andrew. That matches my diagnosis. Kai: computel, our customer, should be able to help you prepare an entry for the RADB; failing that, please feel free to turn to noc(a)ans.net or engineer(a)sprint.net for assistance in updating the RADB so that your prefix is heard by ANS. See, ANS has an inbound route-filter too... and it's MUCH older than Sprint's. Sean. - -- Sean Doran <smd(a)sprint.net> - -- | From nanog-request(a)merit.edu Mon Sep 25 01:04:24 1995 | Resent-Date: Mon, 25 Sep 1995 01:03:08 -0400 | From: asp(a)uunet.uu.net (Andrew Partan) | Resent-To: <smd(a)chops.icp.net> | Subject: Re: 204.82.160.0/22 invisible | To: kai(a)belcom.net (Kai) | Cc: dorian(a)CIC.Net, kai(a)belcom.net, avg(a)sprintlink.net, baldwin(a)SDD.COMSAT.COM, bertolini(a)computel.com, concaj(a)belcom.net, donagm(a)belcom.net, | ilya(a)phri.nyu.edu, insc(a)sprintlink.net, ken(a)belcom.net, khalfk(a)belcom.net, ladycom(a)computel.com, nanog(a)MERIT.EDU, noc(a)digex.net, smd(a)icp.net, | smd(a)sprint.net, susan.evans(a)SPRINT.SPRINT.COM | Resent-From: nanog(a)MERIT.EDU | X-Mailing-List: <nanog(a)MERIT.EDU> archive/latest/167 | X-Loop: nanog(a)MERIT.EDU | Resent-Sender: nanog-request(a)MERIT.EDU | | 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. | | 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. | | Kai: Please don't widly accuse folks before poking into the facts. | --asp(a)uunet.uu.net (Andrew Partan) | | |

1 0

Re: 204.82.160.0/22 invisible
by Sean Doran 25 Sep '95

25 Sep '95

Ahem. We are doing no outbound filtering, as noted earlier, so if you are announcing the /20 to Sprint, and DIGEX isn't hearing it, then either DIGEX or ANS is doing something odd routing-wise, and it should be debugged via the Sprint INSC and not the Sprint legal department. Sean.

1 0

Re: 204.82.160.0/22 invisible
by Ed Kern 25 Sep '95

25 Sep '95

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

1 0

Re: 204.82.160.0/22 invisible
by Gordon Cook 25 Sep '95

25 Sep '95

This *IS* a serious event. It *IS* sponsored by the branch of NATO that furthers international science and technology cooperation between NATO members and Russia and former republics of the former USSR. I attended last years conference at the invitation of Steve goldstein (NSF) who was co-chair. last year we met just outside of Moscow. In my opinion SEAN should make an immediate exception for the week long duration of this significant conference and its hoped for benefit of the growth of the internet in Russia and other former USSR republics. ******************************************************************** Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 The COOK Report on Internet Non Profit. $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook(a)cookreport.com Corporate. Site Lic $650 http://www.netaxs.com/~cook <- Subscription Info & COOK Report Index ******************************************************************** On Sun, 24 Sep 1995, Kai wrote: > > My network assignment 204.82.160.0/22 (Sprint-announced) has become invisible > to all Digex-connected networks, while my old assignment (204.97.218/219) > is still seen normally. > Following the NANOG list, I must suspect this is due to the route prefix > filtering Sean Doran announced, and which seems to have gone into effect. > As Comsat (a Digex client) can now no longer reach BelCom's overseas > subsidaries (BelCom is a Computel client, client of Sprint: Computel is > technically incapable of handling or comprehending this issue, you will > have to deal with me). > I demand that this route prefix filtering is turned off immediately: > The Almaty NATO networking conference is IN SESSION (trace to 206.82.161.1 > if you can ), and I was absolutely positive about the consequences this > will have on the relationship between BelCom and Arna-Sprint in Kazakhstan. > If you want to avoid a press release at the conference detailing names and > circumstances of this engineering terrorism, you should turn off the route > prefix filter THIS MINUTE. There was absolutely no humanly sane reason to > 'pull the plug' on a Sprint customer like this, and to sabotage an event > that has cost us $50,000 plus 200 engineering hours to make happen. > This is off to the lawyers. > > --- > Kai Schlichting > Internet Project Manager, BelCom, Inc. > 515 Madison Ave Suite 2100 > NY,NY 10022 > 212-705-9500 (voice) > 212-755-0864 (fax) > kai(a)belcom.net > Ask us about Internet service in the CIS! > Bringing Internet, where there is none > >

2 1

Re: 206.40.160.0/20
by sob＠academ.com 25 Sep '95

25 Sep '95

Scott, you are also advertising 206.40.160.0/20 to AS114 as individual /24 addresses. You need to stop this as well. Thanks. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: 204.82.160.0/22 invisible
by Eric Kozowski 25 Sep '95

25 Sep '95

>> My network assignment 204.82.160.0/22 (Sprint-announced) has become invisible >> to all Digex-connected networks, while my old assignment (204.97.218/219) >> is still seen normally. > >I see both /16s. > >> The Almaty NATO networking conference is IN SESSION (trace to 206.82.161.1 > >Traffic is bouncing on your side. > --asp(a)uunet.uu.net (Andrew Partan) > >Vienna1-gw#sh ip b 204.82.160.0 >BGP routing table entry for 204.82.0.0 255.255.0.0, version 1489552 >Paths: (1 available, best #1, advertised over IBGP, EBGP) > 3561 577 807, (aggregated by 577 192.68.66.14) > 192.41.177.181 from 192.41.177.181 (204.70.7.53) > Origin EGP, metric 57, valid, external, atomic-aggregate, best >Vienna1-gw#sh ip b 204.97.218.0 >BGP routing table entry for 204.97.0.0 255.255.0.0, version 1145769 >Paths: (1 available, best #1, advertised over IBGP, EBGP) > 1239, (aggregated by 1239 144.228.61.1) > 192.41.177.241 from 192.41.177.241 (144.228.101.1) > Origin IGP, metric 9, valid, external, atomic-aggregate, best > I'm seeing the same thing: sns-pdx1>sho ip bgp 204.82.160.0 BGP routing table entry for 204.82.0.0/255.255.0.0, version 565182 Paths: (2 available, best #2) 701 701 701 3561 577 807 (aggregated by 577 192.68.66.14) 137.39.218.29 from 137.39.218.29 (137.39.2.24) Origin EGP, valid, external, atomic-aggregate 4064 3830 3561 577 807 (aggregated by 577 192.68.66.14) 204.157.10.5 from 204.157.10.5 (204.157.228.50) Origin EGP, valid, external, atomic-aggregate, best sns-pdx1>sho ip bgp 204.97.218.0 BGP routing table entry for 204.97.0.0/255.255.0.0, version 564475 Paths: (2 available, best #2) 701 701 701 1239 (aggregated by 1239 144.228.61.1) 137.39.218.29 from 137.39.218.29 (137.39.2.24) Origin IGP, valid, external, atomic-aggregate 4064 3830 1239 (aggregated by 1239 144.228.61.1) 204.157.10.5 from 204.157.10.5 (204.157.228.50) Origin IGP, valid, external, atomic-aggregate, best Traceroutes are bouncing between: 12 sl-computel-1-S0-T1.sprintlink.net (144.228.64.74) 166 ms 165 ms 164 ms 13 gate.belcom.net (204.97.218.1) 169 ms 184 ms 168 ms 14 ny-msw-256k.belcom.net (204.97.218.4) 170 ms 182 ms 167 ms 15 gate.moscow.belcom.net (206.82.160.1) 315 ms 334 ms 327 ms 16 204.97.219.1 (204.97.219.1) 341 ms 332 ms 337 ms 17 gate.moscow.belcom.net (206.82.160.1) 345 ms 345 ms 342 ms 18 204.97.219.1 (204.97.219.1) 359 ms 360 ms 366 ms 19 gate.moscow.belcom.net (206.82.160.1) 366 ms 368 ms 377 ms . . . Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1

1 0