- NANOG - lists.nanog.org

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

ATM failure - No the other kind of ATM
by Sean Donelan 08 Sep '01

08 Sep '01

As most US residents are aware, the Citibank ATM/Automatic Teller Machine network failed last night. Citibank is still having problems today. >From Reuters: "The Citibank ATM network and other systems experienced a temporary outage last evening." "While our systems were restored by early Wednesday morning, we have continued to experience difficulties this morning. We're working hard to resolve the issues as quickly as possible." Since there is very little "unique" network equipment in the world now, just about everyone buys equipment from the same vendors. So the question is, Can we learn anything from Citibank's experience. Is there anything about their continuing problems which may be used to improve general network reliability? I tried to find out some information from Citibank's web site about the issue, but I didn't see anything.

9 8

IDS Software
by Leo Bicknell 08 Sep '01

08 Sep '01

I'm starting a project for which I would like some quality IDS software. IMHO this opens up a whole can of worms, and will probably start a great discussion, but that's probably good on the whole. First, the requirements. The IDS system must be: * Free * Run on FreeBSD, and/or maybe Linux. * Allow both 'router' detection (where the host acts as a router) and 'passive' (where the host is simply a sniffer on a lan). * Have a reasonable configuration system to allow common false-positives to be supressed. At this point I know almost nothing about IDS systems, other than that several companies make such products and charge huge fees for them, and that there are a number of open-source products that have no confirmed reputations. Replies to the list are ok, as are private replies. Assuming I get something good I will summarize private replies to the list. -- Leo Bicknell - bicknell(a)ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

2 2

The Cidr Report
by CIDR Report 08 Sep '01

08 Sep '01

This is an auto-generated mail on Fri Sep 7 23:00:00 PDT 2001 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 07Sep01 0) General Status Table History ------------- Date Prefixes 310801 103087 010901 103176 020901 103157 030901 103037 040901 103055 050901 103130 060901 103134 070901 103166 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 82.105.0.0/16 from AS3269 *** Bogus 82.105.128.0/17 from AS3269 AS Summary ---------- Number of ASes in routing system: 11536 Number of ASes announcing only one prefix: 6868 (3907 cidr, 2961 classful) Largest number of cidr routes: 847 announced by AS701 Largest number of classful routes: 1395 announced by AS701 1) Gains by aggregating at the origin AS level --- 07Sep01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1285 971 314 24.4% Telstra Pty Ltd AS701 1395 1186 209 15.0% UUNET Technologies, Inc. AS4151 294 165 129 43.9% USDA AS577 313 192 121 38.7% Bell Advanced Communications Inc. AS6595 173 61 112 64.7% DoD Education Activity Network As AS4293 381 272 109 28.6% Cable & Wireless USA AS16473 177 74 103 58.2% Bell South AS13999 113 11 102 90.3% Mega Cable S.A. de C.V. AS705 245 146 99 40.4% UUNET Technologies, Inc. AS7018 756 660 96 12.7% AT&T AS6429 194 102 92 47.4% AT&T Chile Internet S.A. AS4755 214 127 87 40.7% Videsh Sanchar Nigam Ltd. Autonom AS12302 96 26 70 72.9% MobiFon S.A. AS724 230 162 68 29.6% DLA Systems Automation Center AS4200 142 74 68 47.9% Apex Global Information Services, AS7046 320 254 66 20.6% UUNET Technologies, Inc. AS1239 468 402 66 14.1% Sprint AS6471 127 62 65 51.2% ENTEL CHILE S.A. AS209 301 242 59 19.6% Qwest AS16758 63 6 57 90.5% IKON Office Solutions AS19632 67 11 56 83.6% Metropolis Intercom S.A. AS703 311 256 55 17.7% UUNET Technologies, Inc. AS3464 148 93 55 37.2% Alabama SuperComputer Network AS6413 65 13 52 80.0% Southern Online Systems, Inc. AS226 145 93 52 35.9% Los Nettos AS1 543 491 52 9.6% BBN Planet AS17561 113 62 51 45.1% Internet service provision to Wes AS4323 241 194 47 19.5% Time Warner Communications, Inc. AS15290 238 192 46 19.3% AT&T Canada IES AS5536 55 10 45 81.8% Internet Egypt Network 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

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

