September 2001 - NANOG - lists.nanog.org

configuration lost
by Nour Rabii 10 Sep '01

10 Sep '01

hello , my 7513 lost configuration , i don't know why ? i have something like : Rbackbone#wr startup-config file open failed (Device or resource busy) Rbackbone#sh startup-config Using 35806 out of 126968 bytes %Error opening nvram:/startup-config (Device or resource busy) Best regards .

5 4

RE: Where NAT disenfranchises the end-user ...
by Roeland Meyer 10 Sep '01

10 Sep '01

|> From: Jared Mauch [mailto:jared@puck.Nether.net] |> Sent: Sunday, September 09, 2001 2:49 PM |> Let me reprhase my inital statement, "In most cases i've seen |> where someone is using NAT it's part of a security policy and not due |> to lack of available address space". Jared, those whom depend on an accident, for security, deserve what happens when the accident undoes itself. I was just over on www.netcraft.com, checking out their stats for the CodeRed worm. I was amazed at how fast IIS admins responded by applying the patches. If NAT were suddenly "fixed", any incidental security is toast. NAT was never designed for, and was never intended as, a security method. Any current protection is strictly the result of a side-effect. The side-effect that breaks the internet connection. It's a result of the connection being broken. A properly built firewall is much more effective and definitely more deterministic. Neither is it vulnerable to a "fix patch".

1 0

IDC management software
by Benjie Ko 10 Sep '01

10 Sep '01

Hello, I dont know if this is the right list to email this. No flames please. For those who are operating IDCs or server farms, what software do you use to monitor/manage your client's server farm. Monitor includes latency,bandwidth usage,cpu/mem/disk usage. Also, any providers for a DS3 connection colocated at 1 wilshire in LA (email me privately for this)? Regards, Benjie __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com

1 0

once again: RE: Where NAT disenfranchises the end-user
by Roeland Meyer 10 Sep '01

10 Sep '01

|> From: Adam McKenna [mailto:adam-nanog@flounder.net] |> Sent: Friday, September 07, 2001 4:49 PM |> I realized that the NAT argument is just a smokescreen which |> enables Meyer to |> continue his prefix filtering flamewar. The sooner you all |> stop paying |> attention to him, the better off this list will be. Aside from the fact that you seem to have some personal grudge. You are wrong. For one thing, this was, until now, far from flamewar. What you have done, however, is akin to invoking "Nazi". You may not care that NAT issues are restricting the distribution of ICANN's deliberations, but many other do. Folks here may not like H.323 but it is, unfortunately, the best tool we have. Those that can't afford to have static IP addresses will not be able to participate fully. FYI, the Montevideo sessions are going on now. Travel expenses are onerous and telephony expenses are almost as bad. VOIP is the only means that we can do global participation, at reasonable expense and within ICANN budget (cheap) whilst not bankrupting the participants. Client applications are almost universally available, at little to zero cost. Server-side code is widely available as open-source. The only thing mucked up is the stuff in the middle. Sir, that involves network operations, by ANY stretch of the imagination, and bringing that point up is not flamewar. If you can come up with something better then do so. BTW, I think it's a rotten shame that the major ISPs aren't doing something to help with this. I'm not talking about donations to ICANN either. I'm talking about resources, connectivity, and other sorely needed assistance. There should be no reason that the Berkman Center is the only resource provider. Except for randy, mike, patrick, and very few others, you guys have your very own constituency fercrisakes and y'all aren't doing squat! "I gave at the office" ain't cuttin' the mustard. No one behind a NAT boundary can participate in the online meetings (the info of which was sent in my original message, forwarded from the DNSO-GA). That we took a few detours, in these discussions, is the nature of unmoderated group discussions. Certain operational policies are hampering the business development of the internet. They break the Internet. 1) UDRP and uncertainty over DN ownership (being addressed in ICANN/DNSO). 2) Anti-mailer relay activities eliminate certain business models. 3) Instability and unreliability of access makes business nervous (NorthPoint, ATT-CA?) 3a) NAT breaks end2end connectivity with end-users (see H.323 for examples). 3b) lack of true multi-homing capability. 3c) routing issues 3d) etc. If I may don my marketing hat for a mo; from what I'm seeing, VOIP conferencing may be the next killer-app of the Internet and may be the ONLY thing that'll let anyone else play evenly with the ILECs. Like firearms, it levels the playing field, for the little guys. It also does in the IXCs, unless they go there first. So, unless you can come up with something better than H.323, I suggest that we find means to support it rather than breaking it further. NAT is a rather largish problem here. Unless, of course, you *like* the current economic climate. This is not intended as a rant or a flame. Those who feel otherwise, can complain directly to me. -- R O E L A N D M J M E Y E R Managing Director Morgan Hill Software Company tel: +1 925 373 3954 cel: +1 925 352 3615 fax: +1 925 373 9781 http://www.mhsc.com

