- Test - lists.nanog.org

RE: Service Provider Exchange requirements
by Mike Duckett 24 Oct '00

24 Oct '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'll give a few more hints as to what I'm looking for.. How about ethernet versus ATM? With VLANs and high speed such as Gig/10Gig, I can get speed and one to many arrangements (at least for lower speeds). Should Ethernet be point to point or optionally multiaccess in nature? Or, what about MPLS? With MPLS, service provider connections can be established without concern for underlying media (e.g., ethernet, POS, ATM). Is Diff-Serv or ATM QoS a requirement or can 85-90% of requirements be met with loss/latency service as the baseline? What special arrangements should be made for hosting (e.g., local caching or streamers)? Yes, I'm stretching here a bit. - -----Original Message----- From: bmanning(a)vacation.karoshi.com [SMTP:bmanning@vacation.karoshi.com] Sent: Sunday, October 22, 2000 5:24 PM To: mduckett(a)bellsouth.net Cc: 'nanog(a)merit.edu' Subject: Re: Service Provider Exchange requirements > What switching and/or service characteristics would you require > such that an exchange point would be desirable (e.g., media types, > switch fabric, route servers, multicast services, SLAs, ..)? > Kind of depends on what you want out of your exchange and who your target marrket(s) are. Factor in budgets, (financial, space, environmental...) and you should have winnowed down the conceivable to the likely. Enjoy. - --bill -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBOfNoT5uyh6FekS+1EQI8VgCglnkgxLEuT5LYJAoqsYRFd67JejEAn1VJ jOz0O7zVxclHYHxuSQlqvskL =A7/Z -----END PGP SIGNATURE-----

6 8

Re: 64 Megs of Memory... and could this be the hacker?
by Mark Milhollan 24 Oct '00

24 Oct '00

>> >> ``maximum-prefix n p warning-only'' along with a log analyzer that >> >> recognizes the warning, are perhaps a better pair of friends. >> >How so? You recognize the warning, now what? >> Deliver the notice to NOC personel, via whatever means. Perhaps they'll >> terminate the session. Perhaps not. Granted in warning-only mode the >> session won't come back up by itself. > >And how exactly is this better than a maximum-prefix clause which drops >routes instead of dropping the session? The previous, unquoted, message said that having the session drop automatically wasn't always a desireable action. I provided an alternative. The external logic can be more complex than the logic present in IOS. I provided _one_ possible action. It could very well shutdown the session. It could do many things, any of which would be custom and could take into account the structure of the provider. It's also possible to drop the warning-only clause, allowing IOS to drop the BGP session _and_ have log watching tools do other things.

1 0

Re: 64 Megs of Memory...
by Mark Milhollan 23 Oct '00

23 Oct '00

[Sorry for the delay.] Dan Hollis writes: >On Fri, 13 Oct 2000, Mark Milhollan wrote: >> ``maximum-prefix n p warning-only'' along with a log analyzer that >> recognizes the warning, are perhaps a better pair of friends. > >How so? You recognize the warning, now what? Deliver the notice to NOC personel, via whatever means. Perhaps they'll terminate the session. Perhaps not. Granted in warning-only mode the session won't come back up by itself.

3 2

RE: Service Provider Exchange requirements
by Roeland M.J. Meyer 23 Oct '00

23 Oct '00

> As for jumbo frames, will someone remind me what the benefit > of using a > larger MTU on the edges than you have in the core is? Is the > edge device > going to aggregate 6 1500-byte packets into a single > 9000-byte jumbo frame > for me? It's an internal LAN system issue on the edge. In a distributed system environment, having app servers talk to data servers, using jumbo packets, makes for higher system throughput. The Jumbo packets should never be seen at the border, however. In fact, the data servers themselves should never be seen fromn the border <g>.

1 0

Re: Cheapest ethernet switch with monitor/mirror port?
by Henry Yen 23 Oct '00

23 Oct '00

On Sun, Oct 22, 2000 at 11:28:27AM -0400, Stewart MacLund wrote: > Hm. I looked at both the Cisco 3548 and the Intel 460T. In my case, > at least, the Cisco was cheaper per port, even with the Enterprise > software load on the Cisco... www.datacommwarehouse.com lists the 3548 with enterprise s/w at $3,630US. a 16-port 460t lists for $830US. a 24-port 460t lists for $1110US. cheaper out of the box as well as cheaper per port, or did i miss something? what price are you finding for a cisco3548? it appears allied telesyn has a 24-port fully managed switch for $740 (AT-8126XL-10), as well as a 16-port model (AT-8118), and although i'd be surprised if port monitoring weren't a feature, the a-t website doesn't seem to specifically mention it. > Henry Yen wrote: > > On Fri, Oct 20, 2000 at 05:51:25AM -0700, Dan Hollis wrote: > > > Looking for the cheapest ethernet switch with a monitor/mirror port. > > > > Intel 460T switch. http://www.intel.com/network/products/exp460t.htm > > 802.1p, 802.1Q, managed, link aggregation, gigabit or fiber module, > > embedded webserver, 1U size, around $830 (12-port). > > (well, ok, it may not be *the cheapest*, but...) -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York

