Jun
12

A few seats are still available for the 10am and 2pm CCIE Routing & Switching Troubleshooting sessions that INE is running at Cisco Live US in San Diego. Sessions are being held in the Revolution room of the Hard Rock Hotel San Diego. Candidates who previously RSVPed to the sessions at the INE party last night will get priority, and seating after that will be on a first come first serve basis.

In these sessions students will be using our new 28 router and 4 switch CCIE R&S troubleshooting topology. Users will have 2 hours to complete a lab of 10 trouble tickets. Afterwards the sessions will be automatically graded and score reports presented. The user with the highest score for each session will win a new iPad! In the event of a tie the user with the fastest time and highest score will win.

Admission is free, but seating is limited, so get there early!

Mar
19

I just finished up 2 weeks of a really great CCNP Voice bootcamp, covering all 5 of the latest 8.0 version exams from Cisco (CVOICE, CIPT1, CIPT2, CAPPS, & TVOICE). All in all we ended up with 62 completely brand-new hours of informative video that we are sure you will be excited to watch when they are posted to our streaming and download sites here in probably just about a week. We went fairly in-depth on most every topic, one of them being MGCP during our TVOICE section of class.

BTW, with this new 62 hours of CCNP Voice video, this brings INE to 320 hours of total CCNA-to-CCIE Voice video-on-demand training. Far, far more than any other vendor. And it is all up-to-date and taught by me, not by subcontracted instructors.

You may recall that in my last post related to MGCP Troubleshooting, we took a basic look at the MGCP commands that a Call-Agent (server) instructs a Gateway (client) to preform - something the RFC refers to as "verbs".

In this post, we are going to take a look at the output of the "debug mgcp packets" command for a single call, and then break down each section of the output into "transactions" (i.e. Command and Response).


So to begin with, here is the complete output a of single call from "debug mgcp packet":


ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x00FF
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA18381
Preferred, Channel 1
Progress Ind i = 0x8583 - Origination address is non-ISDN
Display i = 'Seattle US Phone'
Calling Party Number i = 0x4180, '2065015111'
Plan:ISDN, Type:Subscriber(local)
Called Party Number i = 0xC1, '2065011002'
Plan:ISDN, Type:Subscriber(local)

MGCP Packet received from 177.1.10.12:2427--->
CRCX 256 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
X: 3
L: p:20, a:G.729, s:off, t:b8, fxr/fx:t38
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---

MGCP Packet sent to 177.1.10.12:2427--->
200 256 OK
I: 31

v=0
o=- 49 0 IN IP4 177.1.254.1
s=Cisco SDP 0
c=IN IP4 177.1.254.1
t=0 0
m=audio 18714 RTP/AVP 18 100
a=rtpmap:18 G.729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
<---

ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x80FF
Channel ID i = 0xA98381
Exclusive, Channel 1

ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8 callref = 0x80FF
Progress Ind i = 0x8088 - In-band info or appropriate now available

