RE: Dumb Question [7:74315]
Here is another dumb question... what is the difference between Extreme network equipment and cisco equipment? I know that Cisco and Nortel... main diff is cli and menu driven. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=74318t=74315 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: Dumb Question [7:74315]
Aspiring Cisco Gurl wrote in message news:[EMAIL PROTECTED] Here is another dumb question... what is the difference between Extreme network equipment and cisco equipment? depending on the model, a few thousand bucks ;- I know that Cisco and Nortel... main diff is cli and menu driven. **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=74324t=74315 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: Dumb Question [7:74315]
The big difference, for me anyway, is that it is a lot easier to find answers to technical questions about the equipment on Cisco's website. Cisco's website is voluminous and easy to search. Perhaps you can get good info with some sort of Extreme login or from Extreme's technical support folks, but when you are a visiting contractor on site you don't necessarily want to ask the customer for their vendor support login or support contract number just to be able to ask a minor question. (Understatement). You want to be able to find answers to most questions on your own. Others will say that Extreme switches are fast and well-priced. That may be so, but I am a researcher (and writer) at heart, and Cisco's website is the best technical support website I have ever seen. Tom Larus, CCIE #10,014 Aspiring Cisco Gurl wrote in message news:[EMAIL PROTECTED] Here is another dumb question... what is the difference between Extreme network equipment and cisco equipment? I know that Cisco and Nortel... main diff is cli and menu driven. **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=74337t=74315 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: Dumb Question [7:74315]
Thomas Larus wrote: The big difference, for me anyway, is that it is a lot easier to find answers to technical questions about the equipment on Cisco's website. Cisco's website is voluminous and easy to search. I agree that Cisco's website is voluminous. It's full of well-written, helpful material, most of it accurate. The search engine never works very well for me, though. I use Google. :-) Try searching at Cisco's site on SAFE, for example. Isn't it a bit ridiculous that it comes up with articles that mention fail-safe? (By the way, Google is so cool that you can get it to convert to hex for you. Try typing in 100 in hexadecimal in Google, for example. Isn't that great what it does?) As far as other differences between Cisco and Nortel There's a good reason I never did marketing, so this won't be stated very well, but Cisco strives to offer end-to-end solutions. Not only do they have products that fit into every niche of a mutli-faceted enterprise or service provider's network, but they also have software tools to optimize the services offered at every layer of a multi-layered network. They have tools for the edge, for the core, for campus networks, home networks, huge service provider networks, etc. Other vendors focus on just one aspect of networking and don't offer end-to-end solutions. One downside with Cisco equipment is that it is designed to support gazillions of features. Features are more important to Cisco than ease of use. Not only can their equipment (espeically PIXes) be a pain in the butt to configure, but it can be almost impossible to even figure out which version of software to use since there are hundreds. It's important to work with a Cisco partner when figuring out which software to use and when buying equipment. Cisco makes it pretty much impossible for the ordinary person to do this... Cisco's Technical Assistance Center (TAC) is excellent. I've heard a few complaints over the years, but I think some people just got unlucky. Most of the time when you call TAC you get a very experienced, knowlegable engineer. Many of them are CCIEs. Priscilla Perhaps you can get good info with some sort of Extreme login or from Extreme's technical support folks, but when you are a visiting contractor on site you don't necessarily want to ask the customer for their vendor support login or support contract number just to be able to ask a minor question. (Understatement). You want to be able to find answers to most questions on your own. Others will say that Extreme switches are fast and well-priced. That may be so, but I am a researcher (and writer) at heart, and Cisco's website is the best technical support website I have ever seen. Tom Larus, CCIE #10,014 Aspiring Cisco Gurl wrote in message news:[EMAIL PROTECTED] Here is another dumb question... what is the difference between Extreme network equipment and cisco equipment? I know that Cisco and Nortel... main diff is cli and menu driven. **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=74339t=74315 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: Dumb Question [7:74315]
To add to Chuck's comment: If you're familiar with Cisco, your sanity is also the difference. The way Nortel configures their routers is dramatically different and can leave you very frustrated if you're not used to them. Do they still use Site Mangler...er, I mean Manager? In all honesty, it's probably a lot easier, but if you're a CLI officianado, a GUI can really screw with your mind. Robert Chuck Whose Road is Ever Shorter wrote in message news:[EMAIL PROTECTED] Aspiring Cisco Gurl wrote in message news:[EMAIL PROTECTED] Here is another dumb question... what is the difference between Extreme network equipment and cisco equipment? depending on the model, a few thousand bucks ;- I know that Cisco and Nortel... main diff is cli and menu driven. **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=74346t=74315 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: Dumb Question [7:74315]
Difference between Cisco and Nortel - main diff is cli and menu driven? Not necessarily. If you are talking about the old Wellfleet/Bay Nortel routers, then they certainly have a CLI. You just need to know the MIB very well, and you should be able to configure it with the CLI. I know it used to freak the Wellfleet engineers out when I would configure OSPF with the CLI by using SNMP set commands. They'd say, how can you DO that! You are supposed to use Site Mangler. You could say that the main difference is the underlying architecture. However, Cisco has several different kinds of architecture in their product line. I suppose the biggest difference is that Cisco attempts to make all of their hardware look the same, by having IOS on all platforms. Nortel has many different types of interfaces. For example, their BayRS and Passport (8600) line has completely different interface types. On the other hand, Cisco has several different types of interfaces also: IOS, CatOS, VxWorks (old wireless), VPN Concentrators, etc. Another historical difference is that Wellfleet always believed in SMP, or multiple CPUs in a router working together. Their BN routers had/have a CPU per slot, all working together. Cisco had always fundamentally believed that one CPU is good enough. I don't know the details, but once upon a time a Wellfleet engineer told me that the head Cisco router architect either quit or threatened to quit because of this difference, and he was concerned that Cisco was going to be left behind because there was no way that once CPU could outperform the multiple CPU architecture of Wellfleet BNs. Of course, that didn't happen, and it could have been made-up marketing hype. And now I believe Cisco has multiple CPU's in some of their higher-end equipment, but I'm not familiar with their whole product line. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Aspiring Cisco Gurl [mailto:[EMAIL PROTECTED] Sent: Sunday, August 24, 2003 11:12 PM To: [EMAIL PROTECTED] Subject: RE: Dumb Question [7:74315] Here is another dumb question... what is the difference between Extreme network equipment and cisco equipment? I know that Cisco and Nortel... main diff is cli and menu driven. **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=74353t=74315 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Re: Dumb Question [7:74315]
At 6:36 PM + 8/25/03, Robert Edmonds wrote: To add to Chuck's comment: If you're familiar with Cisco, your sanity is also the difference. The way Nortel configures their routers is dramatically different and can leave you very frustrated if you're not used to them. Do they still use Site Mangler...er, I mean Manager? In all honesty, it's probably a lot easier, but if you're a CLI officianado, a GUI can really screw with your mind. Robert Site Mangler is pretty much dead except in shops that are used to it. It was a practical market requirement to be Cisco CLI-like, although you obviously can't have every command alike when the underlying structure is different. Now, I may have a bias because I know the internals and the developers, but BCC (not Technician Interface) is actually rather elegant. Inside Bay RS, the command language is strictly object and MIB oriented, where many Cisco commands are more ad hoc. Unfortunately, Nortel has gotten rid of almost all of its IP experts, and has no central routing RD group. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=74357t=74315 -- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
RE: Dumb question [7:58783]
You are absolutely right. It didn't occur to me. It seemed to me that one would have to go out of their way to create a loop in a hub environment. Then after reading your response, I realized I encountered something like this just a few months ago. 2 dual homed Citrix servers using 2 logical subnets but sharing the same physical network. The end user had enabled forwarding between the nics on one of the servers. Guess what the problem was? Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 12:10 PM To: [EMAIL PROTECTED] Subject: RE: Dumb question [7:58783] Jay Dunn wrote: A hub or repeater operates at layer 1 and makes no intelligent decision about what to forward. A packet enters a port and is forwarded out all other active ports on the hub. The concept of a loop only exists at higher layers. A loop could exist at the physical layer too. A newbie could connect the hubs in such a way that there was a loop. And it could indeed cause problems due to the fact that a hub doesn't make any intelligent decisions about what it forwards, as you say, and doesn't participate in higher-layer loop-avoidance solutions such as STP, Dijkstra, split horizon, etc. There would be nothing to stop the looping bits. The very idea makes me cringe. :-) It's kind of funny that nobody thinks about this. A network of hubs must be designed in a hierarchical fashion. I guess that is just second-nature to people who grew up with hubs. When hubs entered the market they allowed us to move away from the ubiquitous bus topology and into a star (hub-and-spoke) topology. They allowed us to start using the structured cabling that ATT and other vendors were starting to install, rather than the Christmas-tree-lights topology so popular with coax cable and so prone to problems. As networks grew, it became necessary to connect multiple hubs. The term that was often used was cascating hubs. Hubs cascaed from other hubs, within the rules related to Ethernet propagation delay and collision detection. Priscilla Jay Dunn IPI*GrammTech, Ltd. www.ipi-gt.com Nunquam Facilis Est -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Han Chuan Alex Ang Sent: Monday, December 09, 2002 3:44 AM To: [EMAIL PROTECTED] Subject: Dumb question [7:58783] I am wondering if Hub could be subjected to loop problems , if not, what will happen if there is a loop within a Hub enviroment Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58868t=58783 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Dumb question [7:58783]
A hub or repeater operates at layer 1 and makes no intelligent decision about what to forward. A packet enters a port and is forwarded out all other active ports on the hub. The concept of a loop only exists at higher layers. Jay Dunn IPI*GrammTech, Ltd. www.ipi-gt.com Nunquam Facilis Est -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Han Chuan Alex Ang Sent: Monday, December 09, 2002 3:44 AM To: [EMAIL PROTECTED] Subject: Dumb question [7:58783] I am wondering if Hub could be subjected to loop problems , if not, what will happen if there is a loop within a Hub enviroment Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58787t=58783 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Dumb question [7:58783]
Jay Dunn wrote: A hub or repeater operates at layer 1 and makes no intelligent decision about what to forward. A packet enters a port and is forwarded out all other active ports on the hub. The concept of a loop only exists at higher layers. A loop could exist at the physical layer too. A newbie could connect the hubs in such a way that there was a loop. And it could indeed cause problems due to the fact that a hub doesn't make any intelligent decisions about what it forwards, as you say, and doesn't participate in higher-layer loop-avoidance solutions such as STP, Dijkstra, split horizon, etc. There would be nothing to stop the looping bits. The very idea makes me cringe. :-) It's kind of funny that nobody thinks about this. A network of hubs must be designed in a hierarchical fashion. I guess that is just second-nature to people who grew up with hubs. When hubs entered the market they allowed us to move away from the ubiquitous bus topology and into a star (hub-and-spoke) topology. They allowed us to start using the structured cabling that ATT and other vendors were starting to install, rather than the Christmas-tree-lights topology so popular with coax cable and so prone to problems. As networks grew, it became necessary to connect multiple hubs. The term that was often used was cascating hubs. Hubs cascaed from other hubs, within the rules related to Ethernet propagation delay and collision detection. Priscilla Jay Dunn IPI*GrammTech, Ltd. www.ipi-gt.com Nunquam Facilis Est -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Han Chuan Alex Ang Sent: Monday, December 09, 2002 3:44 AM To: [EMAIL PROTECTED] Subject: Dumb question [7:58783] I am wondering if Hub could be subjected to loop problems , if not, what will happen if there is a loop within a Hub enviroment Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58800t=58783 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Dumb question [7:58783]
Give me a cross-over cat5, a couple hubs, and a clustered server with a dual NIC card having each interface to each respective hub and I'll bet I can make the hubs go into a loop... -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 12:10 PM To: [EMAIL PROTECTED] Subject: RE: Dumb question [7:58783] Jay Dunn wrote: A hub or repeater operates at layer 1 and makes no intelligent decision about what to forward. A packet enters a port and is forwarded out all other active ports on the hub. The concept of a loop only exists at higher layers. A loop could exist at the physical layer too. A newbie could connect the hubs in such a way that there was a loop. And it could indeed cause problems due to the fact that a hub doesn't make any intelligent decisions about what it forwards, as you say, and doesn't participate in higher-layer loop-avoidance solutions such as STP, Dijkstra, split horizon, etc. There would be nothing to stop the looping bits. The very idea makes me cringe. :-) It's kind of funny that nobody thinks about this. A network of hubs must be designed in a hierarchical fashion. I guess that is just second-nature to people who grew up with hubs. When hubs entered the market they allowed us to move away from the ubiquitous bus topology and into a star (hub-and-spoke) topology. They allowed us to start using the structured cabling that ATT and other vendors were starting to install, rather than the Christmas-tree-lights topology so popular with coax cable and so prone to problems. As networks grew, it became necessary to connect multiple hubs. The term that was often used was cascating hubs. Hubs cascaed from other hubs, within the rules related to Ethernet propagation delay and collision detection. Priscilla Jay Dunn IPI*GrammTech, Ltd. www.ipi-gt.com Nunquam Facilis Est -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Han Chuan Alex Ang Sent: Monday, December 09, 2002 3:44 AM To: [EMAIL PROTECTED] Subject: Dumb question [7:58783] I am wondering if Hub could be subjected to loop problems , if not, what will happen if there is a loop within a Hub enviroment Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58807t=58783 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Dumb question [7:58783]
Creighton Bill-BCREIGH1 wrote: Give me a cross-over cat5, a couple hubs, and a clustered server with a dual NIC card having each interface to each respective hub and I'll bet I can make the hubs go into a loop... Yes, indeed, that's a loop also. I was going to mention this example too, but took it out at the last minute. The difference here is that the server doesn't forward the bits (hopefully!) If the server forwarded the bits (like a hub would), there would be no stopping of the bits and the network would be hosed. Priscilla -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 12:10 PM To: [EMAIL PROTECTED] Subject: RE: Dumb question [7:58783] Jay Dunn wrote: A hub or repeater operates at layer 1 and makes no intelligent decision about what to forward. A packet enters a port and is forwarded out all other active ports on the hub. The concept of a loop only exists at higher layers. A loop could exist at the physical layer too. A newbie could connect the hubs in such a way that there was a loop. And it could indeed cause problems due to the fact that a hub doesn't make any intelligent decisions about what it forwards, as you say, and doesn't participate in higher-layer loop-avoidance solutions such as STP, Dijkstra, split horizon, etc. There would be nothing to stop the looping bits. The very idea makes me cringe. :-) It's kind of funny that nobody thinks about this. A network of hubs must be designed in a hierarchical fashion. I guess that is just second-nature to people who grew up with hubs. When hubs entered the market they allowed us to move away from the ubiquitous bus topology and into a star (hub-and-spoke) topology. They allowed us to start using the structured cabling that ATT and other vendors were starting to install, rather than the Christmas-tree-lights topology so popular with coax cable and so prone to problems. As networks grew, it became necessary to connect multiple hubs. The term that was often used was cascating hubs. Hubs cascaed from other hubs, within the rules related to Ethernet propagation delay and collision detection. Priscilla Jay Dunn IPI*GrammTech, Ltd. www.ipi-gt.com Nunquam Facilis Est -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Han Chuan Alex Ang Sent: Monday, December 09, 2002 3:44 AM To: [EMAIL PROTECTED] Subject: Dumb question [7:58783] I am wondering if Hub could be subjected to loop problems , if not, what will happen if there is a loop within a Hub enviroment Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58812t=58783 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Dumb question [7:58783]
It's kind of funny that nobody thinks about this. A network of hubs must be designed in a hierarchical fashion. I guess that is just second-nature to people who grew up with hubs. I thought about it too (and was shaking my head to the uh-uh fashion), but was waiting for your reply... :) (The thought that ran through my head was : O, Priscilla's gonna love this one, hehehe... Have a good one! -Mark -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Mon 12/9/2002 12:10 PM To: [EMAIL PROTECTED] Cc: Subject: RE: Dumb question [7:58783] Jay Dunn wrote: A hub or repeater operates at layer 1 and makes no intelligent decision about what to forward. A packet enters a port and is forwarded out all other active ports on the hub. The concept of a loop only exists at higher layers. A loop could exist at the physical layer too. A newbie could connect the hubs in such a way that there was a loop. And it could indeed cause problems due to the fact that a hub doesn't make any intelligent decisions about what it forwards, as you say, and doesn't participate in higher-layer loop-avoidance solutions such as STP, Dijkstra, split horizon, etc. There would be nothing to stop the looping bits. The very idea makes me cringe. :-) It's kind of funny that nobody thinks about this. A network of hubs must be designed in a hierarchical fashion. I guess that is just second-nature to people who grew up with hubs. When hubs entered the market they allowed us to move away from the ubiquitous bus topology and into a star (hub-and-spoke) topology. They allowed us to start using the structured cabling that ATT and other vendors were starting to install, rather than the Christmas-tree-lights topology so popular with coax cable and so prone to problems. As networks grew, it became necessary to connect multiple hubs. The term that was often used was cascating hubs. Hubs cascaed from other hubs, within the rules related to Ethernet propagation delay and collision detection. Priscilla Jay Dunn IPI*GrammTech, Ltd. www.ipi-gt.com Nunquam Facilis Est -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Han Chuan Alex Ang Sent: Monday, December 09, 2002 3:44 AM To: [EMAIL PROTECTED] Subject: Dumb question [7:58783] I am wondering if Hub could be subjected to loop problems , if not, what will happen if there is a loop within a Hub enviroment Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58817t=58783 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Dumb question [7:58783]
A loop could exist at the physical layer too. A newbie could connect the hubs in such a way that there was a loop. And it could indeed cause problems heh... I just did this last weekend at a local high school i volunteer at sometimes, and I've been doing this a while. The hubs were old and didn't have any error detection/avoidance circuitry, so it took me a minute to figure out what had happened... While we're on the topic of physical ethernet design, don't forget the 5/4/3 rule for 10Mbps. Also, IIRC, the 100Mbps spec requires not more than 2 100m segments between layer 3 devices. Anyone remember the details? -sd Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58837t=58783 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Dumb question [7:58783]
Steve Dispensa wrote: A loop could exist at the physical layer too. A newbie could connect the hubs in such a way that there was a loop. And it could indeed cause problems heh... I just did this last weekend at a local high school i volunteer at sometimes, and I've been doing this a while. The hubs were old and didn't have any error detection/avoidance circuitry, so it took me a minute to figure out what had happened... While we're on the topic of physical ethernet design, don't forget the 5/4/3 rule for 10Mbps. Also, IIRC, the 100Mbps spec requires not more than 2 100m segments between layer 3 devices. Anyone remember the details? Of course I do remember the details of scaling shared Ethernet. Sigh. ;-) The round-trip propagation delay in one collision domain must not exceed 512 bit times. This is a requirement for collision detection to work correctly. This rule means that the maximum round-trip delay for 10-Mbps Ethernet is 51.2 microseconds. One way to make this work is by following the 5-4-3 rule. The maximum round-trip delay for 100-Mbps Ethernet is only 5.12 microseconds because the bit time on 100-Mbps Ethernet is 0.01 microseconds as opposed to 0.1 microseconds on 10-Mbps Ethernet. To make 100-Mbps Ethernet work, there are much more severe distance limitations than those required for 10-Mbps Ethernet. The general rule is that a 100-Mbps Ethernet has a maximum diameter of about 200 meters when UTP cabling is used. Theoretical discussions always talk about the two classes of repeaters for 100 Mbps, although, as far as I know, all vendors use Class II repeaters, but just in case, here's the info. Note that the real concern is propagation delay and repeaters (as well as cabling) introduce some delay, so they must be taken into account. In the IEEE 100BaseT specification, two types of repeaters are defined: * Class I repeaters have a latency of 0.7 microseconds or less. Only one repeater hop is allowed. * Class II repeaters have a latency of 0.46 microseconds or less. One or two repeater hops are allowed. Of course, none of this is all that relevant IF: * You use fiber-optic cabling (which has less delay than copper) * Your 100 Mbps Ethernet isn't shared (which most aren't today) I wrote the rules up at one point. I'll see if I can find a URL. Here we go: http://www.priscilla.com/enetscales.htm Priscilla -sd Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58862t=58783 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: dumb question IPV6 [7:53712]
Please don't take this post the wrong way. I'm not trying to badger you, but just offer some food for thought. Mossburg, Geoff (MAN-Corporate) wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... You know, that's not such a bad idea. Why wait until the last minute to implement a pending technology; do it now and work out all the bugs before it's forced on you. There's a very good reason to wait. Why spend money on something that's not really pressing at the time-being, why not instead spend that money dealing with more important issues of the day? There is only a finite amount of budget available at any one time, and ideally it should go to the problems that need solving immediately. Either that, or take that money and invest it in bonds or something. The point I'm trying to make is that you can't simply say that implementing a pending technology immediately is always the right thing to do. It has to be analyzed for its financial costs and benefits, just like anything else. I hope people take this seriously; corporations just LOVE to wait until they're forced into something, so they can gripe and complain about how complicated it is, when if they would just plan ahead for the inevitable, First of all, ipv6 is far from inevitable. There is raging debate about just how inevitable it really is. What if it turns out to be much ado about nothing - just like ATM to the desktop, Fiber-to-the-curb, and so many other technology initiatives before that? If you had spent money implementing ipv6 and it turns out not to be inevitable, then you just wasted budget dollars that could have been spent doing useful things. they wouldn't have to worry about the problems procrastination brings. (Sorry for the soapbox speech, but I like to encourage proactive ideas.) Yeah well, there are also very serious problems associated with building things out before its time. For example, the telcos, especially the ISP's. Or the dotcoms. So sure you don't want to fall behind the curve. But you don't really want to be too far in front of it either. It's a tricky balancing act. How do you not fall behind your competition and yet not waste money on initiatives that turn out to be worthless? -Original Message- From: Brian Zeitz [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 5:18 PM To: [EMAIL PROTECTED] Subject: RE: dumb question IPV6 [7:53712] Yes, it was me that said 2007. Seems the courts want to push the deadline on updating TV signals before the due date, maybe IPV6 will follow. In the past people have pushed to use certain technology, now its time for us to sit back, because technology is starting to take over by itself. Meaning that companies are going to be forced to use it, or suffer loss to the competition. I know Microsoft and Cisco equipment is IPV6 ready, lets just all switch to IPV6 (insert a date here). -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 3:00 PM To: [EMAIL PROTECTED] Subject: RE: dumb question IPV6 [7:53712] Hopefully it won't be as bad as your analogy with the shipping port workers, which is even more fraught with political issues. The balance of power between the workers and management has a history of being way off balance, one way or the other, with technological changes being marred by work stoppages and violence. It's a precarious situation. (I had the job in the 1980s of replacing one of the highest-paid longshoreman with an automated crane. Boy was that a challenge, not helped by the fact that our management made us install it before the bugs were worked out.) Anyway, the conversion to IPv6 won't be that bad I don't think. Someone asked about a timeframe. (Was it you?) I think it will be beofre 2007. Five years from now, who knows where we'll be? ;-) Priscilla Brian Zeitz wrote: I am for IPV6, I think with e-commerce applications, and because there is a trend to use internet enabled devices. I know it would be confusing for system engineers, just when everyone understood IPV4 I know there are some updated troubleshooting tools, ICMP as well. I think critical mass will push this into reality. I guess it's just like the story with shipping port workers who do not want to use computerized shipping methods to make the process 4x faster like the rest of shipping ports in the world (Singapore,HK) . I think you can put off technology, but they can't hold it back. Eventually, Mexico will build a larger, better high tech computerized shipping port, and people will complain about jobs going to Mexico. Then the shipping dock will shut down, and we will have all these people laid off complaining. I guess we have to do things the hard way when it comes to technology. If it didn't hurt the US economy and businesses so bad, I would be laughing about it. -Original
NAT (was Re: dumb question IPV6) [7:53795]
Hi Priscilla - Can I ask you to expound a bit on something you said in an earlier discussion? When talking about IPv6, you mentioned: ...even though NAT is a horrid solution from a technical standpoint. I don't have an opinion about NAT simply due to a lack of practical experience with it. But I'm curious what your reasons are behind the above statement. :-) Thanks, BJ (Go Blue!) Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53795t=53795 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: dumb question IPV6 [7:53712]
At 10:46 PM + 9/20/02, Priscilla Oppenheimer wrote: nrf wrote: More to the point, it's not really technical or political issues that are at play. It's financial issues. It's business. What exactly do the providers gain by migrating? What new revenue streams? Is there a business model in place to justify the expense of migrating and maintaining two protocols in the interim? What's the ROI? That's a very good point. And it applies to the enterprise corporate side too. What financial benefits do they gain?? Priscilla For one, the economic benefit of being able to change ISPs without internal numbering, and the consequence that the ISPs lose the leverage of locking in customers to their address space. Remember that in V6 addressing, only the low-order part of the address needs to be enterprise-specific. New revenue streams MAY be possible with some of the organizations that already have adopted V6, such as 3rd generation wireless, HDTV, and next-generation air traffic control. For example, people talk about how wonderful ipv6 is for eliminating the need for NAT and how you can now give every device in the world its own unique address. Speaking as someone who was there when the decisions on V6 were made, and continuing to be active in NAT work, this wonderful idea is, in the view of the IETF, urban legend. There was NEVER an attempt to justify V6 because it could give a static address to everything in the world. The long address is there because it allows provider addressing information to be decoupled from enterprise addressing information. I realize that there are large organizations, such as the PRC government, that look at V6 as something that can give them unique static addresses (and it could), but that's NOT the way it was designed to be used. Aside from the addressing aspects, there are also functional changes in the protocol. Yes, pretty much all can be done with IPv4 extensions, but not as cleanly or as efficiently. But the crucial question is how exactly do the providers benefit financially from all this? If nothing else, it gives providers the ability to get into new accounts that previously were barred to them by the customer's unwillingness to renumber out of provider-assigned addres space. Have customers demonstrated that they are willing to pay extra to their provider for the ability to get a unique global address for their refrigerator? What's the evidence? That scenario is somewhat unrealistic anyway. Any smart house proposal I have seen assumes the cable set-top box, etc., is a router with one external address. The appliances, etc., could have link-local addresses on the LAN, and the only address that appears in the global routing system is the (aggregated) subnet of the router. Don't forget that there has long been a clash between using IPv4 addresses as endpoint identifiers as well as routing locators. DNS(v6) is intended to handle some of these complexities. If anything, the IPv6 address splits into a locator and identifier part, although that's something of an oversimplification giving enterprise dynamic (AppleTalk/OSI style) and DHCPv6 addressing. For a carrier, migrating to a new protocol takes months, even years of proper testing and validation, and that's a big expense. What's the evidence that there will be sufficient payback quickly enough to justify that expense? I say all this not to rain on the parade of ipv6, but rather to inject a tone of realism into the equation. As Tom Nolle once said, carriers do not make real expenditures based on hypothetical revenue streams. You don't just spend money on infrastructure based on the thin reed that you hope that customers will come. That's not the way carrier capex financing works these days.It's not 1999 anymore. \ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53799t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: dumb question IPV6 [7:53712]
For one, the economic benefit of being able to change ISPs without internal numbering, and the consequence that the ISPs lose the leverage of locking in customers to their address space. Remember that in V6 addressing, only the low-order part of the address needs to be enterprise-specific. It is difficult for me to see that there is enough money here to justify a transition. New revenue streams MAY be possible with some of the organizations that already have adopted V6, such as 3rd generation wireless, HDTV, and next-generation air traffic control. The key question there is 'may'. Carriers don't just spend money just because there may be new revenue streams - they have to be pretty darn sure there will be and how much and when they will start getting it and all that. Like I said, the dotcom silliness is over. For example, people talk about how wonderful ipv6 is for eliminating the need for NAT and how you can now give every device in the world its own unique address. Speaking as someone who was there when the decisions on V6 were made, and continuing to be active in NAT work, this wonderful idea is, in the view of the IETF, urban legend. There was NEVER an attempt to justify V6 because it could give a static address to everything in the world. The long address is there because it allows provider addressing information to be decoupled from enterprise addressing information. I realize that there are large organizations, such as the PRC government, that look at V6 as something that can give them unique static addresses (and it could), but that's NOT the way it was designed to be used. Good, very good. I'm glad somebody said this. Please come to alt.certification.cisco and set the guys there straight. Dudes over there seem to love ipv6 because they apparently see some reason in giving their toaster a globally unique address. Aside from the addressing aspects, there are also functional changes in the protocol. Yes, pretty much all can be done with IPv4 extensions, but not as cleanly or as efficiently. I believe that almost everything in telecom could be done more cleanly and efficiently. The problem is that there is so much legacy infrastructure that nobody wants to throw out. One guy once said that God made the world in 7 days because he didn't have an installed base to deal with. I replied that it was more like God made the world in 7 days because he didn't have any gear on a 15-year depreciation schedule. But the crucial question is how exactly do the providers benefit financially from all this? If nothing else, it gives providers the ability to get into new accounts that previously were barred to them by the customer's unwillingness to renumber out of provider-assigned addres space. That is, unfortunately, counteracted by providers who want to lock in accounts by forcing those accounts to renumber if they want to get another provider. So I think it's a wash. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53812t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: dumb question IPV6 [7:53712]
If you want to be ISP provider independent, you should have got PI (Provider Independent ) address space from your LIR. though this is discouraged by RIPE, ARAN, and IANA. due to backbone routing tables explosion of routes This is where your LIR assigns you global address space and not you ISP. You could move ISP's transparently if you had these addresses instead of the usual PA address space assigned, though you would need justification to get them. I think currently about 5% of RIPE's address space allocation requests are PI address space, and the rest are PA space.. Kind regards. Paul. -Original Message- From: nrf [SMTP:[EMAIL PROTECTED]] Sent: 21 September 2002 20:29 To: [EMAIL PROTECTED] Subject: Re: dumb question IPV6 [7:53712] For one, the economic benefit of being able to change ISPs without internal numbering, and the consequence that the ISPs lose the leverage of locking in customers to their address space. Remember that in V6 addressing, only the low-order part of the address needs to be enterprise-specific. It is difficult for me to see that there is enough money here to justify a transition. New revenue streams MAY be possible with some of the organizations that already have adopted V6, such as 3rd generation wireless, HDTV, and next-generation air traffic control. The key question there is 'may'. Carriers don't just spend money just because there may be new revenue streams - they have to be pretty darn sure there will be and how much and when they will start getting it and all that. Like I said, the dotcom silliness is over. For example, people talk about how wonderful ipv6 is for eliminating the need for NAT and how you can now give every device in the world its own unique address. Speaking as someone who was there when the decisions on V6 were made, and continuing to be active in NAT work, this wonderful idea is, in the view of the IETF, urban legend. There was NEVER an attempt to justify V6 because it could give a static address to everything in the world. The long address is there because it allows provider addressing information to be decoupled from enterprise addressing information. I realize that there are large organizations, such as the PRC government, that look at V6 as something that can give them unique static addresses (and it could), but that's NOT the way it was designed to be used. Good, very good. I'm glad somebody said this. Please come to alt.certification.cisco and set the guys there straight. Dudes over there seem to love ipv6 because they apparently see some reason in giving their toaster a globally unique address. Aside from the addressing aspects, there are also functional changes in the protocol. Yes, pretty much all can be done with IPv4 extensions, but not as cleanly or as efficiently. I believe that almost everything in telecom could be done more cleanly and efficiently. The problem is that there is so much legacy infrastructure that nobody wants to throw out. One guy once said that God made the world in 7 days because he didn't have an installed base to deal with. I replied that it was more like God made the world in 7 days because he didn't have any gear on a 15-year depreciation schedule. But the crucial question is how exactly do the providers benefit financially from all this? If nothing else, it gives providers the ability to get into new accounts that previously were barred to them by the customer's unwillingness to renumber out of provider-assigned addres space. That is, unfortunately, counteracted by providers who want to lock in accounts by forcing those accounts to renumber if they want to get another provider. So I think it's a wash. This E-mail is from O2. The E-mail and any files transmitted with it are confidential and may also be privileged and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised direct or indirect dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received the E-mail in error please notify [EMAIL PROTECTED] or telephone ++ 353 1 6095000. * Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53815t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: dumb question IPV6 [7:53712]
For one, the economic benefit of being able to change ISPs without internal numbering, and the consequence that the ISPs lose the leverage of locking in customers to their address space. Remember that in V6 addressing, only the low-order part of the address needs to be enterprise-specific. It is difficult for me to see that there is enough money here to justify a transition. ISP service is becoming more and more a commodity. Incumbent carriers often retain accounts due to the difficulty of renumbering. I'm not saying that enterprise flexibility to change carriers is going to result in more revenue to the carrier -- quite the contrary. It will make IP transport cheaper, and the carriers may have to go there to be competitive. New revenue streams MAY be possible with some of the organizations that already have adopted V6, such as 3rd generation wireless, HDTV, and next-generation air traffic control. The key question there is 'may'. Carriers don't just spend money just because there may be new revenue streams - they have to be pretty darn sure there will be and how much and when they will start getting it and all that. Like I said, the dotcom silliness is over. Agreed, and I'm certainly not recommending a massive cutover to V6. I also will make the point that V6 itself doesn't do much to deal with the problems of global routing scalability, probably a more immediate problem than address exhaustion. It could help a little with several built-in levels of aggregation, but that's by no means a solved problem. You might want to look at the discussion in the IETF PTOMAINE working group, as well as the two IRTF reports on future domain routing. But niche applications will grow. For example, people talk about how wonderful ipv6 is for eliminating the need for NAT and how you can now give every device in the world its own unique address. Speaking as someone who was there when the decisions on V6 were made, and continuing to be active in NAT work, this wonderful idea is, in the view of the IETF, urban legend. There was NEVER an attempt to justify V6 because it could give a static address to everything in the world. The long address is there because it allows provider addressing information to be decoupled from enterprise addressing information. I realize that there are large organizations, such as the PRC government, that look at V6 as something that can give them unique static addresses (and it could), but that's NOT the way it was designed to be used. Good, very good. I'm glad somebody said this. Please come to alt.certification.cisco and set the guys there straight. Dudes over there seem to love ipv6 because they apparently see some reason in giving their toaster a globally unique address. Not sure I have time for another newsgroup, but feel free to pass this on. Ask them to look at such things as the Router Renumbering Protocol, autoconfiguration with the Neighbor Discovery Protocol, etc., and ask why they are there if static addressing is the answer. And for that matter, DHCP or self-configuration dynamic DNS update is probably more scalable and easier to troubleshoot than something that completely depends on addresses. One of the hardest things to get across when one gets into serious routing theory is the difference between a locator and identifier, especially when people overload the IP address to be both. I get frustrated with some of my own sysadmins when I even give them the DNS RRs to name a new host, and they insist on referring to it by IP address---which gets especially confusing when I might variously be accessing it in front of, or behind, the NAT firewall. Aside from the addressing aspects, there are also functional changes in the protocol. Yes, pretty much all can be done with IPv4 extensions, but not as cleanly or as efficiently. I believe that almost everything in telecom could be done more cleanly and efficiently. The problem is that there is so much legacy infrastructure that nobody wants to throw out. One guy once said that God made the world in 7 days because he didn't have an installed base to deal with. I replied that it was more like God made the world in 7 days because he didn't have any gear on a 15-year depreciation schedule. Oh, there's much to be learned in that context. Is it an accident, do you think that evil was introduced by the SNAke? Or that multivendor interoperability was first demonstrated when Eve held an apple in one hand and a wang in the other? :-) But the crucial question is how exactly do the providers benefit financially from all this? If nothing else, it gives providers the ability to get into new accounts that previously were barred to them by the customer's unwillingness to renumber out of provider-assigned addres space. That is, unfortunately, counteracted by providers who want to lock in accounts by forcing
RE: dumb question IPV6 [7:53712]
Brian Zeitz wrote: Can anyone give a guess to when IPV6 will be implemented in the US? 2007? IPv6 is already in use on Internet 2, which is pretty prevalent at universities. More info here: http://www.internet2.edu/html/about.html Other than Internet 2, it's hard to say. Workarounds like NAT and CIDR kind of make IPv6 not necessary, even though NAT is a horrid solution from a technical standpoint. The experts don't agree on when, if ever, the migration to IPv6 should happen. Some attendees at IETF meetings are adament that it's time to plan for the conversion now. Others scoff at the entire idea. Others seem irritated that the problem wasn't fixed with good solutions that were presented almost 10 years ago before the Internet exploded. So, it's fraught with political problems, not just technical. ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53725t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: dumb question IPV6 [7:53712]
We have a pilot of IPv6 running on our campus currently. Larry Brian Zeitz wrote: Can anyone give a guess to when IPV6 will be implemented in the US? 2007? -- Larry Letterman Network Engineer Cisco Systems Inc. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53726t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: dumb question IPV6 [7:53712]
I am for IPV6, I think with e-commerce applications, and because there is a trend to use internet enabled devices. I know it would be confusing for system engineers, just when everyone understood IPV4 I know there are some updated troubleshooting tools, ICMP as well. I think critical mass will push this into reality. I guess it's just like the story with shipping port workers who do not want to use computerized shipping methods to make the process 4x faster like the rest of shipping ports in the world (Singapore,HK) . I think you can put off technology, but they can't hold it back. Eventually, Mexico will build a larger, better high tech computerized shipping port, and people will complain about jobs going to Mexico. Then the shipping dock will shut down, and we will have all these people laid off complaining. I guess we have to do things the hard way when it comes to technology. If it didn't hurt the US economy and businesses so bad, I would be laughing about it. -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 1:40 PM To: [EMAIL PROTECTED] Subject: RE: dumb question IPV6 [7:53712] Brian Zeitz wrote: Can anyone give a guess to when IPV6 will be implemented in the US? 2007? IPv6 is already in use on Internet 2, which is pretty prevalent at universities. More info here: http://www.internet2.edu/html/about.html Other than Internet 2, it's hard to say. Workarounds like NAT and CIDR kind of make IPv6 not necessary, even though NAT is a horrid solution from a technical standpoint. The experts don't agree on when, if ever, the migration to IPv6 should happen. Some attendees at IETF meetings are adament that it's time to plan for the conversion now. Others scoff at the entire idea. Others seem irritated that the problem wasn't fixed with good solutions that were presented almost 10 years ago before the Internet exploded. So, it's fraught with political problems, not just technical. ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53731t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: dumb question IPV6 [7:53712]
I remember scripting my first IPv6 tool for IPv6-IPv4 DNS compatibility back in 96/97 during university days .. still surprised that the standpoint for IPv6 among IETF committee members is still the same some 6-7 years ago as it is today (well, maybe with 1 or 2 forward movements since).. nice to know not everything in IT changes with every sunrise :-) -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Saturday, 21 September 2002 03:40 To: [EMAIL PROTECTED] Subject: RE: dumb question IPV6 [7:53712] Brian Zeitz wrote: Can anyone give a guess to when IPV6 will be implemented in the US? 2007? IPv6 is already in use on Internet 2, which is pretty prevalent at universities. More info here: http://www.internet2.edu/html/about.html Other than Internet 2, it's hard to say. Workarounds like NAT and CIDR kind of make IPv6 not necessary, even though NAT is a horrid solution from a technical standpoint. The experts don't agree on when, if ever, the migration to IPv6 should happen. Some attendees at IETF meetings are adament that it's time to plan for the conversion now. Others scoff at the entire idea. Others seem irritated that the problem wasn't fixed with good solutions that were presented almost 10 years ago before the Internet exploded. So, it's fraught with political problems, not just technical. ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53735t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: dumb question IPV6 [7:53712]
Hopefully it won't be as bad as your analogy with the shipping port workers, which is even more fraught with political issues. The balance of power between the workers and management has a history of being way off balance, one way or the other, with technological changes being marred by work stoppages and violence. It's a precarious situation. (I had the job in the 1980s of replacing one of the highest-paid longshoreman with an automated crane. Boy was that a challenge, not helped by the fact that our management made us install it before the bugs were worked out.) Anyway, the conversion to IPv6 won't be that bad I don't think. Someone asked about a timeframe. (Was it you?) I think it will be beofre 2007. Five years from now, who knows where we'll be? ;-) Priscilla Brian Zeitz wrote: I am for IPV6, I think with e-commerce applications, and because there is a trend to use internet enabled devices. I know it would be confusing for system engineers, just when everyone understood IPV4 I know there are some updated troubleshooting tools, ICMP as well. I think critical mass will push this into reality. I guess it's just like the story with shipping port workers who do not want to use computerized shipping methods to make the process 4x faster like the rest of shipping ports in the world (Singapore,HK) . I think you can put off technology, but they can't hold it back. Eventually, Mexico will build a larger, better high tech computerized shipping port, and people will complain about jobs going to Mexico. Then the shipping dock will shut down, and we will have all these people laid off complaining. I guess we have to do things the hard way when it comes to technology. If it didn't hurt the US economy and businesses so bad, I would be laughing about it. -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 1:40 PM To: [EMAIL PROTECTED] Subject: RE: dumb question IPV6 [7:53712] Brian Zeitz wrote: Can anyone give a guess to when IPV6 will be implemented in the US? 2007? IPv6 is already in use on Internet 2, which is pretty prevalent at universities. More info here: http://www.internet2.edu/html/about.html Other than Internet 2, it's hard to say. Workarounds like NAT and CIDR kind of make IPv6 not necessary, even though NAT is a horrid solution from a technical standpoint. The experts don't agree on when, if ever, the migration to IPv6 should happen. Some attendees at IETF meetings are adament that it's time to plan for the conversion now. Others scoff at the entire idea. Others seem irritated that the problem wasn't fixed with good solutions that were presented almost 10 years ago before the Internet exploded. So, it's fraught with political problems, not just technical. ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53736t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: dumb question IPV6 [7:53712]
More to the point, it's not really technical or political issues that are at play. It's financial issues. It's business. What exactly do the providers gain by migrating? What new revenue streams? Is there a business model in place to justify the expense of migrating and maintaining two protocols in the interim? What's the ROI? For example, people talk about how wonderful ipv6 is for eliminating the need for NAT and how you can now give every device in the world its own unique address. But the crucial question is how exactly do the providers benefit financially from all this? Have customers demonstrated that they are willing to pay extra to their provider for the ability to get a unique global address for their refrigerator? What's the evidence? For a carrier, migrating to a new protocol takes months, even years of proper testing and validation, and that's a big expense. What's the evidence that there will be sufficient payback quickly enough to justify that expense? I say all this not to rain on the parade of ipv6, but rather to inject a tone of realism into the equation. As Tom Nolle once said, carriers do not make real expenditures based on hypothetical revenue streams. You don't just spend money on infrastructure based on the thin reed that you hope that customers will come. That's not the way carrier capex financing works these days.It's not 1999 anymore. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53759t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: dumb question IPV6 [7:53712]
Yes, it was me that said 2007. Seems the courts want to push the deadline on updating TV signals before the due date, maybe IPV6 will follow. In the past people have pushed to use certain technology, now its time for us to sit back, because technology is starting to take over by itself. Meaning that companies are going to be forced to use it, or suffer loss to the competition. I know Microsoft and Cisco equipment is IPV6 ready, lets just all switch to IPV6 (insert a date here). -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 3:00 PM To: [EMAIL PROTECTED] Subject: RE: dumb question IPV6 [7:53712] Hopefully it won't be as bad as your analogy with the shipping port workers, which is even more fraught with political issues. The balance of power between the workers and management has a history of being way off balance, one way or the other, with technological changes being marred by work stoppages and violence. It's a precarious situation. (I had the job in the 1980s of replacing one of the highest-paid longshoreman with an automated crane. Boy was that a challenge, not helped by the fact that our management made us install it before the bugs were worked out.) Anyway, the conversion to IPv6 won't be that bad I don't think. Someone asked about a timeframe. (Was it you?) I think it will be beofre 2007. Five years from now, who knows where we'll be? ;-) Priscilla Brian Zeitz wrote: I am for IPV6, I think with e-commerce applications, and because there is a trend to use internet enabled devices. I know it would be confusing for system engineers, just when everyone understood IPV4 I know there are some updated troubleshooting tools, ICMP as well. I think critical mass will push this into reality. I guess it's just like the story with shipping port workers who do not want to use computerized shipping methods to make the process 4x faster like the rest of shipping ports in the world (Singapore,HK) . I think you can put off technology, but they can't hold it back. Eventually, Mexico will build a larger, better high tech computerized shipping port, and people will complain about jobs going to Mexico. Then the shipping dock will shut down, and we will have all these people laid off complaining. I guess we have to do things the hard way when it comes to technology. If it didn't hurt the US economy and businesses so bad, I would be laughing about it. -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 1:40 PM To: [EMAIL PROTECTED] Subject: RE: dumb question IPV6 [7:53712] Brian Zeitz wrote: Can anyone give a guess to when IPV6 will be implemented in the US? 2007? IPv6 is already in use on Internet 2, which is pretty prevalent at universities. More info here: http://www.internet2.edu/html/about.html Other than Internet 2, it's hard to say. Workarounds like NAT and CIDR kind of make IPv6 not necessary, even though NAT is a horrid solution from a technical standpoint. The experts don't agree on when, if ever, the migration to IPv6 should happen. Some attendees at IETF meetings are adament that it's time to plan for the conversion now. Others scoff at the entire idea. Others seem irritated that the problem wasn't fixed with good solutions that were presented almost 10 years ago before the Internet exploded. So, it's fraught with political problems, not just technical. ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53760t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: dumb question IPV6 [7:53712]
You know, that's not such a bad idea. Why wait until the last minute to implement a pending technology; do it now and work out all the bugs before it's forced on you. I hope people take this seriously; corporations just LOVE to wait until they're forced into something, so they can gripe and complain about how complicated it is, when if they would just plan ahead for the inevitable, they wouldn't have to worry about the problems procrastination brings. (Sorry for the soapbox speech, but I like to encourage proactive ideas.) -Original Message- From: Brian Zeitz [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 5:18 PM To: [EMAIL PROTECTED] Subject: RE: dumb question IPV6 [7:53712] Yes, it was me that said 2007. Seems the courts want to push the deadline on updating TV signals before the due date, maybe IPV6 will follow. In the past people have pushed to use certain technology, now its time for us to sit back, because technology is starting to take over by itself. Meaning that companies are going to be forced to use it, or suffer loss to the competition. I know Microsoft and Cisco equipment is IPV6 ready, lets just all switch to IPV6 (insert a date here). -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 3:00 PM To: [EMAIL PROTECTED] Subject: RE: dumb question IPV6 [7:53712] Hopefully it won't be as bad as your analogy with the shipping port workers, which is even more fraught with political issues. The balance of power between the workers and management has a history of being way off balance, one way or the other, with technological changes being marred by work stoppages and violence. It's a precarious situation. (I had the job in the 1980s of replacing one of the highest-paid longshoreman with an automated crane. Boy was that a challenge, not helped by the fact that our management made us install it before the bugs were worked out.) Anyway, the conversion to IPv6 won't be that bad I don't think. Someone asked about a timeframe. (Was it you?) I think it will be beofre 2007. Five years from now, who knows where we'll be? ;-) Priscilla Brian Zeitz wrote: I am for IPV6, I think with e-commerce applications, and because there is a trend to use internet enabled devices. I know it would be confusing for system engineers, just when everyone understood IPV4 I know there are some updated troubleshooting tools, ICMP as well. I think critical mass will push this into reality. I guess it's just like the story with shipping port workers who do not want to use computerized shipping methods to make the process 4x faster like the rest of shipping ports in the world (Singapore,HK) . I think you can put off technology, but they can't hold it back. Eventually, Mexico will build a larger, better high tech computerized shipping port, and people will complain about jobs going to Mexico. Then the shipping dock will shut down, and we will have all these people laid off complaining. I guess we have to do things the hard way when it comes to technology. If it didn't hurt the US economy and businesses so bad, I would be laughing about it. -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 1:40 PM To: [EMAIL PROTECTED] Subject: RE: dumb question IPV6 [7:53712] Brian Zeitz wrote: Can anyone give a guess to when IPV6 will be implemented in the US? 2007? IPv6 is already in use on Internet 2, which is pretty prevalent at universities. More info here: http://www.internet2.edu/html/about.html Other than Internet 2, it's hard to say. Workarounds like NAT and CIDR kind of make IPv6 not necessary, even though NAT is a horrid solution from a technical standpoint. The experts don't agree on when, if ever, the migration to IPv6 should happen. Some attendees at IETF meetings are adament that it's time to plan for the conversion now. Others scoff at the entire idea. Others seem irritated that the problem wasn't fixed with good solutions that were presented almost 10 years ago before the Internet exploded. So, it's fraught with political problems, not just technical. ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53769t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: dumb question IPV6 [7:53712]
nrf wrote: More to the point, it's not really technical or political issues that are at play. It's financial issues. It's business. What exactly do the providers gain by migrating? What new revenue streams? Is there a business model in place to justify the expense of migrating and maintaining two protocols in the interim? What's the ROI? That's a very good point. And it applies to the enterprise corporate side too. What financial benefits do they gain?? Priscilla For example, people talk about how wonderful ipv6 is for eliminating the need for NAT and how you can now give every device in the world its own unique address. But the crucial question is how exactly do the providers benefit financially from all this? Have customers demonstrated that they are willing to pay extra to their provider for the ability to get a unique global address for their refrigerator? What's the evidence? For a carrier, migrating to a new protocol takes months, even years of proper testing and validation, and that's a big expense. What's the evidence that there will be sufficient payback quickly enough to justify that expense? I say all this not to rain on the parade of ipv6, but rather to inject a tone of realism into the equation. As Tom Nolle once said, carriers do not make real expenditures based on hypothetical revenue streams. You don't just spend money on infrastructure based on the thin reed that you hope that customers will come. That's not the way carrier capex financing works these days.It's not 1999 anymore. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53772t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: dumb question IPV6 [7:53712]
Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... nrf wrote: More to the point, it's not really technical or political issues that are at play. It's financial issues. It's business. What exactly do the providers gain by migrating? What new revenue streams? Is there a business model in place to justify the expense of migrating and maintaining two protocols in the interim? What's the ROI? That's a very good point. And it applies to the enterprise corporate side too. What financial benefits do they gain?? Exactly. How many enterprises really have so many devices that they are exhausting their RFC1918 address space? I would say about zero. You don't just install extra protocols in your enterprise just 'for fun', you do it because your enterprise actually needs it. And besides what exactly is the point of running ipv6 internally if your carrier is still running ipv4? Which brings us to the carriers. Ipv6 was meant for really large networks, like the large carriers. The problem is that really large networks are correspondingly important in that there is a substantial dollar value attached to any downtime of that network, which means that any change of that network entails more expense for proper testing and validation to make sure that a new feature implementation isn't buggy. But that raises the bar for a proper implementation of ipv6 even more - ipv6 only makes sense for the largest carriers (because they are the only networks that might require the expanded address space that ipv6 provides) , yet large carriers will have to find even more compelling revenue streams to justify the cost of testing/migration because uptime is so crucial. So you could say that the biggest problem of ipv6 is ...ipv6. Oh, and for all you ipv6 junkies, don't try to come back by saying that you can effect a simple migration just by expanding existing ipv4 addresses into ipv6 addresses. Why? Simple. The problem is that you're still effectively confined to a 32-bit address space which thereby removes the main impetus behind going to ipv6 in the first place. So if you're not going to reap the advantages, then why do it at all? In short, how do you justify to the bean-counters that such a migration makes sense? We're past the weird free-love, free-money dotcom profit-mirage days. 1999 is gone and it ain't coming back. Nowadays you don't just install technology just for the hell of it, and you certainly don't spend serious money doing so. That's not the way corporate finance works. Now you install technologies because there are clear revenue streams to be gained for doing so. Not hypothetical streams but actual proven streams. You have to demonstrate a quick payback period to whatever tech initiatives you are touting using financial figures that can be verified. Anything that smacks of castles-in-the-clouds is going to be dismissed as so much dotcom backwash. Priscilla For example, people talk about how wonderful ipv6 is for eliminating the need for NAT and how you can now give every device in the world its own unique address. But the crucial question is how exactly do the providers benefit financially from all this? Have customers demonstrated that they are willing to pay extra to their provider for the ability to get a unique global address for their refrigerator? What's the evidence? For a carrier, migrating to a new protocol takes months, even years of proper testing and validation, and that's a big expense. What's the evidence that there will be sufficient payback quickly enough to justify that expense? I say all this not to rain on the parade of ipv6, but rather to inject a tone of realism into the equation. As Tom Nolle once said, carriers do not make real expenditures based on hypothetical revenue streams. You don't just spend money on infrastructure based on the thin reed that you hope that customers will come. That's not the way carrier capex financing works these days.It's not 1999 anymore. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53773t=53712 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Dumb question of retansmits
Hello, Well, it depends what type of transmission problem occurs. If a CRC failure occurs on the serial link depending upon the protocol being used between devices then that data may or may not be re-transmitted. However, if either error checking is not present, or the devices do not notice a problem, then the sending host will re-transmit packets per TCP/IP standard. The receiving host will actually request the re-transmission. But like I said, if a CRC error were to occur in a serial line protocol then neither host would be the wiser, and it would the routers would re-transmit. Brandon Ripper -ccna At 10:37 AM 3/26/01 -0700, you wrote: Hi All, I know I should know this, but frankly I can not remember the details to save my life... Let's say we have two routers connected over a serial link, they are doing routing, not bridging. If the serial line takes a hit who is responsible for retransmitting? The sending host or the first router? Now let's say same config but the routers are bridging over the serial line. Who retansmits, the sending host or the first bridge? TIA John Hardman _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Dumb question of retansmits
Hi All, I know I should know this, but frankly I can not remember the details to save my life... Let's say we have two routers connected over a serial link, they are doing routing, not bridging. If the serial line takes a hit who is responsible for retransmitting? The sending host or the first router? Now let's say same config but the routers are bridging over the serial line. Who retansmits, the sending host or the first bridge? TIA John Hardman Retransmission is not inherently part of routing _or_ bridging. For most modern environments, retransmission is done between end hosts [1]. When retransmission is defined at the data link layer, it is done between whatever devices are at the two ends of the link -- hosts and hosts, hosts and routers, routers and routers, etc. [1] In networks that follow the "end to end" assumption of the Internet, and do not contain "midboxes" such as NATs, firewalls, proxies, tunneling devices, etc. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Dumb question of retansmits
Hey John, for the tests you will want to go with the answer of "the sending router" if routing is turned on. The "sending host" if only bridging is turned on. jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Hardman Sent: Monday, March 26, 2001 12:37 PM To: [EMAIL PROTECTED] Subject: Dumb question of retansmits Hi All, I know I should know this, but frankly I can not remember the details to save my life... Let's say we have two routers connected over a serial link, they are doing routing, not bridging. If the serial line takes a hit who is responsible for retransmitting? The sending host or the first router? Now let's say same config but the routers are bridging over the serial line. Who retansmits, the sending host or the first bridge? TIA John Hardman _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Dumb question of retansmits
Lest we go through all of this again, a few weeks ago there was a great thread on this very topic. The resolution was that in just about every situation, it is the hosts that do the retransmitting, NOT the routers! To find out why, go to the archives and search through the last three months for a topic similar to this one. There is a some very useful information contained therein. HTH, John "Brandon Ripper" [EMAIL PROTECTED] 3/26/01 11:25:10 AM Hello, Well, it depends what type of transmission problem occurs. If a CRC failure occurs on the serial link depending upon the protocol being used between devices then that data may or may not be re-transmitted. However, if either error checking is not present, or the devices do not notice a problem, then the sending host will re-transmit packets per TCP/IP standard. The receiving host will actually request the re-transmission. But like I said, if a CRC error were to occur in a serial line protocol then neither host would be the wiser, and it would the routers would re-transmit. Brandon Ripper -ccna At 10:37 AM 3/26/01 -0700, you wrote: Hi All, I know I should know this, but frankly I can not remember the details to save my life... Let's say we have two routers connected over a serial link, they are doing routing, not bridging. If the serial line takes a hit who is responsible for retransmitting? The sending host or the first router? Now let's say same config but the routers are bridging over the serial line. Who retansmits, the sending host or the first bridge? TIA John Hardman _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Dumb question of retansmits
What can be seen by my statement is that the host would re-transmit unless there was a CRC problem on the serial link that the protocol corrected on its own. Please read more carefully. At 11:40 AM 3/26/01 -0700, you wrote: Lest we go through all of this again, a few weeks ago there was a great thread on this very topic. The resolution was that in just about every situation, it is the hosts that do the retransmitting, NOT the routers! To find out why, go to the archives and search through the last three months for a topic similar to this one. There is a some very useful information contained therein. HTH, John "Brandon Ripper" [EMAIL PROTECTED] 3/26/01 11:25:10 AM Hello, Well, it depends what type of transmission problem occurs. If a CRC failure occurs on the serial link depending upon the protocol being used between devices then that data may or may not be re-transmitted. However, if either error checking is not present, or the devices do not notice a problem, then the sending host will re-transmit packets per TCP/IP standard. The receiving host will actually request the re-transmission. But like I said, if a CRC error were to occur in a serial line protocol then neither host would be the wiser, and it would the routers would re-transmit. Brandon Ripper -ccna At 10:37 AM 3/26/01 -0700, you wrote: Hi All, I know I should know this, but frankly I can not remember the details to save my life... Let's say we have two routers connected over a serial link, they are doing routing, not bridging. If the serial line takes a hit who is responsible for retransmitting? The sending host or the first router? Now let's say same config but the routers are bridging over the serial line. Who retansmits, the sending host or the first bridge? TIA John Hardman _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Dumb question of retansmits
Hey John, for the tests you will want to go with the answer of "the sending router" if routing is turned on. The "sending host" if only bridging is turned on. jason For the tests, ROUTERS DON'T RETRANSMIT as a matter of course. Retransmission is an exception to the rule, and only takes place when a specific feature is enabled that calls for retransmission. In general, such features are link-specific data link protocols such as X.25/LAPB and SDLC. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Hardman Sent: Monday, March 26, 2001 12:37 PM To: [EMAIL PROTECTED] Subject: Dumb question of retansmits Hi All, I know I should know this, but frankly I can not remember the details to save my life... Let's say we have two routers connected over a serial link, they are doing routing, not bridging. If the serial line takes a hit who is responsible for retransmitting? The sending host or the first router? Now let's say same config but the routers are bridging over the serial line. Who retansmits, the sending host or the first bridge? TIA John Hardman _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Dumb question of retansmits
Why not take a look at X.25 the protocol accounted for "missing frames". I'm not sure about the specifics of what HDLC does if a CRC error occurs, but I'd imagine it would re-transmit At 01:16 PM 3/26/01 -0700, you wrote: I did read your statement correctly. Which datalink protocols retransmit errored frames without the knowledge of the host? Are there some that do it by default? Are there some that don't do this by default but can be configured to do so? "Brandon Ripper" [EMAIL PROTECTED] 3/26/01 12:43:16 PM What can be seen by my statement is that the host would re-transmit unless there was a CRC problem on the serial link that the protocol corrected on its own. Please read more carefully. At 11:40 AM 3/26/01 -0700, you wrote: Lest we go through all of this again, a few weeks ago there was a great thread on this very topic. The resolution was that in just about every situation, it is the hosts that do the retransmitting, NOT the routers! To find out why, go to the archives and search through the last three months for a topic similar to this one. There is a some very useful information contained therein. HTH, John "Brandon Ripper" [EMAIL PROTECTED] 3/26/01 11:25:10 AM Hello, Well, it depends what type of transmission problem occurs. If a CRC failure occurs on the serial link depending upon the protocol being used between devices then that data may or may not be re-transmitted. However, if either error checking is not present, or the devices do not notice a problem, then the sending host will re-transmit packets per TCP/IP standard. The receiving host will actually request the re-transmission. But like I said, if a CRC error were to occur in a serial line protocol then neither host would be the wiser, and it would the routers would re-transmit. Brandon Ripper -ccna At 10:37 AM 3/26/01 -0700, you wrote: Hi All, I know I should know this, but frankly I can not remember the details to save my life... Let's say we have two routers connected over a serial link, they are doing routing, not bridging. If the serial line takes a hit who is responsible for retransmitting? The sending host or the first router? Now let's say same config but the routers are bridging over the serial line. Who retansmits, the sending host or the first bridge? TIA John Hardman _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Dumb question of retansmits
I did read your statement correctly. Which datalink protocols retransmit errored frames without the knowledge of the host? Are there some that do it by default? Are there some that don't do this by default but can be configured to do so? "Brandon Ripper" [EMAIL PROTECTED] 3/26/01 12:43:16 PM What can be seen by my statement is that the host would re-transmit unless there was a CRC problem on the serial link that the protocol corrected on its own. Please read more carefully. At 11:40 AM 3/26/01 -0700, you wrote: Lest we go through all of this again, a few weeks ago there was a great thread on this very topic. The resolution was that in just about every situation, it is the hosts that do the retransmitting, NOT the routers! To find out why, go to the archives and search through the last three months for a topic similar to this one. There is a some very useful information contained therein. HTH, John "Brandon Ripper" [EMAIL PROTECTED] 3/26/01 11:25:10 AM Hello, Well, it depends what type of transmission problem occurs. If a CRC failure occurs on the serial link depending upon the protocol being used between devices then that data may or may not be re-transmitted. However, if either error checking is not present, or the devices do not notice a problem, then the sending host will re-transmit packets per TCP/IP standard. The receiving host will actually request the re-transmission. But like I said, if a CRC error were to occur in a serial line protocol then neither host would be the wiser, and it would the routers would re-transmit. Brandon Ripper -ccna At 10:37 AM 3/26/01 -0700, you wrote: Hi All, I know I should know this, but frankly I can not remember the details to save my life... Let's say we have two routers connected over a serial link, they are doing routing, not bridging. If the serial line takes a hit who is responsible for retransmitting? The sending host or the first router? Now let's say same config but the routers are bridging over the serial line. Who retansmits, the sending host or the first bridge? TIA John Hardman _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Dumb question of retansmits
Someone who knows more about the specifics than I do will correct me if
I'm wrong, but if I remember correctly HDLC will not retransmit due to a
line error. And again, IIRC, neither does PPP, frame relay, or
ethernet. My impression is that those protocols utilize error
detection, but not error correction. I have absolutely zero experience
with x.25. Does it retransmit due to line errors by default or does
that feature need to be configured?
From what others have been saying, it sounds like current reasoning
suggests that it's better if the hosts are aware of network problems so
that upper-layer protocols can make the necessary adjustments.
Also, someone on the list has pointed out to me that I appear to be in
a bad mood today. :-) This is not the case! I just seem to be typing
that way. ("I'm not bad. I'm just drawn that way." - Jessica Rabbit)
My apologies for being short. I've already had my daily limit of
caffeine so I'd better just go home and take a nap. g
Regards,
John
"Brandon Ripper" [EMAIL PROTECTED] 3/26/01 2:13:03 PM
Why not take a look at X.25 the protocol accounted for "missing
frames".
I'm not sure about the specifics of what HDLC does if a CRC error
occurs,
but I'd imagine it would re-transmit
At 01:16 PM 3/26/01 -0700, you wrote:
I did read your statement correctly.
Which datalink protocols retransmit errored frames without the
knowledge of the host? Are there some that do it by default? Are
there
some that don't do this by default but can be configured to do so?
"Brandon Ripper" [EMAIL PROTECTED] 3/26/01 12:43:16
PM
What can be seen by my statement is that the host would re-transmit
unless
there was a CRC problem on the serial link that the protocol
corrected
on
its own. Please read more carefully.
At 11:40 AM 3/26/01 -0700, you wrote:
Lest we go through all of this again, a few weeks ago there was a
great
thread on this very topic. The resolution was that in just about
every
situation, it is the hosts that do the retransmitting, NOT the
routers!
To find out why, go to the archives and search through the last
three
months for a topic similar to this one. There is a some very
useful
information contained therein.
HTH,
John
"Brandon Ripper" [EMAIL PROTECTED] 3/26/01
11:25:10
AM
Hello,
Well, it depends what type of transmission problem
occurs.
If
a
CRC failure occurs on the serial link depending upon the protocol
being
used between devices then that data may or may not be
re-transmitted.
However, if either error checking is not present, or the devices do
not
notice a problem, then the sending host will re-transmit packets
per
TCP/IP
standard. The receiving host will actually request the
re-transmission.
But
like I said, if a CRC error were to occur in a serial line protocol
then
neither host would be the wiser, and it would the routers would
re-transmit.
Brandon Ripper -ccna
At 10:37 AM 3/26/01 -0700, you wrote:
Hi All,
I know I should know this, but frankly I can not remember the
details
to
save my life...
Let's say we have two routers connected over a serial link, they
are
doing
routing, not bridging. If the serial line takes a hit who is
responsible for
retransmitting? The sending host or the first router?
Now let's say same config but the routers are bridging over the
serial
line.
Who retansmits, the sending host or the first bridge?
TIA
John Hardman
_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to
[EMAIL PROTECTED]
_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to
[EMAIL PROTECTED]
_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to
[EMAIL PROTECTED]
_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Dumb question of retansmits
John Neiberger wrote, Someone who knows more about the specifics than I do will correct me if I'm wrong, but if I remember correctly HDLC will not retransmit due to a line error. And again, IIRC, neither does PPP, frame relay, or ethernet. My impression is that those protocols utilize error detection, but not error correction. I have absolutely zero experience with x.25. Does it retransmit due to line errors by default or does that feature need to be configured? From what others have been saying, it sounds like current reasoning suggests that it's better if the hosts are aware of network problems so that upper-layer protocols can make the necessary adjustments. It depends. There definitely are cases where combinations of slow transmission speed, long propagation delay, and high error rates make link-level retransmission more appropriate for optimized throughput. Certain applications, such as voice, are more intolerant to delay (as might be caused by retransmission) than to error. They have no error correction whatsoever, although they have error detection that causes them to drop errored packets. There are other cases where forward error correction (FEC) makes sense. FEC involves sending additional error-detecting and -correcting bits with a frame, increasing the overhead, but allowing the receiver to figure out what the transmitted bits were without the need for retransmission. FEC can get quite mathematically complex, but it is useful in certain applications where retransmission (anywhere) would be VERY painful. Consider the extreme case, for example, of telemetry to deep space probes where speed-of-light delay can be in minutes or hours (Voyager? You out there?). Additional FEC applications are found in wireless transmission, and in certain modem applications at the bleeding edge of bandwidth for a medium. Another variant of retransmission is SSCOP, the data link protocol for SS7. SSCOP allows redundant links to be set up, with the structure that if either, but not both links, receives a packet with a bad frame check sequence, the packet is accepted only from the link with the good FCS. Retransmission takes place only if both links detect an error, or one link fails. This is NOT an inverse multiplexing protocol intended to deliver twice the bandwidth over paired links; it is intended for situations where the traffic MUST get through and the delay of any sort of retransmission is undesirable. Other applications resend the data, but in a less anal-retentive manner than SSCOP. Some digital weather facsimile broadcasts simply retransmit the same weather map several times. Experience has shown that in the space of 6-10 minutes, every receiver will get an error-free copy, which is quite fast enough to get new weather information by the time anyone can do anything about it. There may be retransmission above the transport layer, as with NFS/RPC. In such cases, there's no real need for the lower layers to retransmit. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Dumb question of retansmits
Hi And thanks one and all for the help! I feel a lot more confident in my understanding. It has been my understanding that the sending host would always send any retransmitts, with the exception of something like a X25 or LLC2 network in between hosts. But I got to reading a bit more on RSRB and DLSw+ the other day, and the more I read the more I got confused... Therefore the question I posted today. Sometimes I hate the CCO pages ;-) I get too deep off on a tangent and lose sight of the forest. Thanks for defining the forest again. THX John Hardman ""Howard C. Berkowitz"" [EMAIL PROTECTED] wrote in message news:p0500191eb6e53e951c3a@[63.216.127.100]... Hi All, I know I should know this, but frankly I can not remember the details to save my life... Let's say we have two routers connected over a serial link, they are doing routing, not bridging. If the serial line takes a hit who is responsible for retransmitting? The sending host or the first router? Now let's say same config but the routers are bridging over the serial line. Who retansmits, the sending host or the first bridge? TIA John Hardman Retransmission is not inherently part of routing _or_ bridging. For most modern environments, retransmission is done between end hosts [1]. When retransmission is defined at the data link layer, it is done between whatever devices are at the two ends of the link -- hosts and hosts, hosts and routers, routers and routers, etc. [1] In networks that follow the "end to end" assumption of the Internet, and do not contain "midboxes" such as NATs, firewalls, proxies, tunneling devices, etc. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Dumb question
Jeremy - even better, what protocl is self correcting ? I need that protocol running on my network ASAP ! Nick Payton Forward error correcting protocols accept addional overhead to provide enough redundancy to give the receiver a fighting chance to correct the frame without retransmission. They tend to be used in radio applications, the extreme case being deep space missions where the probe doesn't have the power or antenna to do routine retransmission, and where the speed of light delay is in minutes or longer. Another approach to self correction can be seen in such protocols as SSCOP, which have options for sending the same message over parallel physical links, and retransmitting only if a frame with a correct checksum is not received on any link. While not strictly error correcting, TCP is highly self correcting with respect to congestion, although there is a continuing evolution of corrective mechanisms. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeremy Dumoit Sent: Thursday, February 08, 2001 8:32 PM To: [EMAIL PROTECTED] Subject: Dumb question I think I'm unclear on some of the protocols here... for what purpose would a protocol detect errors, but not correct them? Maybe QoS? Several reasons. One, the nature of the application is such that some errors are tolerable, and it is worse to delay the packet than drop it. Think packetized voice. Second, you need to look at the overall protocol stack. If you know a higher- or lower-layer protocol will retransmit, why bother duplicating error correction? Think of NFS over RPC over UDP, where RPC does the retransmission at the record level. Alternatively, think of UDP over X.25. Third, the topology is such that it's impractical to retransmit. Think one-to-many multicasting such as sending weather maps to thousands of airports. Individual errors are tolerable here, because weather only changes significantly at 5 or 10 minute intervals (or longer), and a new copy of the weather map is sent every 30-60 seconds. Statistically, you just need to wait and you will get a clean copy. -- "What Problem are you trying to solve?" ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Technical Director, CertificationZone.com Senior Mgr. IP Protocols Algorithms, Core Networks Advanced Technology, NortelNetworks (for ID only) but Cisco stockholder! "retired" Certified Cisco Systems Instructor (CID) #93005 _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Dumb question
Jeremy - even better, what protocl is self correcting ? I need that protocol running on my network ASAP ! Nick Payton -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeremy Dumoit Sent: Thursday, February 08, 2001 8:32 PM To: [EMAIL PROTECTED] Subject: Dumb question I think I'm unclear on some of the protocols here... for what purpose would a protocol detect errors, but not correct them? Maybe QoS? _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Dumb Question
On Sat, 27 May 2000, Jason wrote: How do I get the router to prompt me for a password when connecting through the Console. It would allow me access to the user prompt without any password. Setting password on Console doesn't seems to work. Thks. You also need to set login. en # conf t #(config) line con 0 #(config-line) password WORD #(config-line) login #(config-line) CTRL-Z #wr m -- Jay Hennigan - Network Administration - [EMAIL PROTECTED] NetLojix Communications, Inc. NASDAQ: NETX - http://www.netlojix.com/ WestNet: Connecting you to the planet. 805 884-6323 ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
