RE: VoIP over IPsec
So do you suppose that in my scenario, I'd be better off leaving the VoIP out of the encrypted tunnels and use a separate [cleartext] path for them? I'm worried about the security implications, not because I feel there is a huge security risk but because I'm sure the topic will be brought up. (Communicating over one provider's backbone provides little opportunity for third parties to snoop packets between points, of course.) Has the issue of VoIP security ever been addressed? I suppose I should really do my homework. C. -Original Message- From: Stephen Sprunk [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 1:22 PM To: Charlie Clemmer Cc: [EMAIL PROTECTED] Subject: Re: VoIP over IPsec Thus spake Charlie Clemmer [EMAIL PROTECTED] Stephen, I know this is outside of Charles' original inquiry, but I'm not familiar with this qos pre-classify feature. Since we would be encrypting voice traffic ... at what point would you classify it? If I classify it before it goes into the tunnel and gets encrypted, would that classification last once it's encrypted? If we try to classify after it's been encrypted, how can we tell it's voice traffic? It seems to me that jitter from both the actual encryption process as well as that associated with basic serialization would be the potential death of VoIP in this scenario, but I'm not sure mechanisms available to help resolve that risk. In the default IOS code path, encryption happens before QOS (and after GRE). Modern IOS versions copy the DSCP when encapsulating/ encrypting packets, so DSCP-based QOS will still work, but IP- and port-based QOS will not. More importantly, encryption is slow; even hardware encryption is significantly slower than the rest of the forwarding process. It's also FIFO by default, meaning that large data packets can get stuck ahead of your VoIP packets, causing jitter. 'qos pre-classify' adds a second QOS stage before encryption, which allows you to classify packets in their unencrypted state and, more importantly, adds PQ capability to the encryption stage. For more information: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos _c/fqcprt1/qcfvpn.htm S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
RE: VoIP over IPsec
Using hardware encryption with the qos pre-classify feature, I imagine that jitter will no longer be an issue - (that is, the jitter you mention previously is introduced by the lack of prioritization into the encryption queue). Or am I missing something? C. -Original Message- From: Stephen Sprunk [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 2:24 AM To: Charles Youse Cc: [EMAIL PROTECTED] Subject: Re: VoIP over IPsec Thus spake Charles Youse [EMAIL PROTECTED] In order to cut costs in our telecom budget I'm toying with the idea of replacing a lot of our inter-office leased lines with VPN connections over the public Internet. [...] Assume for the moment that latency and bandwidth are not an issue; e.g., any two points that will be exchanging voice data will both have transit from the same provider with an aggressive SLA. Latency, bandwidth, and packet loss are moot. Jitter is VoIP's enemy. Does anyone have any experience running VoIP over such tunnels? Is there a technical reason why this solution is not feasible? Are Cisco routers not happy doing VoIP/IPsec/GRE in concert? IPsec itself will not cause you problems; there's no theoretical conflict. Unfortunately, IOS can introduce jitter when encrypting packets. To mitigate this, you can apply QOS, with a strict priotiy queue for the VoIP packets and the qos pre-classify feature. Your mileage will vary depending on the CPU power of the router, the traffic levels, and whether you're using hardware encryption. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
RE: VoIP over IPsec
Because you need to use GRE to create a virtual interface on the router and thus enable the use of routing protocols. At least, that's the only way I know how to do it. C. -Original Message- From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 6:19 PM To: Steve Feldman Cc: [EMAIL PROTECTED] Subject: Re: VoIP over IPsec On Mon, 17 Feb 2003, Steve Feldman wrote: through the corporate enterprise net, Cisco routers with IPSEC/GRE tunnels over the public Internet. Maybe a stupid question... why would you need GRE tunneling while IPsec has a tunnel mode of its own?
VoIP over IPsec
Hello again, I've heard a lot of encouraging things on this list in response to my previous inquiries about VoIP - hoping you can help me out again. In order to cut costs in our telecom budget I'm toying with the idea of replacing a lot of our inter-office leased lines with VPN connections over the public Internet. (I've got a lot of experience doing this in major production environments so I'm aware of the gotchas in this scenario.) My general method is to create IPsec-encrypted GRE tunnels between sites and then treat them as true virtual circuits; i.e., I run OSPF over the tunnel and exchange dynamic routing information, blah-de-blah. Assume for the moment that latency and bandwidth are not an issue; e.g., any two points that will be exchanging voice data will both have transit from the same provider with an aggressive SLA. Does anyone have any experience running VoIP over such tunnels? Is there a technical reason why this solution is not feasible? Are Cisco routers not happy doing VoIP/IPsec/GRE in concert? Thanks as always, C.
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. Off-list replies please; if anyone is interested in the results I will condense the responses and post back to the list. Thanks, C.
RE: Voice over IP - performance
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:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 2:43 PM To: Charles Youse Cc: [EMAIL PROTECTED] 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
RE: VoIP QOS best practices
That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? As someone who is looking to deploy VoIP in the near future this is of particular interest. C. -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 12:48 PM To: [EMAIL PROTECTED] Subject: Re: VoIP QOS best practices Looking for some links to case studies or other documentation which describe implementing VoIP between sites which do not have point to point links. From what I understand, you can't enforce end-to-end QoS on a public network, nor over tunnels. I'm wondering if my basic understanding of this is flawed and in the case that it's not, how is this dealt with if the ISPs of said sites don't have any QoS policies? QoS is completely unnecessary for VoIP. Doesn't appear to make a bit of difference. Any relationship between the two is just FUD from people who've never used VoIP. -Bill
RE: VoIP QOS best practices
My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout. C. -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:05 PM To: Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? That's generally true as well. But why would you need it? What's the advantage to be gained in using QoS to throw away packets, when the packets don't need to be thrown away? As someone who is looking to deploy VoIP in the near future this is of particular interest. Go ahead and deploy it. It's easy and works well. It certainly doesn't need anything like QoS to make it work. -Bill
RE: VoIP QOS best practices
But I could conceivably have 10+ voice channels over a T-1, I still don't quite understand how, without prioritizing voice traffic, the quality won't degrade... C. -Original Message- From: Bill Woodcock [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:20 PM To: Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices My main concern is that some of the sites that will be tied with VoIP have only T-1 data connectivity, and I don't want a surge in traffic to degrade the voice quality, or cause disconnections or what-have-you. People are more accustomed to data networks going down; voice networks going down will make people shout. It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. -Bill
RE: VoIP QOS best practices
Indeed, but in this case I'm dealing with a private network that doesn't have so much surplus as to guarantee no contention. C. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:23 PM To: Charles Youse Cc: Bill Woodcock; [EMAIL PROTECTED] Subject: Re: VoIP QOS best practices On Mon, 10 Feb 2003 13:02:39 EST, Charles Youse [EMAIL PROTECTED] said: That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised? Qos is designed for dealing with who gets preference when there's a bandwidth shortage. Most places are having a bandwidth glut at the moment, so the VoIP traffic gets through just fine and QoS isn't able to provide much measurable improvement.
RE: VoIP QOS best practices
Speaking of codecs, what are the primary variables one uses when choosing a codec? I imagine this is some function of how much bandwidth you want to use versus how much CPU to encode the voice stream. C. -Original Message- From: Alec H. Peterson [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 1:40 PM To: Bill Woodcock; Charles Youse Cc: [EMAIL PROTECTED] Subject: RE: VoIP QOS best practices --On Monday, February 10, 2003 10:19 -0800 Bill Woodcock [EMAIL PROTECTED] wrote: It works fine on 64k connections, okay on many 9600bps connections. T1 is way more than is necessary. I'd say that largely depends on which codec you are using and how many simultaneous calls you will have going. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: VoIP QOS best practices
But in order for RTP to resync the out-of-order packets it must introduce some delay, no? And that delay causes issues. C. -Original Message- From: Stephen Sprunk [mailto:[EMAIL PROTECTED]] Sent: Monday, February 10, 2003 5:21 PM To: Leo Bicknell Cc: North American Noise and Off-topic Gripes Subject: Re: VoIP QOS best practices Reordering per se doesn't affect VoIP at all since RTP has an inherent resync mechanism. Reordering is also unlikely, since each packet is sent 20ms or more apart; I'm not aware of any network devices that reorder on that scale. S - Original Message - From: Leo Bicknell [EMAIL PROTECTED] Sent: Monday, 10 February, 2003 12:43 Subject: Re: VoIP QOS best practices - --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In a message written on Mon, Feb 10, 2003 at 01:19:08PM -0500, chaim fried = wrote: happens). There is no reason to implement QOS on the Core. Having said that, there still seems to be too many issues on the tier 1 networks with pacekt reordering as they affect h.261/h.263 traffic.=20 I've got a question about this issue. Many networks reorder packets for a number of reasons. At least once before I've attempted to measure the effects of this reordering on a number of forms of traffic, but I have never understood the particular effects on VOIP traffic. Indeed, the two times I was asked to investigate this for video people it turns out the video receivers /had no ability to handle out of order frames/. That's right, get one packet out of order and the video stream goes away until it resynchronizes. Now, I realize reordering should not happen to a large percentage of the packets out there, but it also seems to me any IP application has to handle reordering or it's not really doing IP. So what's the real problem here? Are the VOIP boxes unable to handle out of order packets? Do the out of order packets simply arrive far enough delayed to blow the delay budget? What percentage of reordered packets starts to cause issues? - --=20 Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org - --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline - -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE+R/LkNh6mMG5yMTYRAsn4AJ9Y1vO1RILDjvGdTJUPmiiknUlpHgCfedQm rOH5KvKO+PVnSVoLPZkG4zI= =LCXI - -END PGP SIGNATURE- - --OXfL5xGRrasGEqWY-- --
RE: Weird networking issue.
Title: RE: Weird networking issue. By nature, a hub is half-duplex - it's a repeater. Besides, misconfigured duplex will not cause CRC errors. C. -Original Message- From: David G. Andersen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 2:08 PM To: Drew Weaver Cc: '[EMAIL PROTECTED]' Subject: Re: Weird networking issue. Rule number 1 with any ethernet: Check to make sure you have the duplex and rate statically configured, and configured identically on both ends of the connection. I'd wager you've got half duplex set on one side, and full on the other... -Dave On Tue, Jan 07, 2003 at 02:19:10PM -0500, Drew Weaver mooed: Hi, this is kind of a newbie question but this doesn't make a whole lot of sense :P I have an etherstack hub connected to a FastEthernet port on a cisco 3660 router, these are the stats when I do a show int fast0/0: 5776 input errors, 5776 CRC, 2717 frame, 0 overrun, 0 ignored Whats weird is I just cleared the counters 12 minutes ago, and already there are almost 6000 CRC errors. This connected via a standard Cat5 ethernet cable, I have tried replacing the cable to noavail. Is this a fairly normal situation, If so that's great, but it seemed rather ridiculous to me, and if it is not a normal situation, what would cause this? Any ideas are appreciated. Thanks, -Drew Weaver -- work: [EMAIL PROTECTED] me: [EMAIL PROTECTED] MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
RE: 18.0.0.0/8
Title: RE: 18.0.0.0/8 Care to elaborate? -Original Message- From: Joe Abley [mailto:[EMAIL PROTECTED]] Sent: Friday, December 20, 2002 1:12 PM To: jcvaraillon Cc: nanog list Subject: Re: 18.0.0.0/8 On Friday, Dec 20, 2002, at 13:02 Canada/Eastern, jcvaraillon wrote: 4Today the network 18.0.0.0/8 disappeared from the Internet, it is now reachable. I went to different looking glass (MAE East, LINX, GRnet) and 18.0.0.0/8 was not in their routing table. Is it related to a major problem? Yes. Not enough people understand RFC1918. Joe
RE: CW Move
What game is this? I have some gear at SJC1 and I've not heard anything. C. -Original Message- From: David Schwartz [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 2:02 PM To: [EMAIL PROTECTED]; Nanog Subject: Re: CW Move On Wed, 16 Oct 2002 12:23:20 -0500, Moe Allen wrote: We are in that CW group and CW is telling us we have to sign the contract by Friday the 18th. We were only notified Last Friday. I get concerned when things happen this quick without a lot of backup information. thanks Morris Allen VidcomNet, Inc. Sounds similar to the game AboveNet is playing with all their SJC1 customers. DS
RE: the cost of carrying routes
I think you're confusing commercial peering agreements with providing customers the ability to advertise their routes via BGP. Two different issues. C. -Original Message- From: Jeff S Wheeler [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 5:11 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: the cost of carrying routes Ron, Many carriers require that you advertise a certain minimum number of routes to them over your peering sessions, or they will not peer with you. This suggests that those carriers see routes carried as a point of value, rather than or in addition to one of cost. I have seen 5,000 routes as a minimum used by more than one transit-less carrier. Is this really an operational value perception at these carriers, or is it simply a means of creating a barrier-to-peering? Are fewer, shorter prefixes seen as more valuable than longer ones, e.g. swamp /24s? Is a University or other entity with a legacy /16 more or less valuable as a peer than a growing ISP with a few /20s, and presumably more eyeballs and/or content behind them? -- Jeff S Wheeler [EMAIL PROTECTED] On Mon, 2002-10-14 at 16:47, Ron da Silva wrote: *snip* Do any ISPs charge based on the number of announcements a customer advertises? If downstream advertisements became mainly smaller prefixes (say /24) that were not aggregatable by you as their upstream ISP, would you answer the above question differently?
RE: iBGP next hop and multi-access media
Really, the only way this could happen is if Router B is not announcing its routes to 172.16.16/24 and Router A has a default route to its Ethernet interface. C. -Original Message- From: Ralph Doncaster [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 06, 2002 9:06 PM To: E.B. Dreger Cc: [EMAIL PROTECTED] Subject: Re: iBGP next hop and multi-access media RD When I setup a situation like the above, with Router B advertising RD the 172.16.16.0/24 to router A, router A sees a next hop of RD 10.10.10.2. This is not good since packets from A going to the RD 172.16.16 subnet get sent to Router B, which then ARPs the RD desitnation, instead of just being ARPed by router A. Is this what you're trying to do: route-map foo match whatever set ip next-hop something Not really, what I want is router A to learn that ther is no next hop IP- the subnet is on the local ethernet. -Ralph
RE: redistribute bgp considered harmful
I've never subscribed to the Are you sure? concept, or preventing problems by removing functionality, effectively tying an operator's hands behind his/her back. The fact is that redistributing BGP into an IGP can have its uses (though not usually, okay, never, when carrying a full table on the public Internet) and I'd hate to see the messy workarounds that would come about, when the solution could otherwise be straightforward. My Windows workstation asks me Are you sure? all the time. Just annoying, really. C. -Original Message- From: Sean Donelan [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 6:01 PM To: [EMAIL PROTECTED] Subject: redistribute bgp considered harmful Should the Service Provider version of routing software include the redistribute bgp command? Other than CCIE labs, I haven't seen a real-world use for redistributing the BGP route table into any IGP. If the command was removed (or included a Are your sure? question) what would the affect be on ISPs, other than improving reliability by stopping network engineers from fubaring a backbone?