MGCP Packet received from 177.1.10.10:2427--->
RQNT 257 S0/SU0/DS1-0/1@Branch2 MGCP 0.1
X: 1
R: D/[0-9ABCD*#]
S: G/rt
Q: process,loop
<---

MGCP Packet sent to 177.1.10.10:2427--->
200 257 OK
<---

ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8 callref = 0x80FF
ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x00FF

MGCP Packet received from 177.1.10.12:2427--->
MDCX 258 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
I: 31
X: 3
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: sendrecv
R: D/[0-9ABCD*#], FXR/t38
S:
Q: process,loop

v=0
o=- 49 0 IN EPN S0/SU0/DS1-0/3@corphq.voice.ine.com
s=Cisco SDP 0
t=0 0
m=audio 18214 RTP/AVP 0
c=IN IP4 177.1.11.26
a=X-sqn:0
a=X-cap:1 image udptl t38
<---

MGCP Packet sent to 177.1.10.12:2427--->
200 258 OK
<---

ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x00FF
Cause i = 0x8290 - Normal call clearing

MGCP Packet received from 177.1.10.12:2427--->
MDCX 259 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
I: 31
X: 3
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---

MGCP Packet sent to 177.1.10.12:2427--->
200 259 OK
<---

MGCP Packet received from 177.1.10.12:2427--->
DLCX 260 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
I: 31
X: 3
S:
<---

MGCP Packet sent to 177.1.10.12:2427--->
250 260 OK
P: PS=974, OS=155840, PR=981, OR=156960, PL=1, JI=3, LA=0
<---

 
 
So now just looking at the first transaction, we see an Inbound call (thanks to the inclusion of the 'debug isdn q931' output) and that the call-agent (UCM) instructs the gateway to "CRCX" or "CreateConnection", and the Gateway responds with very simple "200 OK", while also including the SDP (IETF Session Description Protocol) pertaining to such things as audio codec and DTMF. Notice how after each call-agent instructed verb (command) and gateway response there is a 3 digit number that corresponds. This is the transaction number, and use of it essentially ensures that the response is specific to the command (as there may be many commands and responses being issued on a heavily populated MGCP gateway). We can clearly see in this initial command that the call-agent is instructing the use of the "a:G.729" audio codec on the "L" line, and the gateway is obliging with the SDP response that will use the RTP/AVP (Audio Video Profile) codec number 18, G.729 without Annex B. More on this line reveals other things about the call such as "p" being the packet or sampling size of 20ms, "s" being VAD, "t" being the RFC 2474 ToS/DSCP bits (b8 is hex for 10111000 or DSCP EF), and fax capabilities. You also might note that the gateway was instructed to "M: recvonly" or as far as the "connectionMode" is concerned, that the gateway should only Receive packets, not send them. The "C" line is the global CallID and the "X" line is essentially the local callID. The "R" line is the supported DTMF.


MGCP Packet received from 177.1.10.12:2427--->
CRCX 256 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
X: 3
L: p:20, a:G.729, s:off, t:b8, fxr/fx:t38
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---

MGCP Packet sent to 177.1.10.12:2427--->
200 256 OK
I: 31

v=0
o=- 49 0 IN IP4 177.1.254.1
s=Cisco SDP 0
c=IN IP4 177.1.254.1
t=0 0
m=audio 18714 RTP/AVP 18 100
a=rtpmap:18 G.729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
<---

 
 
The next transaction shows us the ISDN is telling us the phone out on the PSTN is now alerting (ringing) and the MGCP Request Notify tells the gateway with the "S" line to play the "rt" or ringback tone.


ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8 callref = 0x80FF
Progress Ind i = 0x8088 - In-band info or appropriate now available

MGCP Packet received from 177.1.10.10:2427--->
RQNT 257 S0/SU0/DS1-0/1@Branch2 MGCP 0.1
X: 1
R: D/[0-9ABCD*#]
S: G/rt
Q: process,loop
<---

MGCP Packet sent to 177.1.10.10:2427--->
200 257 OK
<---

 
 
In this next transaction we see the ISDN output showing that the call is now connecting and the MGCP output that the call-agent us informing the gateway to "MDCX" or "ModifyConnection" again, this time to change its RTP connectionMode to send and receive packets "M: sendrecv". This is where the call was answered, and audio now commences.


ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8 callref = 0x80FF
ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x00FF

MGCP Packet received from 177.1.10.12:2427--->
MDCX 258 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
I: 31
X: 3
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: sendrecv
R: D/[0-9ABCD*#], FXR/t38
S:
Q: process,loop

v=0
o=- 49 0 IN EPN S0/SU0/DS1-0/3@corphq.voice.ine.com
s=Cisco SDP 0
t=0 0
m=audio 18214 RTP/AVP 0
c=IN IP4 177.1.11.26
a=X-sqn:0
a=X-cap:1 image udptl t38
<---

MGCP Packet sent to 177.1.10.12:2427--->
200 258 OK

 
 
In this next transaction we see from the ISDN output that the call is being disconnected and the call-agent is informing the gateway to "MDCX" or "ModifyConnection" again, this time to change its RTP connectionMode back to receive only. This is the call-agent prepping the gateway that the call is being torn down.


ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x00FF
Cause i = 0x8290 - Normal call clearing

MGCP Packet received from 177.1.10.12:2427--->
MDCX 259 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
I: 31
X: 3
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---

MGCP Packet sent to 177.1.10.12:2427--->
200 259 OK
<---

 
 
In this final (and immediately following the previous) section, we see the call-agent instructing the gateway to "DLCX" or "DeleteConnection". The gateway obliges, and also provides some useful statistics (ConnectionParameters to be specific) about the call, namely "P: PS=974, OS=155840, PR=981, OR=156960, PL=1, JI=3, LA=0". (PS=PacketsSent, OS=OctetsSent, PR=PacketsReceived, OR=OctetsReceived, PL=PacketsLost, JI=Jitter, LA=Latency). BTW, if we had anything such as no audio or a one-way audio issue, we could clearly see that by either both PS & PR or in the case of only one-way audio only PS or PR having a value of 0 (no packets sent and/or received).


MGCP Packet received from 177.1.10.12:2427--->
DLCX 260 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
I: 31
X: 3
S:
<---

MGCP Packet sent to 177.1.10.12:2427--->
250 260 OK
P: PS=974, OS=155840, PR=981, OR=156960, PL=1, JI=3, LA=0
<---

 
 
Seeing as we have just covered SDP, it will only make sense to move on to looking as SIP, as it uses SDP for audio information as well.

 

Related Posts

%RELATEDPOSTS%

Jan
25

Over the coming weeks I will be running a new series here on Troubleshooting Voice. I often have students in class that report to me that one of the most difficult parts of their CCIE Voice exam experience was having to deal with the inner workings of some of the protocols and how to read and decipher them accurately. I have also begun to see this more and more across the various mailing lists and forums, and so I decided it was time to start an entire series on these not-to-be-feared topics. Since these protocols are covered quite in-depth in the CCNP Voice course (most specifically in the CVOICE portion), I highly encourage people starting out in Unified Communications, not to skip the lower level courses, and to really dig in at that CCNA Voice and then CCNP Voice level, before going into the CCIE Voice. At each level something is presented that is not explained at the next level, so it really is crucial to go through each progression of the track in a sequential and systematic order. This goes especially for those who might already have a CCIE, and think they understand what the CCIE is all about. They probably understand very well what the exam itself is all about, however the underlying Voice technologies are quite vastly different than the data world they may be used to. In fact, I hear this quite a lot from people making the jump from a R&S IE to the Voice side of the realm - "Man, this Voice stuff is totally different!".

To begin with, we will start out a bit easy, and go over the basics of everyone's favorite client/server gateway protocol - MGCP or "Media Gateway Control Protocol".

MGCP has a series of commands that are exchanged between the client and the server. In the basic Cisco UC world (basic meaning enterprise side of things rather than the carrier side), the client ('gateway') is almost always an IOS voice-enabled router, and the server ('call agent') is always the Unified Communications Manager (UCM).

Here are the basic commands that are used to exchange messages between call-agent and gateway:

Connection Commands

  • CRCX = CReate Connection
  • DLCX = DeLete Connection
  • MDCX = MoDify Connection

Audit Commands

  • AUEP = AUdit EndPoint
  • AUCX = Audit Connection

Request Command

  • RQNT = Request for Notification

Endpoint Command

  • EPCF = EndPoint ConFiguration

Notify Command

  • NTFY = Notify

Restart Command

  • RSIP = ReStart In Progress

 

Now, let's look at each command in a bit more detail.

Connection Commands

Three messages are used by a call-agent to manage an RTP connection on a media gateway

CRCX = CReate Connection

  • In this message the call-agent instructs the gateway to establish a connection with an endpoint. The parameters in the CReateConnection provide the what is necessary to build an understanding of each connection. The parameters include the codec, packetization period, QoS marking, usage of echo cancellation, silence suppression, gain control, RTP security, and resource reservations.
DLCX = DeLete Connection
  • This message informs the recipient to delete a connection. The call agent or the gateway can issue the command. The gateway or the call agent issues the command to advise that it no longer has the resources to sustain the call. As a side effect, the call agent collects statistics on the execution of the connection. The statistics include number of packets sent, received, and lost, interarrival jitter, and average transmission delay.
MDCX = MoDify Connection
  • This message instructs the gateway to update its connection parameters for a previously established connection. The call agent issues the command. The parameters used are the same as in the CreateConnection command, with the addition of a ConnectionID that identifies the connection within the endpoint.


Audit Commands

Two messages are used by a call-agent to query the status of a media gateway

AUEP = AUdit EndPoint
  • This message requests the status of an endpoint. Information that can be audited with this command includes RequestedEvents, DigitMap, SignalRequests, RequestIdentifier, QuarantineHandling, NotifiedEntity, ConnectionIdentifiers, DetectEvents, ObservedEvents, EventStates, BearerInformation, RestartMethod, RestartDelay, ReasonCode, PackageList, MaxMGCPDatagram, and Capabilities. The response will include information about each of the items for which auditing info was requested.

AUCX = Audit Connection

  • This message simply requests the status of a connection.

Request Command

One message is used by a call-agent to request a notification of events on a media gateway

RQNT = Request for Notification

  • This message instructs the media gateway to watch for events on an endpoint and the action to take when they occur, such as fax tones. The call-agent may then decide to specify use of a different type of encoding method should be used and instruct the gateway to change with a ModifyConnection command.

 

Endpoint Command

One message is used by a call-agent to manage a media gateway

EPCF = EndPoint ConFiguration

  • The EndpointConfiguration command can be used to specify the encoding of the signals that will be received by the endpoint, such as A-law or mu-law. The call-agent can use the EndpointConfiguration command to pass this information to the media gateway.


Notify Command

One message is used by the media gateway to notify the call-agent about an event which the call-agent requested notification about

NTFY = Notify

  • This message informs the call-agent of an event for which a notification was requested. A single notification message may carry an entire list of events that the gateway detected and accumulated.


Restart Command

One message is used by the media gateway to tell the call-agent that it is in the process of restarting

RSIP = ReStart In Progress

  • This message tells the call-agent that the gateway and its endpoints are removed from service or are being placed back in service. The message carries an EndPointId to identify the endpoint(s) that are put in-service or out-of-service. The RestartMethod parameter specifies the type of restart.
  • The various RestartMethods are defined as:
    • "Graceful" restart method indicates that the specified endpoints will be taken out-of- service after the specified delay.
    • "Forced" restart method indicates that the specified endpoints are taken abruptly out- of-service. The established connections, if any, are lost.
    • "Restart" method indicates that service will be restored on the endpoints after the specified "restart delay,"that is, the endpoints will be in-service. The endpoints are in their clean default state and there are no connections that are currently established on the endpoints.
    • "Disconnected" method indicates that the endpoint has become disconnected and is now trying to establish connectivity. The "restart delay" specifies the number of seconds the endpoint has been disconnected. Established connections are not affected.
    • "Cancel-graceful" method indicates that a gateway is canceling a previously issued "graceful" restart command. The endpoints are still in-service.

 

Here is a brief visual aid I quickly put together to help put some of these commands into a bit of perspective as to when each is sent and what function it serves:
In our next post, we will explore how these messages interact in a much more in-depth fashion, between the call-agent and the gateway, with the aid looking at debug output from a live UCM and IOS MGCP gateway.Throughout this series, we will be taking a look at virtually every protocol that is used in the Cisco UC network, so be sure to check back regularly for the complete set.

Troubleshooting MGCP Part II here

 

Related Posts

%RELATEDPOSTS%

Jul
14

Brian Dennis and I attended Cisco Live! - Networkers this week, and both enjoyed the privilege of sitting down to talk privately with Yusuf Bhaiji (Program Manager over the entire CCIE program) and Ben Ng (Program Manager over the CCIE Voice track) for roughly 45 minutes. It was quite an enjoyable and spirited talk, and I believe it benefited both sides - our side to gain a better understanding of why some of the choices have been made, and theirs possibly to see things a bit more 'through the eyes of the typical hard-studying student'. I would like to take a moment to jot down some of the highlights from our conversation, and then unpack them in a bit more detail, so that you may benefit from the open conversation.

Highlights

I'll jot down some very simple, high-level topics that were discussed during our conversation, and then unpack them in more detail in the following section.

  • Upcoming changes to every CCIE Lab Exam
    • Protecting the integrity of the CCIE certification
    • Robust, matured results-based grading engine
    • Heuristic logic embedded into task wording
    • Accuracy and detail of lab score reports
    • Cisco's CCIE Lab Delivery System and virtualization for mobile labs
    • No re-reads
  • CCIE Voice
    • Next blueprint version expectation
    • Topics for current and next blueprint versions
  • CCIE Data Center
    • CCIE Storage grows up
  • Reason behind Cisco.com CCIE Statistics web page being removed

Let's Unpack This a Bit More

Firstly, if I could sum up our entire conversation into one, clear theme, it would be "Protecting the Integrity of the CCIE Program". Indeed, both Yusuf and Ben clearly stated that central theme was the primary guiding principle behind every meeting they have regarding any aspect of the program, every planning session for the future of the program, and every decision made to add, remove and/or change anything in any of the tracks.

The main focus is to ensure that candidates who are attempting the lab exams are what Cisco is certifying them as: Experts. To ensure that no one is able to memorize any aspect of the exam, and to make sure that those of us that are teaching these potential candidates about the technologies involved, are in fact teaching our students everything they need to know about a given group of technologies necessary to become a true expert - something INE has always worked incredibly hard to do. This focus (and the changes it will affect) implicitly deals with the problems that have arisen in the past with a small minority of people who dishonestly try just to memorize parts of the exam, as well as companies who blatantly cater to that small minority by attempting to gain access to a given exam and publish entire exams, or even parts of them.

Now, this has always been a driving focus for the program, however they realized that while some of their efforts in the past to this end have been successful, that many also may not have succeeded in the manor in which they had intended for them to. Case in point: Core Knowledge/Open-Ended Questions (and their complete removal from all tracks). Another attempt at this from long ago -and still in place but soon to possibly change- was the 'detailed score report' (or shall I say 'lack' of detail in the score report). More on that last bit in a moment.

Upcoming Changes to Every Lab

So, onto the specifics of how they plan to accomplish this. With no definites given as to exactly how or when the implementation of any of these initiatives would be implemented, some things were quite frank and very clearly stated. They talked about how their lab grading engine has been in use for some time now, and has reached quite a mature level with it's results-based scoring (both terms of it's accuracy as well as it's modularity). Now would be remiss if I didn't take a quick aside to say when I mention that it has reached a high level of accuracy, some might immediately jump to the conclusion that it wasn't accurate before, and that might have been the reason for their failed attempt. Just to quell those fears, a (human) proctor has always, and will continue to look over and verify a candidate's lab and scripted grading results before issuing the final grade. Now with the fact that the engine grades based on results-based testing (and not on any specific commands input into the configuration), as well as the key point that it is extremely modular (due to it's structured XML nature), any given task can be tested in the same way, however worded in 10-15 different ways on different iterations of any given lab exam. This leads naturally to the ability for them to have upwards of 25 or 50 labs in rotation at any given time for any given CCIE track and blueprint, which makes it nearly imposible for anyone to actually memorize any/all of the questions or versions of lab exams. Thus making those that pass, truly validated as experts. They spoke of a sort-of heuristic logic woven into all of the task wording to accomplish this. Also talked a lot about was how troubleshooting was one of the best things that they added (added 'back' I should say, since it used to be there in the 2-day exam). So look for that to not only continue, but permeate its way through more exams in more ways. No mention was specifically made as to whether any other track outside of R/S would go to the same sort of segregated TS section that it utilizes - so it may happen, it may not. Just have to wait and see.

They have been developing towards this goal for some time now, they know exactly how they will carry it out (however to disseminate that specific knowledge would be completely counter-intuitive to the very idea of integrity protection - so anyone telling you they 'know' how it's being done clearly doesn't know what they are talking about). They mentioned that it will be occurring soon, though when exactly won't ever be known or disclosed, and it won't be necessary to 'announce' it per-se, since it won't require the upgrade/change of any hardware/software or technology-specific topics.

All of what we've talked about up till this point, this obviously doesn't negatively impact any of our readers here, as you all are true learners, true knowledge-seekers - those who wish to not only know, but to truly understand (to paraphrase Einstein, if I may). However, it may have some positive implications that you have not yet considered. Aside from the obvious fact that it preserves the integrity of the prestigious certification that you have (and continue to) worked so diligently towards achieving, another possible benefit from this is that since the CCIE program has/will-have this new ability to have so many exams in rotation (and thus exponentially-if-not-entirely reducing the possibility of memorization of tasks), they can relax a bit on their very ambiguous failed score reports. For those of you who are not yet aware, while some candidates pass on their first attempt, most do not. In fact the average (very loose average) is roughly 2-3 attempts at any given CCIE lab before a 'Pass' is awarded, and you only receive a broken down score report if you fail - if you pass you simply receive a 'PASS' (and frankly, you don't care that you didn't receive a report). Now they didn't state for certain that this would in fact occur (more detailed reports), but they did indicate that it was being discussed internally as a strong possibility - since the grading engine obviously reports back in extreme detail - although he (Yusuf) said it would never include specifically which tasks you got right vs wrong. However, he did also mention that the purpose of the CCIE Program is not to train candidates or provide feedback - it is to test them. It is the responsibility of us, the CCIE training providers, to not only teach, but pre-test and provide accurate feedback to students before they make the actual journey to the Lab and truly become candidates for admission into the prestigious certification that is the CCIE. That by the way, is something that INE is committed to, and indeed already provides more than adequate resources for CCIE R/S, and will soon be adding for the CCIE Voice as well (more on that later).

Another one of the initiatives of the program is to make it much more widely accesible to everyone, everywhere. This was the impetus behind the original idea of having the lab able to be taken from any Prometric/Vue testing center. But Vue wasn't really ready to handle the stringent requirements, and thus the attempt didn't ultimately succeed. Then came the CCIE Mobile Testing Labs. Those worked. Well. Really well in fact. And now the push is to make every single track able to be tested in that same mobile fashion. However, there are a few challenges to overcome first, before that can become a reality. Take CCIE Voice for instance - in order for the Voice lab to become truly mobile, everything has to be ported to Cisco's CCIE Lab Delivery System (where everything: the tasks, the desktop for CLI/GUI, etc. are all completely virtualized). This means the phones themselves as well. Softphones won't do. They don't behave at all like hardware phones. So they are working on creating a completely virtualized hardware-like phone, that behaves exactly like a hardware phone (but doesn't remotely control one). When they get that completed, then you will begin to see the Voice lab become available in the mobile testing centers (along with every other lab once their similar challenges are met).

One last thing I asked Yusuf about regarding specifically the CCIE Voice lab exam, was why they hadn't yet allowed for re-reads (the ability that, if you fail an exam but think you should have passed, you can pay $300 USD to have your lab re-graded manually). He mentioned that since the overall percentage since they began offering that option was so extremely low of those who request a re-read actually results in a grade being overturned (we're talking like 1 out of every 5,000), not to mention that that number has dropped even more with results-based scripted grading, that the focus was not to add more of that unnecessary burden on the already taxed proctors, but to reduce it. So while he didn't provide any guidance on when (if ever) they will completely eliminate that practice from the other tracks (R/S, Sec, SP), he did say that the focus is on removing that option from those tracks vs. adding that option to other tracks (Voice, WiFi, Storage).

CCIE Voice

There was a very interesting breakout session this year entitled "CCIE Voice: Cryptography in Cisco Unified Communications", which inevitably led to the question by participants: "If this class is prefaced by the title 'CCIE Voice', does this mean that Cryptography/Security is going to begin being tested in the lab exam?". The answer to this when asked by the attendee and then later in a bit more detail by me was answered with the basic answer of (and I'll paraphrase): "This has been tested in the written exam for some time now, however there is absolutely nothing stopping us from testing this in the lab today with version 7 of the various UC platform servers, and obviously no problem testing it moving forward to UC version 8 (or 9, etc), as even more security has been added to the new version of UC platforms".

Of course, in the main CCIE Voice 8-hour Technical Seminar, the question was asked by some participants (as well as by me in more detail later in private) when we might anticipate the Voice lab being updated to UC platform version 8.x (or beyond, if FCS'd for better than 6 months by time of announcement), to which Ben gave no real guidance publicly, yet in private alluded to (reverting back to our previous mention in this blog post) the desire to virtualize the hardware phones and deliver the exam with the new virtual Lab Delivery System, so that they could support the mobile labs.

Now of course 8.x has been in production for well over a year now in many networks around the globe, but 9.x doesn't FCS (First Customer Ship) until April '12, meaning that they could possibly update the lab to UC platform version 8 anytime (with a standard 6-month pre-announcement of course), but to update to version 9 would mean that they couldn't even announce a new lab based on that version until Oct '12, with it going live around Apr '13 at the earliest. I have no idea at all which they will end up doing, and from talking with Ben, he made it seem like they hadn't reached an internal decision yet either. In fact it probably will largely depend on how quickly they get that virtualized hardware-like phone put into production in all reality.

Either way, it doesn't really matter. INE has you covered. The major new things in CUCM ver 8.x that can be tested are the following:

  • Call Control Discovery over the new Services Advertisement Framework (CCD / SAF) with RSVP SIP Preconditions
  • Extension Mobility Cross Cluster (EMCC)
  • SIP Normalization using the Lua scripting language

They can't really test the Intercompany Media Engine (IME) - it's just not technically possible. EMCC is easy, and within the day of them announcing this being tested I'll have a minimum 2-hour video ready. I already have over 4 hours recorded on every aspect of CCD over SAF and another half hour of the RSVP with SIP Preconditions in our new CCNP Voice product (which should be posted to our CDN in about a week). SIP Normalization with Lua -- eewww -- let's hope they don't test you on it - but either way, we'll have a video for you the week they announce it.

There are way too many small new features in UC 9.x to list here, -- I'll do a post covering those in the not-too-distant future, but needless to say, it won't be hard to add content to what we have to cover it. The best news is that everything you are studying today, is 100% completely relevant to any new version of the lab that could be announced, whenever they decide to do so -- so don't loose an moment of sleep over a possible upgrade -- you'll be 98% ready anyhow.

As for the possible testing of Cryptography/Security, I will be adding labs to our Volume II Workbook here in the upcoming month, with at least one of which will specifically address this topic. Our racks will allow you to test those features related to security to coincide with the release of that lab.

CCIE Data Center

Now, onto Data Center. Data Center was easily, hands-down, the single largest topic discussed at this year's Cisco Live! event. Not to mention that VMware timed the announcement of version 5 of their suite of virtualization products (including vSphere, vCenter Site Recovery Manager, vSphere Storage Appliance, and vCenter Heartbeat Center) to be exactly 1 hour prior to (and thus ending with the beginning of) John Chamber's Keynote address at Cisco Live!.

But here's how everything relates to the CCIE program. It was very clear that the CCIE Storage is going to become the CCIE Data Center. In fact, aside from that being very clearly stated, the breakout this year was entitled: "Cisco Data Center/Storage Certification". It was stated that the following would be what comprised the new CCIE DC.

Written exam will include (this is their wording copied verbatim):

 

  • Revised Smaller version of the existing SAN Track blueprint
    • MDS device operation, Advanced FC Features, SAN extension & switch Interop
    • SAN Management will be integrated in the new overall DC management
  • In addition to new topics to include:
    • Basic Data Center L3 topology
    • Data Center Access Layer deployment
      • L2, vPC, Fabric Multipathing, QoS
      • Virtualization
      • Unified I/O, FCoE , DCBX
    • Unified Computing System (UCS)
    • Load Balancing techniques and algorithms
    • Branch WAN Acceleration
    • Data Center Management

Lab exam will look like this (this is their wording copied verbatim):

  • MDS will remain in the lab as well as 3rd party FC switches
  • We will consider adding DC solutions and technologies that can be deployed on the following Cisco Products:
    • MDS SAN Switches
    • Nexus 7000, 5000 and 2000
    • Cisco Unified Computing Systems (UCS)
    • Application Control Engine (ACE)
    • Global Site Selector (GSS) in case of DR scenario
    • Wide Area Application Services (WAAS)
    • Data Center Management for both LAN & SAN
    • Virtualization with Nexus 1000v

Of all those things that can be tested, the most obvious ones that would almost have to be included are the Nexus line of DC switches and the UCS blade servers, complete with Fabric Interconnects and Virtual Interface Cards. So those are the things that INE will begin immediately to record video-based lessons on, adding them to our All Access Pass. Guidance wasn't provided on exactly when this track might go into live testing, though sources tell us that we may be less than 12 months away from it going live. Watch this blog for announcements soon on when you might expect the first of those Nexus and UCS training videos. Storage wasn't big. Data Center is already huge. The CCIE Data Center is going to be as well.

UPDATE

I mentioned above two things that I forgot to include, so I will add them in here.

First off I mentioned that we will be adding graded mock labs to the Voice track. Please email me directly if you would be interested in participating in a graded mock lab. It would involve using a dedicated rack for 8.5 hours (8 hours for config and .5 for lunch, just like the real lab) with basic minimal access to the proctor (myself) for basic question clarification, but no real assistance (again, just like the real lab).

Second thing was the reasoning behind the removal of the CCIE stats page from cisco.com. This might sound like a strange reason - I thought so, but after listening to Yusuf talk a bit more about it, it did make good sense in the end. The reason was completely centered around the fact that when one updates his/her cisco.com testing profile with the proper home mailing address, and most importantly home country, and then takes and passes any CCIE exam, his/her CCIE number is forever associated with that country. The problem was, people didn't always stay in that country. They sometimes moved, as is a reasonable assumption. However, the CCIE stats page wasn't designed as a synchronous page that would do a real-time DB lookup each time it was loaded, and so it would always report X number of CCIEs in X country. Yusuf used himself as an example. He's from Pakistan, and so his CCIE was basically 'registered' there (at least so far as that stats page went). Problem is, he moved to Australia for a number of years, but according to that stats page, his CCIE was still in Pakistan. Then he moved to Dubai in the UAE. CCIE? Still in Pakistan. So why should any of that matter? Well, to you and me - it might not. However, when a Cisco Partner in Pakistan (just continuing our example of Yusuf) is told by their Channels team: "You must have 4 CCIEs to become a Gold Partner" (or CCDE's, they count now too for that metric), and maybe the parter reports back: "But there aren't enough CCIEs in Pakistan to accomplish that!", the Cisco Channels team would just pull up that stats page, point to it and show the Partner and say: "Yes there are, see here?" (Again, Pakistan is just an example country, I have no idea how many CCIE/CCDEs there are there, so please don't think I'm being partial for/against that or any other country in any way - nothing is implied). It actually became a very, very big issue with Channels and Partner certifications. And Cisco is a large organization. If any of you have worked for one, you know that a team like the CCIE program has nothing to do with web page programming - that's a completely different part of the business. And to get something changed there requires a requisition to be submitted, go through various levels of approval, and finally implementation. And believe it or not, it took about 4 months for that process to occur, and by the time the implementation of it was being carried out (the removal of that page off of cisco.com), it truly just happened to coincide with a period just following a CCIE R/S change that was resulting in less people passing the lab at that specific point in time. Yusuf stated that it couldn't have been worse timing, however it truly was purely coincidental. He also mentioned that - yes, for a period of time after any type of a change to any lab track, there is always a fall-off in the number of CCIEs awarded for that track, but then it always picks back up. This is perfectly natural for any type of change for a number of reasons. 1) People stop booking a given lab en-masse right after a new version is announced - their basically afraid of what they don't know (aren't we all to some degree?). 2) If you sit a brand new lab version, and have no idea what to expect, you might be thrown for a bit of a loop, and therefore loose a bit of time you would expect to be productive during that lab attempt. By the way, this doesn't have to be. Take a bootcamp course from veterans of the lab such as Brian & Brian (and possibly counting myself as a veteran at this point, I guess I'm getting up there in years :-), my first lab attempt was in '02, so I'm going on 10 years next year .... wow -- although Brian Dennis has his 15 year anniversary coming up in just a few months!), and anyway, you'll be prepared no matter what they throw at you, and there will be no need for you to be counted in with the stats of people that 'don't know what to expect after a new version change'. Anyway, he finally mentioned that while Cisco doesn't (and won't) publish the exact statistics of CCIE Pass/Fail, if you look at the overall average number of passing scores over the life of any blueprint version, those numbers have always been, and will continue to keep trending upward.

