- NANOG - lists.nanog.org

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

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

06 Dec '99

I think the more pertinent question is whether ARIN might give out parts of former class B space in blocks smaller than /16. If so, then the routing policies are unreasonable. I tend to think that rigidly following the classful structure is unwise, since one can expect over time that CIDR will result in many Class C & B networks becoming superneted, while A's and B's will most likely be subnetted. The supernetting C's and B's benefits the size of the route table, while subnetting A's and B's allows better space utilization. To assume or make policy that there won't be subneting of A's and B's seems to be counterproductive. Thats where much of the better address space utilization was supposed to come from. It would be nonsensical for ARIN to make allocations based on arbitrary ISP's routing policies. Rather, ISP's should make routing policies based on allocation policies. ISP's can join ARIN to have some input on its policies. Seems we just got our invoice last week... --Dean Around 02:17 AM 12/4/1999 -0500, rumor has it that jlewis(a)lewis.org said: > >On Fri, 3 Dec 1999 bmanning(a)vacation.karoshi.com wrote: > >> > As for BSDI, is it possible for them to trade their /17 in to ARIN for a >> > more likely routable one? >> >> NO. Arin can't presume to know what is or is not routable. > >Assuming route filter policies are based on what the IP registries are >giving out, the registries should be able to make at least good guesses as >to which allocations will be routable and which will not. Since the >registries have no control over backbone BGP filters, they can't guarantee >routability. If there's not a good chance of their allocations being >routable, then what's the point in allocating space? > >---------------------------------------------------------------------- > Jon Lewis *jlewis(a)lewis.org*| Spammers will be winnuked or > System Administrator | nestea'd...whatever it takes > Atlantic Net | to get the job done. >_________http://www.lewis.org/~jlewis/pgp for PGP public key__________ > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

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

06 Dec '99

I would imagine some sort of Internet Authority on Routing. There are already quite a few authorities for other such things on the Net. But perhaps a better solution would be for everyone to register with a Routing Authority. We already require any one that wants to use a domain name to register, and if you want a block of IP space or a BGP number you have to register with ARIN. I realize there are registries like RADB and RIPE, but these don't seem to be used to their full potential. Some backbone providers still enter in route filters manually, which seems a little obsolete considering the number of routes being advertised. -- James Smith, CCNA Network/System Administrator DXSTORM.COM http://www.dxstorm.com/ DXSTORM Inc. 2140 Winston Park Drive, Suite 203 Oakville, ON, CA L6H 5V5 Tel: 905-829-3389 (email preferred) Fax: 905-829-5692 1-877-DXSTORM (1-877-397-8676) It's Unix or nothing! On Mon, 6 Dec 1999, Scott Huddle wrote: > required by whom? > > -scott > > At 01:11 PM 12/06/1999 -0500, James Smith 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. > > > > > > > >-- > >James Smith, CCNA > >Network/System Administrator > >DXSTORM.COM > > > >http://www.dxstorm.com/ > > > >DXSTORM Inc. > >2140 Winston Park Drive, Suite 203 > >Oakville, ON, CA L6H 5V5 > >Tel: 905-829-3389 (email preferred) > >Fax: 905-829-5692 > >1-877-DXSTORM (1-877-397-8676) > > > >It's Unix or nothing! > > > >On Mon, 6 Dec 1999, Andrew Bender wrote: > > > > > > > > Dr. Li wrote: > > > > Date: Fri, 03 Dec 1999 23:35:18 -0800 > > > > From: Tony Li <tony1(a)home.net> > > > > Subject: Re: Verio Decides what parts of the internet to drop > > > > > > > > I'll also note that this would also decrease the pressure on the address > > > > space. No need to go get a /19 if I can get my /23 globally advertised. > > > > : > > > > : > > > > The correlation with route flap should be re-examined. I suspect > > that this > > > > is no longer a driving force and is more than adequately compensated > > for by > > > > having flap damping parameters that scale geometrically with the prefix > > > > length. > > > > > > To state an obvious extension of these ideas: > > > > > > Without relief, space registrants are thus incented to (continue to) > > subvert the > > > spirit of the allocation scheme in order to overcome its deficiencies. > > In doing > > > so, a trend toward lower (shorter) "characteristic prefix length" is > > created by > > > networks that would otherwise be suited by smaller allocations closer > > to their > > > actual occupancy. > > > > > > Metastability in interdomain routing is currently maintained by an > > algorithm [1] > > > that suppresses oscillations to an acceptable level, deferring treatment of > > > another "interesting problem" [2,3]. If distinctions between highly > > aggregated > > > networks and large, underoccupied ones are progressively obscured, > > strategies > > > that inversely correlate prefix length with oscillatory period may be > > > circumvented. > > > > > > Past experience [*] suggests that further detraction from the elusive > > "global > > > routing stability" is more poignant and at greater issue to operators > > than the > > > combined problems of address occupancy and table population. > > > > > > Indeed, it seems that a review of operational policy is in order. > > > > > > Regards, > > > Andrew Bender > > > Total Network Solutions, Inc. > > > > > > [1] C. Villamizar, R. Chandra, R. Govindan. RFC 2439. > > > [2] K. Varadhan, R. Govindan, and D. Estrin. Persistent route > > oscillations in > > > inter-domain routing. USC/Information Sciences Institute, 1996. > > > [3] T. Griffin, G. Wilfong. An Analysis of BGP Convergence Properties. > > Computer > > > Communication Review, October 1999. > > > [*] http://www.techweb.com/wire/story/TWB19991202S0002 > > > > > > > > > >