1 0

Reminder: Talk on Tuesday afternoon
by J. Scott Marcus 22 Oct '00

22 Oct '00

Sorry if this post is repetitive - I'm re-sending because some people seem not to have received the original. Cheers, - Scott >>>Date: Fri, 13 Oct 2000 05:48:10 -0400 >>>To: nanog(a)merit.edu >>>From: Ira Richer <richer(a)cnri.reston.va.us> >>>Subject: Invitation >>> >>> >>>The next IOPS meeting will be held "in tandem" with the upcoming >>>NANOG meeting in Washington, DC. At 4:00 pm on Tuesday, October >>>24, Scott Marcus of Genuity will give a talk on "Recent ITU Actions >>>on International Internet Charging." NANOG attendees are welcome. >>>The talk will be at the Renaissance Hotel, where the NANOG meeting >>>is being held. >>> >>>Also, if any ISP has potential interest in joining IOPS and in >>>attending the IOPS meeting on the 25th, please contact me. FYI, >>>some time at this meeting will be spent learning more about ISACs >>>(Information Sharing and Analysis Centers). ISACs for critical >>>infrastructure are encouraged by Presidential Decision Directive >>>PDD 63. They exist now for the banking/financial-services industry, >>>and for the telecommunications industry; others are being >>>considered by the electric power industry and by some "information >>>technology" companies. >>> >>>Ira Richer >

1 0

Service Provider Exchange requirements
by Mike Duckett 22 Oct '00

22 Oct '00

What switching and/or service characteristics would you require such that an exchange point would be desirable (e.g., media types, switch fabric, route servers, multicast services, SLAs, ..)?

2 1

RE: DOS Attacks and reliable network contact data.
by rdobbins＠netmore.net 22 Oct '00

22 Oct '00

That's why MPLS is such a Good Thing - attacks which would cripple 72xx-series & 75xx-series routers can actually be handled without flinching, as the CPU overhead is reduced tremendously by making use of the switch's muscle and efficiency. One of my customers was getting DoSed all the time; his router (7206, NPE-150) was seeing 75%-100% CPU utilization during these times (average was 50%). We took that 7206 and used it as the MLS-RP for a Catalyst 5509 he had lying around (Sup-III, NFFC II), and now he just hums along when they try and zorch his router. An attack which would max him out at 100% before now drives his CPU to perhaps 25%. His -average- CPU load went down from the aforementioned 50% to 5%, all without changing the router in any way other than turning it into the layer-3 engine for the switch. A pretty decent solution, for having been put together from existing equipment. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: Basil Kruglov [mailto:basil@cifnet.com] Sent: Saturday, October 21, 2000 4:05 PM To: nanog(a)nanog.org Subject: Re: DOS Attacks and reliable network contact data. On Sat, Oct 21, 2000 at 05:14:53PM -0400, Jason Slagle wrote: > 21259901:21259901(0) ack 1412091198 win 2144 <mss 536> > 22:30:52.822459 255.255.255.255.80 > 205.133.127.30.6667: R 0:0(0) ack > 2473479669 win 0 > 22:30:52.822711 210.251.128.255.80 > 205.133.127.30.6667: R 0:0(0) ack > 529389642 win 0 > 22:30:52.822962 195.53.123.0.80 > 205.133.127.30.6667: . ack 1625272127 > win 9112 (DF) > 22:30:52.823213 152.158.37.127.80 > 205.133.127.30.6667: R 0:0(0) ack > 1362286194 win 0 We do get this sort of crap daily at least 5 times a day, distributed tcp/ack, tcp/syn, etc, over 40-50Kpps+ sometimes.. my list of over ~230 slave networks (in /24 format). Kids are after taking CPUs in routers out and not killing you with hundrends and hundreeds of Mbps, high-pps attacks are also very nasty, and of course everything is over some stupid IRC issue. > Their exists no reliable way to get the contact of a network without first > querying arin, then apnic, then the .jp registry for instance. This is a > royal PITA and is in no way scriptable that I can see. What is neat is all those 'slaves' are spoofing inside their own /24 or whatever allocation they sit in, and it's very hard to persuade somebody to look into this as they claim those ip addresses are not in use or have only routers/switches and there is no way those devices could've generated a [d]DoS attack. -- Basil Kruglov [BK252-ARIN] Network Engineering and Security CIFNet, Inc.

1 0

RE: DOS Attacks and reliable network contact data.
by rdobbins＠netmore.net 22 Oct '00

22 Oct '00