----------------------

Well, that's about all I can think of at the moment. I just finished a long flight from Las Vegas to Minneapolis sitting next to Louie Anderson, and to be honest, I'm not sure how I got any writing done. That guy's funny. I need to see him next time I hit the strip.

-Mark

Sep
03

I enjoyed Petr's article regarding explicit next hop.  It reminded me of a scenario where a redistributed route, going into OSPF conditionally worked, depending on which reachable next hop was used.

Here is the topology for the scenario:

3 routers ospf fa blogpost

Here is the relevant (and working :)) information for R1.

R1 screenshot

When we replace the static route, with a new reachable next hop, we loose the ability to ping 100.100.100.3

R1 screenshot 2

When we change the next hop for the static route, (which is being redistributed into OSPF), the route to 100.100.100.0/24 no longer works, even though we have verified ability to ping the new next hop.

Can you solve this puzzle?  Please post your ideas!

For more troubleshooting scenarios, please see our CCIE Route-Switch workbooks, volume 2, for more than 100 challenging troubleshooting scenarios.

We will post the results right here, in a few days, after you have had a chance to post your comments and ideas.

Best wishes.

 

Follow-up-

Thank you for all the great answers, (below in the comments).

R1, using a next hop of 172.16.33.33 in its static route, will include that same address in the LSA as the forwarding address.  Among the requirements that make this possible, the one we are going to focus on here is that this next hop is in the same IP subnet as an OSPF interface (Lo0) on R1.  172.16.1.1/16 (R1) and 172.16.33.33 (next hop address, owned by R3).

