April 1998 - Test - lists.nanog.org

Re: Traffic Shapping
by Ehab Hadi 25 Apr '98

25 Apr '98

I think traffic shaping is very importent. I agree to the point that the new traffic shaping approches tends to shape on near the edges, but that would not prevent applying such approches in the core especially if its an interprise net. The shapping implemintation preferred to be implemented in switch because the hardware is simply fast and efficient. Jeremy, Would you please specify what kind of Cisco platform that you are using? Ehab Hadi Northern Telecom. Interprise Networking Ottawa, Ontario K1Y 4H7 Canada >From owner-nanog(a)merit.edu Fri Apr 24 09:39:40 1998 >Received: from localhost (daemon@localhost) > by merit.edu (8.8.7/8.8.5) with SMTP id MAA26391; > Fri, 24 Apr 1998 12:27:05 -0400 (EDT) >Received: by merit.edu (bulk_mailer v1.5); Fri, 24 Apr 1998 12:25:12 -0400 >Received: (from majordom@localhost) > by merit.edu (8.8.7/8.8.5) id MAA26259 > for nanog-outgoing; Fri, 24 Apr 1998 12:25:11 -0400 (EDT) >Received: from freeside.fc.net (freeside.fc.net [207.170.70.2]) > by merit.edu (8.8.7/8.8.5) with ESMTP id MAA26217 > for <nanog(a)merit.edu>; Fri, 24 Apr 1998 12:24:37 -0400 (EDT) >Received: from freeside.fc.net (localhost.fc.net [127.0.0.1]) > by freeside.fc.net (8.8.8/8.8.8) with ESMTP id LAA14282; > Fri, 24 Apr 1998 11:24:30 -0500 (CDT) >Message-Id: <199804241624.LAA14282(a)freeside.fc.net> >To: "Natambu Obleton" <no(a)frontier.net> >cc: nanog(a)merit.edu >Subject: Re: Traffic Shapping >In-reply-to: Your message of "Thu, 23 Apr 1998 17:51:16 MDT." > <072601bd6f12$b4f15050$3b8d2dc7(a)hermosa.frontier.net> >Date: Fri, 24 Apr 1998 11:24:29 -0500 >From: Jeremy Porter <jerry(a)freeside.fc.net> >Sender: owner-nanog(a)merit.edu > > >Sure we do it all the time. There are CPU limitations on the >amount of total traffic that can be pushed through a router that >is traffic shaping. I'm assuming because all the shaped traffic is >process switched. Also you will probably want to dedicate a router >to it. > >Typically these are only useful near the customer connection, as >you can really only shape outbound packets. (unless you >traffic shape at your boarders, and have a "large" network, you've >already paid for the traffic by the time you discard it.) > >In message <072601bd6f12$b4f15050$3b8d2dc7(a)hermosa.frontier.net>, "Natambu Oble >ton" writes: >>Has anyone here successfully implement the traffic shaping option on a Cisco >>router? >>-- >>Natambu Obleton - Network Administrator - Frontier Internet Inc. >>970 385 4177 - fax: 970 385 6745 - http://www.frontier.net >>777 Main St. - Suite #201 - Durango - Colorado - 81301 - USA >> >> > >--- >Jeremy Porter, Freeside Communications, Inc. jerry(a)fc.net >PO BOX 80315 Austin, Tx 78708 | 512-458-9810 >http://www.fc.net > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: Traffic Shapping
by Ehab Hadi 25 Apr '98

25 Apr '98

