- NANOG - lists.nanog.org

Re: FTP with authentication to RADIUS
by joshua stein 04 Jan '01

04 Jan '01

John A. Tamplin wrote: > Unless I misread something, the Radius PAM module only supports accounting > not authentication. nope. we're using for authentication with proftpd and postfix (cyrus-sasl). http://www.freeradius.org/pam_radius_auth/

1 0

RE: Dialup congestion and winter weather (fwd)
by Roeland Meyer 04 Jan '01

04 Jan '01

Yes, I was dialing into my own network. No, I didn't make the connection to the weather. Yes, it was LD from coast to coast, via AT&T calling card. Yes, I did make the point that it was time-dependent. But, that could have easily been a local-loop circuit dependency. Where, I got a circuit that wasn't limited. I am now back on the west coast and no longer in southern bell's region. However, when I was there, I ran local loop tests that indicated that the problem was on the near-end (NC). On the CA end, I consistantly get >33.6K connections. I get similar results from CO, NV, WA, and OR metro areas (>33.6K, consistently [I run both V.90 and 33.6K modem banks]). Only in southern bell's regions does it drop to 14.4K (I was in Graham, NC). Note: In the past 15 years, most (90%) of the bandwidth problems, using modems, both customer and corporate, that I have had, were "last mile" issues (IOW, local loop, usually at the end-node). -----Original Message----- From: Christopher Grupe [mailto:cgrupe@nortelnetworks.com] Sent: Thursday, January 04, 2001 9:27 AM To: Roeland Meyer; Roeland Meyer; 'multics(a)ruserved.com'; nanog(a)merit.edu Subject: RE: Dialup congestion and winter weather (fwd) Maybe I misunderstood the statement you made... Let me paraphrase your original statement... During bad weather, at certain periods of time you experience: consistent 14.4Kbps connections using AT&T (ISP? or Long distance?) Long distance from Coast to Coast??? Are you just dialing into your network? Christopher Grupe Sr. Sales Engineer Nortel Networks, Service Provider & Carrier cgrupe(a)nortelnetworks.com I speak for myself! -----Original Message----- From: Roeland Meyer [ mailto:rmeyer@mhsc.com <mailto:rmeyer@mhsc.com> ] Sent: Thursday, January 04, 2001 2:19 AM To: Grupe, Christopher [DPARK:9234:EXCH]; Roeland Meyer; 'multics(a)ruserved.com'; nanog(a)merit.edu Subject: RE: Dialup congestion and winter weather (fwd) 1) I'm my own ISP, dialing into my own modem banks. I am reasonably confident that I know what my own systems are doing. They are not interacting as you describe. 2) Local loop-back tests show that my servers see full bandwidth, on their last mile. Similar testing on the NC "last mile" show the bandwidth contraints. Since the bandwidth is constrained on the "last mile", the LD trunk behavior is irrelevent. Although, that was a probability, until I did the tests. 3) You really wouldn't believe the telco attachment equipment I carry in the *other* half of my lap-top case. On the road, I can attach to the tin-cans-n-string communications network, if I have to. Even if it does add 15 pounds to the carry weight<g>. -----Original Message----- From: Christopher Grupe [ mailto:cgrupe@nortelnetworks.com <mailto:cgrupe@nortelnetworks.com> ] Sent: Wednesday, January 03, 2001 7:56 AM To: Roeland Meyer; 'multics(a)ruserved.com'; nanog(a)merit.edu Subject: RE: Dialup congestion and winter weather (fwd) He Sent, >-----Original Message----- >From: Roeland Meyer [ mailto:rmeyer@mhsc.com <mailto:rmeyer@mhsc.com> ] >Sent: Wednesday, January 03, 2001 12:53 AM >To: 'multics(a)ruserved.com'; nanog(a)merit.edu >Subject: RE: Dialup congestion and winter weather (fwd) > > > >That isn't the only issue. I've just found that Southern Bell does bandwidth >limiting on their residential customers. Most folks would never know the >difference, but when v.90 modems start consistantly connecting at 14.4K, or >less, then I know that the telco is only allowing 32K per voice channel >(rather than the usual 64K). BTW, that was using AT&T universal LD from >Graham, NC, to Livermore, CA. I only ever got full-speed late at night. Come on, The ISP is not going to write an init script for their modems to permanently have them connect at 14.4. Telco's don't turn down the PCM rate on dial up's to 32KBps either... Telco's (RBOC's) have a separate (unregulated) ISP, which handles dial up traffic. The regulated side is the switched side (voice switch).... One has nothing to do with the other (usually union workers on the regulated side, and non-union on the unregulated side). So to prove your point, the dial side (ISP non-union) would call the CO's and have the Switchman changed the line card to an ADPCM (32Kbps) card at the switch, and the ISP sets their modems to connect at 14.4Kbps. No way Jose! Some CLEC's are running their line cards using ADPCM (32Kbps) and over an ATM backbone. The RBOC's at this time are still using typical PCM (64Kbps) per channel, for the line cards (unless using BRI). The problem you may be experiencing is with the inter switched trunks, or coming in a span that has timing slips, Errored Seconds, and severely errored seconds, etc. Especially if you are going LD from NC to CA. Christopher Grupe Sr. Sales Engineer Nortel Networks, Service Provider & Carrier cgrupe(a)nortelnetworks.com I speak for myself!

1 0

SLC power failures
by Sean Donelan 04 Jan '01

04 Jan '01

As power is being restored throughout the midwestern part of the US, one interesting feature showed up. A lot of telephone companies are using Subcriber Loop Carriers (SLCs) to provide service. Some phone companies are using local power sources with limited battery backup for some SLCs. With the extended power outages, central offices with generators maintained service; however, the remote equipment didn't have local generators. This resulted in people losing their local loops and telephone service as the power outages lasted for days. What does this have to with the Internet? Well, it started me thinking about Southwestern Bell Telephone's new Project Pronto, their plan to deploy DSL. As part of this, my understanding of the technology, is the increased equipment huts and remote locations without the same backups found in central offices.

5 4

Follow-up to "EGP/Peering survey"
by abha 04 Jan '01

04 Jan '01

Hi All! Just wanted to do one last recruit for ISP volunteers to participate... and to gently nudge those who have surveys to complete them. Thank you all for helping out with this! -abha ;) ---------- Forwarded message ---------- Date: Wed, 27 Dec 2000 10:23:27 -0800 (PST) From: abha <ahuja(a)wibh.net> To: nanog(a)merit.edu Subject: EGP/Peering survey Hey Nanog Folks! I've posted my request on many other lists and now it is time to post here.... Please let me know if any of you are interested in participating.... ---------- Hi All! I'm working on gathering some information about how providers interact with each other for a research project. I've compiled a rather lengthy survey that asks questions about peering, peering policy and ISP practices. If you've ever set-up peering policies, etc. for an ISP, I'd love to have your responses to this survey. While answering all questions isn't necessary, I would appreciate it. And I'll be giving T-shirts out to those who complete the whole thing! :) All answers will be kept confidential and will be anonymized and aggregated before being included in any published findings... Anyone here willing to particpate? Drop me a note and I'll send you the survey! Thanks for your help! -abha ;) ps - some of you might've filled out a survey with me at NANOG some time ago, this is actually a follow-up to that one... ;) So, your participation in this round is still appreciated!

