- Test - lists.nanog.org

RE: IPv6 subnet calculators?
by Irwin Lazar 13 Feb '03

13 Feb '03

Try: http://freshmeat.net/projects/sipcalc/?topic_id=150 > -----Original Message----- > From: Jeffrey Wheat [mailto:jeff@cetlink.net] > Sent: Wednesday, February 12, 2003 5:58 PM > To: nanog(a)merit.edu > Subject: IPv6 subnet calculators? > > > > I am trying to find an IPv6 subnet calculator or even a > "cheat sheet" that > will help show how a /32 allocation is broken down into /40, > /48 and /64 > subnets. Has anyone found such a tool? I have been using the NorthStar > web based database tool for dealing with my IPv4 allocations. > While the > author has mentioned support for IPv6 in the future, I am > trying to get > things rolling now. Any information is greatly appreciated. > > Best regards, > Jeff > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com) > Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003 > >

2 1

Re: [Re: Cisco VoIP/dominatrix link explored]
by Joshua Smith 12 Feb '03

12 Feb '03

Bill Woodcock <woody(a)pch.net> wrote: > > On Wed, 12 Feb 2003, neal r wrote: > > Voice over IP is a stinking, fetid swamp, and I suggest if anyone > > feels compelled to waste money and feel pain while doing something > > with telephones and the internet... > > All I can say is, you must not be doing it right. I know a lot of people, > myself included, who are doing it on a large scale now, and it's > relatively painless, particularly as compared with the PSTN. > > If an existence proof isn't sufficient for you, I'm not quite sure how to > communicate with you. > > -Bill > not that bill needs my approval, but i agree completely. the one thing that i have run into with voip is hardware compatibility - each vendor tells you one thing, and then an engineer who does it in the field tells you something else (or perhaps this is unique to my experience). despite this, i have voip routes running around the world, and they do a decent number of minutes - and to add my $0.02 to the thread from the past two days, most of the traffic is over the public internet, with little (read no) qos in place. if i only have a single e1, i don't push more than an e1 worth of traffic there (no fancy queuing, just simple engineering) "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

1 0

RE: Voice over IP - performance
by Mathew Lodge 12 Feb '03

12 Feb '03

At 03:23 PM 2/12/2003 -0500, Charles Youse wrote: >I'm assuming in the case of, e.g., a 2650 + dual T-1 PRI interface can >actually encode/decode 48 simultaneous g729a voice streams without >issues? Any idea what the CPU utilisation is - or is this handled in >separate DSPs in the voice network module itself? On these particular Cisco boxes, the DSP does the all audio filtering, CODEC functions, echo cancellation, jitter buffering & adjustment, silence suppression (AKA voice activity detection, if you turned it on), and also prepends the RTP and IP headers. The router CPU just has to forward the packet that's generated by the DSP. Router CPU utilization is therefore a function of the number of packets per second that the voice card generates and the size of each packet, plus signaling overhead. The packet size and rate depend on the CODEC itself (higher compression CODECs generate smaller packets), the sample size (20ms is the Cisco default, reducing or increasing it makes the packets smaller or larger and the packet rate higher or lower, respectively), and whether voice activity detection is on (roughly halves the packet rate). If you leave the default settings in place (no VAD, 20ms sample size), you'll be OK with any of the CODECs. Mathew. >C. > >-----Original Message----- >From: Bill Woodcock [mailto:woody@pch.net] >Sent: Wednesday, February 12, 2003 2:43 PM >To: Charles Youse >Cc: nanog(a)nanog.org >Subject: Re: Voice over IP - performance > > > > Does anyone have any real-world figures for VoIP performance on > > various platforms? In other words, how many calls can an otherwise > > unused e.g., Cisco 2600 be expected to handle if it's the conversion > > point from trunked voice calls to IP. Some rough numbers for > > different codecs on different hardware would be very useful. Most > > specifically I'm interested in Cisco router platforms but other > > vendor stats would be appreciated as well. > >Actually I just ran the dollars-per-simultaneous-call numbers for >different models for some friends. I'll append it. Basically, if you run >g711, you're limited by the number of PRI channels on the box. If you run >g729a, you're limited by the number of DSPs you can fit in the box. The >numbers I ran were assuming g729a. > > -Bill > > > > Cost > per >Package which can handle 23 simultaneous calls: call >CISCO1760 10/100 Modular Router $1,595 >VWIC-1MFT-T1 1-Port RJ-48 Multiflex T1 $1,300 >PVDM-256K-12 3-DSP Module (9 calls) $1,200 >PVDM-256K-20HD 5-DSP Module (15 calls) $4,000 >Total $8,095 $352 > >Different package which can handle 23 simultaneous calls: >CISCO2650 10/100 Modular Router $3,295 >NM-HDV-1T1-24E Single-Port T1 Voice NM $9,100 >Total $12,395 $539 > >Package which can handle 45 simultaneous calls: >CISCO2650 10/100 Modular Router $3,295 >NM-HDV-2T1-48 Dual-Port T1 Voice NM $9,800 >Total $13,095 $291 > >Package which can handle 46 simultaneous calls: >CISCO2650 10/100 Modular Router $3,295 >NM-HDV-2T1-48 Dual-Port T1 Voice NM $9,800 >PVDM-256K-20HD 5-DSP Module (15 calls) $4,000 >Total $17,095 $372 > >Upgradeable package which can handle 46 simultaneous calls: >AS535-2T1-48-AC-V AS5350-V/2T1 $18,900 $411 > >Package which can handle 92 simultaneous calls: >AS535-4T1-96-AC-V AS5350-V/4T1 $33,600 $366 > >Package which can handle 184 simultaneous calls: >AS535-8T1-192-AC-V AS5350-V/8T1 $58,700 $319 > >Upgradeable package which can handle 184 simultaneous calls: >AS54HPX-8T1-192AC AS5400HPX/8T1 $65,500 $356 > >Package which can handle 644 simultaneous calls: >AS54HPX-CT3-648AC AS5400HPX/CT3 $170,300 $265