4 3

RE: Where NAT disenfranchises the end-user ...
by Roeland Meyer 09 Sep '01

09 Sep '01

|> From: Eric A. Hall [mailto:ehall@ehsco.com] |> Sent: Thursday, September 06, 2001 9:49 PM |> > "Charles Sprickman" <spork(a)inch.com> |> |> > NAT has it's place, and we have many happy customers that are quite |> > pleased with their NAT'd connections; some simple, some fancy. |> |> NATs are a band-aid. ip_masq started out as a cheap way to cheat ISPs that wouldn't allocate IP addrs to dial-up users (home users have no need for a LAN?), or wanted to charge an arm'n'leg for every IP addr. This irked the Linux community sufficiently that they wrote a "cure". Unfortunately, the popularity of the "cure" superceded the need. |> > What irks me more than NAT are crappy protocols like FTP |> and H.323 that |> > make too many assumptions about how much of my machine I |> am willing to |> > expose in order to communicate using these protocols. |> |> FTP was designed for ARPANET, H.323 was designed to work |> over ANY packet |> network. Neither of them were designed for TCP/IP in particular. FTP has well outlived it's usefullness. There are better alternatives. It was a good experiment...on how we shouldn't do some things. NDAs stop me from commenting about H.323. Just know that every SuSE Linux 7.2 distro comes with www.openh323.org and www.opengatekeeper.org software, complete with instructions on interfacing it with NetMeeting3. No, it won't work across NAT boundaries. |> They don't break the end-to-end design principles though. |> Neither do network games, chat tools, and other |> peer-to-peer protocols that run in elected-server |> or server-to-server modes. Damn, more NDA problems <g>. It is sufficient to state that one of the challenges facing p2p projects is presented by the large NAT population. Actually, dynamic IP isn't so good either. But, we are getting around that with LDAP directories. The real problems arise when two clients report the same RFC1918 address to the directory. If both are behind a single NAT'd IP then it gets really fun. |> The fact is that I can write an Internet-compliant |> application in about two minutes that will break every |> NAT ever sold, simply because they don't have a |> proxy for the protocol. NATs violate fundamental Internet |> principles. They were broken from the start. Agreed. It is all fine and dandy to say what developers should and shouldn't do. Rarely, are those practicing such refined methodology, actually writing the code or paying for same. Market needs drive business requirements, which drives code, which drives operations, which *may* drive more market needs. NAT was an answer to a market need that operations wasn't fulfilling. The pent-up market demand for multi-homeing may drive solutions that the operations community may not like. Guys, this is easy. Start accepting prefixes out to /24 like you are already getting paid to do. Then ARIN can start selling /24s and matching ASNs, like they should. Yes, you might lose some revenue from IP addr sales, but the alternatives might be less desireable.

9 9

RE: Where NAT disenfranchises the end-user ...
by Roeland Meyer 09 Sep '01

09 Sep '01

