- NANOG - lists.nanog.org

Re: "Packet Shapers"
by Hank Nussbacher 05 Aug '98

05 Aug '98

At 11:28 AM 7/30/98 -0400, Scott Gifford wrote: I have been using a packet shaper (non commercial product) since 4/96 and have recently been reviewing/testing a number of commercial products on the market. I will ignore the options and features every product has but rather focus on those things to look at when checking these boxes: 1) alerts: a nice feature to have that no commercial product has yet is an alert feature when a bandwidth limiting policy has been exceeded. Example: You limit incoming icmp to 100kb and are suddenly hit by a Smurf eating up 2Mb/sec. You want an alert sent to the NOC via email or some other method. Or you have policy limiting single stream outgoing UDP to 256kb and suddenly see 4Mb/sec. You definitely want an alarm going off somewhere. We have found that email alerts are invaluable. Packeteer doesn't have it. 2) Bandwidth manipulation: some products do buffering, some play with the TCP window. You want both. Packeteer has both. 3) Bypass: you want a hardware and software bypass in the event something goes wrong. This is black box sitting in the data path. You now have a strip of boxes: firewall->packetshaper->router (and perhaps more). If something doesn't work, you don't want to start recabling to bypass the packet shaper. Software bypass via a Web interface is a must, and a hardware bypass is also critical. Packeteer has both. 4) Signon management: In a large ISP operation, many users will need to have access to modify the rules and policies. You will want a system that has individual user signon rather than a single user/pswd. Packeteer has only single user/pswd so therefore it is impossible to track who has done what changes. 5) Topflows: In RMON there is the concept of Top 10. When the network slows down, you want the ability to see a list of the Top n users consuming bandwidth in the past 1 minute/10 minutes/hour. Packeteer does not have that capability. 6) Flows: When a vendor says their box supports T3, one has to check a little deeper and determine the number of max flows allowed. For example, Allot (www.allot.com) supports a T3 box, but tops out at 5000 concurrent flows. Packeteer supports 20,000 concurrent flows. Current realtime numbers on my beta box show 2400 flows consuming 3.3Mb, and often 8000-9000 flows consuming 6.5Mb of bandwidth. Based on those numbers, I will hit 20,000 flows long before I hit 20Mb of bandwidth. I do not think the packet shaper vendors have much of an idea in the ISP market as to the large number of flows involved. They know corporate networks. 7) Platform: Look at the OS platform. Packeteer using a proprietary OS, others may package Linux or NT. None have done any OS hardening on the system so it is best to run something like ISS against the packet shaper to determine what security holes exist. Imagine you start using a packet shaper in production only to have the hackers hack it and set their own super-duper policies. 8) Audit trail: The product should have the ability to have some sort of syslog based on modifications done by personnel. Packeteer has something that is not accessible via the web and is more for debugging. 9) Filters & CPU: Look for products that can support CIDR notation and not the long masks. Packeteer doesn't support CIDR notation masking for filters. Some limit the size of the filter (also called policy, access- list, pipe rule, etc.). Packeteer limits it to 16 lines. The larger the filter the slower the box. Test it out. 10) ToD: All boxes have the ability to control based on source IP, destination IP and port. Not all have the ability to control based on time of day. Suppose you want incoming news to be limited to 128kb during the day but open it up from 2-8am to 800kb. Packeteer has a line command called "schedule". Look for GUI's to do this. 11) Flow limiting: sometimes you want the ability to not only control bandwidth but also the number of flows. Example: you allow IP phone via the Internet via port xxxx but want to guarantee 8kb/sec per flow, but you only have 64kb of bandwidth allocated for that port. You want to have the ability to state that a maximum of 8 flows can use that virtual pipe and the 9th won't get the service. Packeteer says they have this ability but I have not verified it. 12) Graphs: you want the ability for realtime graphs for each policy so you can see how your rule changes have affected the bandwidth. Packeteer has this capability. 13) Multihoming: this is the one *every* vendor fails on and is perhaps the one we need. These packet shaper boxes assume either one outgoing line from the router, or if there are multiple lines - that they are load balanced (NReality - www.nreality.com places their box on the FR line itself after the router - and last I checked only support FR). But in most ISP cases, you are multihomed with 3-4 outgoing lines - which are not fully balanced. Suppose one line is 90% and the others are 30%. The packet shaper can't see any of this and therefore the policy rules are not perfect. The line that is 90% satuarted is hearing 4,000 nets via BGP. How do you get that routing info the packet shaper? None have some sort of BGP import and when I tell them I want to import 52,000 prefixes and build policy rules based on that - they look at me like I am from Mars. In the near future we will be exploring this avenue for Internet-2 in Israel. 14) Transparent proxy: remember that line of boxes? firewall->packet shaper->router? Now add in a transparent proxy. Ugh. Look for a vendor that will include a transparent proxy capability in their box. I wouldn't be suprised if Alteon and Packeteer were to merge. These kind of mergers have to happen. Checkpoint already has packet shaping in their firewall via an addon product called Floodgate. Cisco bought up Classdata (www.classdata.com) so expect to see more of these capabilities in firewalls and routers. If you have read articles in Network World, Data Communications, etc. on this topic you will not find this level of detail there. This only comes with actually using and testing these boxes. Scott, these products do work and are not snake oil. I trust this helps you somewhat. -Hank >I was wondering if anybody out there has had any experience with "Packet >Shapers," which claim to be able to limit traffic to a particular host, >host+port, or host+port+url without dropping packets. They apparently watch >traffic flows and keep track of connections, then dink around with TCP >window size information to slow traffic down if needed. > >The one we have been looking at is called "The Packeteer" >(http://www.packeteer.com) but I have seen a few others (one of which had a >really good picture of a pig in the ad). > >Do these things work as advertised? Is anybody actively using them inside >their networks? I don't know enough down-and-dirty information about TCP to >know if this should work, or if it's just a plastic shell filled with >snake-oil... > >Thanks for any information. Email if you like, I will post a summary if >people are interested. > >------Scott. > >

4 9

Q:traffic engineering practice in real world IP/ATM networks.
by Yu Ning 05 Aug '98

05 Aug '98

Hi friends, It's said that one of the chief advatange of ATM supporting IP traffic is the capability to fulfil traffic engineering(TE) on the base of PVP/PVC, so that there isn't link under-utilized while some are over-utilized. Then my question is: has any real world IP/ATM (or IP/FR) network carried out traffic engeering? How they do it? (There seems not any standard protocol to do so, then do they rely on some off-line performance optimizing tools, which is a little slow in reaction to the network traffic change?) Thanks for any comments. regards, Yu Ning. _____________________________________________* Yu Ning ATM R&D Center of BUPT (Beijing U. of Posts&Telecom) Beijing (ZIP:100876, MBox:147#), P.R.China yuning(a)mindless.com Ideas reflect view points of my own,:-) _____________________________________________

1 0

Re: Possible scam: "Network Abuse"
by Vadim Antonov 05 Aug '98

05 Aug '98

Begging? That may be a lot more malicious. "Give me your firewall's password so i can fix it". Sure, dude. --vadim >From errors-nohumans(a)merit.edu Tue Aug 4 20:57:38 1998 X-UIDL: fc9be4f13610259e5d584676031c5dcc Date: Tue, 04 Aug 1998 20:46:51 -0700 (MST) From: Ehud Gavron <GAVRON(a)ACES.COM> Subject: Possible scam: "Network Abuse" To: nanog(a)merit.edu Cc: GAVRON(a)ACES.COM Organization: ACES Research Inc. MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_[ID_5lnQtjNa7nT7upy77S5Jzg]" Sender: owner-nanog(a)merit.edu --Boundary_[ID_5lnQtjNa7nT7upy77S5Jzg] Content-type: TEXT/PLAIN; CHARSET=US-ASCII This "fellow" sent out this email. Unfortunately, our networks were not used to attack him (or anyone), and upon request for NTP-stamped logs, he quit responding to email. I recommend warning your downstreams that this kind of scam is only just begging. Imagine... $100 for "no ip direc...." E --Boundary_[ID_5lnQtjNa7nT7upy77S5Jzg] Content-type: MESSAGE/RFC822 Return-path: <wrath(a)ns1.jerky.net> Received: from ns1.jerky.net by ACES.COM (PMDF V5.1-7 #EHUD) with ESMTP id <01IZZYRAD8E891W60X(a)ACES.COM> for gavron; Thu, 30 Jul 1998 04:29:16 MST Received: (from wrath@localhost) by ns1.jerky.net (8.8.7/8.8.7) id MAA06007 for gavron(a)ACES.COM; Thu, 30 Jul 1998 12:31:26 +0000 (GMT) Date: Thu, 30 Jul 1998 12:31:26 +0000 (GMT) From: Andrew Shoemaker <wrath(a)jerky.net> Subject: Network Abuse - Netblock 198.182.116.0 - IMPORTANT To: "gavron(a)ACES.COM" <gavron(a)ACES.COM> Message-id: <199807301231.MAA06007(a)ns1.jerky.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Hello My name is Andrew Shoemaker and I am the head security consultant at JNS. We recently were the target of a denial of service attack that saturated our Internet connection. This attack, known as a 'smurf' attack, uses unknowing relays to source the at tack. By relaying the attack through your network the attack is made anonymous and increases in strength. This type of attack causes degraded performance on both the attacked and relay networks and is the result of an improperly configured router at you r site. I urge you to fix your routers. If you are unable to do so, or do not know how I suggest you call a security consultant. JNS is willing to fix your router permanently for a one time fee of $100 US. If you are interested in this deal please co ntact me and I will send you a copy of our security contract and an invoice. Netblock 198.182.116.0 was found to produce 19 replys for each packet sent. This means if the attacker is sending at T1 speeds the amount of your bandwidth used in relaying the attack is equivalent to 19 T1s regards, Andrew Shoemaker JNS Security wrath(a)jerky.net 617.442.5408 --Boundary_[ID_5lnQtjNa7nT7upy77S5Jzg]--

1 0

Possible scam: "Network Abuse"
by Ehud Gavron 05 Aug '98

05 Aug '98

This "fellow" sent out this email. Unfortunately, our networks were not used to attack him (or anyone), and upon request for NTP-stamped logs, he quit responding to email. I recommend warning your downstreams that this kind of scam is only just begging. Imagine... $100 for "no ip direc...." E

1 0

Re: NOC info and Network Status Pages
by Tim Wolfe 05 Aug '98

05 Aug '98

On Tue, 4 Aug 1998, Jim Browne wrote: > At 16:38 -0700 8/4/98, Tim Wolfe wrote: > >I've linked all the network status pages I could find to the names of the > >providers on this page. > > > >http://www.clipper.net/noc-info.html > > > >Please direct corrections/comments/flames to tim(a)clipper.net > > I don't understand. The links go to the respective provider's main web page. > > Sorry I guess I wasn't clear enough, the Provider's that I couldn't find NOC/Network Status pages for I linked to their home pages. I thought that would be better than nothing for. Take a look at MCI. Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

1 0

NOC info and Network Status Pages
by Tim Wolfe 04 Aug '98

04 Aug '98

I've linked all the network status pages I could find to the names of the providers on this page. http://www.clipper.net/noc-info.html Please direct corrections/comments/flames to tim(a)clipper.net Thanks, Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

1 0

leaking of routes by AS3549
by Alan Hannan 04 Aug '98

04 Aug '98

At approximately 1830 UTC [12:00 noon PDT] globalcenter [AS3549] started announcing full routes to peers at most exchange points with an AS-Path of 3549 [customer-as] [worlds view]. This was due to a misconfiguration by a downstream customer and the peering session filters during a customer turn-up. This incident started at approximately 1830 UTC and abated approximately 1705 UTC. It appears that the BGP withdrawal propogation is quite latent due to improper congestion due to this event, but the withdrawls are processing. We apologize for any inconvenience this caused you or your customers. We are reavaluating our turn-up policies and routing filters to prevent a problem such as this from occuring again. Please contact our network operations center (noc(a)globalcenter.net) with any questions or concerns. Our internal operations ticket is 9808040108. -alan

1 2

Re: Network Status Web Sites
by Tim Kempka 04 Aug '98

04 Aug '98

At 10:13 AM 8/4/98 -0700, you wrote: >I'm in the process of compiling a list of Network status pages for the >various larger NSPs. (ie http://www.noc.uu.net/) If anyone has pages for >Sprint, MCI, et al please let me know. When I get a decent number of links, >I'm going to put up a page on our site and I'll post the URL here. > >Thanks, > > Status site for FlashNet Communications is http://status.flash.net/ Tim Kempka ____________________________________________________ Tim Kempka E-Mail: tim(a)flash.net Network Engineer Pager: page_tim(a)flash.net FlashNet Communications Phone: 817-589-2390 ext. 378

1 0

Network Status Web Sites
by Tim Wolfe 04 Aug '98

04 Aug '98

I'm in the process of compiling a list of Network status pages for the various larger NSPs. (ie http://www.noc.uu.net/) If anyone has pages for Sprint, MCI, et al please let me know. When I get a decent number of links, I'm going to put up a page on our site and I'll post the URL here. Thanks, Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

1 0

RE: Q:Why router with ATM interface comes out earlier than pure SONET interface?
by Christian Kuhtz 04 Aug '98

04 Aug '98

> Hmm. How would you assure per-application Quality-of-Service > without letting > the network explicitely know about application behaviour, i.e. signalling > those parameters and establishing some state within network nodes - read: > connection oriented ? How would you ? Even IP's approaches to this problem > are stateful. Clearly define your requirements. Otherwise this discussion is academic. Give me a scenario and I'll engineer you an IP QoS traffic engineering solution. How many "different" application specific behaviors does one need and make up a manageable quantity of CoS across a service provider network? I don't think you'll ever see more than half a dozen or so anytime soon. How exactly do you sell 64 different classes of service to customers? "I would like CoS #57, please." -- "Would you like fries with that, sir?" How is Cos #57 different from CoS #56 or #58? Signaling assumes connection oriented networking. The question is whether you really need to "signal" across the core of a network. Why does the entire core need to know about everything? IP QoS is fundamentally different from a traffic engineer point. You don't define pipes, like in ATM. You don't associate QoS characteristics to a given pipe, because you don't have pipes like in ATM. You define rates, you define drop policies and queuing policies on a per <insert the a defineable *packet* characteristic here>. My point being that all you ATM QoS bigots need to stop thinking like ATM and forget the idea of a connection pipe at the transporrt layer, and listen to us IP QoS bigots :). Perhaps we actually do have a point, and one doesn't actually need ATM. Am I making any sense? I think a Q&A model for this discussion would be best, especially considering the "bandwidth" limitations of all participating parties.. Cheers, Chris -- Christian Kuhtz, BellSouth Corp., Sr. Network Architect <ck(a)bellsouth.net> 1100 Ashwood Parkway, Atlanta, GA 30338 <ck(a)gnu.org> "Legalize free-enterprise murder: why should governments have all the fun?" -- /usr/games/fortune

2 1