1 0

Re: Cisco VoIP/dominatrix link explored
by Bill Woodcock 12 Feb '03

12 Feb '03

On Wed, 12 Feb 2003, neal r wrote: > Voice over IP is a stinking, fetid swamp, and I suggest if anyone > feels compelled to waste money and feel pain while doing something > with telephones and the internet... All I can say is, you must not be doing it right. I know a lot of people, myself included, who are doing it on a large scale now, and it's relatively painless, particularly as compared with the PSTN. If an existence proof isn't sufficient for you, I'm not quite sure how to communicate with you. -Bill

1 0

RE: Voice over IP - performance
by Charles Youse 12 Feb '03

12 Feb '03

I'm assuming in the case of, e.g., a 2650 + dual T-1 PRI interface can actually encode/decode 48 simultaneous g729a voice streams without issues? Any idea what the CPU utilisation is - or is this handled in separate DSPs in the voice network module itself? C. -----Original Message----- From: Bill Woodcock [mailto:woody@pch.net] Sent: Wednesday, February 12, 2003 2:43 PM To: Charles Youse Cc: nanog(a)nanog.org Subject: Re: Voice over IP - performance > Does anyone have any real-world figures for VoIP performance on > various platforms? In other words, how many calls can an otherwise > unused e.g., Cisco 2600 be expected to handle if it's the conversion > point from trunked voice calls to IP. Some rough numbers for > different codecs on different hardware would be very useful. Most > specifically I'm interested in Cisco router platforms but other > vendor stats would be appreciated as well. Actually I just ran the dollars-per-simultaneous-call numbers for different models for some friends. I'll append it. Basically, if you run g711, you're limited by the number of PRI channels on the box. If you run g729a, you're limited by the number of DSPs you can fit in the box. The numbers I ran were assuming g729a. -Bill Cost per Package which can handle 23 simultaneous calls: call CISCO1760 10/100 Modular Router $1,595 VWIC-1MFT-T1 1-Port RJ-48 Multiflex T1 $1,300 PVDM-256K-12 3-DSP Module (9 calls) $1,200 PVDM-256K-20HD 5-DSP Module (15 calls) $4,000 Total $8,095 $352 Different package which can handle 23 simultaneous calls: CISCO2650 10/100 Modular Router $3,295 NM-HDV-1T1-24E Single-Port T1 Voice NM $9,100 Total $12,395 $539 Package which can handle 45 simultaneous calls: CISCO2650 10/100 Modular Router $3,295 NM-HDV-2T1-48 Dual-Port T1 Voice NM $9,800 Total $13,095 $291 Package which can handle 46 simultaneous calls: CISCO2650 10/100 Modular Router $3,295 NM-HDV-2T1-48 Dual-Port T1 Voice NM $9,800 PVDM-256K-20HD 5-DSP Module (15 calls) $4,000 Total $17,095 $372 Upgradeable package which can handle 46 simultaneous calls: AS535-2T1-48-AC-V AS5350-V/2T1 $18,900 $411 Package which can handle 92 simultaneous calls: AS535-4T1-96-AC-V AS5350-V/4T1 $33,600 $366 Package which can handle 184 simultaneous calls: AS535-8T1-192-AC-V AS5350-V/8T1 $58,700 $319 Upgradeable package which can handle 184 simultaneous calls: AS54HPX-8T1-192AC AS5400HPX/8T1 $65,500 $356 Package which can handle 644 simultaneous calls: AS54HPX-CT3-648AC AS5400HPX/CT3 $170,300 $265

