Knowledge and Skills for the Real World
My earlier post introduced the Cisco MeetingPlace solution that combines voice, video and web conferencing products that are housed within the customer’s private network, allowing for a lower cost of service and maximum security.Today we’ll go over the hardware platforms involved.
Continue reading ‘Cisco Unified MeetingPlace Hardware Platforms’
Over the next few years as IP Telephony and VoIP take over the communications industry, many companies will be faced with the difficult decision to migrate their antiquated telephony infrastructure to VoIP. Cisco Unified Communications (UC) combines all forms of business communications into a single, unified system that provides powerful new ways to collaborate. MeetingPlace is a significant component of the suite of products Cisco Systems calls “UC”.
Cisco Unified MeetingPlace Release 7.0 is a Session Initiation Protocol (SIP)-based architecture that provides voice, video, and web conferencing solution to large enterprises. Housed within the customer’s private network, it allows for a lower cost of service and maximum security. End users can enter MeetingPlace conferences by using a variety of desktop applications such as IM clients, IP Telephones, and web browsers. Because of its capabilities to utilize IP Based phones, PSTN, groupware clients and web browsers, MeetingPlace users can ensure their participation and availability in conferences from any location.
Cisco’s MeetingPlace 7.x integrates with Cisco Unified Communications Manager (CUCM – formerly CallManager) 6.0 for audio only, and CUCM 6.1(2) and above for audio and video conferencing. Users enjoy single click access to attend the meetings, and can be notified via e-mail or calendar when meetings are scheduled.
VLANs, as we discussed before, are used to create logical broadcast domains on switches. However this information needs to be synchronized between switches. Manual configuration can be tedious in a large scale network, so understanding how to configure VLAN Trunking Protocol and Dynamic Trunking protocol are necessary.
To begin, you must understand the basic function of VTP. VTP is a messaging protocol that CISCO designed to synchronize the VLAN database (vlan.dat) between switches in a common administratively controlled group (VTP domain). This information is only propagated as Layer 2 multicast advertisements across trunk ports. Additionally, all switches abide by synchronizing to the latest change of the database (this is also referred to as the latest revision number). First we must discuss the function of VTP modes: Server mode, Client mode, and Transparent mode, to maintain this control. Each mode can be configured from global configuration mode and can be verified with the show vtp status command.
A switch that is in Server mode has the ability to create, modify and delete VLANs from the Database, and synchronize to the latest change. Synchronization can occur from receiving messages from that originated from a server switch then passed through a client or another server switch. This is also the default mode.
Example 1:
SW1#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#vtp mode server
Device mode already VTP SERVER.
SW1(config)#exit
SW1#show vtp status
|
VTP Version |
:2 |
|
Configuration Revision |
:4 |
|
Maximum VLANs supported locally |
:250 |
|
Number of existing VLANs |
: 9 |
|
VTP Operating Mode |
:Server |
|
VTP Domain Name |
: POD4 |
|
VTP Pruning Mode |
: Disabled |
|
VTP V2 Mode |
: Disabled |
|
VTP Traps Generation |
: Disabled |
|
MD5 digest |
:0xFA 0xCF 0×65 0xB5 0×11 0×26 0xF2 0×82 |
Configuration last modified by 10.4.1.2 at 3-1-93 00:02:20
Local updater ID is 10.4.1.3 on interface Vl1 (lowest numbered VLAN interface found)
SW1#
Client mode only will make changes to the VLAN database when and a VTP advertisement with a higher Revision number is received. Synchronization is the same as server mode, where client switches updates its own database with the advertisement received then passes the message along out other trunk ports.
Example 2:
SW1#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#vtp mode client
Setting device to VTP CLIENT mode.
SW1(config)#vlan 5
VTP VLAN configuration not allowed when device is in CLIENT mode.
SW1(config)#vlan 10
VTP VLAN configuration not allowed when device is in CLIENT mode.
SW1(config)#exit
SW1#vtp
SW1#show vtp status
|
VTP Version |
:2 |
|
Configuration Revision |
:4 |
|
Maximum VLANs supported locally |
:250 |
|
Number of existing VLANs |
: 9 |
|
VTP Operating Mode |
:Client |
|
VTP Domain Name |
: POD4 |
|
VTP Pruning Mode |
: Disabled |
|
VTP V2 Mode |
: Disabled |
|
VTP Traps Generation |
: Disabled |
|
MD5 digest |
:0xFA 0xCF 0×65 0xB5 0×11 0×26 0xF2 0×82 |
Configuration last modified by 10.4.1.2 at 3-1-93 00:02:20
Transparent mode can create VLANs just like server mode, but instead of synchronizing to the latest revision number, the switch just ignores the message and forwards it out of other trunk ports. Additionally its revision number is always zero.
Example 3:
SW1#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#vtp mode transparent
Setting device to VTP TRANSPARENT mode.
SW1(config)#vlan 5
SW1(config-vlan)#exit
SW1(config)#exit
SW1#show vtp status
|
VTP Version |
: 2 |
|
Configuration Revision |
: 0 |
|
Maximum VLANs supported locally |
: 250 |
|
Number of existing VLANs |
: 11 |
|
VTP Operating Mode |
: Transparent |
|
VTP Domain Name |
: POD4 |
|
VTP Pruning Mode |
: Disabled |
|
VTP V2 Mode |
: Disabled |
|
VTP Traps Generation |
: Disabled |
|
MD5 digest |
: 0×63 0×01 0×67 0×1E 0×9B 0×4E 0xAF 0×50 |
Configuration last modified by 10.4.1.3 at 3-1-93 00:02:20
To administer a network with the least amount of administration overhead (which may waste manpower), each physical broadcast domain should have one or two VTP servers and the remaining switches should operate in Client mode. However, rogue switches (a switch in Server or Client mode with a higher revision number) have the potential to erasing known VLANS from the database. This is sometimes referred to as a VTP wipeout. To prevent this, authentication can be configured between switches with the VTP password command. Switches with dissimilar authentication will not update one another’s database. Otherwise Transparent mode should be configured, to prevent this possible vulnerability, however the VLAN changes must be updated on each switch within that given VTP domain name.
Dynamic Trunking Protocol is a layer 2 protocol that is responsible for dynamically negotiates trunks between switches. It can aid an administrator in building trunks between switches by the given operating mode that can be configured per interface. However, there are best practices for implementing these modes. These modes are Switchport mode: Dynamic Desirable, Dynamic Auto, Trunk and Access.
The first two modes operate by how DTP messages are being sent across the link. Dynamic Desirable mode actively sends DTP packets to negotiate trunks, while Dynamic Auto passively receives DTP packets then sends a response packet to negotiate the trunk.
Example 4:
SW1#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#interface fastethernet 0/5
SW1(config-if)#switchport mode dynamic desirable
SW1(config-if)#end
SW1#show interface fastethernet 0/5 trunk
|
Port |
Mode |
Encapsulation |
Status |
Native vlan |
|
Fa0/5 |
desirable |
802.1q |
trunking |
1 |
Example 5:
SW1#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#interface fastethernet 0/5
SW1(config-if)#switchport mode dynamic auto
SW1(config-if)#end
SW1#show interface fastethernet 0/5 trunk
|
Port |
Mode |
Encapsulation |
Status |
Native vlan |
|
Fa0/5 |
auto |
802.1q |
trunking |
1 |
The next two modes, Switchport mode Trunk and Switchport mode Access, actually allow the administrator to manually configure a trunk or a port that will never be a trunk (access).
Example 6:
SW1#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#interface fastethernet 0/5
SW1(config-if)#switchport mode trunk
SW1(config-if)#end
SW1#show interface fastethernet 0/5 trunk
|
Port |
Mode |
Encapsulation |
Status |
Native vlan |
|
Fa0/5 |
on |
802.1q |
trunking |
1 |
Example 7:
SW1#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#interface fastethernet 0/5
SW1(config-if)#switchport mode access
SW1(config-if)#end
SW1#show interface fastethernet 0/5 trunk
|
Port |
Mode |
Encapsulation |
Status |
Native vlan |
|
Fa0/5 |
off |
802.1q |
non-trunking |
1 |
As a general practice, trunks should be configured manually between switches and manually disable on port that connect to end devices or layer 3 devices. By allowing switches to dynamically negotiate its trunk, could potentially allow the switch to negotiate trunking on an unexpected port which could lead to a VTP wipe out.
These technologies are critical for the CCNA exam, and a practice with each of these commands and protocols with make the testing process easier.
Related Training: CCNA Boot Camp
Author: Jason Wyatte
: 
: 
: 
: 
Session Initialization Protocol (SIP) has clearly won as the leading IETF (internet engineering task force) standard which everyone is using to build Unified Communication applications. Now that the IETF has clearly defined this protocol and the way it is supposed to function, all software manufacturers using it can ensure that their applications will work with other vendor applications using the same standard.
But how did they get there?
The main reason software manufacturers are supporting SIP is the potential to incorporate future improvements being made by their engineers into the internet standards guided by the IETF. Of course, all vendors who have a chair on the IETF committee must all agree before an idea is accepted and implemented. This check and balance, allows protocol to adapt to future hardware and software improvements that will ultimately change the internet in the future. So this standards-based approach is critical.
Additionally, since SIP uses the internet infrastructure for its operation, it is very easily adaptable for Unified Messaging applications for small, medium, to large company environments but also home users. Some companies have already developed and rolled out their solutions for home owners like Vonage, Skype, as well as all the major cable companies now competing in this fast growing market – all due to the development of the SIP protocol.
Since it is quickly becoming the leading communications protocol used by all UC vendors, it is very important to understand how it works and what support it gives to current and future applications under development. First of all there three types of SIP servers which service SIP phones and they are proxy, registrar, and redirect.
The user agent mentioned above is the actual phone device using SIP. A SIP phone device has all of the requirements within it to make and receive a call. To make a call, the phone or user agent will use the client process piece of software code to generate the call request. On the receiving user agent, the server process piece of software accepts the call request. So, UAC (user agent client) makes the call and the UAS (User agent server) receives the request.
If you want to really understand how this protocol functions; you would need to read the IETC working group’s request for comments (RFC) documents #3261 – 3265 (RFC3261 is the main one) that discuss SIP in detail. Now reading RFC’s is not for the novice – they can get pretty technical very quickly – since they are actually written by engineers for engineers. You may want to consider taking a Voice Over IP course where you’ll get detailed information in layman’s terms into the interworking of the protocol and be able to see it in action using leading industry gateways and SIP phone endpoints.
Author: Joe Parlas
My previous post discussed basic VLAN configuration and also more advanced topics such as how to configure VTP and DTP. Now I will focus on a simple topic that is next in VLAN discussion: VLAN encapsulation types. There are two types Cisco ISL and IEEE 802.1q, and these encapsulations have their own distinct features that allow communications between switches.
Before we begin to distinguish the difference between the two, what are the advantages behind having a trunk in the first place? Initially, all ports on the same switch are in the same broadcast domain, and the creation of multiple VLANs breaks this rule. However for traffic in one VLAN that is destined to go to a host on the same VLAN but a different switch, brings us to the need of a way to distinguish VLANs across the link. Otherwise, there would be a requirement for a port from each VLAN to interconnect between switches (ex: 10 VLANs on one switch would have to have 10 ports to connect to another switch, with one port per VLAN). Therefore the need of trunk encapsulation is extremely important for communication for VLAN traffic.
The first type of encapsulation is Inter-Switch Link (ISL). This is a Cisco proprietary protocol that was developed with the ability to distinguish not only VLANS themselves but also the Spanning-tree instance for each VLAN. This was extremely efficient to load sharing purposes by having different discrete Root Bridges to control the forwarding path per VLAN. Additionally, ISL can encapsulate other layer two protocols such as Token Ring, ATM, and FDDI in addition to both Ethernet types. This is useful in environment that would require that type of transportation of other layer 2 datagrams across a LAN. Lastly, ISL encapsulates with a 26 byte header and 4 byte CRC with only adds 30 bytes for Layer 2 overhead. For verification of this type of encapsulation, the show command, Show interface trunk provides the simplest display.
Example 1
SW1#show interface fastethernet 0/5 trunk
Port Mode Encapsulation Status Native vlan
Fa0/5 on ISL trunking
The Second VLAN encapsulation is the IEEE 802.1q. This is non-proprietary so it can be used between different vendor switches. However it doesn’t have the ability to transport Token Ring, FDDI, or ATM because it uses a 4 byte tag that is inserted directly behind the source MAC address in an Ethernet Frame. It can be used to distinguish Spanning-tree instances however but that will be discussed in my spanning-tree blog that is coming up within a few weeks. In addition to adding the four byte header, it also recalculates the FCS because the datagram size has increased. Verification again for this type of encapsulation, the show command, Show interface trunk provides the simplest display.
Example 2
SW1#show interface gigabitethernet 1/15 trunk
Port Mode Encapsulation Status Native vlan
Fa0/5 on 802.1q trunking 1
Lastly, when these encapsulations are compared to one another, each has its own differences. ISL encapsulates every datagram across the trunk link, while IEEE 802.1q encapsulates every VLAN but the one that is specified as the native VLAN. A native VLAN is untagged across the trunk link that would allow spanning tree traffic to be sent or other layer 2 management protocols to be transported across the link. (The initial purpose however was to have the ability to have a hub to connect between switches and a pc that was connected off the hub to see the untagged data and that it should be understood by the pc. Now in today’s world this does seem extremely preposterous due to having a collision domain with multiple switches residing within it). ISL, initially only supported 1024 VLANs while IEEE 802.1q supports 4096 VLAN identification numbers. (However on most Cisco switches, they can only support from under 1005 VLANs).
Concluding, trunks are an important part of VLAN communication. IEEE 802.1q being non-proprietary, is the most widely accepted encapsulation. Each of my posts builds on the next, and in my next post I will discuss Inter-VLAN routing.
Author: Jason Wyatte
: : : :
After 3 ½ years from the date that I earned my CCVP certification and eight years from which I had my first experience with Cisco Call Manager (also known as Communication Manager) I have begun the journey towards joining the ranks of some very talented individuals in the Cisco world. I am talking about the people who have earned the right to call themselves a Cisco Certified Internetwork Expert (CCIE).
CCIE is among the most sought out certification in the technical industry today. Many people want it, but find it difficult to achieve. The dedication and commitment it requires is far beyond what most are willing to sacrifice, especially if you have a full time job and have to study for this test at the same time. There are many that I know have taken six-month sabbaticals from their jobs just to prepare. Yes, it is this serious!
My pursuit of a CCIE Voice started over a year ago when I scheduled my first lab attempt. I later had to reschedule it because of several obligations such as busy schedule and lack of preparation. However, this time around there is no rescheduling.
One thing that has been helpful in getting ready is the fact that I teach the Cisco Voice track, plus I am a consultant and work on the technology regularly. I hope this will make my experience less daunting, however, regardless of years of experience no one can take this exam lightly.
I started my preparation by acquiring CCIE Voice labs from training sources (such as Global Knowledge) and keying away at commands 24/7; yes, my fingers are sore. However, I found my best method in learning the configurations is to hand write the commands on notebook paper. For me, it makes them easier to remember, especially when I am traveling on the road and don’t have access to equipment.
Another hint, and one most folks miss, is to keep in mind that there are thousands of ways to configure something in Call Manager, so I must know them all. This requires that I read Document CD’s in its entirety. There is always something I seem to learn when I read a DocCD or Cisco SRND regardless of how many times I have read it.
The moment has come for me to pass this exam on my first attempt. My exam is just around the corner on May 13, 2009 in San Jose. I am not nervous, just scared. Wish me luck.
: : : :
So, it’s your first major voice deployment and you are wondering what are some basic things that you need to know for a successful project.
The most important thing to know, and to find out at the beginning of the project, is an understanding of all the different aspects of the team; from sales to the engineers, from the service provider contact to the customer. All of these stakeholders can either make or break your voice deployment.
Just recently, I returned from a client in Florida that has been trying for over two years now in trying to implement a Cisco IP Contact Center Enterprise Solution. The project has been delayed by poorly managed customer requirements from day one. Such delays can be avoided by following a few tips listed below:
These are just some basic tips to get you started and in the correct mindset for managing a voice project. Did I miss something? Leave us a comment below with your tips.
Many enterprises have already invested in Cisco and Microsoft communications infrastructures and rather than replace one or the other, want to leverage them for a truly Unified Communications solution.
Download the recorded seminar and learn how a Unified Communications solution based on an integrated Cisco/Microsoft infrastructure can leverage your current investments and result in a faster ROI. In this free one hour webinar, presenters Craig Brown and Joey Dewiele will present:
- Cisco Unified Communications Manager (CUCM),
- Cisco Unified Presence Server (CUPS), and
- Microsoft Office Communication Server (OCS).
CCNA Boot Camp training contains both the Interconnecting Cisco Network Devices Part 1 and Part 2 course material. This intense training course shows students how various network devices use various components to provide connectivity for sharing resources and increasing employee productivity.
Most of us are familiar with our own Local Area Networks (LANs) that use the Ethernet protocol, which operates at the Data Link Layer of the OSI model. What may not be familiar is the fact that LANs may also be designed around the Token Ring and Fiber Distributed Data Interface (FDDI) protocols.
Token Ring
Token ring is a Local Area Network protocol that uses a token-passing network-access technology. It is implemented in a physical ring or physical star topology that creates a logical ring topology. This protocol was initially developed by IBM and was considered to be proprietary. However, the protocol was later codified by the IEEE with the IEEE 802.5 specification.
With token passing, a three-byte token that has a specific and special bit pattern is inserted into a frame and passed in a single direction from one node to another until it forms a complete loop. The node that has current possession of the token is the only one that is allowed to send data at any given time on that LAN. This is considered to be a form of network contention and, because only one node can send data at a time, collisions such as those experienced with Ethernet are avoided.
Rather than using a hub or switch, as does the Ethernet protocol, token ring uses a Multistation Access Unit (MAU) to send a token across the network. The MAU has ports identified as Ring In (RI) and Ring Out (RO). The RO of the first MAU in the ring is connected to the RI of the next MAU. The sequence of token passing continues until the final MAU in the ring, which connects back to the first MAU RI port via its own RO port, is reached. It is important that each device in the ring must be configured for the same speed. Otherwise, the token passing will not function.
One of the primary reasons that Token Ring is considered to be a legacy protocol and rarely used in modern networks is the low bandwidths available. A token-ring LAN can only run at either 4Mbs or 16Mbs. In addition, although this protocol provides a collision-free network, it is more expensive to implement than Ethernet.
FDDI
Another token-passing protocol is known as Fiber Distributed Data Interface (FDDI). This protocol was developed by the American National Standards Institute (ANSI) and is defined in the ANSI X3T9.5 specification. With FDDI, data transmission occurs on fiber-optic cables at a rate of 100Mbs. FDDI was primarily designed and developed to transfer data across the network backbone of a large company.
Instead of using a single copper-media ring, as does token ring, FDDI uses a dual fiber-optic ring that provides both redundancy and fault-tolerance. In addition, since FDDI uses fiber-optic cable, it is not susceptible to Electromagnetic Interference (EMI) as are other media options.
When FDDI devices detect a failure on a network, they use a process called beaconing to send a signal informing the other devices on that LAN that token passing has stopped. The beacon itself travels around the ring from one device to the next until it reaches the last device in that ring. All the network administrator needs to do to troubleshoot a failed network is to identify the beacon at that last device and then check the connection between that device and the next connected device on the FDDI network.
FDDI is also considered to be a legacy protocol and rarely used in modern networks. Although this protocol provides a collision-free network, it is more expensive to implement than Ethernet and is limited to a 100Mbs network speed.
Author: David Stahl
: : : :
In “Part 2”, we solved a subnet masking problem using binary. This time, we’ll look at some helpful shortcuts that can make solving such problems faster and easier for most people (and less error-prone, as well).
First, let’s summarize our findings from before. To subnet the 192.168.1.0/24 network into four subnets, each allowing at least fifty hosts, we determined that we need a mask of “/26”, or “255.255.255.192”. From this, we obtained the following subnets, ranges and broadcast addresses (these are the values in the last octet):
· Subnet: 0, Range: 1 – 62, Broadcast: 63
· Subnet: 64, Range: 65 – 126, Broadcast: 127
· Subnet: 128, Range: 129 – 190, Broadcast: 191
· Subnet: 192, Range: 193 – 254, Broadcast: 255
The first thing to notice is the correlation between the subnet mask and the increment. In this example, the octet of interest is the fourth, and the value of the mask in that octet is “192”. If you take the value of the mask (192) and subtract it from 256 (a magic number!), you get 64, the amount by which the subnets increment (0, 64, 128, 192).
Recall that the 1’s in a subnet mask indicate network-type info, and the 0’s indicate host info. Thus, with a subnet mask of 192 (in the fourth octet), which is “1100000” in binary, there are two subnet bits, and six host bits. Here’s the powers of two chart:
|
n = |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
2n = |
256 |
128 |
64 |
32 |
16 |
8 |
4 |
2 |
Referring to the chart, we see that the value of the least-significant subnet bit is 64 (26 = 64), so the subnets increment by 64. Also, since the mask is a “/26”, there are six host bits, and, as we know, 26 = 64. The bottom line is that whether you look at the mask in decimal, binary or “slash” (bit-count or CIDR) notation, the subnets increment by 64.
In summary the subnet increment can be obtained three ways:
· From 256 minus the mask value (256 – 192 = 64)
· From the value of the least-significant subnet bit (26 = 64)
· From the number of host bits (there are six host bits, and 26 = 64)
Also note that the last subnet is equal to the value of the mask (in this case, 192). What this means is that once you have the mask, you can calculate the subnets in decimal, without using binary. Just start with the network (192.168.1.0), and increment the last octet (you could also start with the last subnet and work your way down, but most people find it easier to work their way up). Either way, using a mask of “/26”, the subnets are:
· 192.168.1.0/26
· 192.168.1.64/26
· 192.168.1.128/26
· 192.168.1.192/26.
Next, let’s examine the broadcast addresses (in a “real-world” design problem, the broadcast addresses are generally not required, but CCNA exams may inquire about them). Note that in each case, the subnet’s broadcast address is equal to the value of the next subnet minus one. For example, on the 192.168.1.0 subnet, the broadcast address is 192.168.1.63, which is one less than the value of the next subnet (192.168.1.64). The exception is the last subnet, for which the broadcast address is always “255” (which is 256 minus 1). Thus, subnets and their broadcast addresses are:
· 192.168.1.0, Broadcast 192.168.1.63 (one less than next subnet)
· 192.168.1.64, Broadcast 192.168.1.127 (one less than next subnet)
· 192.168.1.128, Broadcast 192.168.1.191 (one less than next subnet)
· 192.168.1.192, Broadcast 192.168.1.255 (the last one is always 255)
Finally, let’s look at the ranges of legal host addresses. In each case, the range begins with one more than that of the subnet itself, and ends with two less than the next subnet (which is one less than the subnet’s broadcast address). The exception is the last subnet, for which the last address is always “254” (256 minus 2). Therefore, the subnets and their ranges are:
· 192.168.1.0, Range 1 – 62 (one more to two less)
· 192.168.1.64, Range 65 – 126 (one more to two less)
· 192.168.1.128, Range 129 – 190 (one more to two less)
· 192.168.1.192, Range 193 – 254 (last subnet, one more to 254)
Putting it all together, then, the algorithm is:
· Using the powers of two chart, determine the required subnet mask
· Using the mask, determine the increment
· Using the increment, determine the subnets
· Using the subnets, determine the broadcast addresses (if needed)
· Using the subnets, determine the ranges
Five easy steps … and no binary required! Next time, we’ll use this method to solve several problems.
Author: Al Friebe
: : : :