R1 sends 172.16.33.33 as fa

If we use a next hop that isn't in the same IP subnet as an OSPF interface on R1, the LSA will not include the next hop forwarding address, which will then cause R2 to believe that R1 is the next hop and the route will fail to work.   We could also cause the 0.0.0.0 to show up by changing the ospf network type for R1 Loop 0 to point-to-point, not including Loop 0 in the network statement for OSPF, or by setting Loop 0 as a passive interface for OSPF. (take your pick) :)

R1 sends 0.0.0.0 fa

Again, thanks to all for the EXCELLENT answers and insights.

You rock!

Jul
19

The author and poet Maya Angelou said "Words mean more than what is set down on paper. It takes the human voice to infuse them with deeper meaning.". Well that is certainly what we have attempted to do with the CCIE Voice Deep Dive self-paced Class on Demand series - that is to bring the human instructional voice element to infuse deeper meaning to what is already fantastic Cisco Documentation. Anyone that has set out and determined to undertake the task of studying for and ultimately passing any CCIE Lab exam, knows that at some point during your studies, the words on paper (Cisco Docs, RFCs, books) - while a absolute phenomenal source of information - can at times seem to loose their impact. Perhaps you have been studying too long, read one too many docs, have the time pressure of your family and friends waiting for you to return to be a part of their life, or perhaps you are just starting out on your adventure and don't know where to begin. Whatever stage you are at or whatever the case may be, it is certainly helpful to have a tutor and mentor there beside you at times, assisting you in understanding what each complex technology's documentation is trying to teach you, in possibly a deeper and more insightful way than you can manage on your own.