|> From: Jon Mansey [mailto:JMansey@interpacket.net] |> Sent: Thursday, September 06, 2001 11:41 AM |> |> Isnt part of the solution here for ppl to write NAT-aware |> applications? |> |> I got this idea from a bugtraq post about gnutella that is able to |> detect and announce a different IP address than that of its actual |> private host IP based on what its internet-facing public IP is. |> |> Im sure there are a host of reasons why this is not a good idea from |> a security POV, but its a start, no? |> |> Im not disputing that a NATed connection should not be sold as "full |> Internet connectivity", I agree, but in terms of making it look and |> feel like one, I think we're close. Two software development houses, playing nice with each other, is more rare than two ISPs doing same. The bottom-line is that it comes right off the bottom-line. You can't deny that it's extra work/cost and effects time-to-market. Remember, in software development, it's the second 90% that kills the project. Consider the straw that broke the camel's back. Then consider that 80% of all software projects never make it to market. Then consider that most developers are NOT network engineers. They expect the network to *be there*, period.

8 7

RE: Where NAT disenfranchises the end-user ...
by Daniel Senie 09 Sep '01

09 Sep '01

At 02:30 PM 9/9/01, woody weaver wrote: >I'm not sure who was first, in terms of IOS NAT and ip_masq. If memory >serves (and it usually doesn't) then 11.2 was released around Aug 97. I >don't see any easy way to identify the release date. > >However, I think the linux code is older, although of course its largely >based upon the BSD firewall code. Proteon was shipping NAT (NAPT) in routers in 1994 or there abouts, well before Cisco. It was popular on the small GT60 router, especially in southeast asia, where ISPs wouldn't give out anything other than single addresses, and at the time getting a dedicated link was nearly impossible. NAT (NAPT) allowed them to connect up small offices. Of course Proteon neglected to tell the world about this or most other features. Marketing really does matter... ----------------------------------------------------------------- Daniel Senie dts(a)senie.com Amaranth Networks Inc. http://www.amaranth.com

1 0

Happy Billenium
by Lee Watterworth 09 Sep '01

09 Sep '01

Epoch has rolled to 1 billion seconds since Jan 1, 1970. Lee -------------------------- Sent from my BlackBerry Wireless Handheld (www.BlackBerry.net)

3 2

Earthlink or BBN Tech Support? Forget it... Latency in Oakland/San Jose...
by Marcos R. Della 09 Sep '01

09 Sep '01

Ok, several days later and many multi-hour waits to get through to someone who knows something at Earthlink has finally resulted in this posting since I can't get help any other way. Maybe someone can shed some light on if anyone is working on this particular problem. Oakland, CA POP for mindspring/earthlink appears to have significant latency and packet loss problems for the last week or so independent of time of day. This appears to happen either through a session via bbnplanet links or even through their own peering sessions there. This might very well be nothing more than a BBNPlanet meltdown in San Jose, however the first two included traceroutes show something other than BBN... Any clues or anyone from either of these places care to comment? Examples include: 1 <10 ms <10 ms <10 ms netopia.cstone.com [192.168.124.1] 2 20 ms 40 ms 30 ms user-38lc1g1.dialup.mindspring.com [209.86.6.1] 3 90 ms 360 ms 30 ms cisco-g4-0-0.oak.mindspring.net [209.86.81.129] 4 460 ms * 441 ms serial2-0-9.hsipaccess1.SanFrancisco1.Level3.net [166.90.48.37] ... 1 <10 ms <10 ms <10 ms netopia.cstone.com [192.168.124.1] 2 151 ms 60 ms 20 ms user-38lc1g1.dialup.mindspring.com [209.86.6.1] 3 30 ms 30 ms 30 ms cisco-g4-0-0.oak.mindspring.net [209.86.81.129] 4 470 ms 481 ms 471 ms sl-gw9-sea-1-0-0.sprintlink.net [144.232.218.5] 5 470 ms 461 ms 461 ms sl-bb10-sea-1-3.sprintlink.net [144.232.6.101] ... 1 <10 ms 10 ms <10 ms netopia.cstone.com [192.168.124.1] 2 30 ms 30 ms 30 ms user-38lc1g1.dialup.mindspring.com [209.86.6.1] 3 30 ms 30 ms 30 ms cisco-g4-0-0.oak.mindspring.net [209.86.81.129] 4 30 ms 40 ms 30 ms s3-1-0.oakland-cr2.bbnplanet.net [4.0.68.117] 5 30 ms 40 ms 30 ms f0-0.oakland-br1.bbnplanet.net [4.0.16.1] 6 30 ms 40 ms 30 ms p5-2.snjpca1-cr1.bbnplanet.net [4.0.1.194] 7 30 ms 30 ms 40 ms p1-0.snjpca1-br1.bbnplanet.net [4.24.9.133] 8 451 ms 441 ms 450 ms p2-0.paix-bi1.bbnplanet.net [4.24.7.62] 9 431 ms 440 ms 441 ms p7-0.paix-bi2.bbnplanet.net [4.0.3.142] ... 8 * 30 ms 30 ms p9-0.snjpca1-br2.bbnplanet.net [4.24.9.130] 9 20 ms 30 ms 40 ms p1-0.sjccolo-dbe2.bbnplanet.net [4.24.6.249] 10 30 ms 40 ms 30 ms p6-0.sanjose1-nbr2.bbnplanet.net [4.0.6.233] 11 30 ms * 30 ms p12-0-0.sanjose1-cr2.bbnplanet.net [4.0.3.198] 12 431 ms 440 ms 461 ms s2-1-0.xsanjose15-abovenet.bbnplanet.net [4.0.85.5] 13 431 ms * 441 ms core6-sjc6-oc3.sjc1.above.net [207.126.96.105]