1 0

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

06 Dec '99

Dr. Li wrote: > Date: Fri, 03 Dec 1999 23:35:18 -0800 > From: Tony Li <tony1(a)home.net> > Subject: Re: Verio Decides what parts of the internet to drop > > I'll also note that this would also decrease the pressure on the address > space. No need to go get a /19 if I can get my /23 globally advertised. > : > : > The correlation with route flap should be re-examined. I suspect that this > is no longer a driving force and is more than adequately compensated for by > having flap damping parameters that scale geometrically with the prefix > length. To state an obvious extension of these ideas: Without relief, space registrants are thus incented to (continue to) subvert the spirit of the allocation scheme in order to overcome its deficiencies. In doing so, a trend toward lower (shorter) "characteristic prefix length" is created by networks that would otherwise be suited by smaller allocations closer to their actual occupancy. Metastability in interdomain routing is currently maintained by an algorithm [1] that suppresses oscillations to an acceptable level, deferring treatment of another "interesting problem" [2,3]. If distinctions between highly aggregated networks and large, underoccupied ones are progressively obscured, strategies that inversely correlate prefix length with oscillatory period may be circumvented. Past experience [*] suggests that further detraction from the elusive "global routing stability" is more poignant and at greater issue to operators than the combined problems of address occupancy and table population. Indeed, it seems that a review of operational policy is in order. Regards, Andrew Bender Total Network Solutions, Inc. [1] C. Villamizar, R. Chandra, R. Govindan. RFC 2439. [2] K. Varadhan, R. Govindan, and D. Estrin. Persistent route oscillations in inter-domain routing. USC/Information Sciences Institute, 1996. [3] T. Griffin, G. Wilfong. An Analysis of BGP Convergence Properties. Computer Communication Review, October 1999. [*] http://www.techweb.com/wire/story/TWB19991202S0002

2 1

multi-homing
by Dana Hudes 06 Dec '99

06 Dec '99

The pressure is on to use co-location service only from Big Players. Indeed, remember the big fight over Exodus peering arrangements? Someone (GTE?) decided that Exodus should pay them for transit and pulled peering. since no other large network pulled such stunt the result was that GTE customers were inconvenienced more than Exodus customers. The message is loud and clear. If you want your server farm to have good access, put it in a good co-location facility in the US run by (or connect your co-located equipment to) a very large provider who has good redundancy not only of their network as a whole but of their colo facility (a co-lo facility with only one WAN circuit does not have good redundancy even if the LAN is exceedingly good and fault-tolerant etc.). Outside the US, the filtering of long prefixes doesn't seem to be as much of a problem -- but nobody wants to see an announcement from their peer of a /16 broken into individual /24 all with the same next hop. Even when router memory and CPU capacity are not near limits, it is annoying. (sorry that the previous version went out in MIME format, I had replied to someone else's MIME formatted message). Dana

6 7

More sites to shutdown over new year's
by Sean Donelan 06 Dec '99

06 Dec '99

Yet more sites are planning to shutdown part or all of their networks, or disconnect the networks over the New Year's weekend. http://www.zdnet.com/intweek/stories/news/0,4164,2404384,00.html

1 0

Re: Mars lander (Re: How to achieve application reliability)
by brett watson 06 Dec '99

06 Dec '99

> How can you be so sure the hosts you were hitting with pings and > traceroutes were the same hosts? It's quite possible smoke and mirrors > were in between (smoke: web directors answering the pings... mirrors: > anycast addressing with policy routing). > > It's getting pretty wierd to debug IP these days... sure, i was admittedly making some blind assumptions. i didn't check any dns entries. then again we've all seen a few other "media events" fall over and die because folks haven't done the server/os/app side very well. -brett

1 0