Wait no longer for such help to arrive! INE is happy to announce that each Live-Online Deep Dive course that we have taught has been recorded, and you have the ability to access these extensive repositories of knowledge at any time.

Here are a couple of great demo's of just a portion of the latest Deep Dive session we held on Globalization & Localization in order to whet your appetite:

Demo 1: Globalization Prezi - Theory and Reasons

Demo 2: Inbound Calling Party Localization

For each complex topic we have held -- or will soon hold (listings to follow below) -- a separate online class where we dive down deep and explore all the concepts, practical application and troubleshooting associated with each technology topic. We then allow you to purchase each module individually (if you like) so that you can either try small sections of the product, or so that those who only need to plug in small gaps of knowledge can do so at a very deep, intense level - either one without committing to purchase the entire product series.

The general format for each Class-on-Demand Deep Dive module spends between 4-7 hours on the given topic for that day, and during that time follows this outlined training methodology:

  • Collectively discuss and teach all concepts involved in the technology
  • Whiteboard concepts to further deepen every participant's understanding
  • Define a specific set of tasks to be accomplished
  • Demonstrate how the tasks and concepts are implemented and properly configured
  • Test the configuration thoroughly
  • Vary the configuration to understand how different permutations effect the outcome
  • Debug and trace the working configuration to understand what should be seen
  • Break the configuration and troubleshoot with debugs and traces to contrast from the working set