08 Sep '01

|> From: Charles Sprickman [mailto:spork@inch.com] |> Sent: Thursday, September 06, 2001 9:16 PM |> On Thu, 6 Sep 2001, Roeland Meyer wrote: |> > To be honest, even though I've used NAT myself and have |> implemented NAT for |> > friends and clients, I would NEVER represent that a NAT'd |> address has the |> > full connectivity to the Internet that a static address does. |> |> True... neither does a well-firewalled LAN. There is a substantial difference between broken access and controlled access.

15 24

Re: end2end? (was: RE: Where NAT disenfranchises the end-user ... )
by Dickson, Brian 08 Sep '01

08 Sep '01

Leo Bicknell wrote: > On Fri, Sep 07, 2001 at 05:09:43PM -0400, Andy Dills wrote: >> One is content, the other a content-delivery mechanism. Think about the >> post office. It's perfectly acceptable for them to stamp a forwarded >> address on the envelope to ensure it's delivery, but perfectly >> unacceptable to modify the content inside. > But NAT goes further. Consider if the post office opened up your > letter, looked at the return address on it, saw that was wrong and > stuck the new one on it, put it back in the envelope and then sent > it on its way. That's exactly what NAT does with some protocols. Funny story (with a NAT analogy): The US post office will forward mail within the USA for free, but won't redirect mail to outside the USA for free. My roommate moved back to Canada. Rather than re-address (and pay) per-letter, I saved a bunch of his mail up, boxed it, and sent it via the post office. International mail generally gets inspected, which is to say, opened. The package contained a bunch of mail, with valid postmarks and addresses. Somehow, the *contents* got re-injected into the mail system. The mail returned to its original (ie old) address, thus defeating my attempt to bulk-forward it to my ex-roommate. ;-) The moral is, if I wanted my package to survive the broken forwarding mechanism, I should have re-addressed the contents, too. Or, if it absolutely, positively needs to get where you want it to go... don't mail it. (end funny story) IP is the transport layer. While many programs may let us type IP addresses at them, any protocol higher up the stack which involves or relies on IP addresses is, IMHO, badly broken. It would be just as bad to involve MAC addresses. At the very least, it defeats the whole purpose of having a *stack*. smd is correct in his observation of the overloading (network location and ID) being a problem. Generic NAT (1:1 or many:fewer, no special handling of ports or protocols)is incompatible with things that put IP addresses in the payload and expect them to match the headers. If brand X of NAT is messing with the contents, it's probably to work around this incompatibility, or rather to try and fix a broken protocol. (Leo - you are complaining about a NAT box *fixing* a problem for you! Did that occur to you?) Anything that needs to assure identity, even using local knowledge of IP addresses, should at a minimum do so by tunneling, so that the NAT affects on the encasulation, not the encapsulated header+data. (Hello, IPsec.) Or better yet, use some other identity mechansim. Fundamentally, TCP (which is the real issue) is client-server. (E.g.: Syn, syn-ack, ack.) The server must be known; who the client is arbitrary and irrelevant. (Not unlike NANOG. :-) ) It's really this simple: If you need to do non-TCP, server-server stuff, you need a static IP. It doesn't matter whether dynamic IP and port comes from NAT or DHCP - there will always be things you can't do behind those. If you want to do those things, don't go behind one of them. Or implement better protocols that don't break when NAT is used, or place ridulous burdens on ports that need to be opened on firewalls (H.323 ?!?), or better yet, use some kind of 3-way, 3-party handshake to establish peer-peer between NAT'd client-type boxes (for programs that facilitate copyright violations.) And by the way, whatever happened to the notion that the firewall should also be a proxy at the application layer rather than a mere packet-forwarding-and-munging box? Brian Dickson (now at Velocita, but speaking for himself.)

2 1

Looking for contact at HKT.net...
by Bulger, Tim 07 Sep '01

07 Sep '01

Sorry for the spam, but can anyone possibly point me in the direction of a network engineer at HKT.net that understands the concept of local preference? Thanks in advance, Tim Bulger EA.com Network Engineering

1 0