2 1

Voice over IP - performance
by Charles Youse 12 Feb '03

12 Feb '03

Does anyone have any real-world figures for VoIP performance on various platforms? In other words, how many calls can an otherwise unused e.g., Cisco 2600 be expected to handle if it's the conversion point from trunked voice calls to IP. Some rough numbers for different codecs on different hardware would be very useful. Most specifically I'm interested in Cisco router platforms but other vendor stats would be appreciated as well. Off-list replies please; if anyone is interested in the results I will condense the responses and post back to the list. Thanks, C.

2 1

IPsec with ambiguous routing
by David Wilburn 12 Feb '03

12 Feb '03

I've been attempting to beef up my knowledge of IPsec recently, and got to thinking hypothetically about a *possible* problem with implementing IPsec on larger networks. My experience with IPsec is currently limited at best, so hopefully I can communicate this properly: Let's assume that I have a large-ish network with multiple connections to the Internet and ambiguous routing (meaning that a packet might come in one gateway and the response packet might leave through a different gateway). Let's also assume that I'd like to allow IPsec tunnels into my network to allow single workstations and small networks to attach to mine. With such ambiguous routing, is my understanding correct that the response traffic could potentially bypass the VPN concentrator altogether and travel to the destination unencrypted? Is there any best practices advice for dealing with IPsec on such a network, or am I stuck with either "redesign your network architecture" or "don't allow IPsec?" From what I can figure, those last two options are my best bet, unless I want to allow lots of VPN concentrators deeper within the network where the routing is less ambiguous. Are there any solutions for quickly, reliably, and securely sharing IPsec Security Association databases between gateways, so that the other gateways would know to encrypt the traffic before letting it out? Any other relevant thoughts, experiences, insults, rude gestures, etc.? Thanks! -Dave Wilburn

4 3

RE: IPsec with ambiguous routing
by Braun, Mike 12 Feb '03

12 Feb '03

When the IPsec tunnel is formed, traffic is sent between the IPsec terminating equipment/client at the remote office and the VPN concentrator located at the other end. The source and destination networks are not seen while the data is encrypted over the WAN. Only through a configuration error could the traffic be sent unencrypted from source to destination. It makes no difference that you have multiple WAN links, or even that a potential for an asymmetrical traffic flow exists. The source and destination address as it appears in the WAN cloud always remains the same. Best regards, Mike Braun -----Original Message----- From: David Wilburn [mailto:dwilburn@mitre.org] Sent: Wednesday, February 12, 2003 10:40 AM To: nanog(a)merit.edu Subject: IPsec with ambiguous routing I've been attempting to beef up my knowledge of IPsec recently, and got to thinking hypothetically about a *possible* problem with implementing IPsec on larger networks. My experience with IPsec is currently limited at best, so hopefully I can communicate this properly: Let's assume that I have a large-ish network with multiple connections to the Internet and ambiguous routing (meaning that a packet might come in one gateway and the response packet might leave through a different gateway). Let's also assume that I'd like to allow IPsec tunnels into my network to allow single workstations and small networks to attach to mine. With such ambiguous routing, is my understanding correct that the response traffic could potentially bypass the VPN concentrator altogether and travel to the destination unencrypted? Is there any best practices advice for dealing with IPsec on such a network, or am I stuck with either "redesign your network architecture" or "don't allow IPsec?" From what I can figure, those last two options are my best bet, unless I want to allow lots of VPN concentrators deeper within the network where the routing is less ambiguous. Are there any solutions for quickly, reliably, and securely sharing IPsec Security Association databases between gateways, so that the other gateways would know to encrypt the traffic before letting it out? Any other relevant thoughts, experiences, insults, rude gestures, etc.? Thanks! -Dave Wilburn "MMS <firstam.com>" made the following annotations on 02/12/03 11:04:13 ------------------------------------------------------------------------------ "THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM." ==============================================================================

