- Test - lists.nanog.org

Please help me...
by Hyunseog Ryu/Brookfield/Norlight 08 Dec '99

08 Dec '99

Hi, folks Please help me. I need your help. If you have the right to access your router, please send me the result of following command at your router. Show ip bgp reg 1_7260 Maybe it will be long. But I need that. Actually we connected to GTE recently. But we are not sure that our routing is going to anywhere in Internet. I used DIGEX's looking glass home page. But we can not see any information for our GTE connection from there. Please help me. Hyun ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hyunseog Ryu Network Engineer/Applications Engineering Norlight Telecommunications, Inc. 275 North Corporate Drive Brookfield, WI 53045-5818 Tel. +1.262.792.7965 Fax. +1.262.792.7733

1 0

Re: Verio Decides what parts of the internet to drop
by George Herbert 08 Dec '99

08 Dec '99

Austin writes: >George writes: >>I am not sure whether the danger in opening up the B space for >>/17 blocks is particularly bad, but lacking a single consistent >>policy body with sufficient clue about both the Tier-1 backbone >>issues and the address allocation issues, it's hard to fault >>any given ISP for insisting on /16s in B space. >> > Sounds good, but what exactly does that mean? Does any end network >capable of justifying a /24 then get a routable chunk, thus blowing up the >tables? What if you could do it based upon traffic generation? That would be >difficult to verify, and the definition for 'large' amounts of traffic is >ever changing. > So, if we say that a /20 is a sufficiently large amount of space to >get a routable chunk, then they would be able to get it from ARIN anyway, >and we're back to square one. > In the far term as space becomes scarce we will need to find a solution >to wasted B space, but that is several years out. Perhaps by that time routers >will have so much memory and CPU as to make an extra ~4 million possible routes >negligible. The danger of /17 blocks in B space is limited to 64*256 more routes (16 k more, maximum). All at once that would be bad, but over time it would be reasonable. I would personally, were I setting route policy at a Tier 1, allow a /17 in B space, but there's no reason to try and force anyone else to accept that. As others don't right now and aren't inclined to, I would dissuade anyone from trying it as it's either going to be a royal pain or impossible to get routing for. Again, this is where not having a single policy body is killing us; some people get oddball blocks, somehow or another, and are then screwed on routability. I am most certainly not going to suggest radical surgery to the current way of doing it; right now, small places deserving of multihoming have to work at it, and you have to be clued enough to not step in a few holes like trying to portably subdivide a B. I am not sure that there's any obvious fix in the nearterm for those problems, which are avoidable. As long as they're avoidable I think the thing to do is to leave well enough alone. -george william herbert gherbert(a)crl.com Disclaimer: I speak for myself only, not my ISP, Cats, wife, or car.

7 6

Re: multi-homing
by Rich Braun 08 Dec '99

08 Dec '99

