Cisco vs. the world! WAS Re: eXtreme and Cisco
Mohamed, The short answer to your original question... No, Cisco will not die. They are too entrenched in the corporate networks to die. However, they certainly will not be as dominate in the service provider space (i.e., telcos, ISPs, ASPs, etc.) as they are in the enterprise (corporate) market. Now the longer answer... I think you hit the nail right on the head. The small, specialized companies are causing problems for Cisco in the service provider market. The niche players are becoming very good (very quickly I might add) in their respective areas. Juniper in core routers and Extreme in core switches are excellent examples of this. I think Cisco is finding it difficult to beat out all of these niche players in their respective areas. Will one niche player like a Juniper "kill" Cisco? Absolutely not...not on their own. However, while Cisco is almost untouchable in the enterprise market, the combination of these niche companies (Juniper + Extreme + Sycamore + Ciena + etc.) could pose a huge obstacle in Cisco's quest for market share in the service provider space. Also, keep in mind that as the Junipers of the world get bigger, their market cap also grows. For Cisco, this means that the "can't beat them, but them" option becomes less of a reality. Last point: In the SP (service provider) space, end-to-end solutions mean less than in the enterprise market. Been in a central office lately? You'll likely find Cisco, Lucent, Nortel, Ciena, Tellabs, ADC, and a bunch of others. In a perfect world, a single vendor end-to-end solution would be great (especially from a network management perspective). But a lot of SPs often want best-in-class for each individual product type (routers, switches, ADMs, cross-connects, etc). End-to-end is of secondary importance in the SP market and SPs are where Cisco is now putting its focus. Regards. Marcus P.S. The CCIE is indeed safe. It will retain it's value for long time. At 03:21 PM 12/11/2000 +0400, you wrote: hi guys just coming now from extreme presentation .looks like they have much more stronger products than cisco (in giga swtiches of course )do u think guys that Cisco is going to die because of small focused companies like extreme and jinper ??? if anyone feel interested ..we would like to discuss this Mohamed _ 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: TCP/IP book...Douglas Comer/Stevens/Radia?
Hello, If you are looking for books that focus strictly on the IP protocol suite (IP, TCP/UDP, ARP, ICMP, etc), I would not suggest Radia Perlman's "Interconnections" or Jeff Doyle's "Routing TCP/IP Volume 1". While "Interconnections" is an excellent text that addresses a lot of topics quite well, its coverage of TCP/IP is limited in comparison to the other books. And Doyle's book, while great in its own right, has as its primary focus IP routing protocols. Therefore, while there is some good information on IP itself (and associated protocols like ARP), I believe the title of the book, "Routing TCP/IP", states its focus quite well. That leaves the books by Stevens and Comer. Honestly, they are both excellent books that cover the IP protocol suite very well. I think it's really a toss up between the two books. My personal belief is that while the Comer book is great, the Steven's book covers the IP suite in a bit more detail . That said, if I were purchasing a TCP/IP book today, I might go with the Comer text strictly because it has been updated recently. Again, either way you go, I don't think you will be disappointed. Just my $0.02 (US) -Marcus At 06:05 PM 07/18/2000 -0400, [EMAIL PROTECTED] wrote: >Hello group, > >I want to get a very good book on this particular subject..TCP/IP. I checked >reviews on amazon.com for different books, can't decide which one I should >get. They all seem very good. > >Douglas Comer book is..Internetworking with TCP/IP >Stevesnts.TCP/IP Illustrated Vol 1 >Radia..Interconnections with ... >and there is another one...Jeff Doyle...Routing with TCP/IP (I am waiting for >the new edition of this book, not out yet) > > I have taken MCSE TCP/IP exam a year back but that was for Windows NT 4.0. >I want to learn it at advance level now, for Internetworking. >I am finishing up my CCNP and will be going for CCIE soon. > >Any comments will be helpful. >Thanks! > >___ >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] = Marcus A. Walton Lucent Technologies, Inc. NetworkCare Professional Services "The Knowledge Behind the Network" ___ 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]
Re: Voice over IP
Hi Keith, I'm not an expert on RSVP but I'll give this a shot... The reservation of bandwidth using RSVP simply prioritizes RSVP traffic of a given flow over all other incoming traffic (note that one RSVP flow can be prioritized over another RSVP flow). Thus, the RSVP traffic will always be routed before non-RSVP traffic. This has the effect of reserving bandwidth for RSVP traffic. Now, what happens if there isn't any incoming traffic on a given RSVP flow (i.e. your silence suppression example)? In the case of an extended gap between RSVP flow packets, non-RSVP packets could slip in and get routed due to the lack of priority traffic. Thus, the bandwidth is available to other traffic as along as there is no incoming RSVP traffic. That said, keep in mind that an RSVP session (flow) on a router will timeout if: 1) No RSVP packets in a flow have been received within a specified amount of time 2) No PATH or RESV message has been sent to periodically refresh the router's RSVP state machine When a timeout occurs (timeout intervals are specified in the PATH message), the router stops giving priority to RSVP traffic thereby releasing the bandwidth reservation. This is why it is unlikely that you would see a large number of non-RSVP packets being routed between two RSVP packets of the same flow (the session would probably timeout before this could occur). Hope this helps... -Marcus At 04:16 PM 07/26/2000 +0100, keith wood wrote: >I am currently reading throught the CVoice notes and have just passed the >section on RSVP. You can reserve bandwidth with this protocol to give to >active voice channels for the duration of the call - this much I understand, >no problem. > >What isn't clear in the notes is whether or not the bandwidth is available >to other traffic if the voice traffic is not using it all - ie: during >silence suppressed moments. > >Anybody know..? > >Thanks. > > > >___ >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] = Marcus A. Walton Lucent Technologies, Inc. NetworkCare Professional Services Division "The Knowledge Behind the Network" ___ 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]
Re: MAC address
Hi Oscar, Q1: "While an IP packet is being packaged to be delivered at the Ethernet frame stage, how is the destination MAC address determined?" A1: The Address Resolution Protocol (ARP) is used to determine the destination MAC address when only the destination IP is known. The source host will broadcast an ARP request to all hosts on the local network asking the owner of the destination IP address to respond. Only the host that owns the destination IP will respond (using a unicast packet) with an ARP reply saying "Here's my MAC address...". All other hosts will ignore the ARP request since it does not pertain to them. Q2: "Is the destination MAC address going to be the MAC address of the local gateway or the remote host?" A2: It depends. If the destination host is on the local network (i.e., source & destination are connected to the same segment) then the destination MAC will the MAC address of the remote host. However, if the destination host is on a remote network then the destination MAC will be the address of the local gateway (router). The reason for this is that the ARP request (which is broadcast) will not be forwarded by the router. Therefore, the remote host will never have a chance to reply to the ARP request since it will never see it. In cases such as these, the router will respond to an ARP request on behalf of a remote host - this is known as Proxy ARP. Q3: "Is the MAC changed by the network devices (routers) along the way until it has been delivered to the destination Ethernet IP address?" A3: Yes, the destination MAC addresses will change hop to hop (router to router) as the packet travels across the network. On the other hand, the destination IP address will remain the same until it reaches its destination. Q4: "Which half is the vendor specific portion?" A4: The vendor specific portion of the MAC address (also known as the OUI - Organizationally Unique Identifier) is the first 24 bits (3 bytes) of the MAC. In your example, this would be 01 23 45. Q5: "Where would the multicast bit and locally administered MAC address bit be located?" A5: The multicast bit is the low-order bit of the first octet of an ethernet address. This bit should be set to 1 for multicast mode. For example, given the MAC address 08 01 02 03 04 05, the multicast address would be 09 01 02 03 04 05 (last bit in the first byte changed from 0 to 1). As far as the locally administered bit is concerned, that should be bit number 7 (out of 48) of the MAC. Again, 1 means local, 0 means global or IEEE administered. HTH, Marcus At 10:46 PM 08/08/2000 +, Oscar Rau wrote: >While an IP packet is being packaged to be delivered at the Ethernet frame >stage, >how is the destination MAC address determined? Is the destination MAC >address going >to be MAC address of the local gateway or the remote host? > >Is the MAC changed by the network devices (routers) along the way until it >has been delivered to >the destination Ethernet IP address? > >If a MAC address is, > > 01 23 45 67 89 11 > >Which half is the vendor specific portion? Where would the multicast bit >and locally >administered MAC address bit be located? > >Thank you in advance. >-- > >Oscar Rau >[EMAIL PROTECTED] > >___ >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] = Marcus Walton Lucent Technologies, Inc. NetworkCare Professional Services Division "The Knowledge Behind the Network" ___ 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]