Natambu, Can you please specify what platform that you are using? any why you like to do the traffic shaping on the Ethernet which is suppositly 10 Mbps? Ehab Hadi Northern Telecom Interprise Networks Ottawa, ON K1Y 4H7 Canada ehabh(a)hotmail.ca >From owner-nanog(a)merit.edu Fri Apr 24 09:59:44 1998 >Received: from localhost (daemon@localhost) > by merit.edu (8.8.7/8.8.5) with SMTP id MAA27417; > Fri, 24 Apr 1998 12:51:49 -0400 (EDT) >Received: by merit.edu (bulk_mailer v1.5); Fri, 24 Apr 1998 12:50:49 -0400 >Received: (from majordom@localhost) > by merit.edu (8.8.7/8.8.5) id MAA27342 > for nanog-outgoing; Fri, 24 Apr 1998 12:50:48 -0400 (EDT) >Received: from home.merit.edu (home.merit.edu [198.108.60.42]) > by merit.edu (8.8.7/8.8.5) with ESMTP id MAA27334 > for <nanog(a)merit.edu>; Fri, 24 Apr 1998 12:50:43 -0400 (EDT) >Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id MAA04749 for nanog(a)merit.edu; Fri, 24 Apr 1998 12:50:43 -0400 (EDT) >Received: from animas.frontier.net (root(a)frontier.net [199.45.141.1]) > by merit.edu (8.8.7/8.8.5) with ESMTP id MAA27293 > for <nanog(a)merit.edu>; Fri, 24 Apr 1998 12:49:01 -0400 (EDT) >Received: from hermosa (hermosa [199.45.141.59]) > by animas.frontier.net (8.8.8/8.8.8) with SMTP id KAA20190 > for <nanog(a)merit.edu>; Fri, 24 Apr 1998 10:48:50 -0600 >Message-ID: <00f301bd6fa1$4fdd1a70$3b8d2dc7(a)hermosa.frontier.net> >From: "Natambu Obleton" <no(a)frontier.net> >To: <nanog(a)merit.edu> >Subject: Re: Traffic Shapping >Date: Fri, 24 Apr 1998 10:52:04 -0600 >X-Priority: 3 >X-MSMail-Priority: Normal >X-Mailer: Microsoft Outlook Express 4.72.2106.4 >X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 >Sender: owner-nanog(a)merit.edu > >I am looking to do the shaping on Ethernet Interfaces for a large fiber >plant. I have been looking the solution by Aponet. Anyone out there used it? >I believe it is what above.net uses. > >-- >Natambu Obleton - Network Administrator - Frontier Internet Inc. >970 385 4177 - fax: 970 385 6745 - http://www.frontier.net >777 Main St. - Suite #201 - Durango - Colorado - 81301 - USA >-----Original Message----- >From: Alex P. Rudnev <alex(a)Relcom.EU.net> >To: Natambu Obleton <no(a)frontier.net> >Cc: nanog(a)merit.edu <nanog(a)merit.edu> >Date: Friday, April 24, 1998 10:33 AM >Subject: Re: Traffic Shapping > > >>Hmm, it depends of what do you mean as _successfully_ -:). >> >>It works, but creates some bugs under heavy conditions. >> >> >> >>On Thu, 23 Apr 1998, Natambu Obleton wrote: >> >>> Date: Thu, 23 Apr 1998 17:51:16 -0600 >>> From: Natambu Obleton <no(a)frontier.net> >>> To: nanog(a)merit.edu >>> Subject: Traffic Shapping >>> >>> Has anyone here successfully implement the traffic shaping option on a >Cisco >>> router? >>> -- >>> Natambu Obleton - Network Administrator - Frontier Internet Inc. >>> 970 385 4177 - fax: 970 385 6745 - http://www.frontier.net >>> 777 Main St. - Suite #201 - Durango - Colorado - 81301 - USA >>> >>> >>> >> >>Aleksei Roudnev, Network Operations Center, Relcom, Moscow >>(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, >N 13729 (pager) >>(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) >> > > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: Network Operators and smurf
by Havard.Eidnes＠runit.sintef.no 25 Apr '98

25 Apr '98