Thus far, we have held 10 online sessions - each with a median recorded runtime of 6 hours. We have almost 60 hours of Class on Demand content, and we've only just begun! We conservatively estimate that by the time we complete our more than 30 planned modules, that we will have at over 200 hours of Deep Dive recordings.

Below is a detailed index from the 10 currently available sessions:

Module 1 :: Network Infrastructure with LAN Quality of Service

  • Catalyst 3560/3750 Classification and Marking
  • Catalyst 3560/3750 Conditional Trust
  • Catalyst 3560/3750 Ingress Interface Mapping
  • Catalyst 3560/3750 Ingress Interface Queuing
  • Catalyst 3560/3750 Ingress Interface Expedite Queue
  • Catalyst 3560/3750 L2 CoS to L3 DSCP Mapping
  • Catalyst 3560/3750 Egress Interface Mapping
  • Catalyst 3560/3750 Egress Interface Queuing
  • Catalyst 3560/3750 Interface Queue Memory Allocation
  • Catalyst 3560/3750 Egress Queue-Set Templates
  • Catalyst 3560/3750 Weighted Tail Drop (WTD) Buffer Allocation
  • Catalyst 3560/3750 Egress Interface Expedite Queue
  • Catalyst 3560/3750 Egress Interface Sharing
  • Catalyst 3560/3750 Egress Interface Shaping
  • Catalyst 3560/3750 Scavenger Traffic Policing

Module 02 :: CUOS GUI and CLI Admin

  • CUCM WebUI: Service Activation and Stop/Start/Reset
  • CUCM WebUI: Bulk Administration Tool (Import/Export, Phone Reports, etc)
  • CUCM WebUI: DB Replication Status
  • CUCM WebUI: Trace Files
  • CUOS CLU: TFTP Files Management
  • CUOS CLU: Status and Hostname
  • CUOS CLU: DB Replication Assurance
  • CUOS CLU: DB Replication Repair and Cluster Reset
  • CUOS CLU: Trace Files
  • CUOS CLU: RIS DB Search
  • CUOS CLU: Performance Monitor (PerfMon)
  • RTMT: Trace Files
  • RTMT: Performance Monitor (PerfMon)

Module 03 :: CUCM System and Phone - SCCP and SIP Fundamentals

  • CUCM Services
  • UC Servers and Groups
  • Date/Time with NTP Reference
  • Regions and Codecs
  • Location-Based Call Admission Control
  • SRST References
  • Device Pools
  • System Parameters
  • Enterprise Parameters
  • Phone Button Templates
  • Softkey Templates
  • SCCP Phone Basics
  • SIP Phone Basics

