- NANOG - lists.nanog.org

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by salo＠msc.edu 16 Dec '96

16 Dec '96

1 0

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by Sanjay Dani 16 Dec '96

16 Dec '96

> From: dvv(a)sprint.net (Dima Volodin) > More of that - at least one site uses one of our hosts as a target of > pings for measuring "Internet health". > We consider this to be an abuse of our resources Perhaps they are evaluating you against other backbone providers by sending an icmp packet every few minutes. Is that still considered abuse or an incentive to you to potentially gain business by keeping your sites up all the time? Our potential clients evaluate us by visiting our web site to just see the performance. Sanjay.

1 0

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
by salo＠msc.edu 16 Dec '96

16 Dec '96

> Subject: Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... > To: doleary(a)cisco.com (dave o'leary) > Date: Mon, 16 Dec 1996 16:00:09 -0500 (EST) > Cc: mleber(a)he.net, forrestc(a)iMach.com, nathan(a)netrail.net, joe(a)Navigist.Com, > nanog(a)merit.edu > From: dvv(a)sprint.net (Dima Volodin) > > More of that - at least one site uses one of our hosts as a target of > pings for measuring "Internet health". > We consider this to be an abuse of our resources How many ping per second do you see? How many pings per second can your host handle? Your network? > and, most probably, we will disable any external > traffic we find inappropriate for this or other hosts. So, do I understand you correctly as saying that you have no interest in helping your customers understand the state of your service? -tjs "Those darn customers, things would work just fine, if they didn't keep using the network..."

2 1

Re: [Announce] traceroute sites
by Jason Fesler 16 Dec '96

16 Dec '96

Likewise, http://www.calweb.com/cgi-bin/trace has existed for quite a while. One of my next goals is to start saving traceroute data that it gets it with, and have it build a map with the given data.. Hard part will be making it pretty when starting with just ascii data :-). >> >traceroute url: >> >http://www.cwix.net/cgi-bin/trace -- Jason Fesler jfesler(a)calweb.com Internic: 'whois jf319' Admin, CalWeb Internet Services http://www.calweb.com Junk email returned, in bulk, back to sender; w/copies to all postmasters. You got junk mail problems? Use Eudora Pro, MSIE's mail, or 'man procmail'.

3 2

Re: Nanog list uncharacteristically quiet?
by Paul Ferguson 15 Dec '96

15 Dec '96

This is pretty much consistent with flow-data that I have seen from other places in the net. - paul At 12:04 PM 12/15/96 -0700, Brett D. Watson wrote: > >core1.sjc1#sh ip ca f >IP packet size distribution (219413380 total packets): > 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 > .000 .388 .040 .014 .017 .014 .023 .013 .030 .026 .014 .010 .004 .004 .004 > > 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 > .044 .003 .143 .000 .102 .097 .000 .000 .000 .000 .000 > >IP Flow Switching Cache, 22757 active, 42779 inactive, 9734878 added > 0 flows exported, 0 not exported, 0 export msgs sent > 5 cur max hash, 13 worst max hash, 20773 valid buckets > 0 flow alloc failures > statistics cleared 36123 seconds ago > >Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) >-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow >TCP-Telnet 15886 0.4 159 78 70.1 97.7 44.3 >TCP-FTP 175819 4.8 6 72 31.0 6.1 45.9 >TCP-FTPD 34862 0.9 280 591 270.4 82.3 44.7 >TCP-WWW 5135690 142.1 20 391 2848.3 12.3 45.9 >TCP-SMTP 179682 4.9 18 178 94.0 7.1 45.8 >TCP-X 838 0.0 157 127 3.6 86.3 45.4 >TCP-BGP 4298 0.1 90 113 10.7 322.8 39.4 >TCP-Frag 679 0.0 19 733 0.3 22.0 45.2 >TCP-other 399609 11.0 181 411 2008.3 65.7 44.9 >UDP-DNS 2411976 66.7 5 132 339.2 14.9 45.5 >UDP-NTP 164740 4.5 2 76 9.4 1.2 45.9 >UDP-TFTP 2 0.0 2 69 0.0 0.0 59.8 >UDP-Frag 42 0.0 2747 173 3.1 436.4 35.7 >UDP-other 759665 21.0 22 227 466.6 7.5 45.5 >ICMP 429570 11.8 7 88 93.3 19.8 44.7 >IGMP 85 0.0 1707 102 4.0 1670.4 6.2 >IPINIP 370 0.0 13 114 0.1 55.0 45.1 >GRE 119 0.0 245 139 0.8 1810.6 4.0 >IP-other 1490 0.0 31 123 1.2 64.0 43.9 >Total: 9715422 268.9 23 365 6256.0 15.3 45.7 > > > web flows obviously beat the pants off of most everything else (big >surprise). it seems odd to me that idle seconds/flow are pretty much >equal regardless of the protocol. bytes/packet is under 500 >(average) for just about all protocols. lots of tiny packets >floating around. > >-brett >

1 0

Re: Nanog list uncharacteristically quiet?
by Vadim Antonov 15 Dec '96

15 Dec '96

>Here's something to chew on. As an end-node site who has recently become >triply-homed I've been wondering whether it would be useful if routers had >a way of making a route selection based on output queue levels. Not. That will cause reordering of packets, and so trigger false TCP retransmits. >Ie., let's say I have 2 paths to a destination of equal as-path distance >through neighbor A and neighbor B. Based on recent discussion it sounds >like IOS will send the packet to the neighbor with the lowest IP address. Not. This is a default tie-breaking rule in cisco's BGP implementation, and doesn't have anything to do with packet forwarding. --vadim

5 5

Re: Nanog list uncharacteristically quiet?
by Brett D. Watson 15 Dec '96

15 Dec '96

> On Sat, 14 Dec 1996, Mike Leber wrote: > > |} Has anybody collected stream duration data? What does the distribution > |} look like? 98% of streams last how long? (I bet less than 5 minutes) > |} I think something like this was brought up at the Ann Arbor NANOG. > > What are you calling a 'stream' ? People are starting to collect flow > data in quite a few places with some interesting results. > > > -jh- > we've been running netflow for a few weeks now. we dont' have all the data collection working yet and havent' done any real analysis yet but in case anyone is interested in a single viewpoint from our backbone, here's a snapshot of the netflow cache on our core router in san jose: core1.sjc1#sh ip ca f IP packet size distribution (219413380 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .388 .040 .014 .017 .014 .023 .013 .030 .026 .014 .010 .004 .004 .004 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .044 .003 .143 .000 .102 .097 .000 .000 .000 .000 .000 IP Flow Switching Cache, 22757 active, 42779 inactive, 9734878 added 0 flows exported, 0 not exported, 0 export msgs sent 5 cur max hash, 13 worst max hash, 20773 valid buckets 0 flow alloc failures statistics cleared 36123 seconds ago Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 15886 0.4 159 78 70.1 97.7 44.3 TCP-FTP 175819 4.8 6 72 31.0 6.1 45.9 TCP-FTPD 34862 0.9 280 591 270.4 82.3 44.7 TCP-WWW 5135690 142.1 20 391 2848.3 12.3 45.9 TCP-SMTP 179682 4.9 18 178 94.0 7.1 45.8 TCP-X 838 0.0 157 127 3.6 86.3 45.4 TCP-BGP 4298 0.1 90 113 10.7 322.8 39.4 TCP-Frag 679 0.0 19 733 0.3 22.0 45.2 TCP-other 399609 11.0 181 411 2008.3 65.7 44.9 UDP-DNS 2411976 66.7 5 132 339.2 14.9 45.5 UDP-NTP 164740 4.5 2 76 9.4 1.2 45.9 UDP-TFTP 2 0.0 2 69 0.0 0.0 59.8 UDP-Frag 42 0.0 2747 173 3.1 436.4 35.7 UDP-other 759665 21.0 22 227 466.6 7.5 45.5 ICMP 429570 11.8 7 88 93.3 19.8 44.7 IGMP 85 0.0 1707 102 4.0 1670.4 6.2 IPINIP 370 0.0 13 114 0.1 55.0 45.1 GRE 119 0.0 245 139 0.8 1810.6 4.0 IP-other 1490 0.0 31 123 1.2 64.0 43.9 Total: 9715422 268.9 23 365 6256.0 15.3 45.7 web flows obviously beat the pants off of most everything else (big surprise). it seems odd to me that idle seconds/flow are pretty much equal regardless of the protocol. bytes/packet is under 500 (average) for just about all protocols. lots of tiny packets floating around. -brett