> Wait; all traffic is coming in one interface. The CEF thing > will have no effect if the spoofed source address is a real > network. "The CEF thing" configuration from my first message in this thread does the following: For each packet entering an interface with "ip verify unicast reverse-path" turned on, the router will look up the source address from the IP packet in the CEF table and find the interface (or set of interfaces) it would use to route back to the source. If the incoming interface for the actual packet is not among those returned by the "reverse-path" lookup, the packet is dropped on the floor. >From my point of view this is exactly the sort of functionality which is needed to prevent us from being the host (originator) of a Smurf attack (or more generally from attacks involving IP address spoofing), as in the case of a Smurf attack packets with the victim's source address entering from the wrong interface will be dropped on the floor. If you still think this doesn't help or isn't useful, I propose that we take it to private e-mail (?). - Håvard

1 0

Operational: MAE-EAST outage
by dlr＠bungi.com 25 Apr '98

25 Apr '98

Many of our mae-east peers went down around 11:30 PDT, and didn't come up again until nearly 12:30. When called, MFS said that they had done "scheduled maintenance", and replaced a "clocking card". MFS ticket #210855. Did anyone get notified? -- Dave Rand dlr(a)bungi.com http://www.bungi.com

2 1

Network Operators and smurf
by Rusty Zickefoose 24 Apr '98

24 Apr '98

-----BEGIN PGP SIGNED MESSAGE----- Hi all, <rant> If were reading this list on a professional basis, we should be a little clued, or at least attempting to get there. We're in the big leagues now, read up on CIDR, figure out classless subnetting. To advocate breaking legitimate routing because we, as an industry, don't want to put in the time and effort to educate our end users is just a little lame. </rant> Had to get that off my chest. Anyway, it's been said here several times before, but I'll say it again. To end the smurf type exploits, we need to do 2 things. 1. Routers/Gateways should be configured to prevent the transmission of echo-request packets, out an interface, to a destination address identical to the broadcast address of that interface, except in those cases where specifically required. This means getting vendors to give us a knob, and having it default to off. This is the easy one folks, figuring out net-masks aren't that hard. The transit providers might have problems with implementing this due to hardware meltdown, but that's not where it needs to be implemented. !!Educate your (our) users!! 2. Routers/Gateways should be configured to drop all packets with invalid source addresses. This is a little bit more difficult, particularly if your multi-homed, but again, it's not the transit providers that are need to implement this, its the end user. once more !!Educate your (our) users!! No. 2 has the benefit of fixing all manner of ills. The problem is us. This isn't a research network run and maintained by the knowledgable. This is a business. We're selling a product, and if we expect it to operate as advertised, it's up to us to educate those we sell it to. This is Mr. Pot, saying so long to all you kettles out there. - -- Rusty Zickefoose | The most exciting phrase to hear in science, rusty(a)mci.net | the one that heralds new discoveries, is not | "Eureka!", but "That's funny ..." | -- Isaac Asimov -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNUDlvu4+ch/bGDylAQGktAQAolKXogM3Gyr/Wp/AE1h6jZo6QQOTtOIU ZkFUI+Dk7tKCoc6BPZ4VrsiPF1zslnQoIWwdceubl7kK+GwIyH4CTWtAyXGP+wr3 6EHKiYfZ19P/Wvhi0Cjxo2buxYgpLCEHeKR4GUKwnJI66HlInemlUp4zDpMQFy8R mNIdSK/Pw1k= =/Dxy -----END PGP SIGNATURE-----

9 16

Traffic Shapping
by Natambu Obleton 24 Apr '98

24 Apr '98

Has anyone here successfully implement the traffic shaping option on a Cisco router? -- Natambu Obleton - Network Administrator - Frontier Internet Inc. 970 385 4177 - fax: 970 385 6745 - http://www.frontier.net 777 Main St. - Suite #201 - Durango - Colorado - 81301 - USA

4 3

The Cidr Report
by Tony Bates 24 Apr '98

24 Apr '98

