- Test - lists.nanog.org

Archive Editing - Summary
by Eric Germann 06 Aug '98

06 Aug '98

UNCLE! It will stay put, which was my first inclination anyways. 42-0 (so far) to keep it intact. Eric ========================================================================== Eric Germann CCTec ekgermann(a)cctec.com Van Wert, OH 45891 http://www.cctec.com Ph: 419 968 2640 Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

1 0

RE: Strange BGP announcement.
by Martin, Christian 06 Aug '98

06 Aug '98

This capability negotiation is only seen on the CC train. Thus, if you have CEF, you have the problem. Ironically, a colleague of mine mentioned this problem last night during a maintenance session. A foreshadowing??? -Chris- -----Original Message----- From: Craig A. Huegen [mailto:chuegen@quadrunner.com] Sent: Thursday, August 06, 1998 2:05 PM To: Brett Frankenberger; nanog(a)merit.edu Subject: Re: Strange BGP announcement. Egads. I suppose I should have had more coffee, then read the update. =) The problem I mentioned is a separate case. Never mind me. /cah On Thu, Aug 06, 1998 at 09:39:50AM -0700, Craig A. Huegen wrote: ==>On Thu, Aug 06, 1998 at 10:48:53AM -0500, Brett Frankenberger wrote: ==> ==>==>Bays don't crash (at least not in the general case ... for example, ==>==>mine stayed up this time and the last time this happened), but they do ==>==>send a NOTIFY and bring down the BGP session, as required by the RFC. ==>==>(I believe gated does this also.) ==>==> ==>==>The reason this issue causes problems is that Cisco violates the RFC ==>==>and passes the bad announcement around, so it eventually reaches most ==>==>non-Cisco routers who properly terminate the BGP connection. If Cisco ==>==>would do the NOTIFY upon receipt of the announcement, then the ==>==>information wouldn't spread, and only one router's worth of peerings ==>==>(i.e. the guy who "started" the bad annoucnement) would be lost. ==> ==>The "bad announcement" that you're talking about is capability negotiation ==>for RFC 2283, multi-protocol extensions to BGP--used for MBGP. It's not ==>a bad announcement, but an OPEN message intended to support multiple ==>NLRI types. ==> ==>The intended behavior for 11.1(20)CC is that when it sees a NOTIFY ==>of code 2, subcode 4 (unknown authentication parmeter), it backs off ==>and uses the unicast IPv4 NLRI type only (and the OPEN format without the ==>options). Unfortunately, there is a case where the Cisco will respond ==>to the TCP session close by tearing down the peer before it ever sees ==>the NOTIFY message. ==> ==>CSCdk30915 addresses this, and it will be fixed in an early interim ==>of 11.1(20)CC. A temporary workaround is to enable "neighbor x.x.x.x ==>dont-capability-negotiate" on the Cisco. ==> ==>/cah

1 0

Re: Q:Why router with ATM interface comes out earlier than pure SONET interface?
by Tony Li 06 Aug '98

06 Aug '98

wsimpson(a)greendragon.com (William Allen Simpson) writes: > Finally, a commercial vendor (NetStar) decided that they could build it. > And Cisco got wind of the project. Cisco hates to be second to market, > so they quickly came out with their own, beating NetStar by a few weeks. Actually, at the time that Cisco started working on it, they had NO idea of the NetStar project. Instead, they were being beaten up by one particular customer's engineer. Tony

1 0

Re: ISL Question
by owen＠DeLong.SJ.CA.US 06 Aug '98

06 Aug '98

The answer is "It depends..." If you configure both interfaces on the 2901 as trunks and you configure the trunks to forward all of the applicable VLANs, and you configure the interface on the 1900 as a Trunk, then it will work just fine. If you get any thing wrong, it will break. As to different ISL groups, I'm not sure what you mean. There are no ISL groups. ISL is ISL. It encapsulates a VLAN number onto each packet going onto the wire, and decapsulates the packet into the VLAN on the receiving switch. As such, you could do the following (which is what I think you're aiming for): Cisco Router Subinterfaces F0/0.2-500 == VLANs 2-500 Subinterfaces F0/0.501-999 == VLANs 501-999 2901 Trunk Port 1/1 == VLANS 1-1000 and connects to Cisco Router Trunk Port 1/2 == VLANS 1,501-999 and connects to 1900 1900 Trunk Port 1/1 == VLANS 1,501-999 and connects to 2901 Then you could put users on VLANs 2-500 on the 2901 and users on VLANs 501-999 on the 1900, and be just fine. Additionally, if you wanted to add a VLAN to the trunk between the 2901 and the 1900, say VLAN 250 (so that the new list would look like 1,250,501-999), you could even put some people in VLAN 250 on each switch and still have them talking to F0/0.250 on the router. Hope that helps. Owen > > Can you double-hop ISL? Suppose: > > > |cisco | > |router|------|Cat 2901|-------|Cat 1900| > > Can ISL run 'through' the 2901? The Cat 1900 Enterpise can do ISL; what I > am asking is can I assign interfaces off of the 1900 to sub-interfaces on > the router (ISL then would run through the 2901), and at the same time > have other interfaces on the 2901 act in other ISL groups? > > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Atheism is a non-prophet organization. > I route, therefore I am. > Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member > Father of the Network and Head Bottle-Washer > Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 > Don't choose a spineless ISP! We have more backbone! http://www.nac.net > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > >

