September 1995 - Test - lists.nanog.org

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

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

25 Sep '95

This should be fixed now. Thanks for bringing this to my attention. > > A customer of ours 206.40.160.0/20 has been hit by > > the sprintlink filtering. This is just a datapoint. > > I can see it from here. It also looks like (AS 114) Sesquinet is not > CIDRizing very well. Humm - the /20 and all of its /24s and > inconsistant origin AS as well. > --asp(a)uunet.uu.net (Andrew Partan) > > Network Next Hop Metric LocPrf Weight Path > *>i206.40.160.0 137.39.24.34 1 100 0 114 ? > * 206.40.160.0/20 192.41.177.181 73 0 3561 114 i > * i 198.32.136.12 69 100 0 3561 114 i > *>i 137.39.24.34 100 0 114 3764 i > *>i206.40.161.0 137.39.24.34 1 100 0 114 ? > *>i206.40.162.0 137.39.24.34 1 100 0 114 ? > *>i206.40.163.0 137.39.24.34 1 100 0 114 ? > *>i206.40.164.0 137.39.24.34 1 100 0 114 ? > *>i206.40.165.0 137.39.24.34 1 100 0 114 ? > *>i206.40.166.0 137.39.24.34 1 100 0 114 ? > *>i206.40.167.0 137.39.24.34 1 100 0 114 ? > *>i206.40.168.0 137.39.24.34 1 100 0 114 ? > *>i206.40.169.0 137.39.24.34 1 100 0 114 ? > *>i206.40.170.0 137.39.24.34 1 100 0 114 ? > *>i206.40.171.0 137.39.24.34 1 100 0 114 ? > *>i206.40.172.0 137.39.24.34 1 100 0 114 ? > *>i206.40.173.0 137.39.24.34 1 100 0 114 ? > *>i206.40.174.0 137.39.24.34 1 100 0 114 ? > *>i206.40.175.0 137.39.24.34 1 100 0 114 ? > -- 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 asp＠uunet.uu.net 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 Vienna1-gw#trace 206.82.161.1 Type escape sequence to abort. Tracing the route to gate.almaty.belcom.net (206.82.161.1) 1 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 4 msec 4 msec 0 msec 2 sl-dc-8-H1/0-T3.sprintlink.net (144.228.10.41) [AS 1239] 104 msec 200 msec 16 msec 3 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) [AS 1239] 8 msec 0 msec 4 msec 4 sl-pen-1-H2/0-T3.sprintlink.net (144.228.10.34) [AS 1239] 4 msec 4 msec 4 msec 5 sl-pen-4-F0/0.sprintlink.net (144.228.60.4) [AS 1239] 12 msec 8 msec 8 msec 6 sl-computel-1-S0-T1.sprintlink.net (144.228.64.74) [AS 1239] 16 msec 16 msec 16 msec 7 gate.belcom.net (204.97.218.1) [AS 1239] 20 msec 20 msec 20 msec 8 ny-msw-256k.belcom.net (204.97.218.4) [AS 1239] 32 msec 28 msec 20 msec 9 gate.moscow.belcom.net (206.82.160.1) [AS 1794] 168 msec 172 msec 168 msec 10 204.97.219.1 [AS 1239] 184 msec 184 msec 184 msec 11 gate.moscow.belcom.net (206.82.160.1) [AS 1794] 188 msec 188 msec 196 msec 12 204.97.219.1 [AS 1239] 204 msec 200 msec 200 msec 13 gate.moscow.belcom.net (206.82.160.1) [AS 1794] 204 msec 216 msec 208 msec 14 204.97.219.1 [AS 1239] 220 msec 220 msec 220 msec 15 gate.moscow.belcom.net (206.82.160.1) [AS 1794] 224 msec 224 msec 236 msec 16 204.97.219.1 [AS 1239] 232 msec 236 msec 236 msec 17 gate.moscow.belcom.net (206.82.160.1) [AS 1794] 240 msec 240 msec 240 msec 18 204.97.219.1 [AS 1239] 252 msec 252 msec 252 msec 19 gate.moscow.belcom.net (206.82.160.1) [AS 1794] 260 msec 388 msec 260 msec 20 204.97.219.1 [AS 1239] 288 msec 272 msec 436 msec 21 gate.moscow.belcom.net (206.82.160.1) [AS 1794] 272 msec 276 msec 340 msec 22 204.97.219.1 [AS 1239] 288 msec * 292 msec 23 gate.moscow.belcom.net (206.82.160.1) [AS 1794] 292 msec 292 msec 292 msec 24 204.97.219.1 [AS 1239] 304 msec 304 msec 304 msec 25 gate.moscow.belcom.net (206.82.160.1) [AS 1794] 312 msec 312 msec 308 msec 26 204.97.219.1 [AS 1239] 324 msec 324 msec 324 msec 27 gate.moscow.belcom.net (206.82.160.1) [AS 1794] 328 msec 328 msec 328 msec 28 204.97.219.1 [AS 1239] 340 msec 340 msec 340 msec 29 gate.moscow.belcom.net (206.82.160.1) [AS 1794] 344 msec 364 msec 364 msec 30 204.97.219.1 [AS 1239] 376 msec 356 msec 368 msec

