Tip:
Highlight text to annotate it
X
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 cisco.com 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 177.3.12.0/24, 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 *** 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 177.1.10.10 -- 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 ***.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 177.2.11.1
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.