This is an auto-generated mail on Fri Apr 24 12:00:00 PDT 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 24Apr98 0) General Status Table History ------------- Date Prefixes 170498 51188 180498 51220 190498 51064 200498 51247 210498 51425 220498 51496 230498 51401 240498 51504 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3488 Number of ASes announcing only one prefix: 1659 (861 cidr, 798 classful) Largest number of cidr routes: 376 announced by AS3561 Largest number of classful routes: 1115 announced by AS701 1) Gains by aggregating at the origin AS level --- 24Apr98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 657 413 244 37.1% iSTAR Internet, Inc. AS4293 441 217 224 50.8% IMCI AS816 670 461 209 31.2% UUNET Canada (ASN-UUNETCA-AS4) AS701 1115 939 176 15.8% Alternet AS3602 469 306 163 34.8% Sprint Canada Inc. AS3749 219 64 155 70.8% TECNET AS174 750 601 149 19.9% Performance Systems International AS8505 156 30 126 80.8% Middle East Technical University AS7046 253 149 104 41.1% UUNET-CUSTOMER AS5668 119 45 74 62.2% Century Telephone Inc. AS2048 162 90 72 44.4% LaNet AS3221 110 41 69 62.7% EENet Autonomous System AS4755 97 29 68 70.1% Videsh Sanchar Nigam Ltd. India AS11003 127 59 68 53.5% UNKNOWN AS10928 104 44 60 57.7% UNKNOWN AS271 111 52 59 53.2% BCnet Backbone AS3804 200 142 58 29.0% Bell Solutions AS4313 67 14 53 79.1% DELTANET AS549 209 159 50 23.9% ONet Backbone AS1239 541 492 49 9.1% SprintLink Backbone AS72 84 36 48 57.1% Schlumberger Information Network AS1221 275 227 48 17.5% AARNET-AS AS6392 80 33 47 58.8% MidWest Communications, Inc. AS4763 123 76 47 38.2% Telstra New Zealand AS684 94 52 42 44.7% Manitoba Regional Network Backbon AS852 157 117 40 25.5% AGT Advance Communication AS4740 353 314 39 11.0% ASN-OZEMAIL (Ozemail Pty Ltd) AS3493 164 126 38 23.2% INTERLINK AS4200 129 92 37 28.7% AGIS (Apex Global Information Ser AS803 72 36 36 50.0% SaskNet Backbone For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

cflowd - seems OK now ;-)
by Leigh Porter 24 Apr '98

24 Apr '98

Hiya folks, With regards to my earlier problem: This is an extract of /var/log/messages Apr 24 18:44:52 mekong cflowd[16202]: [E] recv.c:100 recvfrom() returned 928 Apr 24 18:44:52 mekong cflowd[16202]: [E] recv.c:100 recvfrom() returned 1168 Apr 24 18:44:52 mekong cflowd[16202]: [E] recv.c:100 recvfrom() returned 1168 Apr 24 18:44:53 mekong cflowd[16202]: [E] recv.c:100 recvfrom() returned 400 Apr 24 18:44:53 mekong cflowd[16202]: [E] recv.c:100 recvfrom() returned 1168 Apr 24 18:44:54 mekong cflowd[16202]: [E] recv.c:100 recvfrom() returned 208 Apr 24 18:44:54 mekong cflowd[16202]: [E] recv.c:100 recvfrom() returned 1168 Apr 24 18:44:54 mekong cflowd[16202]: [E] recv.c:100 recvfrom() returned 1168 Apr 24 18:44:56 mekong cflowd[16202]: [E] recv.c:100 recvfrom() returned 400 Apr 24 18:44:56 mekong cflowd[16202]: [E] recv.c:100 recvfrom() returned 1168 Apr 24 18:44:56 mekong cflowd[16202]: [E] recv.c:100 recvfrom() returned 1168 Apr 24 18:44:57 mekong cflowd[16202]: [E] recv.c:100 recvfrom() returned 208 And the offending code: len = recvfrom(sockfd, (char *)flowpdu, sizeof(*flowpdu),0, (struct sockaddr *)&Saddr,&alen); if (len < (sizeof(FLOW_PDU_HDR) + (ntohs(flowpdu->header.count) * sizeof(FLOW_PDU_ENTRY)))) { syslog(LOG_ERR,"[E] %s:%d recvfrom() returned %d", __FILE__,__LINE__,len); return(-1); } It was getting the flow data all the time, bit it did not like it. I am running 11.2.(9)P on which the command: ip flow-export version 5 origin-as Does not exist, only the following is there: ip flow-export dest Is it a version problem? Anyway, I commented out the above code and it's collecting stats, I get a lot of: Apr 24 18:58:32 mekong cflowd[16687]: [E] cflowd.c:364 missed 2.12341e+07 flows from 193.164.160.114 Apr 24 18:58:32 mekong cflowd[16687]: [E] cflowd.c:364 missed 2.91787e+07 flows from 193.164.160.114 Apr 24 18:58:32 mekong cflowd[16687]: [E] cflowd.c:364 missed 2.07987e+09 flows from 193.164.160.114 But it's collecting something...! -- Leigh Porter