2 1

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

25 Sep '95

1 0

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

25 Sep '95

>Kai, it looks like Sprint is announcing this route. If you are a Sprint >customer, I don't recall Sprint saying anything about filtering its own >advertisements, either on NANOG or CIDRD. >Also, this is a typo, and it should be 206.82.160/22, no? Sean didn't say >anything about filtering 204/N either. >-dorian 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!"... This was not the right way to enforce the relevant RFCs, what's an RFC worth that even the Internic doesn't obey ? And , I beg everyone's pardon: I have only read the NANOG list for a few weeks now, could not make it to nearby Pittsburgh,PA (did this topic surface?) due to work pertinent to just this event, but I NEVER heard of this imminent route prefix filtering until now. Given the anti-trust questions this entire issue raises, I don't see a very bright future for the landscape of network operators at this time: If you are small, you can only get a small network assignment (slow start), as you will be running into the Great Wall "Internic" even with a request for a /22, and if you really succeed with your /22 or /20 assignment, you will have to discover that the conspiracy of the big 6 (laugh!) might have decided you are not worthy, and to go route what you got to yourself and don't expect them even wanting to know about it. If, on the other hand, you bravely get your network assignment from your friendly network provider, once you change this very provider, you are told you can't take the networks you got with you to the new provider, or in the event you are going multi-home (foreseeable for MANY larger Web/Slip/PPP-outfits in the next 6-9 months), you aren't allowed (or outright can't) announce those networks via the additional connection, too. I remember a time when 800 numbers belonged to the LD carriers, who had ranges of them assigned/reserved with the "800 number authority" , BellCore. What's left of those ? The lawyers came, technology came, and swept these anti-competitive practises away, and given the changes in switching/routing of telephony switches that were required to allow 800-number portability, I stop to see the 'impossibilitee' of getting just the same together for IP networks. Either we change, or the lawyers will change us, and I feel there is no longer a choice. Changing your network provider with all your attached networks shall be no less painful then changing the LD carrier on your residential telephone line, and this is exactly what even small/mid-sized (16-64 class-C net-strong) providers want. The steps we see now, are exactly the opposite of this (we won't see nice auto-configuring IPv6 networks for years!), which is deeply troubling to anyone who has ever read anti-trust decisions. If it takes a first stone to be thrown, or a walk with the iron cross, count me in, for the better of us all. --- 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

206.40.160.0/20
by Scott Mace 25 Sep '95

25 Sep '95

A customer of ours 206.40.160.0/20 has been hit by the sprintlink filtering. This is just a datapoint. Scott

2 1