February 2004 - NANOG - lists.nanog.org

RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 or other vendor ?
by Alexander Hagen 27 Apr '04

27 Apr '04

Well this has been quite a stimulating discussion! It appears the sweet spot would be as follows: 7507 Dual A/C Power.....~ 750 Dual RSP4 with 256 MEM .~900 VIP2-50 with 128 MB RAM.~400 Now this can all be obtained for about 2000.00 perhaps... The problem is the Fast Ethernet Interfaces CX-FEIP-2TX ( 400?) PA-FE-TX (250) The PA-2FE-TX is about 1600.00- better to get a second PA-FE-TX with second VIP2-50 Now why is the CX-FEIP-2TX so much cheaper than the PA-2FE-TX ????? Alexander Hagen Etheric Networks Incorporated, A California Corporation 527 Sixth Street No 371261 Montara CA 94037 Main Line: (650)-728-3375 Direct Line: (650) 728-3086 Cell: (650) 740-0650 (Does not work at our office in Montara) Home: (Emgcy or weekends) 650-728-5820 fax: (650) 240-1750 http://www.etheric.net -----Original Message----- From: Roldan, Brad [mailto:BRoldan@covad.com] Sent: Sunday, February 08, 2004 12:40 PM To: Alexander Hagen Subject: RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 or other vendor ? Alex, I used the RS3000 extensively in a previous life for a Metro E provider. These are great Layer 2 switches. When it comes to Layer 3 services, Riverstone has been lacking. The last firmware revision I looked at was in the 9.x series. At that time, routing protocols, such as BGP, were still evolving in terms of basic support. For instance, at the time BGP communities were not supported. I don't know hoe Riverstone's support for Layer 3 routing has evolved since 9.x. Hope this helps. Brad -- Covad Communications 2510 Zanker Road San Jose, CA 95131 +1-408-434-2048 broldan(a)covad.com -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Alexander Hagen Sent: Saturday, February 07, 2004 5:49 AM To: nanog(a)merit.edu Subject: RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 or other vendor ? Montara is between Pacifica and Half Moon Bay. Everyone has a different perspective - but all valid. However I would say if you are going to go Cisco - and you have no other BGP gear under Smartnet - you might look at the 3725 maxed out. It is new and you will get support and available for 5,000.00 online, equipped with two onboard Fast Ethernet ports. You are likely to buy only single FE modules at 350.00 rather than 2FE's which are hard to find for cheap, and upgrading memory to 256 Megs DRAM is only an addl 150.00. With that said.... I found a rather stupid article that gave the Riverstone high marks. http://www.nwfusion.com/reviews/2003/0714rev.html?page=1 http://research.mwjournal.com/data/jspdetail?id=1025118725_252&type=PROD &src=mwave&x=841473789 The RS 3000 has 20 gbps non blocking. I am likely to go with the Riverstone. I think I can get it for under 2K with 24 10/100 ports, 256 MB of memory, and 20 gbps non blocking switching fabric. Although I will likely place a Cisco box behind it (eventually) for IPSec and the like. Platform Features Feature-rich Wire-speed Services * IP routing, unicast, and multicast * Routing in hardware on each line card * LSR and LER MPLS support in hardware * RSVP-TE and LDP label distribution and signaling * MPLS traffic engineering support * Security (ACLs, L2 filters) * Layer 4 application-flow switching and QoS * Network Address Translation (NAT) * Hardware-based Rate Limiting * Jumbo Frame support * VLANs based on port or protocol * Server Load Balancing (LSNAT) Highly Fault Tolerant * Redundant power supplies (RS 3000) * Hot-swappable media modules * Standards-based VRRP * Layer 2 and 3 redundant protocol support Extensive Management * Wire-speed full RMON/RMON2 * SNMP manageable * SSH * RADIUS * TACACS+ * RS-232 (out-of-band management) * Command Line Interface (CLI) Interfaces 10/100 Base-TX 100 Base-FX 1000 Base-SX 1000 Base-LX 1000 Base-TX 1000 Base-LH (70Km) T1/E1 T3/E3 ATM-OC-3c Up to 4,096 VLANs Up to 256,000 routes Up to 20,000 security/access control filters Up to 512,000 Layer 4 application flows Up to 256,000 Layer 2 MAC addresses RS 1000: 12 Gbps non-blocking switching fabric RS 1000: 4.6 million packets per second routing throughput RS 3000: 20 Gbps non-blocking switching fabric RS 3000: 9.5 million packets per second routing throughput MTBF (predicted) > 200,000 hours Physical Dimensions: 3.25" H x 17" W x 18.5" D (8.25 cm x 43.2 cm x 47 cm) Weight: 20 lbs. (9.1 kg) Environmental Specifications Operating Temp: +0º to +40ºC (32º to 104ºF) Non-operating Temp: -40º to +70ºC (-40º to 158ºF) Operating Relative 10% to 90% (non-condensing) Humidity: Non-operating 5% to 95% maximum Relative Humidity: (non-condensing) Altitude, Operating 10,000 ft (3,000 m) maximum and Non-operating: Shock and Vibration:GR63 Power Requirements AC Input current: 3.0 A - 1.5 A AC Input voltage: 100 to 240 VAC AC Frequency: 50 to 60 Hz DC Input current: 8.0 A DC Input voltage: -48 to -60 VAC Agency Standards and Specifications Safety: Certified UL1950, CSA C22.2 No. 950, EN60950, IEC950, and 72/73/EEC Electromagnetic Compliant with the requirements of compatibility: FCC Part 15, CSA C108.8, EN55022, VCCI, EN50082-1, and 89/336/EEC Standards Supported IETF Standards Support RFC No. Title RFC 768 UDP RFC 783 TFTPv2 RFC 791 IP RFC 792 ICMP RFC 793 TCP RFC 826 ARP RFC 854 Telnet RFC 951 BootP RFC 1058 RIP v1 RFC 1075 DVMRP RFC 1112 Host Extensions for IP Multicasting RFC 1157 SNMPv1 RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments RFC 1245 OSPF Protocol Analysis RFC 1246 Experience with the OSPF Protocol RFC 1256 ICMP Router Discover Message RFC 1265 BGP Protocol Analysis RFC 1266 Experience with the BGP Protocol RFC 1267 BGP-3 RFC 1269 Definitions of Managed Objects for BGP-3 RFC 1332 PPP IPCP RFC 1349 Type of Service in the Internet Protocol Suite RFC 1397 Default Route Advertisement in BGP-2 and BGP-3 RFC 1403 BGP OSPF Interaction RFC 1519 CIDR: an Address Assignment and Aggregation Strategy RFC 1542 Clarifications and Extensions for the Bootstrap Protocol RFC 1552 PPP IPXCP RFC 1570 PPP LCP Extensions RFC 1586 Guidelines for Running OSPF Over Frame Relay Networks RFC 1587 OSPF NSSA Option RFC 1631 IP NAT RFC 1638 PPP BCP RFC 1657 Definitions of Managed Objects for BGP-4 using SMIv2 RFC 1661 PPP RFC 1662 PPP in HDLC-like Framing RFC 1745 BGP-4/IDRP for IP and OSPF Interaction RFC 1765 OSPF Database Overflow RFC 1771 BGP-4 RFC 1772 Application of BGP in the Internet RFC 1773 Experience with the BGP-4 Protocol RFC 1774 BGP-4 Protocol Analysis RFC 1793 Extending OSPF to Support Demand Circuits RFC 1812 Router Requirements RFC 1918 Address Allocation for Private Internet Space RFC 1923 RIPv1 Applicability Statement for Historic Status RFC 1930 Guidelines for creation, selection, and registration of an AS RFC 1966 BGP Route Reflection Alternative to full mesh IBGP RFC 1990 PPP MLP RFC 1997 BGP Communities Attribute RFC 1998 BGP Community Attribute in Multi-home Routing RFC 2082 RIP-2 MD5 Authentication RFC 2131 DHCP RFC 2225 Classical IP and ARP over ATM RFC 2236 Internet Group Management Protocol, Version 2 RFC 2270 Using a Dedicated AS for Sites Homed to a Single Provider RFC 2328 OSPFv2 RFC 2329 OSPF Standardization Report RFC 2236 IGMP-2 RFC 2338 VRRP RFC 2362 PIM-SM RFC 2370 OSPF Opaque LSA Option RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option RFC 2390 Inverse Address Resolution Protocol RFC 2391 LSNAT Load Sharing using IP Network Address Translation RFC 2427 Multi-protocol Interconnect over Frame Relay RFC 2439 BGP Flap Damping RFC 2547 BGP/MPLS VPNs RFC 2453 RIPv2 RFC 2519 A Framework for Inter-Domain Route Aggregation RFC 2570 Introduction to Version 3 of the Internet-standard Network Management Framework RFC 2571 An Architecture for Describing SNMP Management Frameworks RFC 2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) RFC 2573 SNMP Applications RFC 2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) RFC 2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) RFC 2576 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework RFC 2578 Structure of Management Information Version 2 (SMIv2) RFC 2579 Textual Conventions for SMIv2 RFC 2580 Conformance Statements for SMIv2 RFC 2615 PPP over SONET/SDH RFC 2684 Multi-protocol Encapsulation over ATM Adaptation Layer 5 RFC 2702 Requirements for Traffic Engineering over MPLS RFC 2763 Dynamic Hostname Exchange Mechanism for IS-IS RFC 2796 BGP Route Reflection Alternative to full mesh IBGP RFC 2842 Capabilities Advertisement with BGP-4 RFC 2858 Multi-protocol Extensions for BGP-4 RFC 2865 Remote Authentication Dial In User Service (RADIUS) RFC 2866 RADIUS Accounting RFC 2918 Route Refresh Capability for BGP-4 RFC 2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations RFC 2963 Dynamic Hostname Exchange Mechanism for IS-IS RFC 2966 Domain-wide Prefix Distribution with Two-Level IS-IS RFC 2973 IS-IS Mesh Groups RFC 3031 Multi-protocol Label Switching Architecture RFC 3032 MPLS Label Stack Encoding RFC 3036 LDP Specification RFC 3065 Autonomous System Confederations for BGP RFC 3137 OSPF Stub Router Advertisement RFC 3209 RSVP-TE Extensions to RSVP for LSP Tunnels RFC 3210 Applicability Statement for Extensions to RSVP for LSP Tunnels IETF Standards MIB Support RFC No. Title RFC 1471 PPP-LCP-MIB RFC 1472 PPP-Sec-MIB RFC 1473 PPP-IP-NCP-MIB RFC 1474 PPP-Bridge-NCP-MIB RFC 1493 Bridge-MIB RFC 1657 BGP4 using SMIv2-MIB RFC 1595 SONET/SDH Interface Type-MIB RFC 1695 ATM-MIB RFC 1757 RMON-MIB RFC 1724 RIPv2-MIB RFC 1850 OSPFv2-MIB RFC 1907 SNMPv2-MIB RFC 2011 IP-MIB RFC 2012 UDP-MIB RFC 2013 TCP-MIB RFC 2021 RMON2 using SMIv2-MIB RFC 2096 IP-Forward-MIB RFC 2115 Frame-Relay-MIB RFC 2233 IF using SMIv2-MIB RFC 2358 EtherLike-MIB RFC 2495 DS1, E1, DS2, E2 Interface Types-MIB RFC 2496 DS3/E3-MIB RFC 2618 Radius-Auth-Client-MIB RFC 2668 IEEE 802.3 Medium Attachment Units (MAUs)-MIB RFC 2674 P-Bridge-MIB, Q-Bridge-MIB RFC 2787 VRRP-MIB Standards and Protocols IP routing: RIPv1/v2, OSPF, BGP-4, IS-IS Multicast support: IGMP, DVMRP, PIM-DM, PIM-SM QoS: Application level, RSVP IEEE 802.1D IEEE 802.1p IEEE 802.1Q IEEE 802.1x IEEE 802.3 IEEE 802.3ad IEEE 802.3u IEEE 802.3x IEEE 802.3z Alexander Hagen Etheric Networks Incorporated, A California Corporation 527 Sixth Street No 371261 Montara CA 94037 Main Line: (650)-728-3375 Direct Line: (650) 728-3086 Cell: (650) 740-0650 (Does not work at our office in Montara) Home: (Emgcy or weekends) 650-728-5820 fax: (650) 240-1750 http://www.etheric.net -----Original Message----- From: william(a)elan.net [mailto:william@elan.net] Sent: Saturday, February 07, 2004 5:19 AM To: Alexander Hagen Subject: Re: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 or other vendor ? 7500 is your best option indeed, I'm using several of these and have close to 300Mb passing through at max, primarily ethernet, but also have serial and ATM interfaces; multiple BGP feeds with full table and quite complex access lists - and its all WORKING! One thing to remember is that while 7500 line was started long ago, there have been new router cards and VIP cards released. So if you have 7500 with RSP4 or RSP8 and use VIP2-50 with newear PA modules, you're really not in 1995 any more... For VOIP you'll need different routers but I don't think you were talking about using your core router to provide voip handoffs. Traffic accounting is working fine with 7500 and external unix system that actually does it though SNMP. P.S. Where is Montara located? I see familar 650 area code and I though I knew all the cities nearby, but definetly never been to Montara... On Sat, 7 Feb 2004, Alexander Hagen wrote: > > I have been looking for a sub 5K router on the used market to support > around 30-50 megs peak traffic. > > I have found the 7507/7513 but these things appear to have been > manufactured in 1995 ! > > Then there is the 7206 and the 7206 VXR - I guess the 7206 itself is > just as old as the 7507 and 7513 and the same price at the least - > perhaps because of its form factor. > > The 7206 VXR makes me feel a little better - as it was manufactured in > 1999? > > We are looking at a pure Ethernet environment - but with the desire to > support a lot of value added services - such as IPSEC, VoIP, traffic > accounting. Cisco's have traditionally been good at PRI and T-1 and T-3 > type interfaces - which we don't really need -which leads me to think > Foundry might be an option. > > Juniper appears to be at least 7,000.00 - and I am worried about support > - based on other articles I have seen. > > So the question is would a layer 3 switch be a good idea with a lot of > memory - for example the Cat 6509 ? > > Perhaps foundry BigIron with Jetware ? > > Please give me your thoughts - it is hard to believe that the 7507 and > 7513 are my best options.... > > Alexander Hagen > Etheric Networks Incorporated, A California Corporation > 527 Sixth Street No 371261 > Montara CA 94037 > Main Line: (650)-728-3375 > Direct Line: (650) 728-3086 > Cell: (650) 740-0650 (Does not work at our office in Montara) > Home: (Emgcy or weekends) 650-728-5820 > fax: (650) 240-1750 > http://www.etheric.net