2 2

Not much use :-(
by Leigh Porter 24 Apr '98

24 Apr '98

Hello, Further to my last email, it seems that it is not getting any usefull data ;-) Take a look: [root@mekong tmp]# cfdnets 193.164.160.114.netmatrix.cur | head Net Matrix ---------- number of net entries: 436 SRCNET/MASK DSTNET/MASK PKTS BYTES 192.0.0.0/19 0.32.0.0/216 2338702092 2339630048 128.0.0.0/19 0.32.0.0/243 1666817388 1669372960 192.0.0.0/19 0.32.0.0/80 1206167448 1207129420 192.0.0.0/19 0.32.0.128/89 1876078360 1876096604 192.0.0.0/19 0.32.0.128/89 1876090628 1876090628 192.0.0.0/19 0.32.0.0/12 1995179200 1997963672 [root@mekong tmp]# cfdprotos 193.164.160.114.protocol.cur | head Protocol Table -------------- protocol packets bytes 0 2076977636 2077221280 2 247947584 248023436 5 1286321320 1286586400 8 247931232 247966892 10 4201412532 4201768492 13 1333349088 1333353584 14 1581249504 1581374464 [root@mekong tmp]# I am off to the pub, maybe some beer will make it work ;-) -- Leigh

1 0

Re: Traffic Shapping
by Natambu Obleton 24 Apr '98

24 Apr '98

I am looking to do the shaping on Ethernet Interfaces for a large fiber plant. I have been looking the solution by Aponet. Anyone out there used it? I believe it is what above.net uses. -- Natambu Obleton - Network Administrator - Frontier Internet Inc. 970 385 4177 - fax: 970 385 6745 - http://www.frontier.net 777 Main St. - Suite #201 - Durango - Colorado - 81301 - USA -----Original Message----- From: Alex P. Rudnev <alex(a)Relcom.EU.net> To: Natambu Obleton <no(a)frontier.net> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: Friday, April 24, 1998 10:33 AM Subject: Re: Traffic Shapping >Hmm, it depends of what do you mean as _successfully_ -:). > >It works, but creates some bugs under heavy conditions. > > > >On Thu, 23 Apr 1998, Natambu Obleton wrote: > >> Date: Thu, 23 Apr 1998 17:51:16 -0600 >> From: Natambu Obleton <no(a)frontier.net> >> To: nanog(a)merit.edu >> Subject: Traffic Shapping >> >> Has anyone here successfully implement the traffic shaping option on a Cisco >> router? >> -- >> Natambu Obleton - Network Administrator - Frontier Internet Inc. >> 970 385 4177 - fax: 970 385 6745 - http://www.frontier.net >> 777 Main St. - Suite #201 - Durango - Colorado - 81301 - USA >> >> >> > >Aleksei Roudnev, Network Operations Center, Relcom, Moscow >(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) >(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) >

2 1