3 2

RE: Dialup congestion and winter weather (fwd)
by Roeland Meyer 04 Jan '01

04 Jan '01

1) I'm my own ISP, dialing into my own modem banks. I am reasonably confident that I know what my own systems are doing. They are not interacting as you describe. 2) Local loop-back tests show that my servers see full bandwidth, on their last mile. Similar testing on the NC "last mile" show the bandwidth contraints. Since the bandwidth is constrained on the "last mile", the LD trunk behavior is irrelevent. Although, that was a probability, until I did the tests. 3) You really wouldn't believe the telco attachment equipment I carry in the *other* half of my lap-top case. On the road, I can attach to the tin-cans-n-string communications network, if I have to. Even if it does add 15 pounds to the carry weight<g>. -----Original Message----- From: Christopher Grupe [mailto:cgrupe@nortelnetworks.com] Sent: Wednesday, January 03, 2001 7:56 AM To: Roeland Meyer; 'multics(a)ruserved.com'; nanog(a)merit.edu Subject: RE: Dialup congestion and winter weather (fwd) He Sent, >-----Original Message----- >From: Roeland Meyer [mailto:rmeyer@mhsc.com] >Sent: Wednesday, January 03, 2001 12:53 AM >To: 'multics(a)ruserved.com'; nanog(a)merit.edu >Subject: RE: Dialup congestion and winter weather (fwd) > > > >That isn't the only issue. I've just found that Southern Bell does bandwidth >limiting on their residential customers. Most folks would never know the >difference, but when v.90 modems start consistantly connecting at 14.4K, or >less, then I know that the telco is only allowing 32K per voice channel >(rather than the usual 64K). BTW, that was using AT&T universal LD from >Graham, NC, to Livermore, CA. I only ever got full-speed late at night. Come on, The ISP is not going to write an init script for their modems to permanently have them connect at 14.4. Telco's don't turn down the PCM rate on dial up's to 32KBps either... Telco's (RBOC's) have a separate (unregulated) ISP, which handles dial up traffic. The regulated side is the switched side (voice switch).... One has nothing to do with the other (usually union workers on the regulated side, and non-union on the unregulated side). So to prove your point, the dial side (ISP non-union) would call the CO's and have the Switchman changed the line card to an ADPCM (32Kbps) card at the switch, and the ISP sets their modems to connect at 14.4Kbps. No way Jose! Some CLEC's are running their line cards using ADPCM (32Kbps) and over an ATM backbone. The RBOC's at this time are still using typical PCM (64Kbps) per channel, for the line cards (unless using BRI). The problem you may be experiencing is with the inter switched trunks, or coming in a span that has timing slips, Errored Seconds, and severely errored seconds, etc. Especially if you are going LD from NC to CA. Christopher Grupe Sr. Sales Engineer Nortel Networks, Service Provider & Carrier cgrupe(a)nortelnetworks.com I speak for myself!

2 1

SSM vs MSDP (was: IP Multicasting)
by Bill Nickless 04 Jan '01

04 Jan '01

-----BEGIN PGP SIGNED MESSAGE----- Jared Mauch writes: >The advent of SSM (single source multicast) makes such one-to-many much >easier than in the past. I would be interested in learning more details about how this is the case, operationally, today. My perspective argues against Jared's statement as I understand it. For the past 18 months or so I've been involved in making IP multicast work for the Access Grid project (see http://www.mcs.anl.gov/accessgrid ) which is admittedly a many-to-many application. Since the Access Grid project started we have been able to use it to run several multi-day meetings with roughly a dozen sites, plus literally hundreds of meetings with 2-5 sites. We have seen the larger meetings consume 20 megabits/second of multicast bandwidth, sustained for 10+ hours over 2-3 days. Few sites could afford the N^2 bandwidth requirement of unicast, so Access Grid is fundamentally dependant on IP multicast to work properly. I've had lots of fun debugging IP multicast deployment over the past 1.5 years. This has been at sites ranging from national laboratories to universities to Native American tribal colleges, in cooperation with the folks at networks like vBNS+, Abilene, and ESNet and their various connectors. SSM introduces new things to debug, and I think makes IP multicast deployment harder to actually deploy than the existing M-BGP/PIM-SM/MSDP model. Please note the date on this message--these comments are likely to be obsolete in the future. But for now, here are three major reasons why: No SSM Support in IP Multicast Beacon Tool ========================================== We developed a Java-based tool to monitor IP multicast reachability. This tool is intended to be deployed on end stations. Each end station reports reachability to a central server, which makes the information available on a web page (see http://beaconserver.accessgrid.org:9999 for the reachability matrix, and http://dast.nlanr.net/projects/beacon for the code itself.) Obviously this tool could be updated to support SSM, but it's not there yet. SSM Requires IGMPv3 Or Other Proprietary Hacks At The End Station ================================================================= Implementing SSM is trivial at the service provider. Once you have M-BGP and PIM Sparse Mode working you are pretty much done, since your customers will have the burden of sending you PIM-SM joins. It's even easier, because you don't have to worry about MSDP. But at the customer things are much harder. First, the customer has to provide SSM/IGMPv3 support at the edge network devices, and that support is by no means widespread. Second, the customer has to install and debug the IGMPv3 support in the end stations, which is just now becoming available. Compare IGMPv3 availability with IGMPv2 for Windows 95. And finally the middleware and applications need to be appropriately coded to handle the SSM/IGMPv3 model. Are the major Java distributions supporting IGMPv3 yet? What about ACE? (See above for IP Multicast Beacon tool; it's pure Java.) MSDP As A Useful Debugging Tool =============================== Yes, MSDP is another protocol you have to configure and maintain as a service provider. But I have found it to be useful debugging tool for confirming proper operation of M-BGP and PIM-SM in certain cases. - Customer site without PIM-SM configured properly on a sender. If the customer isn't generating an MSDP SA, then we can quickly point the finger at the customer, and give the customer a specific thing to get working (the MSDP advertisements, a.k.a. the A flag on new-model Cisco code.) - Customer site not properly doing route path forward calculation, due (possibly) to misconfiguration of M-BGP. This shows up as MSDP SAs not being properly accepted in the customer. That explains why a customer might not be sending PIM-SM joins towards the service provider. In both of these cases, trying to debug without MSDP, but with SSM, would require considerably more debugging effort. One would need to go deeper into the customer network and/or turn on PIM-SM debugging at the customer edge. Summary ======= If your objective is to reduce the amount of work your engineering staff has to do to support IP Multicast, I can guarantee that telling your customers to use M-BGP/PIM-SM/SSM instead of M-BGP/PIM-SM/MSDP will help a lot--but (in my opinion) for the wrong reason: it will delay the actual availability of IP Multicast service to the end user. Telling your customers to use M-BGP/PIM-SM/SSM *IN ADDITION TO* M-BGP/PIM-SM/MSDP will indeed help reduce the amount of global MSDP state carried in routers over the long term, and that's arguably a very good thing. I look forward to ubiquitous support of IGMPv3 in lots of vendors products--whether they be layer 2, layer 3, software, or whatever. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless(a)mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQCVAwUBOlJN+awgm7ipJDXBAQEQpQQAh2JkINd3K0ZTc3gM+xl2U1luyTufDDqq Kk5AMEIfAi57kXGTmMSnSOfVolTMiz/BLHROKq0BR4q+pZuIWHuaWdUcek4vkPBM FubhTpAUqFVvS4XKgwQkJFOEHw70hK0h2r7kmTilmNSI8MaPYzm6A992e/dM8apP BojosYEvoRs= =prQv -----END PGP SIGNATURE-----

4 5

Re: SSM vs MSDP (was: IP Multicasting)
by brandon＠rd.bbc.co.uk 04 Jan '01

04 Jan '01

> Without sap/sdr capabilities, SSM will never take off. I don't see why, nice to have but not required for it's likely market - replacing unicast streaming media > Having all the web pages out there are nice extras, but do not > replace the needed builtin tools. For the users web works fine at the moment and some content providors would prefer people to look at the pages as well as the stream Doesn't mean it wouldn't be nice to have it as well though some portals would hope not or wish to own it. brandon

1 0

Further Internet Metrics
by Eric Lemond 03 Jan '01

03 Jan '01

The Internet Metrics post in December was a good starting point for my research on backbone traffic, but I'm struggling to get more specific information. Specifically, I am trying to find out the market share for the major backbone providers (so far I've found WorldCom 37% and Sprint 16% of traffic). Boardwatch has this breakdown, but by ISP connections (WorldCom 24% & Sprint 14%). Is the percent of ISP connections a good estimate of the percent of traffic a backbone carries? Also, for the major backbones, is there any kind of breakdown of the percent of a backbone's traffic that is for a corporate end user vs. a personal dial-up or broadband account. Specifically, does WorldCom, Sprint, C&W, ATT, Genuity, Level 3's traffic have a strong tendency to be for corporate or personal accounts? Finally, Is there any source or estimate for the current total amount of Internet traffic carried by all networks? Any information or sources would be greatly appreciated. Thanks, Eric ---------------- Eric Lemond Interdiciplinary Telecommunications Program, CU Boulder Intern, FastIdeas

5 5

RE: Dialup congestion and winter weather (fwd)
by Roeland Meyer 03 Jan '01

03 Jan '01

That isn't the only issue. I've just found that Southern Bell does bandwidth limiting on their residential customers. Most folks would never know the difference, but when v.90 modems start consistantly connecting at 14.4K, or less, then I know that the telco is only allowing 32K per voice channel (rather than the usual 64K). BTW, that was using AT&T universal LD from Graham, NC, to Livermore, CA. I only ever got full-speed late at night. > -----Original Message----- > From: multics(a)ruserved.com [mailto:multics@ruserved.com] > Sent: Wednesday, December 27, 2000 8:47 PM > To: nanog(a)merit.edu > Cc: multics(a)ruserved.com > Subject: Dialup congestion and winter weather (fwd) > > > > An important question to ask people reporting this type of > problem is > are they getitng a normal busy (all modems busy) or a fast busy (telco > out of circuits). Two very different problems. An ISP can work on > fixing the first, but the second is a telco with a shortage > of circuits > between the customer and the isp. > > > It seems like a lot of people are at home, dialing into the Internet > > today. There is a major ice storm in the middle of the country, and > > its pretty much a holiday week elsewhere. Traffic seems to > be moving on > > the major backbones, but some folks in the midwest report > some problems > > dialing in from home. > > -- > Richard Shetron multics(a)ruserved.com multics(a)acm.rpi.edu NO UCE > What is the Meaning of Life? There is no meaning, > It's just a consequence of complex carbon based chemistry; > don't worry about it > The Super 76, "Free Aspirin and Tender Sympathy", Las Vegas Strip. >

1 0

@Home peering contact?
by Alex 03 Jan '01

03 Jan '01

I've tried to get in touch with peering(a)home.com; I've tried to leave that individual an vmail, and I get a 'mailbox is full, goodbye'; I've sent an email to him, and I've no response. Does anyone know of a working peering contact over there? Or, and @home lurkers here? Thanks!

1 0