CCIE Blog » Strategy

CUCME Presence

Amy Ryan — Wed, 01 Sep 2010 13:05:17 +0000

When enabling the presence service in CUCME, you are using the SIP methods of Subscribe and Notify to allow users the ability to see changes in the line state of phones. The phone acts as a watcher using the subscribe method to get status updates from a directory number assigned to a phone that acts as the presentity. CUCME will respond to the request and each time there is a status update for that DN or presentity, CUCME will send all watchers a notification message. CUCME presence can be applied either as a BLF speed-dial assigned to a line button or as BLF call-lists that will support status notifications of a presentity in the directories or call log (missed, placed, received) of the phone.

The first step when configuring presence on CUCME is to enable the router the ability to accept incoming presence requests.

BR2-RTR(config)#sip-ua

BR2-RTR(config-sip-ua)# presence enable

The next step is to enable the presence service and the ability to globally monitor all directory number that will need to be enabled for “watching” via the call lists and directories of the local phones.

BR2-RTR(config)#presence

BR2-RTR(config-presence)#presence call-list

Then configure the directory numbers that will be enabled for watching.

SCCP Phones

BR2-RTR(config)#ephone-dn 1

BR2-RTR(config-ephone-dn)#allow watch

SIP Phones

BR2-RTR(config)#voice register dn 1

BR2-RTR(config-register-dn)#allow watch

!

BR2-RTR(config)#voice register global

BR2-RTR(config-register-global)#create profile

BR2-RTR(config-register-global)#reset

At this point, if BLF monitoring of directory numbers that appear in the call lists and the directories has not been enabled globally, then this can be applied at the phone level and reset devices.

SCCP Phones

BR2-RTR(config)#ephone 1

BR2-RTR(config-ephone)#allow watch

!

BR2-RTR(config)#telephony-service

BR2-RTR(config-telephony)#create cnf

Creating CNF files

BR2-RTR(config-telephony)#reset all

SIP Phones

BR2-RTR(config)#voice register pool 1

BR2-RTR(config-register-pool)#allow watch

!

BR2-RTR(config)#voice register global

BR2-RTR(config-register-global)#create profile

BR2-RTR(config-register-global)#reset

In the event it was asked to enable BLF monitoring of a directory number and associate this DN with a speed-dial assigned to a line button on the phone then first ensure the DN has “allow watch” assigned and then perform the following.

SCCP Phones

BR2-RTR(config-ephone)#blf-speed-dial 1 3001 label Sales

BR2-RTR(config-ephone)#reset

SIP Phones

BR2-RTR(config)#voice register pool 1

BR2-RTR(config-register-pool)#blf-speed-dial 1 3001 label Sales

!

BR2-RTR(config)#voice register global

BR2-RTR(config-register-global)#create profile

BR2-RTR(config-register-global)#reset

By assigning a BLF speed-dial to a phone, it enables that phone to watch all ephone-dns or voice register dns with that same extension number at the same time acting as a speed-dial. However, with CUCME version 7.0 the lamp will only illuminate red if the monitored dn is in use. It will not indicate DND status and cannot distinguish which phone is using the extension number if it is shared across multiple phones or assigned to multiple DNs, much like that of the “monitor mode” button “m”. The main difference to remember with Monitor Mode button is that it is only supported on SCCP devices and will only monitor a single ephone-dn . It is not extension number based. In CUCME 7.0 to achieve status updates if a phone is in DND mode, it can be achieved with the “watch mode” button “w”. This method of presence will watch all activity on the phone in which the ephone-dn assigned is the primary extension. It should be noted here that the ephone-dn used in this method could be shared across phones but not assigned as the primary extension to more than one phone.

To verify presence use the following commands.

-show presence global

-show presence subscription

To troubleshoot presence use the following commands.

-debug presence X

-debug ephone blf 

-debug ccsip messages

Amy Ryan – CCIE #24677 (Voice)
Technical Instructor – IPexpert, Inc.
Mailto: aryan@ipexpert.com

CUCME Conferencing

Amy Ryan — Wed, 25 Aug 2010 13:09:37 +0000

In CUCME 4.1 and later versions, it is possible to provide end users the flexibility of creating ad-hoc conferences involving more than 3 parties with each participant potentially using a low bit rate codec such as g729. As you might expect, IOS software is unable to provide this function natively without the aid of Digital Signal Processors (DSP’s) most likely hosted on the CUCME gateway.

The first step when configuring the DSP’s for conferencing is to enable DSPFarm services on the gateway. By default the DSP’s can only be utilized for voice termination.

BR1-RTR(config)#voice-card 0
BR1-RTR(config-voicecard)#dsp service dspfarm

The DSP resources can only be controlled by the Call Control Agent (UCME in this case) using Skinny (aka SCCP). Skinny needs to be enabled on the gateway and a Call Control Agent(s) defined. In the example below the gateway will source SCCP packets from the primary IP Address assigned to interface FastEthernet0/0.11. The CUCUM IP Address is then provided to the gateway- incidentally the default version of SCCP used is 4.x so it is important the version is specified especially when trying to register an IOS MTP device to UCM since this is an invalid media resource in SCCP version 4.x.

BR1-RTR(config)#sccp local FastEthernet0/0.11
BR1-RTR(config)#sccp ccm 10.10.201.1 identifier 1 version 7.0
BR1-RTR(config)#sccp