Module 04 :: Users, Credentials, Multi-Level Roles and LDAP Internetworking

  • CUCM User Credentials and Policies
  • LDAP Synchronization for CUCM and Unity Connection
  • LDAP Authentication for CUCM and Unity Connection
  • CUCM End Users
  • CUCM User Roles
  • CUCM Multi-Level Administration
  • CUCM Device/Phone/Line User Association
  • UCCX and CUP Basic Users

Module 05 :: Call Features - In-Depth

  • SCCP and SIP Phone Display
  • Phone Firmware
  • Phone Logging
  • Ring Settings
  • Basic and Advanced Call Forwarding Display
  • Auto-Answer Options
  • CallBack (Camp-On)
  • Intercom
  • Advanced Call Hold Options
  • Call Park
  • Directed Call Park
  • Advanced Call Park Settings
  • Call Pickup
  • Group Call Pickup
  • Other Call Pickup
  • Directed Call Pickup
  • Call Pickup Attributes
  • Shared Line
  • Barge and cBarge (Conference Barge)
  • Privacy
  • Built-In IP Phone Bridge

Module 06 :: Media Resources - MTPs, Conf Bridges, Annunciator and Music on Hold

  • IOS Software MTP
  • IOS Conference Bridge
  • IOS Transcoding
  • Media Preference and Redundancy
  • Meet-Me Conferencing
  • Ad-Hoc Conferencing
  • Annunciator
  • Unicast Music on Hold
  • Traditional Multicast Music on Hold
  • Alternate Multicast Music on Hold

Module 07 :: Expert Gateways & Trunks

  • ISDN Switch Types and Advanced CNAM options
  • ISDN Information Elements
  • SIP Trunks - Fundamental and Advanced Options
  • H.323 Gateways - Fundamental and Advanced Options
  • MGCP Gateways - Fundamental and Advanced Options

Module 08 :: Expert H.323 Gatekeeper

  • Provisioning IOS H.323 Gatekeeper
  • Registering CUCM with H.323 Gatekeeper
  • Registering CUCME with H.323 Gatekeeper
  • Routing Calls from CUCME to CUCM via Gatekeeper in Multiple Zones with Dynamic E.164 Aliases
  • Routing Calls from CUCM to CUCME via Gatekeeper in Multiple Zones with Multiple Tech Prefixes
  • Routing Calls from CUCME to CUCM via Gatekeeper in Multiple Zones with Multiple Tech Prefixes
  • Routing Calls from CUCME to CUCM via Gatekeeper in Multiple Zones with Static E.164 Aliases
  • Routing Calls from CUCM to CUCME and Back via Gatekeeper in One Zone with One Tech Prefix
  • Gatekeeper Call Admission Control
  • Routing Calls from CUCM to CUCME and Back via Alternate Gatekeeper Clustering in Multiple Zones with Multiple Tech Prefixes using GUP

Module 09 :: Dial Plan - Line Device Approach and the Not-So-Basic Fundamentals

  • Class of Service: Calling Search Spaces and Partitions
  • Gateways, Route Groups, Local Route Groups/Device Pools
  • Route Lists and Standard Local Route Groups
  • Route Patterns and Translation Patterns
  • Digit Manipulation: Calling & Called Party Transformations and IOS Dial Peers
  • Private Line Automatic Ringdown (PLAR)

Module 10 :: Dial Plan - Globalization & Localization of both the Calling and the Called Numbers, and with Mapping the Global Number to the Local Variant

  • Inbound PSTN Calls (Ingress from PSTN, Egress to Phones): Calling Party Globalization :: GW Incoming Calling Party Settings
  • Inbound PSTN Calls (Ingress from PSTN, Egress to Phones): Calling Party Localization :: Phone Calling Party Transformations
  • Outbound PSTN Calls (Ingress from Phones, Egress to PSTN): Called Party Globalization :: PSTN Patterns - a.k.a. "Translation Patterns are the *New* Route Patterns"
  • Outbound PSTN Calls (Ingress from Phones, Egress to PSTN): Called Party Localization :: Digit Manipulation: Calling & Called Party Transformations and IOS Voice Translation Rules & Dial Peers
  • Mapping the Global Number to the Local Variant :: + Dialing and One-Button Missed Call DialBack

So stay tuned to this blog as we will shortly post the upcoming modules soon to be held online and recorded.

Jul
09

"Why doesn't this PING work!?!"

Here is a simple 3 router configuration, well at least it is simple on 2 of the 3 routers. R1 and R3 are configured quite traditionally, but R2 is a bit more involved.
Here is the diagram.

ZBF Transparent VRF R2

Here are the details.

R2 is using a VRF which includes both LAN interfaces. R2 is also acting as a Zone Based Firewall in transparent mode, allowing all ICMP traffic in both directions, as well as SSH from the inside to the outside networks. R2 has a bridged virtual interface in the 10.123.0.0/24 network. All are running OSPF, but pings issued from R2 to the loopbacks of R1 and R3 are failing.

Can you identify why?
Here is the relevant output:

R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 1 FULL/DR 00:00:39 10.123.0.3 FastEthernet0/0
10.123.0.2 1 FULL/BDR 00:00:32 10.123.0.2 FastEthernet0/0
R1#show ip route ospf
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/2] via 10.123.0.3, 00:01:33, FastEthernet0/0

R1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/88/172 ms
R1#ssh -l admin 3.3.3.3
Password: <password>

R3#show ssh
Connection Version Mode Encryption Hmac State Username
0 1.99 IN aes128-cbc hmac-sha1 Session started admin
0 1.99 OUT aes128-cbc hmac-sha1 Session started admin
%No SSHv1 server connections running.
R3#exit

[Connection to 3.3.3.3 closed by foreign host]
R1#

Now for R2:

R2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DROTHER 00:00:37 10.123.0.1 BVI1
3.3.3.3 1 FULL/DR 00:00:35 10.123.0.3 BVI1

R2#show ip route ospf

R2#show policy-map type inspect zone-pair
Zone-pair: zp-in-to-out

Service-policy inspect : p-in-to-out

Class-map: c-in-to-out (match-any)
Match: protocol icmp
4 packets, 320 bytes
30 second rate 0 bps
Match: protocol ssh
3 packets, 72 bytes
30 second rate 0 bps
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [4:390]
icmp packets: [0:50]

Session creations since subsystem startup or last reset 8
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [2:1:1]
Last session created 00:02:23
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 3
Last half-open session total 0

Class-map: class-default (match-any)
Match: any
Drop (default action)
0 packets, 0 bytes
Zone-pair: zp-out-to-in

Service-policy inspect : p-out-to-in

Class-map: c-out-to-in (match-all)
Match: protocol icmp
Inspect
Packet inspection statistics [process switch:fast switch]
icmp packets: [0:20]