Roeland M.J. Meyer <rmeyer(a)mhsc.com> wrote on Dec 5: > For large capacity sites, colo is the only way, with potential self-homing > within two years. It just can't happen faster than that. Also, smaller > providers are out, because of public peering point congestion and that is > usually their only avenue. As someone else pointed out, us smaller providers often have multiple connections to tier-1's. In the past, it was likely that your friendly local ISP had only two tier-1 pipes and your regional had a big pipe into one of the NAPs. But given the overwhelming market consolidation of the tier-1's these days, independent regionals are more likely to have done what we've done: just go out and pay UUNET, GTE, et al whatever their toll is so we can guarantee high availability. Even at those high prices, we can still provide better service than any one of those companies can on its own within our market (i.e. it's no big deal to UUNET if their Boston PoP goes down for a few minutes, but it would be if _our_ Boston PoP went down). What I'm also finding these days is that, with the exception of UUNET, wholesale pricing is favorable to us. This business model has, in fact, recently sold well on Wall Street. A company called InterNAP just went public, and that's what they're doing. > Large providers, with their own private > dark-fiber network, leaving only last-mile traffic to the public Internet, > appears to be the only way to go <sigh>. I sure hope not...it takes even longer for them to bring up a new long-haul link than it does for us to upgrade or bring in a new local circuit to one of the major tier-1's. -rich

2 1

IOPS silent night press release
by Sean Donelan 07 Dec '99

07 Dec '99

IOPS.ORG has issued its press release about its "silent night" Y2K monitoring effort over the New Year's weekend. http://www.iops.org/iops-release.html Blame me, not merit, for the mention of nanog. It should NOT be taken as an endorsement or selection by nanog of special ISPs. But as a convient shorthand to refer to the group of ISPs from the nanog mailing list who are participating in some Y2K monitoring and notification efforts.

1 0

Wow, customer communication is catching on
by Sean Donelan 07 Dec '99

07 Dec '99

It looks like this customer communication thing is catching on. After three consective problem Sundays, Microsoft decided it might be a good idea to tell its network customers what was happening (no more nebuleous statements blaming the "Internet"). >From Microsoft's web page: >December 5 Connection Problems >As you may know, at 7 P.M. on the night of Sunday, December 5, there were >severe connection problems, which resulted in disconnections and lag. This was >because a reconfiguration in our datacenter was made at that time. Due to a >communication breakdown (which we are assuring will not happen again), word of >this change did not reach those of us who inform the players of such a >reconfiguration. Had we known about the reconfiguration, we would have warned >you not to play while it was going on. > >Adding to the problem, after the reconfiguration stopped, we gave the players >the "all clear" to re-enter the game. Unfortunately, within 20 minutes, there >was a datacenter problem, and this caused more connection disruptions. We are >still investigating the cause of this problem; it was not caused by another >reconfiguration but probably was a consequence of the previous one. > >We deeply apologize for these problems, both that a reconfiguration was made >during a busy time, and that you did not get adequate warning. > >NOTICE: Datacenter Reconfiguration December 6 > >In an effort to eliminate further connection disruptions in our datacenter, a >reconfiguration is being done late on December 6. This will begin at midnight >and end at 5 A.M., Pacific time. It is strongly advised that you do not play >AC during this time, as bad lag can hit at any moment. After 5 A.M., cautious >play is advised until we are sure the new configuration is stable.

1 0

More Specifics of Classful Nets
by Steve E. Powell 07 Dec '99

07 Dec '99

Greetings. I was following the Verio thread and just wanted to throw out another idea. It is not well thought out, but that is what mail groups are for. It appears that some of the reasons for blocking on prefix length are to encourage aggregation/summarization of routes and to protect against route explosion disaster due to human error or insane code. However, there are organizations that have been allocated blocks that are required to be carried as components. One reason is they are duel homed and another is the orgainzation's internet access spans multiple ISP's Why not have bgp do the work for us? What if the operator had the capability to accept routes based on the ratio of good prefixes to bad prefixes received where a bad prefix is defined as a more specific of a classful network or a classful prefix in swamp space. The idea would be that if ISP A was sensitive to prefix length, ISP B that announces routes to A could only expect ISP A to accept N bad routes providing M good routes are also advertised. A good route could be defined as a range of a certain prefix length that does adequate aggregation. Using some numbers, ISP B announces 10000 routes to ISP A. 2000 routes are of an adequate prefix length for ISP A to define as good. ISP A will allow one bad route for every 100 good routes that are advertised. ISP B wishes to announce 25 bad routes to ISP A. Only 20 routes are accepted by ISP A. The last 5 routes are not accepted until ISP B can convert some of the 8000 neutral routes into 500 good routes. Alternatively some good routes might be weighted as better, allowing for more announcements of bad routes. For example an ISP that could announce a 14 bit prefix out of swamp space would be rewarded more then one that announced a 16 bit prefix out of swamp space. If a customer of ISP B observes that their bad route is no longer routable over ISP A because B is announcing more bad routes, it will ISP B's responsibility to behave better by either aggregting better or removing the new bad components. Else ISP B will have to deal with the wrath of their customer. These ratios could be part of peering contracts. Each side would understand how many bad routes the neighbor will accept. It could also be stipulated contractually that a session would be torn down if an excessive number of bad routes were observed. I see no reason why excessive components cannot be treated the same way as a bad attribute. In this case I am defining excessive as hearing thousands of extra components, not a handful over the quota. This could be an alternative to having to carry every discrete route in a filter to protect oneself or filter on prefix length. Obviously, there are a lot of implementation/practical issues that I have not thought of. stevep

3 2

Question about UDP flooding
by Jongwon Kim(�� ) 07 Dec '99

07 Dec '99

Hi! Everyone. This is Jongwon Kim from Korea Telecom in seoul ,KOREA. We have a severe udp flooding form our server as follow. .Dec 7 10:53:15: %SEC-6-IPACCESSLOGP: list 102 permitted udp 203.234.254.1(43307) -> x.x.x.x(50753), 1 packet .Dec 7 10:53:16: %SEC-6-IPACCESSLOGP: list 102 permitted udp 203.234.254.1(43422) -> x.x.x.x(42084), 1 packet .Dec 7 10:53:17: %SEC-6-IPACCESSLOGP: list 102 permitted udp 203.234.254.1(43539) -> x.x.x.x(47889), 1 packet .Dec 7 10:53:18: %SEC-6-IPACCESSLOGP: list 102 permitted udp 203.234.254.1(43656) -> x.x.x.x(48642), 1 packet .Dec 7 10:53:19: %SEC-6-IPACCESSLOGP: list 102 permitted udp 203.234.254.1(43773) -> x.x.x.x(60407), 1 packet .Dec 7 10:53:20: %SEC-6-IPACCESSLOGP: list 102 permitted udp 203.234.254.1(43890) -> x.x.x.x(48339), 1 packet .Dec 7 10:53:21: %SEC-6-IPACCESSLOGP: list 102 permitted udp 203.234.254.1(44001) -> x.x.x.x(56690), 1 packet .Dec 7 10:53:22: %SEC-6-IPACCESSLOGP: list 102 permitted udp 203.234.254.1(44117) -> x.x.x.x(18638), 1 packet .Dec 7 10:53:23: %SEC-6-IPACCESSLOGP: list 102 permitted udp 203.234.254.1(44234) -> x.x.x.x(12099), 1 packet .Dec 7 10:53:24: %SEC-6-IPACCESSLOGP: list 102 permitted udp 203.234.254.1(44350) -> x.x.x.x(18927), 1 packet .Dec 7 10:53:25: %SEC-6-IPACCESSLOGP: list 102 permitted udp 203.234.254.1(44467) -> x.x.x.x(61352), 1 packet We'd like to know how do i limit the udp port use above 40,000 in the host . Any comment will be appreciated . TIA -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* KORNET Network Assistance Manager(Centural O&M Center) - Voice : 82-2-766-5902 -Fax : 82-2-766-5901 -E-Mail : knight(a)kix.net ====================================================================

1 0

Re: A call for the future. Was: Re: Verio Decides what parts of the internet to drop
by George Herbert 07 Dec '99

07 Dec '99

Kai Schlichting <kai(a)pac-rim.net> writes: >And what I'd really like to know: how many millions and billions were spent >by domestic telcos to accomodate and ultimately deflect anti-trust action >heading their way regaring local, 800 (and soon: cellular, at last!) >number portability ? (lets call it xNP) > >I mean: there must be an order of magnitude of increased HD space, >RAM and SS7 network bandwidth in use right now due to xNP. >Which means that the telcos probably asked their vendors to provide >such capabilities for their switches - and got what they asked for! > >Lets face it: if the US PSTN can accomodate tens of millions of essentially >freely-routed (well, the stubs of the SS7 network are certainly very static, >heh) phone numbers, it must be possible to scale the Internet beyond such >a small pisser: a 1/4 million routes in the BGP table. The issue isn't in storing hundreds of thousands, millions, or tens of millions of routes. This is, all things considered, a piece of cake. The issue is getting the route out of storage, for each packet coming through the router, at a rate of millions of packets per second for each core router. Each IP core router is doing about the same lookup work as the whole combined PSTN network is for all of its freely routed numbers. It is, or should be, quite viable... but not easy, as we've all found. -george william herbert gherbert(a)crl.com

1 0

Re: Verio Decides what parts of the internet to drop
by George Herbert 06 Dec '99

06 Dec '99

James Smith <jsmith(a)dxstorm.com> wrote: >Based on past experiences, I would say that the big backbone providers >shouldn't do any filtering at all. Then, the lower tiers can do all the >filtering they want, and still rely on default routing to send the packets >to the backbone. It may not be the prettiest way to route traffic, but >this would allow smaller ISPs to filter if they cannot afford buying >bigger equipment to hold all the routes. Since the tier-1 guys are the >glue of the Internet, they should be required to take everyone routes. There are numerous instances where that sort of policy would have blown up large chunks of the net. It's already happened. Part of the problem is that the Tier-1 guys can't buy bigger equipment to hold all the routes, either. When Sprint started this sort of filtering in 206.* I yelled and screamed, thinking it was foolish. History has proven us wrong. Without it, we'd be at route announcement levels which would blow up the available backbone hardware. Plus, without that sort of selective filtering, accidents can kill things right and left. I am not sure whether the danger in opening up the B space for /17 blocks is particularly bad, but lacking a single consistent policy body with sufficient clue about both the Tier-1 backbone issues and the address allocation issues, it's hard to fault any given ISP for insisting on /16s in B space. -george william herbert gherbert(a)crl.com Disclaimer: I am a CRL end user, not employee, and speak for myself only.

2 1

Re: MEDIA EVENT-Dec 3 1999 www.marspolarlander.org
by Dean Anderson 06 Dec '99

06 Dec '99

It must be his fault. ;-) Along with all the fiber cuts... Apparently, the FTL sled is pressurized. Or maybe, if you go FTL, you don't need pressurization. --Dean At 09:10 PM 12/5/1999 -0800, Eric Kozowski supposedly said: > >On Thu, Dec 02, 1999 at 05:03:36PM -0800, hardie(a)equinix.com wrote: >> >> As a former NASA geek, may I respectfully ask that you rephrase this to: >> >> "the Mars Polar Lander will land on Mars"? > >it appears sean knew something that nasa didn't.... > >;-> > >> sean(a)donelan.com said: >> > On Friday December 3, 1999 at 4:14pm EST the Mars Polar Lander crashes >> > into Mars. NASA and UCLA plan to make a live feed of the data download >> > available on the web site www.marspolarlander.org >> > >> > They are expecting 250 million visits tomorrow. >> > >> > Cable & Wireless appears to be the primary backbone for the event. > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0