A UCM group containing a list of Call Control Agents needs to be specified to support redundancy. In a stand alone UCME environment only a single Call Control Agent might be provisioned but in a UCM environment the Subscriber UCM, Publisher UCM and backup SRST CME gateway are the priority 1, 2 and 3 Call Control Agents respectively.

BR1-RTR(config)#sccp ccm group 1
BR1-RTR(config-sccp-ccm)# associate ccm 1 priority 1

The profile defining the characteristics of the conference bridge will be the next bit of configuration required. The codecs are defined and the maximum sessions specified. The DSPFarm will also need to be associated to the SCCP protocol at this stage (no other options at the time of writing).

BR1-RTR(config)#dspfarm profile 1 conference
BR1-RTR(config-dspfarm-profile)# codec g711ulaw
BR1-RTR(config-dspfarm-profile)# codec g711alaw
BR1-RTR(config-dspfarm-profile)# codec g729ar8
BR1-RTR(config-dspfarm-profile)# codec g729abr8
BR1-RTR(config-dspfarm-profile)# codec g729r8
BR1-RTR(config-dspfarm-profile)# codec g729br8
BR1-RTR(config-dspfarm-profile)# maximum sessions 2
BR1-RTR(config-dspfarm-profile)# associate application SCCP
BR1-RTR(config-dspfarm-profile)# no shutdown

Each conference session supports up to 8 parties in the same conference call and consumes half a DSP (PVDM2-8). A single DSP (PVDM2-16) supporting conferencing cannot be used for any other media resource- therefore it makes sense to have an even number of conference sessions.

The DSPFarm profile will need to be associated with a SCCP Group- a unique name is given to the conference bridge and this name will serve as the SCCP unique identifier when registering to the UCME.

BR1-RTR(config)#sccp ccm group 1
BR1-RTR(config-sccp-ccm)# associate profile 1 register cvg-cfb

Within the telephony-service CLI the conference bridge needs to be added as a known media resource and the maximum number of DSP Units specified. The UCME will cease to use software conferencing as a result of specifying the “conference hardware” command.

BR1-RTR(config)#telephony-service
BR1-RTR(config-telephony)# conference hardware
BR1-RTR(config-telephony)# sdspfarm units 1
BR1-RTR(config-telephony)# sdspfarm tag 1 br1cfb

Registration of the conference bridge to the UCME can be verified using the “show sdspfarm units” command.

Placeholder ephone-dn’s need to be added to support the number of active Ad-Hoc conference participants required. These DN’s do not need to be dialable numbers (unlike the case of Meet-me conferences). In this example 4 conference participants will be allowed due to there only being 4 available channels associated with ad-hoc conferencing. The ephone-dn’s are providing the lines to anchor the call whereas the DSP resource is used for the transcoding and audio mixing required for conferencing. Conversely, if there were no restrictions placed on the number of available channels, an octo-line could be used to support 8 conference participants.

ephone-dn  5  dual-line
 number A1000
 conference ad-hoc
 preference 2
 no huntstop
!
ephone-dn  6  dual-line
 number A1000
 conference ad-hoc
 preference 1
 no huntstop
!

Tones can be provided to conference participants as and when a person joins or leaves a conference call. The frequency and cadence (including the tone-on and tone-off durations) are defined within the “voice class custom-cptone” CLI.

BR1-RTR(config)#voice class custom-cptone CONF-LEAVE
BR1-RTR(cfg-cptone)# dualtone conference
BR1-RTR(cfg-cp-dualtone)#  frequency 400 800
BR1-RTR(cfg-cp-dualtone)#  cadence 100 50 200 50 300 50 400 50
BR1-RTR(cfg-cp-dualtone)#!
BR1-RTR(cfg-cp-dualtone)#voice class custom-cptone CONF-JOIN
BR1-RTR(cfg-cptone)# dualtone conference
BR1-RTR(cfg-cp-dualtone)#  frequency 1000 2000
BR1-RTR(cfg-cp-dualtone)#  cadence 100 50 200 50 300 50 400 50

The custom tones are then assigned to the DSPFarm profile.

BR1-RTR(config)#dspfarm profile 1 conference
BR1-RTR(config-dspfarm-profile)#shut

Disabling profile will disconnect active CONFERENCING calls,
do you want to continue ? [yes/no] yes

BR1-RTR(config-dspfarm-profile)# conference-join custom-cptone CONF-JOIN
BR1-RTR(config-dspfarm-profile)# conference-leave custom-cptone CONF-LEAVE
BR1-RTR(config-dspfarm-profile)#no shut

To verify an active conference call is using DSP resources on a particular gateway use the “show sccp connections” command. To solve any unusual problems start of by bouncing the SCCP application from within the IOS (no sccp/sccp).

Amy Ryan – CCIE #24677 (Voice)
Technical Instructor – IPexpert, Inc.
Mailto: aryan@ipexpert.com

Seeing is Believing- How can I see the entire config on an ASA?

Brandon Carroll — Mon, 23 Aug 2010 13:04:29 +0000

I remember a time when I taught a class called CIT (Cisco Internetwork Troubleshooting) and there was a wonderful rule that made all the students sweat a little more and all the instructors give that old Dr.Claw laugh (From Inspector Gadget if you have no idea what I’m talking about). Essentially it allowed the Instructor to do things that were really mean and evil and forced the students NOT to take the easy way out. What was that rule? When troubleshooting you may NOT use the command Show Running-Config or any variant of it.