1 0

Re: [Announce] traceroute sites
by William Allen Simpson 15 Dec '96

15 Dec '96

It would be most helpful if the nanog pages had links to these tools.... WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: Nanog list uncharacteristically quiet?
by Jeffrey Payne 15 Dec '96

15 Dec '96

>On Sat, 14 Dec 1996, Mike Leber wrote: > >|} Has anybody collected stream duration data? What does the distribution >|} look like? 98% of streams last how long? (I bet less than 5 minutes) >|} I think something like this was brought up at the Ann Arbor NANOG. > Some folks from Ipsilon did an interesting paper on IP flow (stream?) durations for ISMA in Feb...its at: http://www.ipsilon.com/staff/pn/papers/isma96.html -jp ---------------------------------------------------------------------- Jeffrey Payne Voice:206.674.2364 GM, Technical Operations FAX: 206.674.2696 Progressive Networks, Inc http://www.prognet.com ----------------------------------------------------------------------

3 2

Re: Nanog list uncharacteristically quiet?
by Chris A. Icide 14 Dec '96

14 Dec '96

At 11:24 AM 12/14/96 -0800, Chris Caputo wrote: >Here's something to chew on. As an end-node site who has recently become >triply-homed I've been wondering whether it would be useful if routers had >a way of making a route selection based on output queue levels. Ie., >let's say I have 2 paths to a destination of equal as-path distance >through neighbor A and neighbor B. Based on recent discussion it sounds >like IOS will send the packet to the neighbor with the lowest IP address. >This is nice and predictable, but I wonder if it would be helpful to have >an option that makes this decision be based on current output load of the >link to each neighbor rather than IP address. > >Note, I am not suggesting in any way that this alter advertisements and >causing flapping, I am only wondering about outgoing packets. > The problem that jumps out immediately is that of oscillating loading of an interface. As soon as one interface becomes more loaded than the other, what decision process are you going to make to move only a small amount of traffic to the other interface? If you don't do this in small steps, then you will surely experience an oscillation between the two (or three) interfaces as the lowest load interface immediately becomes the highest loaded interface due to the decision to send traffic that way instead. Also, remember that not only do you have to make the decision on your side, but you also must let your peers know that you want your incoming traffic to move also. So you now must have some method of advertising your desires to the rest of the world. Currently your best choice is to manually develop route-maps which will balance both incoming and outgoing traffic on each interface. I definately have some thoughts on the above idea, and how something like that may be accomplished, but they are so very undeveloped that this is not the time or place to display my lack of knowledge. I'd prefer to put it all down on "paper" somewhere and then submit the idea if anyone who really understands all this is interested. I'm sure none of my ideas are original. Chris A. Icide Nap.Net

1 0