1 0

ISL Question
by alex＠nac.net 06 Aug '98

06 Aug '98

Can you double-hop ISL? Suppose: |cisco | |router|------|Cat 2901|-------|Cat 1900| Can ISL run 'through' the 2901? The Cat 1900 Enterpise can do ISL; what I am asking is can I assign interfaces off of the 1900 to sub-interfaces on the router (ISL then would run through the 2901), and at the same time have other interfaces on the 2901 act in other ISL groups? -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP! We have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

1 0

Noc Status/Contact Info page
by Tim Wolfe 05 Aug '98

05 Aug '98

I have updated the page with all the info everyone has sent me. I've also added a seperate column for NOC/Status pages to avoid the confusion and I've readded the AS column. This can now be found at http://www.clipper.net/noc/ 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: Possible scam: "Network Abuse"
by Richard Thomas 05 Aug '98

05 Aug '98

-----Original Message----- From: Ehud Gavron <GAVRON(a)ACES.COM> To: nanog(a)merit.edu <nanog(a)merit.edu> Cc: GAVRON(a)ACES.COM <GAVRON(a)ACES.COM> Date: Tuesday, August 04, 1998 11:59 PM Subject: Possible scam: "Network Abuse" >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...." --- 198.182.116.0 ping statistics --- 1 packets transmitted, 1 packets received, +13 duplicates, 0% packet loss round-trip min/avg/max = 201.1/207.5/216.3 ms Most likely running down SAR... I wonder if anyone actually paid? =)

1 0

Re: Q:Why router with ATM interface comes out earlier than pure SONET interface?
by William Allen Simpson 05 Aug '98

05 Aug '98

> Date: Mon, 3 Aug 1998 11:02:33 +0900 > Then my question is: why 155M ATM interface is easier to make than 155M POS interface? As folks have already mentioned, it isn't. However, for economies of purchasing, at least one vendor is using the same chip, and bypassing the ATM part. > Although the net capacity of 155M ATM is less than 155m POS, their capacity for IP packet > is really close. I think its nearly the same challenge to pump up a 155M ATM pipe as a > 155M POS pipe with IP packet for a router. > It is actually _much_ easier to pump a 155Mbps POS pipe. The first one was a simple graduate student project! Anyway, to fill you in on a bit of the history: ATM was presented to the IETF by George Clapp of Ameritech in November of 1991. This was the same fellow chairing the IP over Large Public Data Networks Working Group. (You remember X.25?) Bob Hinden (then of BBN) lead a short meeting on IP over ATM. Several of us in the back of the room got together, saying this is much too complicated, there has to be a better way. There was a bit of discussion over on the end-to-end-interest list. Craig Partridge wanted a simple PPP-like encapsulation. And so, it fell to me, the Editor of the PPP WG, to study SONET and SDH and their differences (at least 3 months of unpaid work), buying books and specifications, talking to folks at Bellcore, BBN, etc., and come up with something simpler. Which was completed mid-1992. A prototype was built at SUNY Buffalo. Unfortunately, the IESG member (Steve Knowles) responsible for the PPP WG thought nobody would ever build PPP Over SONET commercially, because ATM was the next big thing. And George Clapp and others in IPLPDN were adamantly opposed to the PPP WG covering something they considered their turf ("large public data networks". So, we were restricted to a design for short-haul private networks. And the IETF standards process was in flux, so we didn't know whether to publish as Experimental or Proposed Standard. These political problems delayed publication until 1994. Finally, a commercial vendor (NetStar) decided that they could build it. And Cisco got wind of the project. Cisco hates to be second to market, so they quickly came out with their own, beating NetStar by a few weeks. Unfortunately, we've since learned a few things. Features that work fine in a private network fail with the large carrier networks. For example, a widely deployed ATT/Lucent chip has a 200 millisecond DC bias. This blatantly fails to meet both SONET and SDH clock recovery requirements, but is good enough for voice. There were also some other problems with Cisco's quick project. But, the folks there did the honorable thing (how rare) and offered a free replacement for all their fielded boards! Last Fall, the large carriers were up in arms about the DC bias problem; and unlike Cisco, would not replace their bad boards. They insist that we change, instead. It turns out that it doesn't matter much to us, as it never happens by accident. Even when directly induced (the killer packet), it only happens about 1 out of 2,000 packets. Compared to MAE-East, this is nothing.... With a heterogeneous mix of traffic, it would never be noticed. I've put together a compendium of the problems encountered in large carriers, and proposed solutions. I just split it into 3 related internet-drafts last week, and they should be up on the net whenever the busy drafts person gets them posted, probably by the end of the week. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

1 0

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