Session creations since subsystem startup or last reset 2
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [1:1:0]
Last session created 00:25:24
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 1
Last half-open session total 0

Class-map: class-default (match-any)
Match: any
Drop (default action)
4 packets, 96 bytes

R2#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2# show run
version 12.4
hostname R2
!
ip vrf myvrf
!
class-map type inspect match-any c-in-to-out
match protocol icmp
match protocol ssh
class-map type inspect match-all c-out-to-in
match protocol icmp
!
policy-map type inspect p-in-to-out
class type inspect c-in-to-out
inspect
class class-default
policy-map type inspect p-out-to-in
class type inspect c-out-to-in
inspect
class class-default
!
zone security inside
zone security outside
zone-pair security zp-in-to-out source inside destination outside
service-policy type inspect p-in-to-out
zone-pair security zp-out-to-in source outside destination inside
service-policy type inspect p-out-to-in
bridge irb
!
interface FastEthernet0/0
ip vrf forwarding myvrf
no ip address
zone-member security inside
bridge-group 1
!
interface FastEthernet0/1
ip vrf forwarding myvrf
no ip address
zone-member security outside
bridge-group 1
!
interface BVI1
ip vrf forwarding myvrf
ip address 10.123.0.2 255.255.255.0
!
router ospf 1 vrf myvrf
router-id 10.123.0.2
network 0.0.0.0 255.255.255.255 area 0
!
bridge 1 protocol ieee
bridge 1 route ip
end

Here is R3:

R3#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DROTHER 00:00:32 10.123.0.1 FastEthernet0/1
10.123.0.2 1 FULL/BDR 00:00:31 10.123.0.2 FastEthernet0/1

R3#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 10.123.0.1, 00:29:36, FastEthernet0/1

R3#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/117/176 ms
R3#

Similar configuration scenarios are included in both our RS and SC workbooks at INE.

Take a moment, and post your ideas on why the PING from R2 is failing, and thanks for taking the time to assist!

Best wishes.

Jul
02

The best-selling Volume 2 practice lab workbook from INE has been updated with new, 2-hour Troubleshooting sections that mirror the actual Cisco Lab Exam. Labs 1 through 3 are published now to member accounts. More are on the way!

Do you want to watch  Lab 1 TS section solved? Check out the updated Interactive Video Companion! I will be demonstrating my approach to Lab 2 in that product next week.

Enjoy the updates everyone, and as always, thank you so much for choosing INE.

Mar
02

You just cannot assume anything when you sit for your Version 4.0 CCIE R&S Lab Exam. One of the former assumptions we could make with Version 3.x was that our Frame Relay Switch is going to be just fine and dandy. Therefore, if you examined your PVC health (status) and you saw DELETED, you could immediately inspect your Frame Relay map statements, or your frame-relay interface-dlci commands for a typo in the DLCI.

But in this new exam (Troubleshooting section or Configuration section), nothing is off limits from your problem scope. OK, well, to be more accurate, most Layer 1 issues are still indeed out of scope. In fact, in the Troubleshooting section, Layer 1 really cannot be an issue since the devices we are troubleshooting are actually virtual routers. You cannot even run up against a bad cable there! But still, there is a lot more that we can be asked to troubleshoot than in the past. And if you think about the Core Knowledge section, they could even ask Layer 1 troubleshooting-related questions there instead!

In this blog post (dedicated to my current Advanced Troubleshooting Bootcamp Live Class), we will examine Frame Relay troubleshooting where the Frame Relay Switch rears its rather ugly head.

frame

I am going to carefully configure the R1 and R2 interfaces for Frame Relay in this scenario. I am going to "slow down to speed up" in these configurations and make sure they are letter for letter perfect. First, R1 and then R2:

R1:

R1(config)#interface serial 0/1
R1(config-if)#shutdown
R1(config-if)#encapsulation frame-relay
R1(config-if)#no frame-relay inverse-arp
R1(config-if)#ip address 10.20.20.1 255.255.255.0
R1(config-if)#frame-relay map ip 10.20.20.2 102 broadcast
R1(config-if)#no shutdown
R1(config-if)#
...
Mar  2 14:54:33.156: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up

R2:

Rack8R2(config)#interface serial0/1
Rack8R2(config-if)#shutdown
Rack8R2(config-if)#encapsulation frame-relay
Rack8R2(config-if)#no frame-relay inverse-arp
Rack8R2(config-if)#ip address 10.20.20.2 255.255.255.0
Rack8R2(config-if)#frame-relay map ip 10.20.20.1 201 broadcast
Rack8R2(config-if)#no shutdown
Rack8R2(config-if)#
...
Mar  2 14:59:23.362: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up

So far so good!I am thrilled to see the magic UP/UP system messages and I am ready to rock with a PING test.

Rack8R2#ping 10.20.20.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Rack8R2#

Not what I want to see! Let me do some further information gathering:

Rack8R2#show frame-relay pvc

PVC Statistics for interface Serial0/1 (Frame Relay DTE)

Active     Inactive      Deleted       Static
Local          0            0            1            0
Switched       0            0            0            0
Unused         0            0            0            0

DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/1

Wait a minute! DELETED???? I triple-checked my DLCI configuration per the diagram. Can I access the device connecting these routers (R3 in my case)? I sure can...let me view the relevant configuration on the device.

Rack8R3#sh run
...
hostname Rack8R3
!
frame-relay switching
!
interface Serial1/2
no ip address
encapsulation frame-relay
clock rate 64000
frame-relay intf-type dce
!
interface Serial1/3
no ip address
encapsulation frame-relay
clock rate 64000
frame-relay intf-type dce
...
Rack8R3#

It looks like someone made a nice attempt at the Frame Relay Switch configuration here (note the highlighted commands), but they have forgotten the "static routes" for PVC switching on the device.

Rack8R3(config)#interface serial 1/2
Rack8R3(config-if)#frame-relay route 102 interface serial 1/3 201
Rack8R3(config)#interface serial 1/3
Rack8R3(config-if)#frame-relay route 201 interface serial 1/2 102
Rack8R3(config-if)#

Now, drum roll please, let us try that PING again.

Rack8R2#ping 10.20.20.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/61 ms
Rack8R2#

Now that is more like it!!!!!

Jan
10

Our students that attempt the actual exam are consistently passing the Troubleshooting section now with relative ease. Why? Well, they are focusing on strategies that we teach in our bootcamps and discuss here on the blog. They are also practicing frequently with the many sample Trouble Tickets we feature in our materials. The premier product for this practice is the Volume 4 workbook.

INE is currently adding more labs to this best-selling self-paced product. Enjoy the additional practice!

Subscribe to INE Blog Updates