Some of you are thinking….wow- I would be lost. To be honest I would be as well depending on the technology and the situation I’m in. So I won’t burden you with that rule. However, I would like to share a command that does’t just give you the running configuration on the ASA, rather it gives you the “real” running configuration. What am I talking about? Well, simply put- show run all…

That’s right! While many of you know this deep dark secret (it’s not really a secret) other don’t. So there ya go! A little tipt to put in your tip jar.

So the next time the boss says, “Man I cant remember the syntax of the default group policy on our ASA,” you can quickly respond with…

(type..type..type…)

ciscoasa# sh run all group-policy

group-policy DfltGrpPolicy internal

group-policy DfltGrpPolicy attributes

banner none

wins-server none

dns-server none

dhcp-network-scope none

vpn-access-hours none

vpn-simultaneous-logins 3

vpn-idle-timeout 30

vpn-session-timeout none

vpn-filter none

ipv6-vpn-filter none

vpn-tunnel-protocol IPSec l2tp-ipsec webvpn

password-storage disable

ip-comp disable

re-xauth disable

group-lock none

pfs disable

ipsec-udp disable

ipsec-udp-port 10000

split-tunnel-policy tunnelall

split-tunnel-network-list none

default-domain none

split-dns none

intercept-dhcp 255.255.255.255 disable

<--- More --->

“It’s DfltGrpPolicy boss. Anything else you need before I head to lunch?”

-Regards

Brandon Carroll – CCIE #23837

Free CCIE Lab Training: Links to This Weeks & Last Weeks Recorded vLectures

Sanjana Desai — Thu, 19 Aug 2010 13:04:32 +0000

Did you Miss our vLectures that were scheduled for this week & last week? No worries!

All our vLecture sessions are recorded and available for those who have missed our FREE vLecture and for participants who want to review the vLectures sessions again. We have saved the session recordings for you. Watch our world renowned CCIE instructors explaining specific technical topic in our technology-focused classes and capture the technical knowledge needed to increase your chances of passing CCIE exam.

CCIE Voice

Instructor: Vik Malhi
Topic: Cube
Link: http://ipexpert.acrobat.com/p18636770/

Instructor: Amy Ryan
Topic: Unity Connection Integration
Link: http://ipexpert.acrobat.com/p61951501/

Do not miss our vLectures scheduled for the coming weeks. If you’re an IPexpert client and wish to join these sessions, please be sure to reserve a “virtual seat” now, these have been highly anticipated and we’re quite confident that these online training seats will fill up quickly.

H.323 After-Hours Call Blocking

Amy Ryan — Wed, 18 Aug 2010 13:04:29 +0000

When dealing with call routing in general, it is no secret that there are countless ways to manipulate dialed digits to invoke a requested behavior. Anyone who has began studying to achieve the Cisco CCIE Voice certification has become quite aware of the plethora of methods to utilize when completing the Call Routing sections of the lab blueprint. It is quite possible when you sit the CCIE Voice lab to be asked to do some sort of Call Blocking as well, whether that is in the form of blocking calls to or from certain numbers, number type or even blocking calls based on date or time of day. In this blog, we will focus on after-hours call blocking as it pertains to Cisco Unified Communications Manager Express (CUCME) or CME-as-SRST. When implemented, calls matching against a pattern of specified digits will be prevented from proceeding based on day of the week and/or time of day.

CUCME call-blocking configuration applies to all SCCP, H.323, SIP and POTS calls that go through the CUCME router. All incoming calls to the router, except calls from an exempt phone, are also checked against the after-hours configuration. Lets take a quick glance at a sample configuration to see how this is applied.

telephony-service

after-hours block pattern 1 9011
after-hours block pattern 2 1212
after-hours block pattern 3 1617 7-24
after-hours date Dec 25 12:00 23:59
after-hours day Sun 12:00 07:00
after-hours day Mon 19:00 06:59
after-hours day Tue 19:00 06:59
after-hours day Wed 19:00 06:59
after-hours day Thu 19:00 06:59
after-hours day Fri 19:00 06:59
after-hours day Sat 13:00 12:00

In this example, calls made beginning with pattern 9011, 1212 or 1617 are blocked during the above schedule. In this schedule, each day of the week has a defined time for blocking calls to the listed patterns. There are a couple of things to take into consideration when setting up the time of day in this fashion. Let’s use Monday as an example. Based on above, calls are blocked on from 7pm Monday evening until 7am exactly Tuesday morning. Anytime the first timestamp listed is of a higher number than the second timestamp listed, we know that the second timestamp indicates the time of the following day. In addition, if we had used “07:00” instead of “06:59” here, then calls would have been blocked until 7:01am on Tuesday morning. If we made this error on the day it counts, those points would be lost for us. The above example also shows these types of calls cannot be made at anytime on December 25. It further shows that calls matching pattern 1617 will be blocked all hours of all days.

When dealing with blocked calls, it is important to remember the configuration applies globally to all dial peers. However, it may be requested to allow certain phones to be exempt when placing these types of calls. There are a few methods that can be used to achieve this, such as at the individual directory number, phone-level or dial-peer. It can also be set up so Individual phone users can override call blocking utilizing a PIN that has been assigned, however this method does not work on patterns that are blocking 24 by 7 such as pattern 3 in our example above.