2 1

RE: web pages not loading (from certain networks) but not a routi ng issue.
by Nanog 08 Sep '01

08 Sep '01

It's incredibly strange... After testing for the last 24 hours: One thing seems constant encrypted traffic passes without problem (at normal rates of speed). Unencrypted traffic has problems from various networks (even when I try HTTP on different ports). It also seems that it's independent of Windows/IIS. We spent 7.5 hours on the phone with Cisco Friday validating our switches, and our routers. No problems there. Cisco thought it was Code Blue, but my tests using Unix machines are indicating that may not be the case. I've setup a few files to test with (they are all the same ActiveState PERL file): http://www.ware.net:2329/perl.msi and http://www.ware.net/perl.msi and https://store.ware.net/perl.exe <--- This one works for everyone. and http://store.ware.net/perl.exe and http://209.67.152.157/perl.exe <--- Unix Any ideas? -----Original Message----- From: Bruce Pinsky [mailto:bep@whack.org] Sent: Friday, September 07, 2001 12:03 PM To: Nanog; nanog(a)merit.edu Subject: Re: web pages not loading (from certain networks) but not a routing i ssue. At 9/7/2001 07:52 AM -0700, Nanog wrote: >Ok guys, > >Interesting problem that seems to have started on Friday. > >Here's the deal, it seems that certain (not all) web pages on various sites >we host are not loading for certain customers. It started on Friday with >visitors on Verizon DSL waiting forever for pages to load. > >Yesterday and today PacBell DSL and some Netcom customers started >complaining. > >This only seems to occur on HTTP traffic. If we have the visitors try HTTPS >the pages load fine (with the normal encryption slowdown). > >We've looked at Layers 1-4, and can't see any problems, ping looks great, >interfaces and cpus on routers, servers and switches look fine. > >It's almost like it's a transparent cache "bug". Anyone know if Inktomi, or >any major cache vendors rolled out any new code this week? > >For that matter does anyone know what caches Verizon and SBC use for >starters? > >Other variables: it only seems to occur on IIS based systems (I know I know, >no flame wars or suggestions for replacements). Although it's not happening >on all of our IIS servers. > >Any clues are greatly appreciated. Do they get any messages or just page hang? I'm thinking of TCP connection resets particularly. I've seen a problem before where there were two parallel paths, one with a cache and one without and during the loading of a webpage the path switches causing the enduser session to stop using the cache and attempt to hit the origin server. Since the origin server is not in session, it resets. ========== bep

1 0