1 0

RE: Spam Cost Resources [ trustworthy ]
by Mike Damm 12 Feb '03

12 Feb '03

Do these figures take into account the number of calls you will get from sales when they realize you lost the profit equivalent of 2 to 3 large business customers? Or the legal fees incurred by shutting the customer off? Most spammers work terms into their contracts whereas if it is not fulfilled to their satisfaction or if you threaten them, you have the option of buying back the contract from them (it's not as simple as just killing their circuit and telling them to go away). There is a lot more to it than just NOC man hours, which could be very detrimental to your company. --- Michael Damm, MIS Department, Irwin Research & Development V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com -----Original Message----- From: Alif The Terrible [mailto:measl@mfn.org] Sent: Monday, February 10, 2003 7:44 PM To: Martin Hannigan Cc: nanog(a)nanog.org Subject: Re: Spam Cost Resources [ trustworthy ] On Mon, 10 Feb 2003, Martin Hannigan wrote: > > Does anyone have a resource that they believe in when it > refers to how much spam really costs Network operatos? > > http://www.nytimes.com/2003/02/09/magazine/09SPAM.html > > I'm trying to do some validation. Thanks. > > -M Hi Martin, I just did these numbers a little over two months ago, as justification for another head count (cheaper to have more heads as we shut down fewer people). Each complaint costs us about $3.50, and each "case" (more than 5 complaints get a case) costs us around $8.00. The costs associated with actually working a case varied wildly, depending on whether we shut the customer down (worst case), have to repetitively threaten to shut them down, etc... The "Average" case cost us $35.00 to work, but, as I said above, this takes a LOT of things into account. Please feel free to use these numbers, but strip identifying data, as the name associated with them (obviously) did not, and will not, consent to this stuff leaving the company. //Alif

3 2

Re: Streaming dead again.
by odlyzko＠dtc.umn.edu 12 Feb '03

12 Feb '03

On Tue, 11 Feb 2003, John Todd wrote: (snip) > Now, back to the NANOG-ish content: I know a fundamental change in > technology when I see it, and VOIP is an obvious winner. VOIP has > been smoldering for a few years, and the sudden growth of various > easy-to-implement SIP proxies and service platforms, plus the sudden > drop in price of SIP hard-phones, is going to push growth > tremendously. Currently, the underlying technology is UDP that moves > calls around. This is all well and good until you get thousands, > tens of thousands, hundreds of thousands of calls going at once. QoS > is, as Bill says, not a problem right now on public networks; I've > used VOIP across at least three exchange or peering sessions (in each > direction, no less!) and suffered no quality loss, even at 80kbps > rates. However, when a significant percentage of cable and DSL > customers across the country figure this technology out, does this > cause problems for those providers? Is it worthwhile for large > end-user aggregators to start figuring out how they are going to > offer this service locally on their own networks in order to save on > transit traffic to other peers/providers? Or is this merely a tiny > bump in traffic, not worth worrying about? > More interestingly: what happens to the network when the first > "shared" LD software comes into creation? Imagine 1/3 (to pick a > worst-case percentage) of your customers producing and consuming > (possibly) 80kbps of traffic for 5 hours a day as they offer their > local analog lines to anyone who wants to make local calls to that > calling area. > Overseas calling I expect will show similar growth. Nobody wants to > pay $.20 or even $.10 per minute to Asian nations, so as soon as Joe > User figures out how this VOIP stuff works, there will be (is?) a > tendency for UDP increases on inter-continental spans. Nothing new > here; we've all said this was coming for years. Now it's finally > possible - is everyone ready? > JT (snip) VOIP is likely to cause a financial upheaval in the telecom industry, because the overwhelming fraction of revenues still comes from voice services. However, VOIP is likely to have only a minor impact on Internet backbones. The reason is that there simply isn't that much voice traffic. Various estimates (such as those in my papers at <http://www.dtc.umn.edu/~odlyzko/doc/networks.html>) say that already there is about twice as much US Internet backbone traffic as US long distance voice traffic, and that is if you count voice as two 64 Kb/s streams of data. If you use compression, that goes down even further. Now introducing flat rate VOIP service will stimulate voice usage some, but based on various previous experiences, not by enough to make a quantum difference, especially since (again, based on previous experiences) it will take a while for VOIP to spread widely. Andrew Odlyzko

2 1