Call Blocking Exemption for a Directory Number or Individual Phone

This method exempts all directory numbers associated with a phone from the after-hours call blocking configuration.

ephone 1
after-hour exempt
!
voice register dn or pool 1
after-hour exempt
To verify this:
BR2-RTR#sh ephone 
ephone-1[0] Mac:0024.142E.5BD1 TCP socket:[-1] activeLine:0 UNREGISTERED
mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 caps:0
IP:0.0.0.0 0 Unknown 0  keepalive 0 max_line 0
Preferred Codec: g711ulaw
after-hour exempt
BR2-RTR#sh voice register dial-peer  (SIP PHONES)

Call Blocking Exemption for a Dial Peer

This method allows H.323 and SIP trunk calls to proceed in spite of the after-hours configuration. This is critical to remember as you could be doing TEHO routing of some fashion that would be prevented from occurring if you did not exempt the incoming voip dial peer from being blocked.

dial-peer voice 100 voip
incoming called-number .
paramspace callsetup after-hours-exempt  true
To verify this:
BR2-RTR#sh dial-peer voice
VoiceOverIpPeer100
……..
incoming call blocking:
translation-profile = `'
disconnect-cause = `no-service'
advertise 0x40 capacity_update_timer 25 addrFamily 4 oldAddrFamily 4
mailbox selection policy: none
type = voip, session-target = `',
technology prefix:
settle-call = disabled

Amy Ryan – CCIE #24677 (Voice)
Technical Instructor – IPexpert, Inc.
Mailto: aryan@ipexpert.com

Join One of IPexpert’s Industry-Recognized Instructors for FREE Online CCIE Training This Week

Sanjana Desai — Tue, 17 Aug 2010 13:03:11 +0000

Have you ever wanted to attend one of IPexpert’s industry-leading CCIE classes?
Have you ever had problems really understanding a specific technical topic?

Do you want to improve your chances at pass the CCIE Lab?

Do you want to see why IPexpert’s CCIE instructors are considered the best in the training industry?

Do you want IPexpert, the company who has trained more CCIEs in the world, to help you?

…How would you like some FREE CCIE Lab training?

IPexpert is now offering FREE online training sessions to all IPexpert clients. If you want to improve your chances at passing Cisco’s rigorous and prestigious CCIE certifications, or if you simply want to fully-understand a specific technical topic – you can’t miss our FREE Online vLectures! Several times a week, you will be able to sit in, watch and interact with the IPexpert Instructor who will be teaching technology-focused classes on a specific track and topic. If you’re an IPexpert client and wish to join these sessions, please be sure to reserve a “virtual seat” now, these have been highly anticipated and we’re quite confident that these online training seats will fill up quickly.

CCIE Voice:

Date / Time: Aug 17^th at 4 PM EST
Instructor: Amy Ryan
Topic: Unity Connections Integrations

If you’re interested in this FREE online session, click here to Schedule Now!

CCIE Routing and Switching:

Date / Time: Aug 19^th at 10 AM EST
Instructor: Marko Milivojevic
Topic: Interdomain Multicast Routing

Date / Time: Aug 24^th at 10 AM EST
Instructor: Marko Milivojevic
Topic: Frame Relay – From Basics to QoS

If you’re interested in this FREE online session, click here to Schedule Now!

CCIE Service Provider:

Date / Time: Aug 19^th at 10 AM EST
Instructor: Marko Milivojevic
Topic: Interdomain Multicast Routing

If you’re interested in this FREE online session, click here to Schedule Now!

How to Prepare for CCIE Storage

Rick Mur — Thu, 12 Aug 2010 13:05:37 +0000

In this blog I’d like to highlight the ways you can prepare yourself for the CCIE Storage. This CCIE is currently the closest to datacenter networking and if you are installing Cisco UCS systems and/or Nexus 5000s you will need Fibre Channel knowledge and even configure MDS switches or Nexus 5000s who run the exact same code as the MDS switches (NX-OS is basically a renamed SAN-OS). Apart from some Specialist (partner) certifications there is actually no resource to gain this knowledge. So everything has to come from the CCIE Storage.

What happened to CCIE Datacenter?

Everybody thought that new Data Center CCIE will be announced at Cisco Live 2010. Unfortunately (or not), that didn’t happen. In the mostly rumored BRKCCIE-1001 on the final day nothing was announced although we had a great time with Antonella Corno, who is the program manager for CCIE Storage. The final word she had to say about it was: “It will be there sometime, but not now and not tomorrow”. She said that the software is still undergoing major overhauls, especially for UCS. It wouldn’t be a good idea to pick a software version and keep that in the blueprint for 2 years. It’s simply not ‘mature’ yet. I personally think that is a very good argument, as I’ve seen pretty much every UCS version from 1.0.1 to 1.3 and a LOT has changed in these versions.

The next major part of the CCIE Datacenter would be Nexus 2000, 5000 and 7000. NX-OS has been on the market now for about 1.5 to 2 years and you can see they are still adding major features, although with the introduction of OTV and FabricPath this has been completed now for a while. OTV and FabricPath are so new that this is also impossible to fit in a CCIE track as the first release of software was a few weeks ago and FabricPath will be out in September.

Again when everything flattens out and ‘matures’ than the CCIE Datacenter will be released.

CCIE Storage Reading

There are not a lot of resources to study from for CCIE Storage. There are 2 Cisco Press titles.
The first one is Storage Area Network Fundamentals. Which gives you an introduction to SAN technologies. It’s a bit dated (2002), but not much has changed in SCSI and FC standards over the last couple years (except for 8G, 10G FC and FCoE of course). I personally haven’t read this book, but it seems to be a good introduction.

The second is Storage Networking Protocol Fundamentals. This book goes really deep into the different standards and their respective OSI layers. It’s a good book if you know the basics as it really goes deep and can be very confusing if you start with it.

The third is one of the best texts that has even been written on Fibre Channel. The Fibre Channel Bench Reference Guide is a tough one, but describes everything very good! It’s not an easy read, but try and see if you can find the things you need to know and things you don’t need to know (don’t try to remember the 8B/10B encoding and especially not the reasons why you need disparity).

The chapter on SW_ILS communication (basically the enabling of ISLs or inter-switch-links) is the best and was really helpful for me to understand this.

The last recommendation I can give is the IBM Redbook on FICON. There are multiple IBM redbooks on describing FICON, but this one helps as it describes the implementation on Cisco’s MDS switches and gives you a great example of an IOCP file (IBM mainframe configuration files), that you will need to be able to read for the CCIE Storage lab exam.

FICON Native Implementation and Reference Guide: http://www.redbooks.ibm.com/abstracts/sg246266.html
Cisco FICON Basic Implementation: http://www.redbooks.ibm.com/abstracts/redp4392.html

Besides that you will need some real-life experience or some lab time on a couple MDS switches.

CCIE Storage Lab Preparation

To prepare for the CCIE Storage lab is a little more difficult in comparison to other, more popular, CCIE tracks. You need your own rack of 2 or preferably 3 MDS switches, a couple servers with dual HBA’s, dual-attached JBOD’s and preferably a Brocade and/or McData switch for interoperability testing.

The hardware you need can be of various sources, eBay is a good one to start with. One downside of the MDS switches is that they work with a license model. There are several licenses that can be bought for MDS switches. You need the following licenses to study for all topics:

ENTERPRISE_PKG
- This license is required for a LOT of ‘advanced’ features, like read-only zoning, zone-based QoS, IPsec and many other things.
SAN_EXTN_OVER_IP
- This is the so-called FCIP license. You need this just for extending a SAN over IP and the only technology currently available for that is FCIP (Fibre Channel over IP). Be aware that you can only build 3 tunnels per GigE port on the MDS switches!
MAINFRAME
- This license is required for the FICON feature. FICON is a technology used by IBM mainframes and it’s another ULP (Upper Level Protocol) for Layer 1 and Layer 2 Fibre Channel standards. Usually the only ULP used is FCP (Fibre Channel Protocol). FICON has a few own specifics, especially about semi-automatically allocated port numbers versus standard FCID addresses.
FM_SERVER_PKG
- Fabric Manager is the management tool provided by Cisco to manage an entire fabric of MDS switches (multiple connected FC switches are called a fabric). This software can be installed in a stand-alone fashion in which you can manager 1 single fabric. This is perfect for studies, as this doesn’t consume a license, but of course, that’s too good to be true as there is 1 exception, which is that you don’t have access to the web client of Fabric Manager. Therefore you need to install the server-based version that uses a PostgreSQL database and runs as a Windows service. This server based version can manage multiple fabrics, but also supports the web client in which you can create several reports and can run performance monitoring, which is definitely a blueprint topic to study. Unfortunately this server version does consume a license!

Please be aware of the grace period that is available to you when you get a new switch. By default every switch gets 120 days ‘trial’ period for every feature in the box (exception is the Fabric Manager license, that doesn’t know this period).

Hardware

The MDS portfolio knows many different switches. The top notch is the MDS9500 chassis based switch that knows just like the Catalyst 6500 a large amount of modules to fit in its slots and as the hardware got new features, new ‘Generations’ of modules were released.

There are Generation 1, Generation 2 and Generation 3 linecards. You need a Supervisor 2 and NX-OS 4.1 to support Gen 3, so you will not find these in the lab as that is based on SAN-OS 3.2. Generation 2 linecards support 4Gbps FC and know oversubscription limits. Each Generation 2 linecard comes with 4 port-groups each having 12.8Gbps to share, besides that you have to deal with a maximum 4:1 oversubscription rate on all Gen 2 modules except the 48 port module that knows a 5:1 oversubscription limit (this limit can be disabled, but prepare for any combination in the lab) and the 12 port module which has no oversubscription at all (4 port groups = 3 ports per group, 3×4=12Gbps max traffic per port group).

The Generation 2 linecards are very expensive, as are the 9500 chassis and they take a lot of space and power, so are not really suited for a rack at home.

The switches you will want to get are in the most perfect situation MDS9222i switches. These switches have an on-board MPS18+4 module, meaning you have 18 1/2/4Gbps FC ports and 4 GigabitEthernet ports for IP features. Besides that, this particular module supports all the advanced storage features/services that Cisco has built. The 18+4 linecard is a Generation 2 card, so it does know some oversubscription limits. One downside is that this switch is relatively new and is expensive.

The best option from my opinion would be a couple MDS9216i (or MDS9216A) switches. This is a small switch (only 3 RU), has a built-in 14 port 1/2Gbps FC module and has a spare slot in which you can fit a generation 1 MDS9500 module. You will want to have a module in there that has GigabitEthernet ports, in which you have 3 options. First are the IPS-4 and IPS-8 module that have 4 and 8 GigE ports respectively. They support Ethernet port-channeling, Network Simulator and a lot of the IP features, except IPsec VPN’s. The third option is the MPS14/2 linecard which as 14 1/2Gbps FC connections and 2 GigabitEthernet connections. This card supports all IP features, including IPsec VPN’s, except port-channeling and Network Simulator. Please be aware that this switch will not support any Generation 2 linecards, so you can’t practice oversubscription, you can practice Storage Services with the 9032-SSM module. This is another expensive (generation 1) module that supports all the advanced storage features. Please don’t think you really need this card, it’s a nice to have, as there are quite some features to be tested, but this won’t be a core-topic on the lab! 2, preferably 3 MDS9216i switches with at least 2 IPS4/8 or 14/2 cards would suffice all your study needs, but be sure to practice for the oversubscription and storage services by reading documentation.

Documentation

As of labs, try doing everything that is on the blueprint for CCIE Storage. If you master all the topics you can go to the lab and FLY through it. The advantage of the blueprint is that it really tells you what to do and mentions actual technologies and features that you can try.

The MDS Cookbook (3.x) is a fantastic way to start your preparation as it runs you through labs all the way using CLI and GUI. By going over it you should have a good overview of all the basic technologies.

After that the MDS Configuration Guide is the resource you want to be comfortable with. Don’t try to remember the full 1600 page document, but know where to find the stuff you need and use it as a resource for your lab work.

I hope you’ve enjoyed this brief overview of the preparation for CCIE Storage and hope you will enjoy the studying for this awesome track.

–
Rick Mur, CCIE3 #21946 (Routing & Switching / Service Provider / Storage)
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.ipexpert.com/

Quick Look Into OSPF Database: Router LSA

Marko Milivojevic — Wed, 11 Aug 2010 13:01:59 +0000

OSPF is a complex protocol. Understanding how it works is very important for any network engineer. For CCIE candidates, knowing how to effectively get and understand the information in OSPF database is even more so important. This is the first in series of articles about reading information from OSPF database.

We will explore Router LSA first.

Router LSA (Type 1) is possibly the most important LSA type in OSPF. Without it pretty much nothing else makes sense. The purpose of this LSA type is to describe router’s links (interfaces) in such a way that other routers in the same area can understand it and build their SPF trees based on that information. This information travels through the area unchanged and it’s very important to be able to interpret information in the database for effective and correct troubleshooting.

Network Layout

In order to explore this information, we need a very simple network. Even two-router setup will do, but I opted for three routers. here is the initial configuration of the network we’ll use today.

Along with that, here’s the relevant initial configuration of those three routers. We’ll be dealing with the very basics here, so configurations are really simple.

R2:

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Serial0/1/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
!
interface Serial0/1/0.24 point-to-point
 ip address 24.24.24.2 255.255.255.0
 frame-relay interface-dlci 204
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0
!

R4:

interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface Serial0/0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
!
interface Serial0/0/0.24 point-to-point
 ip address 24.24.24.4 255.255.255.0
 frame-relay interface-dlci 402
!
interface Serial0/0/0.45 point-to-point
 ip address 45.45.45.4 255.255.255.0
 frame-relay interface-dlci 405
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0
!

R5:

interface Loopback0
 ip address 5.5.5.5 255.255.255.255
!
interface Serial0/1/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
!
interface Serial0/1/0.45 point-to-point
 ip address 45.45.45.5 255.255.255.0
 frame-relay interface-dlci 504
!
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0
!

Exploring the Database

Before we can effectively explore the database, let’s take a look at what options we have available to us. We’ll focus on R2 for now and all commands I run below will be on R2, unless otherwise noted.

R2#show ip ospf database ?
  adv-router        Advertising Router link states
  asbr-summary      ASBR summary link states
  database-summary  Summary of database
  external          External link states
  network           Network link states
  nssa-external     NSSA External link states
  opaque-area       Opaque Area link states
  opaque-as         Opaque AS link states
  opaque-link       Opaque Link-Local link states
  router            Router link states
  self-originate    Self-originated link states
  summary           Network summary link states
  |                 Output modifiers

We can see that we have plenty of options available to use, but today we’re focusing only on the highlighted one. We want to see only Type 1 LSAs – also known as “Router LSAs”. Let’s take a look at what’s there.

R2#show ip ospf database router

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

  LS age: 19
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0xD206
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 2.2.2.2
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 4.4.4.4
     (Link Data) Router Interface address: 24.24.24.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 24.24.24.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

  LS age: 20
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 4.4.4.4
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000001
  Checksum: 0xB14F
  Length: 84
  Number of Links: 5

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 4.4.4.4
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 5.5.5.5
     (Link Data) Router Interface address: 45.45.45.4
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 45.45.45.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 2.2.2.2
     (Link Data) Router Interface address: 24.24.24.4
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 24.24.24.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

  LS age: 24
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 5.5.5.5
  Advertising Router: 5.5.5.5
  LS Seq Number: 80000001
  Checksum: 0x78BA
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 5.5.5.5
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 4.4.4.4
     (Link Data) Router Interface address: 45.45.45.5
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 45.45.45.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

Wow, that’s a quite a bit of information for a simple network like ours! Don’t be alarmed, everything makes perfect sense there. Let’s look at few things. First of all, examine red bits. These fields can be effectively visually indicate “the start of new router” in the output. What I mean by this is that when you see something like “LS age”, it means you are reading LSA originated by some router in the network. When you encounter another line like that, it means you are reading about information coming from a different device than before. Which device are you reading about -that’s shown in green. Remember that the information here is NOT an IP address, but OSPF Router-ID of the advertising router, which may or may not be a valid and reachable IP in the network. To illustrate this, I will change Router-ID on R5 manually and we’ll see the difference later on.

R5:

router ospf 1
 router-id 55.55.55.55
!

Dissecting the Database

Given enough time, we can sift through the previous output looking for what we need in any particular situation, but even by one glance at it, we can be certain that for any larger network, this output will get very, very long, real quick. It’s a good idea to learn couple of options available to us when using “show ip ospf database router” command. Let’s take a look at them and what they do.

R2#show ip ospf database router ?
  A.B.C.D         Link state ID (as an IP address)
  adv-router      Advertising Router link states
  internal        Internal LSA information
  self-originate  Self-originated link states
  |               Output modifiers

First of all we should learn about “self-originate” option. Each router will advertise to its neighbors descriptions of its own links. We can examine this information about each router using the command “show ip ospf database router self-originate”. Let’s examine R2.

R2#show ip ospf data router self-originate

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

  LS age: 193
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0xD007
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 2.2.2.2
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 4.4.4.4
     (Link Data) Router Interface address: 24.24.24.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 24.24.24.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

Now, this is much more manageable for reading. Note: You can use several different commands to get the exact same information. In our case, “show ip ospf database router self-originate”, “show ip ospf database router 2.2.2.2″ and “show ip ospf database adv-router 2.2.2.2″ produce exact same information. Essentially, those commands are synonym for each other. Options “adv-router” and “A.B.C.D” behave differently depending on LSA type being examined, but for Type 1 they are identical.

Armed with that, let’s examine what R5 is sending us.

R2#show ip ospf data router 5.5.5.5

            OSPF Router with ID (2.2.2.2) (Process ID 1)

Now, this is not what I expected to see… Remember I changed OSPF Router-ID of R5 to 55.55.55.55 just before? It’s easy to correct our mistake when we know this, but let’s use the database to see if we can see new information by ourselves.

R2#show ip ospf database

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         1858        0x80000002 0x00D007 3
4.4.4.4         4.4.4.4         1858        0x80000002 0x00C373 5
55.55.55.55     55.55.55.55     1860        0x80000002 0x008F11 3

That one was easy, so let’s take a look at what R5 is sending us. Again, we can use two commands to get the exact same information – “show ip ospf database router 55.55.55.55″ and “show ip ospf database router adv-router 55.55.55.55″

R2#show ip ospf database router 55.55.55.55

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

  LS age: 41
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 55.55.55.55
  Advertising Router: 55.55.55.55
  LS Seq Number: 80000003
  Checksum: 0x8D12
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 5.5.5.5
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 4.4.4.4
     (Link Data) Router Interface address: 45.45.45.5
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 45.45.45.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

For the end of this article, I would just like to illustrate one of the most important concepts in OSPF – the fact that routers share identical databases. We see above Type 1 LSA from R5 on R2. Let’s examine the same LSA on R5 itself, as well as R4.

R5:

R5#show ip ospf database router self-originate

            OSPF Router with ID (55.55.55.55) (Process ID 1)

                Router Link States (Area 0)

  LS age: 189
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 55.55.55.55
  Advertising Router: 55.55.55.55
  LS Seq Number: 80000003
  Checksum: 0x8D12
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 5.5.5.5
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 4.4.4.4
     (Link Data) Router Interface address: 45.45.45.5
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 45.45.45.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

R4:

R4#show ip ospf database router 55.55.55.55

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Router Link States (Area 0)

  LS age: 220
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 55.55.55.55
  Advertising Router: 55.55.55.55
  LS Seq Number: 80000003
  Checksum: 0x8D12
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 5.5.5.5
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 4.4.4.4
     (Link Data) Router Interface address: 45.45.45.5
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 45.45.45.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

We can clearly see that apart from age, all information is exactly the same! For the very end, I would like to mention “internal” keyword, which is not documented. When using this option, you will see some additional internal IOS information about the LSA, but nothing of any real significance.

Next time, we’ll look into Type 3 LSAs and how to “fish” that information from the database. Enjoy your studies!

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Free CCIE Lab Training: Links to This Weeks & Last Weeks Recorded vLectures

Sanjana Desai — Thu, 05 Aug 2010 13:15:12 +0000

Did you Miss our vLectures that were scheduled for this week & last week? No worries!

CCIE Security

Instructor: Tyson Scott
Topic: ASA & IOS based NAT
Link: http://ipexpert.acrobat.com/p92268115/

Gatekeeper/H323 signaling: RAS, H225, H245

Vik Malhi — Wed, 04 Aug 2010 15:23:13 +0000

First of all let’s start proceedings with the disclaimer. H323 is an ITU protocol used to set up VOIP calls between two endpoints (conferences, gateways, terminals) sitting on the network. It is a very, very complex umbrella protocol with many sub-protocols from ITU and IETF referenced/defined. Not to mention the copious amounts of revisions that have taken place over the past 15 or so years. Needless to say, this blog is not going to be a full comprehensive guide to H323. It is however a streamlined summary (kind of a fast start guide :-) of what is most relevant based on the CCIE Voice Lab blueprint. We will focus in this blog on the H323 messaging involved in a call between UCM & UCME via a gatekeeper.

Calls between UCM & UCME via a gatekeeper

In reality, the fact that we are dealing with UCM and UCME is insignificant. You can treat this situation as a call between two H323 endpoints (gateways).

In this example let’s think of the UCM and UCME as Endpoint 1 and 2 respectively which are both registered to the same Gatekeeper. The same call flow is applicable when you consider Endpoint 1 & 2 as two UCM clusters, two UCME’s or two H323 gateways registered to the same Gatekeeper.

Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF (2) exchange with that Gatekeeper. Contained within the ARQ is a bandwidth request (16kbps and 128kbps for G729 and G711 respectively) and also a telephone (E164) number. The Gatekeeper shall return the Call Signaling Channel Transport Address of Endpoint 2 (called endpoint) in the ACF. You can use the debug gatekeeper main 10 to see how gatekeeper resolves the E164 number and debug gatekeeper call 10 to see the incoming bandwidth request from Endpoint 1. If either the called number cannot be resolved or the bandwidth request is unsuccessful, an ARJ message is returned to Endpoint 1.

Endpoint 1 then sends the Setup (3) message to Endpoint 2 using the Transport Address contained within the ACF message from Gatekeeper. If Endpoint 2 wishes to accept the call, it initiates an ARQ (5)/ACF (6) exchange with the Gatekeeper. It is possible that an ARJ (6) is received by Endpoint 2, in which case it sends Release Complete to Endpoint 1. Endpoint 2 responds with the Connect (8) message which contains an H.245 Control Channel Transport Address for use in H.245 signaling.

You are able to see a high level view of the RAS messaging using the debug ras command on the gatekeeper. The beauty of this command is that is shows the IP addresses of the source/destination in decimal format. In order to see the entire RAS message use the command debug h225 asn1 on the gatekeeper. This command produces A LOT of output and should be used sparingly! If it wise to increases the RRQ keepalive timer to avoid the RRQ/RCF keepalive mechanism from flooding the debug output on screen/log. You are able to do this within UCM from system > gatekeeper and from UCME using the command ras rrq ttl within voice service voip/h323. I suggest 5 minutes as a reasonable value. The debug h225 asn1 command could be used on Endpoint 1 and/or 2 which would in addition to the RAS messaging that particular endpoint exchanged with the gatekeeeper show you the H225 Call Signaling messaging (Setup, Call Proceeding, Alerting, Connect).

Location Request

If Endpoint 2 was registered to another Gatekeeper (Gatekeeper 2) then Gatekeeper 1 would contain a zone prefix to a remote zone which has been defined on Gatekeeper 2. Endpoint 1 (calling endpoint) sends an ARQ (1) to Gatekeeper 1. Gatekeeper 1 sends an LRQ (2) to locate called Endpoint 2. Gatekeeper 2 returns an LCF (3) with the Call Signaling Channel Transport Address of the Endpoint 2. This information is passed onto Endpoint 1 inside the ACF (4) message. Endpoint 1 would then send a Setup message to the Call Signaling Address of Endpoint 2 and the H225 messaging would continue in an identical manner in the previous example.

H245 Messaging

The H225/RAS messaging discussed up to now is responsible for finding the location of the called party. The called party will ring and the calling party will hear ringback. Once the call has been answered then a whole new messaging (H245) sequence is initiated. This H245 messaging is responsible select the appropriate codec/dtmf transport mechanism used for the call and the endpoints RTP/RTCP channels to be used for the media being sent between the endpoints.

There are three main phases of H245 messaging which you are able to see using the debug h245 asn1 command.

(1) TCS. The Terminal Capability Set Message is sent between the endpoints involved in the call to indicate the codecs, dtmf and other capabilities of each endpoint. Each TCS Message must be acknowledged by the other endpoint. If there are no overlapping capabilities then you will see the Terminal Set Reject Message.

(2) MSD. Master/Slave Determination is used to determine the codec since the TCS messages could have indicated multiple codecs supported. The Master will decide the codec and other capabilities to be used in the call. The Master is chosen based on Endpoint type (gateway > terminal), Endpoint capabilities (video & audio > audio only) and randomly (identical endpoints).

(3) OLC. Open Logical Channel messages are used to inform each endpoint of the RTP/RTCP ip address/port numbers.

There is one variation to the above H245 messaging sequence- H245 FastConnect. This was introduced in H323 v2 and solves the problem of having the H245 handshake once the call has answered. In a nutshell when Fast Connect is used the Fast Start Information Element is contained in the SETUP message- this Fast Start IE contains the TCS Message. This allows capabilities Exchange to occur before the call has answered thereby meaning that logical channels are opened quicker compared with H323 Slow Start. The Called Party acknowledges the TCS and sends it’s own TCS in the Connect Message.

Vik Malhi – CCIE#13890
Managing Partner / Instructor – IPexpert Inc