Port 6667 is used quite a bit for IRC traffic, FYI. I think one of my customers got hit with 12mb/sec of this last night, too - didn't do anything, as I've done all the usual stuff to avoid becoming an amplifier. It ran into ACLs in one of my MPLS-enabled switches, which pretty much just ate it. The attack was definitely distributed, because it came in through two of my upstreams. Based upon purely subjective experience, the info I get back from whois from ARIN, APNIC, etc. has been looking more uniform, of late; I should think that some good regexp might do the trick. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: Jason Slagle [mailto:raistlin@tacorp.net] Sent: Saturday, October 21, 2000 2:15 PM To: nanog(a)nanog.org Subject: DOS Attacks and reliable network contact data. I've seen an increase in DOS attacks over the past week or so, of a form I really haven't encountered before. Below are some logs. 22:30:52.821705 255.255.255.255.80 > 205.133.127.30.6667: R 0:0(0) ack 1062615418 win 0 22:30:52.821956 202.172.120.255.80 > 205.133.127.30.6667: R 0:0(0) ack 3046052966 win 0 22:30:52.822208 168.17.227.0.80 > 205.133.127.30.6667: S 21259901:21259901(0) ack 1412091198 win 2144 <mss 536> 22:30:52.822459 255.255.255.255.80 > 205.133.127.30.6667: R 0:0(0) ack 2473479669 win 0 22:30:52.822711 210.251.128.255.80 > 205.133.127.30.6667: R 0:0(0) ack 529389642 win 0 22:30:52.822962 195.53.123.0.80 > 205.133.127.30.6667: . ack 1625272127 win 9112 (DF) 22:30:52.823213 152.158.37.127.80 > 205.133.127.30.6667: R 0:0(0) ack 1362286194 win 0 Lots and lots of TCP ACK's from broadcast addresses. Looks like a new kind of indirect SYN/ACK flood based on broadcast addresses. Which led me to sort through my logs and do my best to get the amps shut down, which led me to my current problem/gripe. Their exists no reliable way to get the contact of a network without first querying arin, then apnic, then the .jp registry for instance. This is a royal PITA and is in no way scriptable that I can see. Am I wrong? Does such a thing exist? What can we do bout these attacks. Jason --- Jason Slagle - CCNA - CCDA Network Administrator - Toledo Internet Access - Toledo Ohio - raistlin(a)tacorp.net - jslagle(a)toledolink.com - WHOIS JS10172 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GE d-- s:+ a-- C++ UL+++ P--- L+++ E- W- N+ o-- K- w--- O M- V PS+ PE+++ Y+ PGP t+ 5 X+ R tv+ b+ DI+ D G e+ h! r++ y+ ------END GEEK CODE BLOCK------

2 1

RE: decreased caching efficiency?
by Roeland M.J. Meyer 22 Oct '00

22 Oct '00

Christian, I invite you to www.photoloft.com Each album is dynamic and the site uses FlashPix technology. Have fun with it. > -----Original Message----- > From: Christian Kuhtz [mailto:ck@arch.bellsouth.net] > Sent: Friday, October 20, 2000 12:14 PM > To: nanog(a)merit.edu > Subject: Re: decreased caching efficiency? > > On Fri, Oct 20, 2000 at 11:59:58AM -0700, Travis Grant wrote: > [..] > > Commerce sites are also dependent on dynamic technology > that cannot be > > cached. Although you will find sites that are entirely > static (buy.com & > > etoys.com) you will generally find that these models are > based on volume and > > that the majority of these sites have never seen a dollar > in profit. However > > the profitable boutique type sites like eStyle.com, are > entirely dynamic. > > Margins are protected by a contractual product line. When > you place an > > order, a query verifies inventory prior to final checkout. > In addition, > > product pages indicate whether items are in stock or not. > You cant cache > > these types of sites. > [..] > > Each and every button, product image etc could be cached, > regardless of the > dynamic nature of the website. Images cost cycles, bw. > > [..] > > Most caching implementations will cost way more than the > bandwidth costs > > they avoid. > > You get no argument there ;-). I never felt that you could > ever justify > caching in terms of bandwidth savings. You can only justify > in terms of > improving a users experience. And in that sense, you are > giving considerable > resources to a content origin, and a free service to them. > > That's why the CDN strategy is much more attractive, where > you have a hosting > relationship of some kind with the content origin. > > [..] > > load on the DB servers. But TTLs will usually have to be > set pretty low (2 > > seconds) in order to do this and the technologies will have > to be catered to > > web development environments (like cacheflow and ASP). > [..] > > Hmm, if you cache what I suggest above, that's not really > neccessary... No? > > Cheers, > Chris > > -- > Christian Kuhtz > Architecture, BellSouth.net > <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm > Atlanta, GA > "Speaking > for myself only." >

1 0