10 12

standard transit arrangements
by Sven Huster 22 Mar '04

22 Mar '04

Hello I just wanted to find out what the "standard" arrangements are when one buys transit traffic. I've been left in charge of this now, without haven't been doing this before :-( So what normally you buy x amount of bandwidth over a physical line e.g. 45Mb/s over FastEthernet or so. They then charge you for excessive usage based on 95th percentile. Is there anything else I need to keep an eye on? Thanks Sven

1 1

[IP] VeriSign prepares to relaunch "Site Finder" -- calls technologists "biased"
by Gregory Hicks 09 Mar '04

09 Mar '04

From Dave Farber's IP list... --------------------------- http://www.washingtonpost.com/wp-dyn/articles/A25819-2004Feb9_2.html VeriSign Reconsiders Search Service "Site Finder was not controversial with users, 84 percent of whom said they liked it as a helpful navigation service," said Tom Galvin, VeriSign's vice president of government relations. "We continue to look at ways we can offer the service while addressing the concerns that were raised by a segment of the technical community." Galvin said that the continued opposition stems from "an ideological belief by a narrow section of the technological community who don't believe you should innovate the core infrastructure of the Internet." Critics also claim that VeriSign must run the domains as a public trust, not a profit-making opportunity. VeriSign is the sole operator of the dot-com and dot-net registries under a contract with ICANN. "I don't begrudge them their profit, but someone in an effectively regulated monopoly position shouldn't use their power for their own profit, beyond the terms under which the community gave it to them," said Steven Bellovin, co-director of the Internet Engineering Task Force's Security Area. Paul Rothstein a law professor at Georgetown University and a paid VeriSign consultant, said that the critics have some legitimate objections but others are motivated by the scientific and technology communities' "bias on policy." Still, he added, it would be tough for VeriSign to win the public relations war because its opponents are highly regarded technologists. ICANN will reserve judgment until VeriSign decides to relaunch Site Finder, said General Counsel John Jeffrey. VeriSign assured ICANN that it would give 60 to 90 days' warning to resolve any remaining technological problems, Jeffrey said. In the meantime, ICANN is waiting for a final report on Site Finder from its Security and Stability Advisory Committee. Committee Chairman Steve Crocker said he doubts that Site Finder can be changed enough that it won't threaten the Internet's underlying infrastructure. "I thought people were relieved that they took it down and it's hard to believe that there would be any quietness if they brought it back," Crocker said. <SNIP> _____Related Coverage_____ <http://www.washingtonpost.com/wp-dyn/articles//wp-dyn/articles/A57670-2003O…> VeriSign Service Spawns More Criticism (washingtonpost.com, Oct 7, 2003) <http://www.washingtonpost.com/wp-dyn/articles//wp-dyn/articles/A42107-2003O…> VeriSign Agrees To Shut Down Search Service (The Washington Post, Oct 4, 2003) <http://www.washingtonpost.com/wp-dyn/articles//wp-dyn/articles/A64437-2003S…> With Site Finder, VeriSign Sparks Internet-wide Criticism (washingtonpost.com, Sep 25, 2003) _____ICANN Headlines_____ <http://www.washingtonpost.com/wp-dyn/articles//wp-dyn/articles/A13538-2004F…> Congress Eyes Internet Fraud Crackdown (washingtonpost.com, Feb 4, 2004) <http://www.washingtonpost.com/wp-dyn/articles//wp-dyn/articles/A23641-2004J…> XO Owner Again Bids For Telecom (The Washington Post, Jan 17, 2004) <http://www.washingtonpost.com/wp-dyn/articles//wp-dyn/articles/A47327-2003D…> U.N. Sets Aside Debate Over Control of Internet (The Washington Post,Dec 9, 2003) <http://www.washingtonpost.com/wp-dyn/technology/techpolicy> Tech Policy Section ------------------------------------- Archives at: http://www.interesting-people.org/archives/interesting-people/ ------------- End Forwarded Message ------------- ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: ghicks(a)cadence.com "The trouble with doing anything right the first time is that nobody appreciates how difficult it was." When a team of dedicated individuals makes a commitment to act as one... the sky's the limit. Just because "We've always done it that way" is not necessarily a good reason to continue to do so... Grace Hopper, Rear Admiral, United States Navy

35 51

Possibly yet another MS mail worm
by Todd Vierling 02 Mar '04

02 Mar '04

This one may be a variant of the recent worms. It's spreading by way of zipfile attachments. I don't have more info yet, but my $orkplace has just been hit by it and it's unknown to McAfee and Symantec at this time. It's not W32.Netsky, as best I can tell, because of the attachment filename: this one uses things like accabaacc.zip that are new to me. I don't have more info on it at this time, but will try to snare a sample in transit if it hits my home system. Just a heads-up, -- -- Todd Vierling <tv(a)duh.org> <tv(a)pobox.com>

15 20

First Post! Annoying Debate at Work.
by Christopher Aldridge 29 Feb '04

29 Feb '04

NOTE: I have been a nanog observer for nearly a year. The following may be slightly off topic, but it seems as though nanog is my last hope. Recently at work, I've been battling fellow coworkers on a very simple debate. The fact that I will not "give in" on my argument really makes me look arrogant, but I absolutely refuse to let this one go without logical reason! The argument non-persuasively put is as follows: Is a USB Ethernet Adapter a "converter"? Personally, I say "no". My coworkers seem to say "yes". My argument: 1) Ethernet isnt "converted" to USB. The adapted information from the ethernet segment may traverse the USB segment if the NIC adapts it to the CPU, but is never "converted" to USB. You can use USB for many things, thus making it an underlying "serial bus" in which other technologies can traverse. Whatis.com definition: USB (Universal Serial Bus) is a plug-and-play interface between a computer and add-on devices (such as audio players, joysticks, keyboards, telephones, scanners, and printers). With USB, a new device can be added to your computer without having to add an adapter card or even having to turn the computer off. USB in this scenario would be synonymous with PCI, in regards to the type of technology that interfaces with the cpu. 2) I cant seem to place "converter" above layer 1. Yet a Network adapter ( both PCI or USB ) have layer 2 mac addresses that are stored into the PROM from the manufactor. From my understanding, if an ethernet frame comes in via cat5, and is destined for the wrong MAC address, the traffic will not move up the OSI model and to the PC; It will be dropped right there and then. Only frames destined for the correct MAC or broadcast will traverse the USB portion. If this is true, then aparantly our "converter" is doing a lot more than "converting" ethernet to "USB"! - Filtering, forwarding, encapsulating, de-encapsulating, etc. 3) Just because a device has two physical mediums of connectivity, dosent make it a "converter". My coworkers argue that a USB Ethernet adapter is an "Ethernet to USB Converter". If this is true, then the following could be said: a. A PCI Ethernet Adapter is a "converter" because it "converts" Ethernet to PCI. b. An Alcatel switch w/ a T1 and a DS3 controller card would be a "converter" because it "converts" cat5 from the T1 card to coax on the DS3 card. c. Lastly ( I love this one ), An integrated Ethernet adapter on a motherboard is a "converter" because it "converts" ethernet to uhh ?? processor? Riiiiight" My co-workers arguments are basically that because Ethernet is plugged into one side, and usb is plugged into the other, it's a converter. I strongly that's an understament if not an incorrect statement. Whats your take and why? Input from ANY of you would be GREATLY appreciated. Otherwise, a simple "I aggree with you" will be fine also! Thanks in advance! Christopher Aldridge Network Analyst CCNA/MCP/MCSA

6 7

Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by Michael.Dillon＠radianz.com 29 Feb '04

29 Feb '04

>[1] Should VoIP include 911/999 service, and how does one resolve the >various geographic location issues associated with this. Anyone who claims to answer this one should consider the how to handle the case of a British subscriber to a VoIP service who travels to the USA, Canada, all over Europe and Australia. What would happen if a native of one of those countries picked up the VoIP device and dialled for emergency services. In Canada and the USA they would dial 911 In the UK they would dial 999 In Europe they would dial 112 or possibly one of the various legacy national numbers for emergency service. And in Australia they would dial 000. Do you route all these calls to Britain? Do you use some sort of geographical locator database for IP addresses to route the call? Do you route the call based on the actual number dialed, i.e. all 000 calls go to Australia? Or do we pass legislation requiring the RIRs and all ISPs to maintain a database with the current physical location of every device with an IP address? Personally I don't think the regulators have a clear enough grasp of the technical issues to be prescribing solutions for this issue. --Michael Dillon P.S. I think a solution lies in the general direction of converting the entire world to use 112 for emergency services and having the VoIP services set up an automated system that rings back whenever your phone connects using a different IP address and asks you where you are.

12 19

Re: Lawsuit on ICANN (was: Re: A few words on VeriSign's sitefinder)
by neil＠DOMINO.ORG 28 Feb '04

28 Feb '04

> http://biz.yahoo.com/rc/040226/tech_verisign_2.html can't say I'm surprised. Another nail in the Verisign coffin.

9 9

RE: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by Pendergrass, Greg 28 Feb '04

28 Feb '04

I think how reliable the internet needs to be depends on what you want to use it for: if you want to call an ambulance you DON'T use the internet, if you want to transfer money from one account to another you DO use the internet. In other words right now it's good for things that are important but not critical from an immediate action standpoint. If it can wait until tomorrow use the internet otherwise pick up the phone and dial. I can count on one hand the number of times I've had problems with my landline in my entire life but I can count on two hands the number of problems I've had with my internet connection in one year. If we ever want the internet to grow from being a handy medium for exchanging data to the converged, all-encompassing communications medium then it needs to go from "Mom, the internet's down again!" to "Dude, my internet connection went down yesterday, that ever happen to you before?". For that to happen there has to be more accountability in the industry. -GP -----Original Message----- From: Steve Gibbard [mailto:scg@gibbard.org] Sent: 26 February 2004 00:30 To: nanog(a)merit.edu Subject: How relable does the Internet need to be? (Was: Re: Converged Network Threat) Having woken up this morning and realized it was raining in my bedroom (last night was the biggest storm the Bay Area has had since my house got its new roof last summer), and then having moved from cleaning up that mess to vacuuming water out of the basement after the city's storm sewer overflowed (which seems to happen to everybody in my neighborhood a couple of times a year), I've spent lots of time today thinking about general expectations of reliability. In the telecommunications industry, where we tend to treat reliability as very important and any outage as a disaster, hopefully the questions I've been coming up with aren't career ending. ;) With that in mind, how much in the way of reliability problems is it reasonable to expect our users to accept? If the Internet is a utility, or more generally infrastructure our society depends on, it seems there are a bunch of different systems to compare it to. In general, if I pick up my landline phone, I expect to get a dialtone, and I expect to be able to make a call. If somebody calls my landline, I expect the phone to ring, and if I'm near the phone I expect to be able to answer. Yet, if I want somebody to actually get through to me reliably, I'll probably give them my cell phone number instead. If it rings, I'm far more likely to able to answer it easily than I am my landline, since the landline phone is in a fixed location. Yet some significant portion of calls to or from my cell phone come in when I'm in areas with bad reception, and the conversation becomes barely understandable. In many cases, the signal is too weak to make a call at all, and those who call me get sent straight to voicemail. Most of us put up with this, because we judge mobility to be more important than reliability. I don't think I've ever had a natural gas outage that I've noticed, but most of my gas appliances won't work without electric power. I seem to lose electric power at home for a few hours once a year or so, and after the interuption life tends to resume as it was before. When power outages were significantly more frequent, and due to rationing rather than to accidents, it caused major political problems for the California government. There must be some threshold for what people are willing to accept in terms of residential power outages, that's somewhere above 2-3 hours per year. In Ann Arbor, Michigan, where I grew up, the whole town tended to pretty much grind to a halt two or three days a year, when more snow fell than the city had the resources to deal with. That quantity of snow necessary to cause that was probably four or five inches. My understanding is that Minneapolis and Washington DC both grind to a halt due to snow with somewhat similar frequency, but the amount of snow requred is significantly more in Minneapolis and significantly less in DC. Again, there must be some threshold of interruptions due to exceptionally bad weather that are tolerated, which nobody wants to do worse than and nobody wants to spend the money to do better than. So, it appears that among general infrastructure we depend on, there are probably the following reliability thresholds: Employees not being able to get to work due to snow: two to three days per year. Berkeley storm sewers: overflow two to three days per year. Residential Electricity: out two to three hours per year. Cell phone service: Somewhat better than nine fives of reliability ;) Landline phone service: I haven't noticed an outage on my home lines in a few years. Natural gas: I've never noticed an outage. How Internet service fits into that of course depends on how you're accessing the Net. The T-Mobile GPRS card I got recently seems significantly less reliable than my cell phone. My SBC DSL line is almost to the reliability level of my landline phone or natural gas service, except that the DSL router in my basement doesn't work when electric power is out. I'm probably poorly qualified to talk about the end-user experience on the networks I actually work on, even if I had permission to. Like pretty much everybody else here, I'm always interested in doing better on reliability. And, like many of my neighbors, I'd like to be able to store stuff on my basement floor. In comparison to a lot of other infrastructure we depend on, it seems to me the Internet is already doing pretty well. -Steve On Wed, 25 Feb 2004, Jared Mauch wrote: > > Ok. > > I can't sit by here while people speculate about the possible > problems of a network outage. > > I think that most everyone here reading NANOG realizes that > the Internet is becoming more and more central to daily life even > for those that are not connected to the internet. > > From where i'm sitting, I see a number of potentially dangerous > trends that could result in some quite catastrophic failures of networks. > No, i'm not predicting that the internet will end in 8^H7 days or anything > like that. I think the Level3 outage as seen from the outside is a clear > case that single providers will continue to have their own network failures > for time to come. (I just hope daily it's not my employers network ;-) ) > > So, We're sitting here at the crossroads, where VoIP is > "coming of age". Vonage, 8x8 and others are blazing a path that > the rest of the providers are now beginning to gun for. We've already > read in press releases and articles in the past year how providers > in Canada and the US are moving to VoIP transport within their long-distance > networks. > > I keep hear of Frame-Relay and ATM signaling that is going > to happen in large providers MPLS cores. That's right, your "safe" TDM > based services, will be transported over someones IP backbone first. > This means if they don't protect their IP network, the TDM services could > fail. These types of CES services are not just limited to Frame and ATM. > (Did anyone with frame/atm/vpn services from Level3 experience the > same outage?) > > Now the question of Emergency Services is being posed here but also > in parallel by a number of other people at the FCC. We've seen the E911 > recommendation come out regarding VoIP calls. How long until a simple > power failure results in the inability to place calls? > > Now, i'm not trying to pick on Level3 at all. The trend I > outline here is very real. The reliance on the Internet for critical > communications is a trend that continues. Look at how it was used > on 9/11 for communications when cell and land based telephony networks > were crippled. > > The internet has become a very critical part of all of our lives > (some more than others) with banks using VPNs to link their ATMs back into > their corporate network as well as the number of people that use it for > just plain "just in time" bill payment and other things. I can literally > cancel my home phone line, cell phone and communicate soley with my > internet connection, performing all my bill payments without any paperwork. > I can even file my taxes online. > > We're at (or already past) the dangerous point of network > convergence. While I suspect that nobody directly died as a result of > the recent outage, the trend to link together hospitals, doctors > and other agencies via the Internet and a series of VPN clients continues > to grow. (I say this knowing how important the internet is to > the medical community, reading x-rays and other data scans at home for the > oncall is quite common). > > While my friends that are local VFD do still have the traditional > pager service with towers, etc... how long until the T1's that are > used for dial-in or speaking to the towers are moved to some sort of > IP based system? The global economy seems to be going this direction with > varying degrees of caution. > > I'm concerned, but not worried.. the network will survive.. > > - Jared > > > On Wed, Feb 25, 2004 at 09:17:30AM -0600, Pete Templin wrote: > > If an IP-based system lets you see the status of the 23 hospitals in San > > Antonio graphically, perhaps overlaid with near-real-time traffic > > conditions, I'd rather use it as primary and telephone as secondary. > > > > Counting on it? No. Gaining usability from it? You betcha. > > > > Brian Knoblauch wrote: > > > > > If you're counting on IP (a "best attempt" protocol) for critical > > >data, you've got a serious design flaw in your system... > > > > > >-----Original Message----- > > >From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > > >Pete > > >Templin > > >Sent: Wednesday, February 25, 2004 9:10 > > >To: Colin Neeson > > >Cc: nanog(a)merit.edu > > >Subject: Re: Level 3 statement concerning 2/23 events (nothing to see, move > > >along) > > > > > > > > > > > > > > >Are you sure no one died as a result? My hobby is volunteering as a > > >firefighter and EMT. If Level3's network sits between a dispatch center > > >or mobile data terminal and a key resource, it could be a factor > > >(hospital status website, hazardous materials action guide, VoIP link > > >that didn't reroute because the control plane was happy but the > > >forwarding plane was sad, etc.). > > > > > >And if the problem could happen to another network tomorrow but could be > > >prevented or patched, wouldn't inquiring minds want to know? Your life > > >might be more interesting when the fit hits the shan if you have the > > >same vulnerability. > > > > > >Colin Neeson wrote: > > > > > > > > >>Because, in the the grand scale scheme of things, it's really not that > > >>important. > > >> > > >>No one died because of it, the normal, everyday events of the world > > >>went > > >>on, > > >>unaffected by a Level 3 outage... > > >> > > >>Might be nice to know what happened, but my life will certainly not be > > >>less interesting by not having that knowledge... > > -- > Jared Mauch | pgp key available via finger from jared(a)puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. > ---------------------------------------------------------------------------- ---- Steve Gibbard scg(a)gibbard.org +1 415 717-7842 (cell) http://www.gibbard.org/~scg +1 510 528-1035 (home) Vodafone Global Content Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No. 4064873 This e-mail is for the addressee(s) only. If you are not an addressee, you must not distribute, disclose, copy, use or rely on this e-mail or its contents, and you must immediately notify the sender and delete this e-mail and all copies from your system. Any unauthorised use may be unlawful. The information contained in this e-mail is confidential and may also be legally privileged.

7 8

Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by Michael.Dillon＠radianz.com 28 Feb '04

28 Feb '04

>> I think the Internet is doing pretty well save some IOS code problems >> from time to time, and the typical root server hicups. >I'm interested to know what you mean by "typical root server hicups". >I'm trying to think of an incident which left the Internet generally >unable to receive answers to queries on the root zone, but I can't >think of one. There have been several incidents in which some root servers have hiccuped, sometimes being down for several days. But since the service they provide has N+12 resiliency, the service itself has never been unavailable. Similarly, the Internet has always had N+1 or better vendor resiliency so IOS can have problems while the non-IOS vendor (or vendors) keep on running. In fact, I would argue that N+1 vendor resiliency is a good thing for you to implement in your network and N+2 vendor resiliency is a good thing for the Internet as a whole. Let's hope that vendor P manages to get some critical mass in the market along with J and C. --Michael Dillon

3 2

Sail Ho! (was Re: Lawsuit on ICANN ...)
by Eric Brunner-Williams in Portland Maine 27 Feb '04

27 Feb '04

http://fightwls.com/

1 0