INEs CCIE Voice Sample Video

Mark Snow: My name is Mark Snow, I'm an instructor here at Internetwork Expert and I've been teaching the CCIE Voice Lab to candidates for - well in July it will be going on five years now. Enough about me, let's look at the Deep Dive teaching style. We're going to look at some pre-requisites, some objectives to what we hope to attain and accomplish during this course, how we're going to map the various subtopics within those two major topics of infrastructure and QOS to the CCIE voice blueprint, we're going to look at expected outcomes, we're going to look at the outline of how we're going to disseminated up this day - I know we've started a little late. If everyone can afford to go a little late then that's great and if not, if we end up with a lot of content extra to talk about then we certainly have a day set aside to do that. In fact, the way we're doing these recordings is Monday through Thursday, we'll be running these modules and then we'll always leave Friday open without a module schedule and the reason for that is Friday's going to be a makeup day so if we happen to maybe run - I'm not sure what time zone everyone's in but I'm in the East Coast time zone so if we happen to let's say run into 7 pm East Coast or something like that, that could be getting very late for people that are over in Europe or the Middle East or it would be pretty inverse for anyone out who's in Asia pack. But we can opt, if everyone wants to or if enough people want to, to take in and go ahead and table the discussion for that day or the tasks that we're working on and then pick it back up on makeup day of Friday. But that's just if we run out of time and I don't necessarily anticipate that we'll do that. We'll look at the expected outcomes, I'm sorry I already said that, the main presentation, we'll review everything and we'll have a formal question and answer time, we'll have of course the informal questions as we go along through the configuration and troubleshooting. This will just be to wrap up any outstanding issues, look at any conclusions, and then we're going to look at some further study in terms of reading and labs. And let me just go ahead and say something about the further reading, further study and readings at this point, is that whether you're here for the CCIE voice lab exam or any other certification regarding voice or if you're just here to learn about the technologies in general, you have a wealth of information available to you on under their support documentation and also at their design zone guides, often referred to as SRNDs, or solution reference network design. So during the presentation, we're going to be going to rely less on formal PowerPoint slides. I really don't like to do death by PowerPoint as much as possible. But rather what we'll try to do is spend a good amount of time and instead of doing just PowerPoint looking at the actual Cisco documentation as it pertains to whatever topic we have to be talking about at the moment. And by doing so those that are here just for the information in general will know where to look and have good reference and those that are here for the CCIE voice exam we will be able to go through a number of the documents, if not maybe even all of them to some extent -- we're not going to read line by line, word by word, paragraph by paragraph - but we will go over certainly some highlights and skim over and understand where certain bits of content are and what is covered in these documents, especially the SRND, the solution reference network design, because as the CCIE voice candidate has available to them in the lab all of the documentation including a number of the SRNDs in PDF format on their desktop. So we're going to make better use of our time looking through that documentation rather than just PowerPoints because it will show you, one, that the information is there, where to find the answers, and then two, it will serve as a trigger in your memory that if you happen to be in the lab and you're taking in, trying to pass the lab and you've run into some sort of a roadblock, whether mental or you need a bit of configuration or you just need a reference to something, you will hopefully think back and think "Oh, that's right, we looked at that together in these Deep Dive module classes and I know where to go look and I've got the documentation available to us." So we're going to again rely less on PowerPoints and more on those actual Cisco docs that we'll have in a real lab. So pre-requisites: an advanced understanding, I guess I should say at least a good basic understanding is necessary of the following protocols that we're going to talk about such as VLANs and VTP, the VLAN Trunking Protocol, DHCP, TFTP, NTP, those I'm quite confident that probably most people have a good understanding of but we'll look at them of course in depth, and then also at least a basic understanding of the Quality of Service components -- we're going to look at these things in depth - but at least a basic understanding of..., code points, ...behaviors - we're going to look at them in depth as they relate to the configuration. But this is not going to be a week-long Quality of Service course, in fact actually my colleague... is kicking off that right now as we speak, a week-long Quality of Service course. So if you've never ever touched Quality of Service before four hours isn't going to be enough or even six hours isn't going to be enough to really cover everything in QOS. So it would be good to go back and get a full understanding of all the RFCs, all the bits and everything. We'll look at a number of those things, but again, given the time that we have, which is somewhat limited but at the same point somewhat generous but somewhat limited, it's more generous than you might have an hour or two to discuss this in a five-day live class but it's not quite going to the depth of the Token Bucket Theory, for instance. But we will look at how that affects configuration, how that affects debugging and traces, we will look into all of that. So classification and marking, interface queuing, policing, traffic shaping, LFI or Link Fragmentation and Interleaving, CRTP, and we might even look at a little VTAS and VAF, voice adaptive traffic shaping or voice adaptive fragmentation if we have time. Also not in here but is going to be covered today is going to be RSVP and just standard locations based CAC. It really makes sense to go ahead and talk about call admission control today even though if you're sitting in on this Deep Dive module, you might realize that we have not gone through any of the basics for CUCM, in fact that's this Thursday, and we don't have any phones or anything like that, but we actually do have a bit of pre-configuration done and at the end of the class there will be startup or preconfig files that will be handed out as well as all the other whiteboard sessions and all the other distributable class files that you could load in a CSV file into your CUCM and have a basic pre-configuration done so that you could follow along watching this module again in review later as a class on demand recorded but we will go ahead and cover RSVP and locations-based CAC. They really - mainly RSVP makes sense with infrastructure because it's something that we do on the routers before we really ant to touch anything else, especially if it pertains to our CCIE Voice lab. Also, we'll look at the multicast portion, I should say the Network Infrastructure Configuration portion of multicast as it would relate to music on hold, multicast music on hold. We won't look at all the media resources or anything like that, again that's already pre-configured and that will be covered in another Deep Dive module, specifically for media, but we will look at the Network Infrastructure Configuration portion because if you were going in your lab and trying to configure everything in a logical format you would set up the infrastructure first so that if you had to add on to anything later you wouldn't end up messing anything up by adding something on later, you have all the basics set up. Okay, so the objectives: is to provide each student with a comprehensive, in-depth understanding of each technology covered, we already know what we're going to talk about today, to provide an environment where students can both learn and do, and to provide an environment where students are free and able to interact with the class throughout numerous participation events - so it's the configuration, the debugging, and the usage of your questions. If you don't have a mic, question pods over the right and then also your microphone if you do. Looking at our blueprint mappings, Network Infrastructure is loosely tied to the section 1.0 main heading of Implement and Troubleshoot Campus Infrastructure and Services and then those other four - VLAN, DHCP, TFTP, and NTP - all map pretty cleanly to 1.01, 1.02, 1.03, and 1.04 respectively, and then multicast covers a little bit, at least the Network Infrastructure portion of the 7.04 music on hold under the Media Section, again just the Network Infrastructure portion. We'll look at the rest of that and we'll review what we've already done when we come to the module for media which will be another day. Then looking at Quality of Service, this will relate to section 10.0 and it will cover everything in section 10.0 of the actual CCIE Voice version 3 blueprint. So there's going to be a number of things that we're going to talk about that may not seem exactly one for one, I should say, on the blueprint. And this is the same way that it's been for years with many other CCIE tracks and that is that just because something isn't explicitly stated on the blueprint doesn't mean that it's not testable. It's very possible that something can fall somewhere within another main heading. So for instance 10.0.1, we've got our layer 2, layer 3 traffic classifications, so we're certainly going to look at DHCP per op behavior and policing, 10.02 queuing mechanisms, this doesn't necessarily say traffic shaping anywhere over here. On the right hand column this is all the CCIE Voice blueprint itself. it doesn't say traffic shaping and yet I can almost assure you that you will have some form of traffic shaping, either frame relay, proper or generic traffic shaping, both of which we'll cover. It also doesn't talk about CRTP, LFI could be FRF.12 or multilink PPP. So some things are going to loosely relate to the blueprint. In other words the blueprint might have more of an all-encompassing section such as maybe queuing mechanisms. RSCP and CAC is going to directly relate to call admission control in RSVP. Expected outcomes at the completion of each module - we certainly hope and expect that each student should have a complete understanding of each technology and concept that we just listed, all of their question answered regarding the technologies for that day, and again, if you don't have all your questions answered or a complete understanding, that's where you're going to have the opportunity for two things: one, to watch the recorded session again if you just need me to basically go over what I've already gone over or two, if maybe I didn't cover something clearly enough or maybe you had a variation or permutation that I didn't talk about, that's where we have the ability to have the review, the integrated question and answer time and demo time, and then if we run too late we have the ability to have a makeup session or another recording. And in the ability expected outcome, the ability for each student to take the covered material into your private study time and begin to expertly implement and troubleshoot each technology. One thing I'll note, just going through these Deep Dives and watching and participating via audio and via text questioning isn't necessarily going to be enough all by itself just to be ready to go maybe tackle any or all of this material for a lab session, I should say for a real CCIE lab attempt, or have an expert level implementation, I should say, sort of a finger muscle memory type readiness for the lab. You're still going to need to take these concepts and go work them out in your own self-study time - meaning take them, implement them, try them out, test them out - that's how you're really going to solidify that learning. There are statistics, I don't remember exactly what they are about something you hear and the small percentage that you retain, something that you hear and write down you retain and remember and are able to utilize a lot larger percentage of that and then that which you take here, you write down and then you go and do, you're going to be able to retain a lot larger percentage. And then I think one of the biggest ways to retain the information that you've learned is to do really everything - listen, do some reading on your own, write things down, go and try the technologies, and then finally, actually go teach that to someone else, find a colleague or just about anyone that you can - sometimes if nobody else will listen to me I teach my wife certain things, not that she really cares or wants to necessarily know but she's at least a willing subject - just so that I can have better retention of that material. Okay, the outline for the day and really the outline for all Deep Dive modules. We're going to collectively discuss all concepts involved in the technology, define a specific set of tasks to be accomplished, white board those tasks and any notes about them and how to be logically implemented -- and as I mentioned all those white board sessions will be available for download at the end - demonstrate how the tasks and concepts are implemented and properly configured, we'll test all of that thoroughly, then we'll vary the configuration, understand how different permutations affect the outcome, we'll debug and trace the working configuration to understand what should be seen, what you should be seeing when everything's working properly, that way you'll know how and what to expect or what is out of the ordinary when you break the configuration and troubleshoot the debugs and look at the traces or more so in this lab or this module, mostly the debugs, and contrast that from a working set. Okay, so lets jump in and take a look at Network Infrastructure. Okay, so this is where it's going to get a little bit more specific to the CCIE voice lab when we look at voice VLAN configuration. We're specifically going to look at it on the 3750 switch, actually we're going to be using a 3560 switch for my particular rack, that doesn't really matter, it's the same exact configuration, same exact architecture in all ways including QOS as the 3750. The only thing the 3750 has that the 3560 doesn't have is either wise stacking and the ability to do multicast in either channel, none of which really applies to this or voice in general. We're going to look at the network module for Ethernet switch that goes inside of an ISR router. We've got one of those, one of our 2811 ISR routers. We'll look at DHCP configuration both on the CUCM server and from IOS. And then we'll look at NTP for IOS routers and then also for the Cisco unified operating system servers. We'll look at multicast routing for PIM and IGMP Snooping. Okay, so first let's look at adding the VLANs. Don't just assume that they exist. This is again getting a little bit more specific about the CCIE voice lab. Don't just assume they exist, make sure that you actually check or add them, show VLAN in catalyst IOS and for the router IOS with the VLAN Ethernet switch module which actually show VLAN switch. The reason why I say don't assume they exist, they may have been configured for you, they may not have. And you might say or believe or have understood from previous configurations that when you add or actually assign a VLAN to a particular device, say a phone access or voice VLAN, that it will go out and create that VLAN. Well, that is true if the VLAN has never existed in the VLAN in the VLAN.dab or VLAN database file. However, it's possible that someone, like a proctor, could have created a VLAN and then deleted it and taken it away just to be helpful. When I say that I'm a bit fastidiously referring to the fact that there is integrated or inherent troubleshooting within the CCIE Voice lab and recently Ben Ng, CCIE voice content manager had mentioned that - and actually other people inside the Cisco CCIE program as well had mentioned that the amount of troubleshooting for the voice lab was going to step up a little bit. So it's implicit, it's inherent - in other words they're not going to do anything to you live while you're taking the exam, however, they very well could have already added some sort of pre-configuration or a number of separate bits of pre-configuration in a router or in a server, great place for that in a CUCM unified communications manager server would be in the service parameters area, things of that nature. We'll talk about all those as we go through these modules but the idea is don't just assume something exists, go create it and then you won't have to worry about it. so we'll look at three VLANs on our corporate headquarters site -- VLAN 10 for our servers, 11 for our voice, VLANs for phones and 12 for data. So looking at catalyst IOS and specifically 802.1Q trunks - so hopefully everyone's familiar with what 802.1Q is, what the VLAN trunking protocol talks about. We either have 802.1Q, which is the industry standard, or we can use ISL, inter switch link, to the Cisco proprietary, BTP method. However, that's not supported on the IP phones, in this case we're only talking about between the catalyst switch and the router or actually in between switches, multiple switches. Typically that would be the model that you would see in a large enterprise, multiple switches with trunks, but in this environment you'll see that we're actually doing what's called router on a stick, that is we're going to have three VLANs on our catalyst 3560 at corporate headquarters and we're going to bring those VLANs across a BTP trunk or a DOT1Q trunk over to the 2811 ISR router and actually route the layer 3 portion of that on the router even though the layer 2 3560 switch is also a layer 3/layer 4 capable switch so it could do the routing for us. That's just how we're going to have it set up in this particular module. So here in catalyst IOS we have to say switchboard trunk encapsulation DOT1Q, switchboard mode trunk to hard coat it rather than leaving it set to auto or dynamic desirable, and then PortFast trunk, spanning tree PortFast trunk actually allows us to enable spanning tree on a trunk, if we had that trunk keyword in at the end and what we're saying is although this could potentially be a link to another switch and there could be a layer 2 loop we're going to go ahead and turn off, essentially turn off spanning tree for this particular interface and for this particular trunk instead of VLANs. So we're going to trunk a number of VLANs across the interface, in this case... over from the 3560 over to router 1. On router 1 we'll split these out and we'll actually route - I only show a couple here, in fact this actually shows up for our third site - we're going to split out a number of the actual VLANs. First of all we'll create a sub-interface, we can't do this on a main interface, we can't have encapsulation DOT1Q, we can't add DOT1Q headers to the IP packet, so we create a sub-interface and once we create a sub-interface we have to specify some form of encapsulation for trunking, DOT1Q and the VLAN number here, and if this VLAN is going to be native then we would optionally have, which is not pictured here at the end, a native keyword. Now the native keyword and what a DO1Q native VLAN is is this is essentially an untagged VLAN or an untagged Ethernet frame. So we have Ethernet frame that's coming across and all the ones that have a DOT1Q VLAN ID but don't have the native keyword have an extra header and of course it carries information such as the VLAN ID, 802.1P, layer 2 COS or class of service bits that we'll look at in the QOS section, as well as a few other things. So when we have the native keyword, what that's saying is there is no DOT1Q header added on to the Ethernet frame so because there's not I have no way of communicating to you the next device what VLAN this should be in so what you should go ahead and do, and I guess maybe I should back up and say it in a little bit of a different way, I'm receiving the frame, someone's not telling me what to do with this, but I'm receiving an Ethernet frame and it has no DOT1Q header, however, it's on a trunked interface that most Ethernet frames should have that 802.1Q header informing me of the VLAN ID and what VLAN to place this traffic in once I strip that header off. So the native keyword says I'm going to be receiving some frames that won't have any ODT1Q header, go ahead and put all of that traffic in this one particular VLAN. We can leave it unconfigured if we want that to be the default VLAN which of course is 1, VLAN 1. If we want it to be something else like maybe say 12 then we would add the native keyword at the end but this is at the router. So encapsulation DOT1Q12, we're defining another VLAN 12 and we're saying that all traffic there should be routed on and use a layer 3 interface or layer 3 at IP addressing, in this case at, myself the router being DOT1. So for phone ports, we need to take a look at some of the same information regarding DOT1Q trunks and how are we going to get information across to our phones? How are we going to get the information of what VLAN their phone portion - let me back up and say that each Cisco IP phone has a three-port switch. So it's got two ports on the back of it that you see and then one port that's internal that actually gets used for the phone itself. So there's one on the back that says "going toward 10100 switch," that's the one that we typically use to attach as an uplink to another switch, our aggregate access layer switch, and then there's one that says "to the PC." So there's a three-port switch, we need to know which VLAN to assign to the internal switch port for the voice, for the phone itself to use, and then if different, it doesn't have to be, then which one would we use for the PC that's attached to the phone. So we've got a couple of different methods of informing the phone of what to use -- one is known as the access port method and the other's known as the trunk method - and before we even do that we need to know where phones are. So we're going to use CDP, Cisco Discovery Protocol, to actually look and see where are there any phones. So the simple that we'll be using later is "show CDP neighbor" to see where the phones exist on the switch or Ethernet switch module on the route. Once we've determined that we can either use the older trunk port method which - actually I've confused my - on my slides it looks like I have the labels backwards. this is actually the trunk port method and this is the access port method. I apologize about that but moving beyond that - the access port method, or I should say the trunk port method where hard coating, switch port mode trunk, and we are defining switchboard trunk encapsulation DOT1Q and then we can define our voice and access VLANs - sorry our voice and our native VLANs, it wouldn't be access at that point. And then for the access method which is actually pictured down here, we have specified switchboard mode access and then we're defining our access or our PC port, whether it's a Mac or a PC connected, it doesn't matter. Our access VLAN ID is going to be for our PC port on the phone and our voice VLAN is going to be for the internal switch port. Now, you might ask the question and yes, the answer I will get to a diagram in just a moment, something to think about is if we have two separate VLANs here, 12 and 11, and this is actually an access port, I realize I have the names backwards as I mentioned, it says trunk port method but this is actually the access port method as noted here with switch port mode access, how can we have two separate VLANs going across a single switch port if we don't have a trunk set up? And the answer, if anyone - I won't spend too long on this particular question - the answer is we cannot, we cannot have two separate VLANs traversing port if this is not truly an 802.1Q trunk or some form of a trunk which the phones only speak 802.1Q. So when we say switch port mode access, this is really kind of a pseudo access. It's not really an access port. What this is is a one-off. This is actually trunking. Now if we go into the switch and we'll look at this later and do show interface, fast Ethernet, 010 trunking it's going to say "non-trunking," it's going to say "not trunking," it's currently not trunking but that's kind of a lie. The switch or the Ethernet switch module in the router is sort of lying to you. It actually is trunking, as I mentioned, in a one-off type of a situation. The one-off type of a situation is first of all the access VLAN is going to become what would be up here in trunk port method, the access VLAN is going to become the native VLAN. In other words all traffic that is sent to me, the switch, from the phone that does not have any 802.1Q header, it's just a raw Ethernet frame, I will put in inside this VLAN, I'll consider it just like my native VLAN if I we're a trunk so that will be 12. However, if I do receive, again we're talking about the access port method, if I we're to receive any Ethernet frames that do have 802.1Q headers on them I will look at the VLAN ID field in there and if the VLAN ID field matches this VLAN ID that I have here attached to something called the voice VLAN, which we'll talk about in a moment, it doesn't have anything to do with voice, if I do see any 802.1Q header, the VLAN ID matches this voice VLAN ID then I will allow that Ethernet frame to come in as the one-off exception and it will technically be a trunk. However, that's the only other VLAN I'll allow to come across. There's no need - as we can do with the trunking method - to say switch port allowed VLANs and allow certain VLANs but not others. There's no need to do that because the only VLAN ID that will be allowed is 11 in this case so it's sort of a one-off. And it's important that we know this because the access port method, which is really a pseudo trunk, if there are frames coming across, Ethernet frames with 802.1Q headers and they have 802.1P cost bits or I should say we want the ability to support 802.1P layer 2 class of service, COS, bits then we're going to need to have that DOTT1Q header because layer 2 COS, doesn't appear anywhere in the Ethernet frame that's in the actual 802.1Q header so this is a pseudo trunk. Okay, looking at spanning tree - in now way in depth but just a very, very basic overview of something that we can do to reduce the wait time for a phone to talk on the network is we can say spanning tree or span tree port fast. And it looks like Michael has a question, let me go ahead and sign - okay Michael you should have a microphone right? Michael: Okay, if you can go back one slide, I just have a quick question. You we're talking there and you we're talking about the presence essentially in what's technically an access mode of presence of DOT1Q, technically DOT1Q headers at an access point. If CDP doesn't recognize the attached device as a phone, does it still pass those 802.1Q headers to say a PC instead of a phone. Mark Snow: That's a great question. The answer is it doesn't matter what device is on the other end, whether it's a Cisco device or not, whether it's a Cisco PIX or ASA, a router on the other end of another switch - I'm sorry - on the other end of us, a switch. It doesn't matter if it's a non-Cisco device. It really doesn't matter. CDP is going to transmit the information - let me actually back up and say this in two parts. CDP will use this information to inform the phone if it's a Cisco IP phone what VLANs should be used for the voice VLAN, for the internal switch port. However, if lets just say any old device happens to be connected to me and it sends most traffic with no 802.1Q headers, those of course would be placed there in VLAN 12 but it does happen to send 802.1Q headers with the VLAN ID matching this ID which just so happens to be called "voice" but really has nothing to do with voice itself then it will pass that traffic on to the VLAN 11. So it actually has nothing to do with a Cisco product, with CDP other than the fact that CDP will use that voice VLAN to instruct the Cisco phone but other than that, any device that's sending an 802.1Q header with the VLAN ID equaling, in this case, 11 it will pass the traffic properly on to that VLAN. Does that answer the question? Can you still hear me everyone? Michael, does that answer the question? Michael: Yeah, I'm sorry, I must not have held it long enough. Yeah, that does answer the question, thank you. Mark Snow: Great. Okay, so we looked at spanning tree port fast. So before we move on, does anyone have any questions in general about VLANs or BTP or anything or that nature? Okay, I don't see any questions. So we'll move on and look at TFTP. TFTP, the trivial file transfer protocol, is of course what we're going to use for all phones to get their configuration files. So we'll look at a few different things that need to be in place. First of all if we are using CUCM server or if we're talking about it in reference to that, we need to make sure that the TFTP service in the serviceability subsection of the server is enabled and running and if we've uploaded any files or added any files which we'll look at where and how to do that to the TFTP server and that actually can be a very useful thing to do in the CCIE voice lab in order to get files out to a router that you just happen to need to get out there, they don't necessarily have to do with giving configuration files to a phone or gateway or something like that, if we add or upload files then we have to restart that service and serviceability every time we add any files. If we're looking at TFT in relation to IOS or CUCME or SRST which will become very synonymous here in future modules then it's a good idea first of all to know what files you have available to host or share or serve and so let's say we're looking for files for 7961 type phone, a good thing to do might be a show flash pipe to include and to include as on output modifier 7961. And then we'll note all the files in flash and then we'll actually serve those up from global configuration mode. So here we've got a bit of global configuration TFTP/server, turns the TFTP server on for a given file or allows that file to be served, we note where the file is hosted or located, in this case it's on flash, and it's in the directory 7941-61-SCCP\ -- and then the name of the file. However, when a phone goes to request a given file, it does not look in any sort of subdirectories, it looks in the route directory. So if I just said TFTP server flash: the name of this folder and then the name of the file in the folder and that's the format and structure and IOS for CF cards that have been formatted in type 3 flash is that they can have folder structures and that's the way they read, the file's going to be looked from TFTP, maybe TFTP:// the IP address of the server and just the name of the file itself, just the name of the file, not the subdirectory. So what we need to do instead is we need to use the alias command. So the alias command says "Hey, if anyone asks for this file name and it looks like it's just at the root level of the TFTP server, the IP address of us, the router, then go ahead and serve them this file as if it were just at the root of the server." And I realize my line accidentally went a little bit through that - but what that allows us to do, it allows the ability to keep and maintain an orderly structure as files, the amount of files grow on our flash modules, in folder hierarchies but still serve them out as if they were at the root level because that is where phones will request them. Looking at debugs we'll debug TFTP events - is going to be the primary one that we'll use to see what phones are requesting and when from IOS, if we're serving TFTP that way, and then from CUCM we'll actually look at traces. Looking at Network Time Protocol - oh you also had a question back on TFTP which is TFTP is considered as a less secure transfer protocol, can we use a more secure transfer protocol like SFTP? And the answer is well it depends on what it is you're asking can we use it for - just a router support SFTP for various things. It does for certain things, however, when it comes to phones and Cisco IP phones and Cisco IP gateways, getting their configuration files and other various devices, getting configuration files from a Cisco unified communications or communications manager express server then the answer is no, they only support getting them through TFTP. And the reason is if we had to use some more secure method like FTP, well FTP isn't secure other than it has a user name and password but it's in clear text, or SFTP or FTPS or anything of that nature - SSH or SCP or anything like that - we would need a user name and password and we've have to provision the phones to get that. Well the problem is until we've actually done the initial provisioning of the phones there's no way for us to tell them what the user name and password is to use to get their configuration files in the first place unless we actually go out to every phone and manually type that in. Now I don't know what kind of networks various students watching this module have been a part of but if you've ever seen 5000 or 10,000 phone networks or even heard of these type of installations and companies that have sometimes many hundreds of thousands of phones spread out globally, that's just not an option, it just doesn't scale administratively. So what we can do, however, it makes to use TFTP, in fact really it's the only one that really makes sense to use in terms of a scalable option, what we can do in terms of security, though, is if we have enabled our CUCM cluster or CUCME router to use security and that's another module altogether that we'll talk about at a later date, through use of what's called mixed mode clusters, tokens, security certificates and things like that. While we still don't cure TFTP itself in the method or idea of we don't secure the traffic flowing, there's no security of the username/password because there simply isn't any username or password. What we do do for TFTP is we instruct all the phones that they have to obtain a CTL, a certificate trust list or a certified trust list, basically saying "Hey, Mr. Phone or Mr. Gateway or unity connection or any other device that's talking to us, here's a list of the people that you can trust and if their name isn't on this list then you should not talk to them." It's kind of like telling a five-year-old that they should not talk to anyone when they go into school unless they're a student in the class that they know or one of the teachers or yourself as a parent. You're instructing them "Don't talk to anyone for safety reasons except for the people on this list," that's what a CTL or certificate trust list is. So the phones, when the cluster - and again they've already gone through TFTP and gotten their initial configuration and part of that initial configuration was a certified trust list, from there on out they know that they're not supposed to talk to anyone unless their name is on that list and as it relates to TFTP we actually put the IP addresses of the allowed TFTP servers on that list. So if a phone is maybe talking to two TFTP servers out of a cluster of 10 CUCME servers but there are only two designated for TFTP we'll put those two IP addresses there and then maybe also the IP address of a CUCME router that will be used as SRST fallback when they're in fallback, so those three IP addresses. So that's the way that we sort of can somewhat protect the phones in terms of TFTP so that someone doesn't come on to the network and put a rouge TFTP server up there and publish false or erroneous configuration files and try to spoof the phones into grabbing a file that they shouldn't. So it's a very good question and there's a way to accomplish that. Another question from Christian is "Is there a way with SRST that if the cluster goes down that the phones fall back but also be powered on? That new phones also be powered on." Yes - I think you're asking not in regards to TFTP, maybe clarify if you are just - sure, let me go ahead and give you the mike. Christian: Okay, my question was like I know with current implementations of SRST when the connection to the call manager cluster fails the phones fall back on to SRST, that's all well and good but let's say - my question is more let's say you're in SRST right now, the connection to the cluster is dead and a phone reboots. Typically when the phone reboots in SRST mode we cannot get the IOS deployed back on to the phone or whatever, the programming or what not. Is there a way to when in SRST mode and let's say you need to bring on a new phone or a phone reboots or whatever, is there a way to be able to do that? Mark Snow: Okay, good question. If you hear a pause after any time anyone asks a question it's just because for the sake of feedback and echo I typically turn off my mike just for that moment as I would appreciate everyone else and it seems like you have done whenever you're not talking. So I'll address in it sounded like two parts of the question so I'll address the answer in two parts. First question, if I understood it correctly, was when a phone has already been associated to a CUCM cluster, when connectivity to the cluster goes down - I don't want to get too far off topic because this really deals a little bit with TFTP so I'm going to go ahead and answer it but I just wanted to state to everyone else that I won't go too far off on this tangent - the CUCM cluster is unreachable for whatever reason, two or three or four CUCM servers reboot or the wind goes down or whatever and the phone falls back to a local CME or - and I'm not really sure if you relegated it to just SRST proper or possibly also CME as SRST because that actually differs the answer - but maybe a CUCME IOS router acting as SRST. First of all, if the phone is now registered to that that CME as SRST router and then the phone reboots for whatever reason - someone disconnects it, moves their cubicle to another cubicle, or something like that - the CME has already been provisioned either ahead of time or by the fallback, on provisioning the CME or SRST, it's already been provisioned with the configuration file of that phone. Basically the DN, a few parameters relating to what it had - DN, number of lines, number of datable channels, things like that - so when the phone comes back online it should grab the TFTP file or be served the TFTP file from that CME as SRST or just as SRST proper router and that's actually an implicit function of the SRST proper or CME as SRST service running on the IOS router, is that it caches those files, it doesn't actually write hard files to flash but it caches the configuration files, automatically serves them up to TFTP without any need to hard code them in IOS as we see here. So that was the first question. The second question I heard you ask ,and I'll give you a chance to revise if maybe I misunderstood anything, was when we're in SRST fallback mode can we add another phone on to the configuration? And this is where it gets into a differentiation. If it's SRST proper, in other words under IOS global config we say call-manager-fallback. That SRST proper, no we cannot add phones in that were not already previously associated to a CUCM cluster. However, if we're running CME as SRST, so that is an IOS global config, we did not do call-manager-fallback, instead we said that telephony-service and then mode SRST and probably had auto provision all or something like that and we do have the ability to go in and create ephones and ephone DNs so yes, we could go assuming we have enough ephones and ephone DNs available, licenses, system, configuration, max ephones, max DNs, that sort of thing. We could go in and add one manually during SRST, CME as SRST fallback mode. However, when the link came back up, band link and regular phones that had already been associated with cluster went back to talk to the cluster, this new phone would not go back and talk to the cluster automatically because it had only ever been provisioned to talk to this local CME router. And that's also assuming that we either manually configured IP and DHCP and - I'm sorry not DHCP but IP address, ...default router, and most importantly TFTP server address or we had used DHCP on that local router and used - in that case we would have probably had to have gone and over ridden the TFTP which normally pointed, let's say, to the CUCM publisher when the WAN link was up, we'd have to over ride that on the phone with something called alternate TFTP. So when the CUCM, when the Wan link came back up and the CUCM was available all the other phones would re-register, we would at that point need to erase our configuration essentially or so to speak, maybe not necessarily but that would be the easiest way on that phone that we manually added to CME as SRST and then allow it to get normal DCHP, normal IP address, most specifically or most importantly normal TFTP server pointing at the CUCM and either auto register it with the CUCM server or allow it to go and manually configure that phone on the CUCM server. Hopefully that answers the question. How many phones per minute can a call manager handle for TFTP startup? It depends on the server, the server size that you're provisioning in terms of CPU, there's also some service parameters that we can take a look at, that we can basically tweed to make sure that we don't overwhelm the CUCM server. So we'll look at those when we get to the live configuration under service parameters. No problem. No problem, Christian. Okay, so next looking at network time protocol - network time protocol in terms of the lab, the CCIE voice lab and probably voice networks in general, we mainly are concerned with the two functions, the two functions of master and server or what could also be called server and client. ANTP Master specifies that someone is in authoritative time source. The number afterwards which we can optionally put in there, is the stratum number, anywhere from 1 to 15, 1 being essentially a CZM or atomic time clock, most authoritative, 15 being the least authoritative, and then we also have the configuration command NTP server which specifies that we are a client and we're looking to the IP address as a server. There's also something called NTP peer. Now peer -- in a peer-to-peer relationship there is no authority in terms of the time source so one does not sync with the other, instead they exchange - and I might add they exchange very small increments so if you have two clocks set very far apart in NTP, almost regardless of whether they're doing peer or not, but especially if they're doing peer, and they're trying to peer up with each other, they're sending small increment deviations from the previous time stamp that they sent back and forth to each other until they're getting closer and closer and closer and really inching closer and closer and closer, I guess inching is a US word, for those not in the US maybe - I don't know if anyone says "centimetering" or something like that, closer and closer to each other - but they're just crawling finally towards each other until they finally get a time that they agree on. That's NTP peer and we're not really going to use that too much because it's not authoritative. Then we'll mostly focus on master and source. Now configuring a CUCM server with NTP, we only configure it on the publisher any and all subsequent subscribers to the cluster, always sync with the publisher server, we configure it on the publisher either via the CUOS which is the Cisco Unified Operating System web user interface or via command line if we prefer. And we can sort of verify it via the way we look at that, ...interface with a web UI, but the only way to really fully verify exactly what time and everything it's been synced with, the publisher that is, is via the SSH into the server's command line and we'll take a look at that with... NTP status command. Another module this week is going to take a look at a lot of other things in the SSH command line so we won't look too heavily on to everything else or into anything else really. Don't forget when you're working with routers of even switches to set time zones for CUCME, for SRST, or just for any router or switch that you're using NTP especially if it's going to be a master. It has to have it if it's going to be a master, it's definitely a good idea to do it even in a client using the configuration word server setting. Also, although we won't get too far into it today because it deals more with CUCM basics which is another module this week, you shouldn't forget to configure date and time groups, they really don't have to do with NTP per se but just date and time in general. And then one thing that does deal specifically with NTP is a phone NTP reference. Now what this is is for SCCP or skinny base phones all of their time comes from SCCP skinny messages back and forth from themselves, the phones, and the CUCM publisher server. However, SIP phones having to conform of course to the IETF SIP RFC don't use SIP signaling to synchronize time. The IETF said "Hey, we already have a great mechanism for that, why try and re-do it again inside of SIP just for endpoints like phones? Why not just use NTP?" So when we're talking in CUCM administration web interface about a phone NTP reference which we'll take a look at, that's only ever being used by phones that are getting their configuration files that are going to be using these SIP signaling protocol and this will be the IP address that they will synchronize to for their time. So if we're told to synchronize all phones to the publisher, we basically do nothing for skinny and we would tell the SIP phones, give them a phone NTP reference that would point them to the IP address of the publisher and maybe we would want to synchronize them to a router or something different but that's just as an example. Looking at DHCP, if we want to enable DHCP from CUCM, the Cisco Unified Communications Manager server, first of all we need to make sure that we enable the DHCP monitor service in serviceability, we'll configure the DHCP server itself and in the lab that might typically be the publisher, but you could be given anything as an instruction. In a real life enterprise setting it might not be the publisher, it might be something else. Well, hopefully in a real life enterprise setting you're actually not using CUCM as a DHCP server. It really wasn't intended to be used as one. You'll see that from the lack of insight that we get or ability to peer into the leases and everything being handed out. It was more just added on as a convenience for really smaller installations but it's almost always a better idea to use some other method but if we need to, we'll configure the server then we'll configure subnets for each site. We need to make sure that we've assigned the proper router IP address and of course TFTP address and then for any subnets under any switch, any VLAN interface which is called an SPI switch virtual interface or maybe data or voice, especially voice, we're going to need or just any other router interface in general where the DHCP server is not local to the client requesting IP address, you need to enter an IP helper address on that layer 3 interface. So DHCPs are sent via broadcast and of course routers or layer 3 routing interfaces, whether they're on a switch, switch virtual interface or even a switch virtual interface on a router, or a router fast Ethernet, whatever the case may be, those define layer 3 broadcast boundaries, domains so broadcasts don't traverse routing interfaces traditionally, right? Unless we're using... or in this case what we're doing with IP helper address is not just for DHCP but for anything that we use the IP forward protocol command for which it's already set for a number of services, one of them being port69 UDP which is DHCP but it's turning those broadcasts into specific unicasts for a given server and it's forwarding that request on with the destination address as whatever is at the end of this IP helper address - IP helper address -- if we wanted to turn all DHCP broadcasts into a unicast for our CUCM publisher server. And someone asked about a topology earlier, I will put a topology up in just a moment. Okay, so it's turning them into unicasts, however, one other thing to think about - so that's what's happening for the destination IP address, what about the source the IP address? Well the source IP address wasn't coming from any source IP address, right? Because it's DHCP, we want to get an IP address, we don't yet have one, so we don't know where we're coming from, we don't know who we are. That's kind of the problem. We're in a little bit of an identity crisis. So how are we going to know what scope to get the IP address from? We don't know who we are, we don't know what IP address or layer 3 network we are on, then how are we going to know which layer 3 scope or subnet to request an IP address from, we don't know where we're at? When the router turns that broadcast into a unicast and forwards it to the destination address of IP helper address xxx.x.x.x.x, that's the destination. What happens though is that it has to come from not only a layer 2 but a layer 3 interface on a router, again, or switch but a router interface and if there is no routed interface - I'm sorry let me finish that - it will essentially inform the DHCP payload that it's looking for the IP address on this subnet. So the phone, for instance, requests layer - well really a layer 3 broadcast requesting an IP address but it does so on a layer 2 medium. That layer 2 medium, whatever the VLAN is or if it's all one VLAN, the switch, but whatever VLAN that's on, it goes out through either switch virtual interface, that is interface VLAN something, and gets its helper IP address and gets turned into a unicast or goes through a routed interface like fast Ethernet 0/1 for instance and that has to have an IP address. So the reason I'm pointing this out is if we have phones and we have created a VLAN and put those phones in the voice VLAN in that VLAN and the VLAN exists in the database, that's great. However, if that VLAN doesn't have an SVI, switch virtual interface, IP, interface VLAN 11, IP address for instance, it doesn't have an IP address and it doesn't know how to modify that broadcast to unicast conversion with a valid source subnet with which to request IP address from a specific given subnet or scope. So it's very important that we actually have layer 3 SVIs created anywhere we have a switch. We're already going to have an IP address assigned to a router interface, that much I'm not worried about you forgetting, it's the layer 3 switch virtual interfaces on either a router for instance, if we have the Ethernet switch module, or just on a switch itself. Now, if that router again or I mean if the switch traverses back to a router and the router has the layer 3 then that's good enough. We need to verify the address allocation under each scope, which as I mentioned for CUCM is going to be a bit of a problem but for routers it's not, and then we should also pin phone addresses to make sure we allocate a default gateway correctly, maybe even web over to those devices to bring up a browser and go to the IP address of that phone device to see that it has the proper TFTP server. Looking at IOS DHCP, again show DHCP bindings will be the way that we will verify what IP address we've handed out. We want to make sure we configure any exclusions to the pool before we actually configure the pool itself or else we shut down the phones because the problem can be if we do create an exclusion range as we see here but we haven't or I should say we've already created the pool but we have not yet created the exclusion range, the pool will begin handing out IP addresses then we go ahead and create the exclusion range but the problem is the phones aren't just going to give up their IP address and come back and get one from the subset that is not the exclusion range. We would actually have to go to a DHCP release and renew on the phones so it's important that you just power the phones down or shut down the layer 3 interface or just do your exclusion range before doing your DHCP pool. Also sometimes if you did go ahead and do this you can power cycle a phone. It takes either too much time to get an IP address or maybe got one outside of the exclusion range and you want it to release that IP. Phones can be very stubborn about releasing configurations or about releasing their IP address so sometimes what can help is powering a phone off and then doing clear CSDP table that will sometimes help convince a phone to actually give up its rights to its IP address and get a new one from the pool but without the exclusion range. And then lastly, before we talk - go into actually configuration about these things and we'll go to QOS a little bit later - is just looking at multicast routing. So the need for multicast music on hold or I should say that's the need that we might have for multicast routing in terms of voice really as it pertains to the CCIE voice lab, there are other things that we could use multicast IP traffic for outside of voice such as IPTV or things that relate to video and certainly related to unified communications but not really as it relates to the CCIE voice lab so we will stick with multicasts here for music on hold. And again, as I mentioned, we won't go into the full configuration or all of the options of multicast or I should say really a music on hold -- we'll deal with that in a media module - but we'll talk about the multicast from a network infrastructure standpoint, from a switch and a router standpoint, go ahead and verify and debug that because I already have - Now for a lab environment, typically for a small lab environment, you should just use PIM dense mode everywhere, especially if we're talking about the CCIE voice lab. If you're talking about an enterprise configuration and you're lobbying it up to prepare for some sort of rollout, dense mode is not what you want and it's definitely not what you want in a real life live production environment. Dense mode basically just opens the flood doors and sends all multicast traffic everywhere. And the problem is let's say we've got a pub or we've got two servers serving multicast music on hold and we happen to have four audio source files and they have all their codex enabled, that is four files times 4 codex times 2 servers. Now again I'm not going to get too far into media but the point is we're already at 32 multicast streams of traffic and that's a lot of traffic, it's a lot of bandwidth being used so you don't want to flood multicast traffic everywhere in a production environment. That being said, the lab, the CCIE voice lab specifically, a practical hands-on exam where you will most likely need to configure multicasts, it's perfectly fine to turn on dense mode there because it's a small contained environment, you only have a very small number of servers, two, and a small number of files, maybe one or two source files, and at the most four codex but probably more likely one or two. So it's not going to be a problem in a lab environment, a small one, but you should not use that in production. You didn't hear Mark Snow it was safe to use dense mode in production environments, okay? I just want to clear that up. I only have to make that disclaimer because I had a student come back to me one time and get a little upset that they had - I hadn't done that disclaimer and they had gone back and configured it on their very large campus and needless to say they we're also doing other things of multicast like... and with many gigs of traffic multicasting out they sort of broke a few things on the network. So never ever mention any names but that's why I make the disclaimer. Looking at verification we can always do a show IPM route to see what multicast routes are traversing routers and then show IP PIM neighbor, PIM is protocol independent multicast, it's the protocol that most people typically use these days, there are older ones but I won't really talk about them; IGMP is the internet group management protocol, internet groups are what are referred to as - some people call them IP multicast IP addresses, they're really more properly called multicast group numbers. It is a reserve range of IP addresses but the internet group management protocol's what runs on a switch in order to facilitate a sparse mode like environment. So on the routers we have dense mode and we have sparse mode. Dense floods everywhere but it does route the traffic, that means it comes in one interface and routes out another; and then we have sparse mode which means that only the people that are requesting that stream, that group - that's the only stream or group that we will flood out rater than all the groups that we have - and we'll only flood about the one interface that we see the request coming in from. IGMP is like sparse mode for a switch - instead of flooding traffic for all internet groups or all multicast IP addresses out all ports, we'll only send it for the specific groups that are requested and for only out the ports that have specifically requested it in. Now, that's great and it's a good thing to use, however we can sometimes run into issues with - specifically with network module Ethernet switch, NM-ESWs or the Ethernet switch network modules or WIC or VWIC cards that can be installed in the ISO routers because the routers then functioning as a multicast router using PIM and also as a switch using IGMP and there's definitely been bugs associated with that so we will turn that off on an Ethernet switch module. Now it won't hurt if you also want to turn it off on all your other switch in a CCIE voice lab because that's essentially saying "Hey, I've got 24 or 48 ports or whatever but we'll just go ahead and flood all multicast traffic everywhere regardless of who's requesting it." Again, not bad for a lab environment, especially if you think you have issues with IGMP although you shouldn't outside of the Ethernet switch module, however not good for production. So on a router we're going to configure IP multicast routing and then under -- basically the safe thing to do is unless you're instructed otherwise, ask your instructor to only configure it on the necessary interfaces, then configure IP PIM dense mode on every interface that you see an IP address on, every layer 3 interface, including loopbacks. Now it's not necessary on loopbacks as it used to be in IOS to send traffic out to a PSTN or across a TDM... However, it just can't hurt to put it on every interface. You definitely won't miss anything if you put it on every interface. Now if you we're instructed to only configure PIM on necessary interfaces - you had that key word "only" and maybe key word "necessary" or something like that - then we just need to take into account which interfaces we need it on. Technically we only need it on the interface where it's coming in and going out to. However, an easy thing to do if you're unsure is configure it on every interface, even if you we're told only the necessary ones, and then just begin taking it off the interfaces you don't think needs it and leave your multicast music on hold stream up, leave it continuing to flow, leave the person on hold and your listing to the music, so get it working first, put it on every interface, get it working, and then begin taking it off one by one off each interface. And if it doesn't work, all of a sudden it stops, put it back on that interface and note that's one that needs it, just make sure you leave it on the ones that in the end are the only ones that need it, so process of elimination. Okay, Yusuf asks the question "What's the impact of multicast is not configured at all, is music on hold going to work?" Well that depends on what we're talking about in terms of what sort of an environment. First of all if we're just talking about any environment -- production, lab, CCIE lab, whatever - and we can't have multicasts enabled, we also haven't instructed our CUCM server to force the usage of multicast for music on hold then by default unicast music on hold should work provided that the codex are supported, so either we enable all the codex - we'll talk more about that in the media module - but we enable all the codex for the server which is an option that's not done by default or we provide the MOH server, music on hold server, with the transcoder, one of the two. If that's the case then unicast music on hold should work properly assuming everything else about media is proper - media resource group list, media resource groups, regions, locations, everything that we have to take into account that we'll look at in the media module not really today. Today we're just looking at the infrastructure portion of multicast.