In our last article we looked at IPv6 over IPv4 DMVPN configuration, where IPv4 transport was used to tunnel IPv6 traffic. In this blog post I would like to show you how to deploy pure IPv6 DMVPN network, and even more importantly, how to enable one IPv6 Routing Protocol over another in the Cloud.

Since IPv6 will be now also used as the underlying transport, the overall configuration of the DMVPN devices will be a little bit different from the previous example; also note that our topology was slightly modified :

Key thing here is that NBMA addresses are no longer IPv4; basically IPv6 is used everywhere, which means that our mappings on the Spokes will be always referring to v6 information.

Let’s start our configuration. We will first configure our Hub (R3), then the Spokes (R2, R4), and finally enable routing on the Overlay network. Since IPSec is optional, we will not be using it in this example (note that to protect IPv6 packets IKEv2 would have to be used, not IKEv1).

R3 (Hub) configuration. Again, everything is IPv6, including the tunnel mode. Don’t forget that link-local addresses must be always hard-coded on a given Cloud, on every device :

Let’s now quickly verify our configuration. First thing look at the transport mechanism for the Tunnel :

Now the NHRP mappings learned by the Hub after Spokes joined to the Cloud :

And we see we have connectivity within the Cloud :

OK so at that point, what we don’t know yet is private networks connected to our devices. We have to somehow advertise this information and the way we do this is by enabling a Routing Protocol over the Cloud. This is how we extend our regular Control Plane with VPN information needed to prepare the Data Plane for DMVPN-through traffic.

What I would like to show you specifically, is how to use EIGRPv6 and OSPFv3, and how to adjust the protocol’s configuration to match the DMVPN Phase configured in the network. Before we start, make sure that everyone can route IPv6 packets :

DMVPN Phase II

We are going to start with EIGRP. I am going to use a new configuration framework for this protocol, which is known as EIGRP Named Mode. In short, it allows you to configure a single process for multiple different Address Families, plus it supports configuration of few new features that cannot be enabled in the Classic Mode :

The good thing about Named Mode is that all protocol-related configuration is done under the process; you no longer have to move back and forth between interface and process level configuration modes (Next-Hop and Split Horizon here). Since the process activates on all interfaces of the device by default, you have to say “shutdown” under every interface you don’t want to run a given Address Family on. In our case we only want to run EIGRPv6 on the Tunnel interfaces (and private subnets to advertise them), so I shut it down everywhere else. Another major thing to remember about is that Router-ID is by default taken from the highest-numbered IPv4 interface of the router (loopbacks preferred) – but if no interface runs IPv4 you have to statically hard-code it. Similar configuration goes to the Spokes :

The end result is that we should be now able to reach other prefixes and build direct Spoke-to-Spoke tunnel between R2 and R4. Unfortunately this particular version of IOS I am running on (15.3) apparently has some issues with NHRP, and Spokes always resolve other Spokes’ Next-Hop address to the NBMA of the Hub. This is either an IOS bug or Cisco is basically pushing towards Phase III deployments, deeming Phase II a legacy solution :

So in this particular code the traffic is still flowing through the Hub, and that’s obviously not what we want. But before we switch to Phase III, let’s also take a look at OSPFv3 configuration you would normally use to support Phase II :

In case of OSPF we must use a Broadcast network type to keep the original IP address as a Next-Hop. Since there is going to be a DR/BDR election on that network, make sure that Hub is a DR (otherwise routes will not get propagated to all Spokes). This translates to setting the OSPF priority to 0 on the Spokes. The process was also enabled on Loopbacks 10 because I am using them to emulate our private sites.

Unfortunately we will have the same problem in the Data Plane like with EIGRP – again, this is probably a bug or new “feature” :

DMVPN Phase III
What’s going to change here? First and foremost, we will have to enable NHRP Redirections on the Hub, and Shortcuts on the Spokes :

Now the protocol-related changes (I am modifying configs shown for Phase II). For EIGRP we only need to enable changing of the Next-Hop so it always points to the Hub :

Now at that point NHRP Redirection should have already taken place – after R2 receives a Resolution Reply for 2192:1:4::4/128, an NHRP cache entry will be added. Now with the Shortcut feature enabled, NHRP intercepts every data packet in the output feature path. It checks to see if there is an NHRP cache entry to the destination of the data packet and, if yes, it replaces the current output adjacency with the one present in the NHRP cache. The data packet is therefore switched out using the new adjacency provided by NHRP. We can confirm that with another trace :

Also note that newer IOS versions will actually tell you about NHRP-learned information :

Also the CEF FIB table gets automatically updated :

Finally, DMVPN Phase III configuration for OSPFv3 requires a single change on the Tunnels :

After you send some data packets, you should be able to see the Shortcuts installed :

Please join us in congratulating the following iPexpert students who have passed their CCIE lab!

This Week’s CCIE Success Stories

• Martin Fischer, CCIE #48881 (Security)
• Joseph Ploehn, CCIE #17658 (Data Center)
• David Sun, CCIE #48879 (Routing and Switching)

We Want to Hear From You!

Have you passed your CCIE lab exam and used any of iPexpert’s self-study products, or attended a CCIE Bootcamp? If so, we’d like to add you to our CCIE Wall of Fame!

As many of you have heard by now, Cisco has announced their new CCNA Cloud and CCNP Cloud certifications. These certifications are designed to be a focus-based around their “Internet of Things” (IoT) concept, which will also play into the “Internet of Everything” (IoE) transformation that we’ll see happening over the next several years. In addition to Cisco, so many other companies are participating in the IoT concept, at a minimum, the companies listed here.

As a quick summary, the IoT definition refers to the endpoints, devices, and networks that connect to the internet, whereas their IoE definition is more of a “tied in system” that brings networked devices, and endpoints (IoT) together into a much larger solution that will allow the ability to connect people, places, and things in a much more relevant and valuable way than ever imagined. IoE brings people, processes, data, and the connected devices together to form – essentially, in my own words “a connected world”.

For a visual explanation, check out this slideshow and video (which I love) developed by Cisco.

Top IoT Trends and Their Impact on the Internet of Everything

Cisco’s Internet of Everything | Circle Story

As I read into Cisco’s announcement, it’s my opinion that they’re beginning to produce “Cloud Training” geared for the IoT, which ultimately, I believe the CCIE Cloud will be more of an IoE certification. The new CCNA and CCNP Cloud certifications are an awesome starting point for learning how to become a connected world, and I would guess that this kicks off a much larger IoE training phenomenon of many more vendors participating in IoE training, such as Facebook (https://internet.org/about) and Google Loon (http://www.google.co.in/loon/). To assist in the IoE training concept, Cisco has partnered with a company called Rockwell Automation. You can see that they offer Cisco’s courses, as well as others. Could it be possible that Rockwell is a key player in Cisco’s future (potential) CCIE Cloud certification? I guess one day, we shall see!

CCNA Cloud at a Glance

The CCNA Cloud certification will consist of two exams. The first is available now, and is titled “Understanding Cisco Cloud Fundamentals” (210-451 CLDFND).

This course will cover the following topics and technologies:

The Understanding Cisco Cloud Fundamentals course is designed to provide students with the necessary knowledge, skills and abilities (KSA) to perform foundational tasks related to Cloud computing. It teaches the characteristics and deployment models of a Cloud network. Upon course completion, students will be able to:

• Describe common cloud characteristics
• Describe and identify the cloud service models
• Describe and compare cloud deployment models
• Identify cloud deployment decision factors
• Identify and illustrate key features of UCS
• Define server virtualization

The second appears to be announced in July 2015 and is titled “Introducing Cisco Cloud Administration” (210-455 CLDADM).

Due to the course not yet being available, I was not able to locate any of the course topics.

CCNP Cloud at a Glance

The CCNP Cloud will consist of four exams. The four exams are as follows:

• Implementing and Troubleshooting the Cisco Cloud Infrastructure (300-CLDINF)
• Designing the Cisco Cloud (300-505 CLDDES)
• Automating the Cisco Enterprise Cloud (300-506 CLDAUT)
• Building the Cisco Cloud with Application Centric Infrastructure (CLDDACI)

Currently there is no information pertaining to these exam topics, and Cisco notes that it should be available in August 2015.

Lastly, I’m also going to list a few additional links that really help explain where Cisco and the future of networking is headed.

• Tomorrow Starts Here
• The Internet of Everything Connects Shoppers
• The Internet of Everything Improves Efficiency in Operations
• The Internet of Everything Transforms Hamburg into a Smart Connected City
• Internet of Everything :: IndustrialInternetNow.com
• ATT :: Internet of Things
• Gartner :: Internet of Things Research
• Gartner Says Personal Worlds and the IoE are Colliding to Create New Markets
• Wiki :: Internet of Things
• Cisco Blog :: How the IoE Will Change the World

So in summary, this is clearly where the IT industry is headed, as well as what should be expected within our worldwide chase for fast data and simplified communications (just to name a few). I suspect that the Cloud certifications from Cisco are going to be one of the biggest initiatives in the certification industry that we’ve seen in the past 10 years. Oh, and to answer your question before it’s asked, we WILL be all over Cisco Cloud training once the full curriculum is posted and we understand what the certifications will cover (all tests).

Thanks for reading! – Wayne

Please join us in congratulating the following iPexpert students who have passed their CCIE lab!

This Week’s CCIE Success Stories

• Ali Syed, CCIE #48998 (Data Center)
• Panayiotis Chiras, CCIE #48880 (Wireless)
• Evgeniy Petrunko, CCIE #48938 (Data Center)

We Want to Hear From You!

Have you passed your CCIE lab exam and used any of iPexpert’s self-study products, or attended a CCIE Bootcamp? If so, we’d like to add you to our CCIE Wall of Fame!

Please join us in congratulating the following iPexpert students who have passed their CCIE lab!

This Week’s CCIE Success Stories

• Luis Garcia, CCIE #49023 (Data Center)
• Hamed Zolghadri, CCIE #36789 (Data Center)

We Want to Hear From You!

Have you passed your CCIE lab exam and used any of iPexpert’s self-study products, or attended a CCIE Bootcamp? If so, we’d like to add you to our CCIE Wall of Fame!

The jabber-config.xml file is an essential piece of configuration for the Jabber client. Sure, the client has the ability to operate just fine without this file. Video calling, deskphone control, instant messaging, etc. all work flawlessly. However, if you need to add any additional options, policies, or directory integrations, the jabber-config.xml file becomes necessary. Within the realm of the CCIE Collaboration certification, we are specifically concerned about two different configurations: UDS Directory Integration and SIP URI Dialing.

User Data Service (UDS) simply put, is the name for the End User database within Cisco Unified Communications Manager (CUCM). It contains all relevant information about that user, as would any other directory. UDS, however, is not enabled by default on the Jabber client. In fact, Jabber is geared towards integration with an LDAP source “out of the box”. This means that we must instruct the Jabber client to use UDS if we would like to be able to search the CUCM database to communicate with other users. Since this will have to be done by using the jabber-config.xml file, we must first determine how to create it. Thankfully, the Cisco documentation does not disappoint in this regard. From the Product/Technology Support page (http://www.cisco.com/cisco/web/psa/default.html?mode=prod), navigate to Collaboration Endpoints → Software Clients → Jabber for Windows → Install and Upgrade Guides → Cisco Jabber for Windows 9.7 Installation and Configuration Guide → Configure Cisco Jabber → Example Configuration. At this point, a wonderful example for the jabber-config.xml file format is displayed.

You can easily copy and paste the format of the configuration file to Notepad++ (which is available to you in the lab) and begin adding/removing the proper XML tags. But what are the proper tags? To find out, we must navigate to a different section of this document, called “Integrate with Directory Sources”. Once there, click the “UDS Integration” link to reveal the necessary configuration.

As you can see, this is a pretty self-contained configuration. The proper XML tags are available for use within our custom jabber-config.xml file. The first tag, “DirectoryServerType” simply specifies the type of integration that we should be using, which of course, is UDS. Believe or not, the other two XML tags, “UdsServer” and “UdsPhotoUriWithToken” are not necessary unless there are specific requirements. At this point, the jabber-config.xml file can be built to allow for UDS integration.

Next, to allow for SIP URI Dialing to take place, we must search for a parameter to satisfy the requirement. Within the “Configure Cisco Jabber” section of the same document, click the “Common Policies” link to reveal a list of available policies. In this list, you will find a parameter called “EnableSIPURIDialling”, which has a value of “true” or “false”. This parameter can be used within the “Policies” section of the jabber-config.xml file to enable URI dialing. The file can now be configured as shown below.

The last step is uploading the file, named exactly as jabber-config.xml, to the CUCM TFTP servers that are assigned to provide configuration files to the Jabber client. Remember to restart the Cisco TFTP Service in Cisco Unified Serviceability! With that, the Jabber client will now have ability to search the CUCM directory and dial Directory URIs accessible by the configured dial plan.

I hope this blog was helpful for you in your CCIE Collaboration preparation! As always, give us a call and speak with a training adviser if you’re interested in purchasing our workbooks, attending a class, or have any questions regarding your preparation. Thanks again for reading and good luck in your preparation!

I had the pleasure of attending the CCIE Wireless tectorial at Cisco Live in San Diego this year. One of the topics discussed was the new diagnostic section of the lab. Jerome Henry gave us insights into what the section would look like as well as some examples of the types of things that we can expect in the section. I wanted to pass on some of that information along with a few insights about how you should prepare for this section since it’s quite different than what we’ve seen before in the lab.

What is the Diagnostic section?

Starting in v3 of the wireless lab, each lab will begin with a 1-hour diagnostic section. This section has no configuration task associated with it. Instead, you will be playing the role of TAC, or a senior level engineer. Your job is to look at information gathered from a client by a first-level engineer and analyze it so that you can answer questions related to troubleshooting an issue.

It sounds like you can expect maybe 3-4 separate troubleshooting scenarios with approximately 10 questions to answer across those 3-4 scenarios. So that means there will probably be 2-4 questions per scenario. All questions will have set answers to choose from (multiple choice style).

There will be a minimum score that you must achieve in the diagnostic section in order to pass the lab. If you do fail the diagnostic section, you still get to proceed to the main lab configuration section. You won’t even know if you passed or failed the diagnostic section until you receive your overall lab results.

We were told that if you finish the diagnostic section before the 1-hour time limit, you might be able to start the configuration section early (this is still to be determined). But you will definitely NOT gain any extra time to be used in the configuration section. You always have 7 hours for the configuration section. So there is no incentive to ending the diagnostic section early other than being able to finish your day sooner.

What can you expect to see in the Diagnostic section?

Each troubleshooting scenario will have a number of separate documents to view. There will typically be an email chain between the client and the first-level engineer that describes the issue along with some general information gathered by the engineer. Then there will be also documents that contain things like running configs of devices, show/debug command outputs, a basic topology diagram, and maybe something like a packet capture. Somewhere in those documents will be the information needed to answer the questions.

What types of questions will there be?

While there could be many different types of questions, here are some examples of questions that you may see.

• Which device is causing the issue?
• How could you solve the issue?
• Which command on which device was the most helpful in identifying the cause of the issue?

The way that they did the questions definitely makes up for the inherent increased simplicity of the multiple-choice format. For instance, maybe you run into a scenario that you aren’t 100% sure about. But thanks to the process of elimination, you might be able to answer one of the questions correctly. For instance, maybe you could figure out the solution to the issue. But unless you really understand what’s happening, it’s very unlikely that you could use the same process to pick which command on which device gave the primary clue. So it’s not something that you can fake your way through.

How can you prepare for this section?

Our classic methods of preparing for the lab will definitely still apply to the diagnostic section. Troubleshooting has been built into the lab in previous versions. So we’ve needed to be able to diagnose and fix issues in the past. What makes this different is that you are being forced into a particular method of troubleshooting that may not be your standard method. So your natural troubleshooting methodology may not be sufficient to answer the diagnostic questions. In other words, just because you could solve the problem your way doesn’t mean that you’ll be able to solve the problem their way.

For example, I personally never relied much on debugging or looking at the CLI running configuration of WLCs. I was always able to troubleshoot fairly effectively using other methods. But in the diagnostic section, it seems to favor CLI-based output. So you will be presented with running configurations (of all different types of devices), show command outputs, and debugging command outputs. If you aren’t used to looking at those, that can be a problem.

What this means from a preparation standpoint is that you must force yourself to become much more familiar with CLI-based configurations and common debugging outputs. It doesn’t means that you necessarily need to learn how to configure everything through the CLI from memory. But you at least must be able to comfortably interpret CLI-based configurations. You need to know what any given thing should look like in the CLI so that you can spot mistakes, which could include wrong lines of configuration or even missing lines of configuration.

You will need to practice using debugs of common actions like client authentications and AP joins. Know what things should look like when they work correctly as well as what they look like when they don’t. This is going to have to be intentional. You may need to learn more about how these different processes work so that you actually understand what you are seeing in the debug.

Thoughts about the Diagnostic section

I think that the inclusion of the diagnostic section was a good move on Cisco’s part. It sounds like every track will eventually have it. It’s probably one of the better methods to try and curb the effects of brain dumps. While the configuration section will be slow to change (which brain dumps use to their advantage), the diagnostic section can be developed at a much faster pace. The section is long enough and has enough questions to be a fair gauge of skill. Also, the use of multiple choice rather than essay takes any human element out of the grading. So there is no subjectivity in the grading.

This section is also going to force candidates to expand their troubleshooting arsenal beyond what they may have developed without it. While that will increase the learning curve and require more time to prepare, in the end we’ll have much more effective and knowledgeable engineers as a result. I am looking forward to being pushed out of my comfort zone as I work on creating materials to help students tackle this section.

Please join us in congratulating the following iPexpert students who have passed their CCIE lab!

This Week’s CCIE Success Stories

• Adrian McCaskill, CCIE #48071 (Wireless)
• Hugo Dantas, CCIE #49174 (Collaboration)
• Jocelyn Hamryszak, CCIE #49036 (Collaboration)
• Ehsan Emad, CCIE #28551 (Data Center)
• Jeremy Porter, CCIE #16273 (Wireless)
• Filipe Gaspar, CCIE #48503 (Wireless)

We Want to Hear From You!

Have you passed your CCIE lab exam and used any of iPexpert’s self-study products, or attended a CCIE Bootcamp? If so, we’d like to add you to our CCIE Wall of Fame!

Router IP Traffic Export (RITE), or simply IP Traffic Export, is a method of copying traffic directly from a router to an external device, such as a Protocol Analyzer or an Intrusion Detection System (IDS). This feature can be used to replace SPAN/RSPAN configurations deployed on L2 ports/VLANs. Two main benefits of RITE is, first, the ability to duplicate the traffic received on a WAN interface, such as Serial port, and second, granularity of our configuration – we can be very selective in what traffic will finally get copied from the network.

Before we discuss the configuration of RITE, just few words about limitations of this feature :

1. The device receiving the exported traffic must be in the same L2 network as the router’s interface (e.g. must be directly connected). This interface is known as “outgoing” in the RITE’s terminology
2. This (outgoing) interface must be an Ethernet port. Incoming interface(s) (where the traffic is received and optionally sent through) can be anything (e.g. WAN/LAN)
3. Traffic generated by the router configured for RITE cannot be exported

A sample topology for RITE may look like one below. Our monitoring station (PC) is directly connected to R2’s RITE outgoing interface, Gig0/0 :

Now when we know what RITE can do for us, let’s take a look at a configuration example. I will be using the topology above as a reference.

The configuration of IP Traffic Export is very straightforward – it is all about creating a Profile and applying it to a monitored interface. In our case, we will configure two different profiles to show you how certain settings affect the traffic which is copied.

Let’s say that our first goal is to copy the traffic sent from or destined to R5. We can easily accomplish that by configuring a RITE Profile and applying it to interface S0/2/0 (so this will be our “incoming” interface) :

By default only traffic incoming to the port gets copied (don’t confuse this with an “incoming interface”, which is what we monitor). This is why I specified the “bidirectional” option – it causes the router to export both, incoming and outgoing traffic on the monitored interface. Next step was to specify what is our “outgoing” interface (“interface”) – again, one through which the copied packets will be sent. This is obviously G0/0, the port connected to our PC (with Network Analyzer turned on), which MAC address is 000c.2905.c1c6 (“mac-address”). Finally I activated the Profile by applying it to the incoming interface, S0/2/0.

Let’s test this configuration :

Here are the results (Telnet, then ICMP) :

Note that not only the traffic from R5 was exported, but also replies from R2 – it is because we configured the “bidirectional” keyword in the Profile.

Next, let’s say we are only interested in traffic coming TO the G0/1 port – we only want to copy the traffic coming from R2. In addition, we will say we only want to copy ICMP packets, just one every 2 (50% of the traffic received on the port). Here’s how we can do that :

OK, what changes here? We did not use the “bidirectional” keyword, so we are only looking at the incoming packets. The “incoming access-list” command was used to tell the router what do we want to copy (specifically the ACL referenced in this command), and “incoming sample one-in-every” says how many packets we want to export (one in two here).

The results :

In addition, we are sending just four ICMP Echos :

We see only two packets got copied, as expected, and no replies were received :

Please join us in congratulating the following iPexpert students who have passed their CCIE lab!

This Week’s CCIE Success Stories

• Victor Yin, CCIE #49618 (Collaboration)
• Christopher Bacon, CCIE #49617 (Route/Switch)
• Majed Al-Logman, CCIE #49639 (Wireless)

We Want to Hear From You!

Have you passed your CCIE lab exam and used any of iPexpert’s self-study products, or attended a CCIE Bootcamp? If so, we’d like to add you to our CCIE Wall of Fame!

Please join us in congratulating the following iPexpert students who have passed their CCIE lab!

This Week’s CCIE Success Stories

• Jaffar Nassiry, CCIE #49339 (Wireless)
• John Meachum, CCIE #49353 (Wireless)
• James Wheat, CCIE #49400 (Wireless)
• Brian McPhail, CCIE #49246 (Route/Switch)
• Abdelfattah Ali, CCIE #48195 (Route/Switch)
• Daniel Lucas, CCIE #49361 (Route/Switch)
• Ding So, CCIE #40685 (Wireless)
• Leonardo Henrique, CCIE #49208 (Collaboration)
• Thomas Bryant, CCIE #49458 (Collaboration)
• Ramcharan Arya, CCIE #28926 (Data Center)
• Muhammad Adil, CCIE #49504 (Data Center)

This Week’s Testimonials

Ramcharan Arya CCIE #28926 (Voice/R&S/DC)
I would like to say “Thank you”, I have passed CCIE Data Center Lab exam last week. Your training material is outstanding for beginners to become an expert in DC technology. Your workbook and proctor lab racks helps in gaining hands-on experience and prepare for lab exam.

Thomas Bryant CCIE #49458 (Collaboration)
Studying for the Collaboration Lab takes years of experience among actual lab study. As most voice focused engineers know, time is extremely precious and dedicating study time is not exactly easy. I took the 10 day boot camp near Chicago to solidify my knowledge and ensure I knew all of the technologies on the blueprint backwards and forwards before my attempt. I can safely say that it was the best 10 days I have ever spent studying during my preparation for the lab. Andy definitely knows the technology and has great method of conveying that knowledge to students, the videos and on site instruction were extremely helpful in filling in some of the gaps on areas most voice engineers do not implement on a daily basis.  Couple that with the tons of practice lab material and any focused engineer will have great success in the lab. 

Daniel Lucas CCIE #49361 (Routing and Switching)
I literally could not passed without the materials, and knowledge from the instructors at iPexpert. I contribute a large part of my success to the many hours the instructors have spent in creating, and ensuring the workbooks are able to prepare students for the lab.

We Want to Hear From You!

Have you passed your CCIE lab exam and used any of iPexpert’s self-study products, or attended a CCIE Bootcamp? If so, we’d like to add you to our CCIE Wall of Fame!

MERRILLVILLE, Ind. – Networking engineers in all industrial sectors who are preparing to take the Cisco Certified Internetwork Expert (CCIE) exam may benefit from a Purdue Research Park tenant that offers products and monthly preparation courses.

iPexpert Inc. is a tenant in the Purdue Research Park of Northwest Indiana that helps its clients prepare to take the CCIE Collaboration certification exam. Andy Vassar, senior technical instructor, said the prep courses are suitable for all networking professionals.

“Today, almost every company will have a networking engineer design and implement computer networks, and almost everyone runs Cisco Systems equipment in their network,” he said. “A CCIE certification is the most respected, sought-after certification in networking and there are many opportunities to use it. Those who earn it are considered the top experts in their profession.”

CCIE certification is available on several subjects including Routing and Switching, Data Center, Wireless and Security. Vassar said iPexpert classes at the Purdue Research Park of Northwest Indiana prepare attendees for the CCIE Collaboration certification, which covers communication via telephone, instant messenger and video.

“CCIE certification exams have two parts: passing the two-hour written test makes you eligible to take the eight-hour lab exam,” he said. “We offer two classes per month, including the lecture-driven Lab Preparation Boot Camp that covers the technology on a topic-by-topic basis. The following week is the One-Week Lab Experience during which an attendee has the opportunity to take two full-scale eight-hour mock lab exams. The Lab Experience class provides them a good perspective of what the real lab will be like.”

Vassar said most students take the two classes in tandem, one week following the other.

“The next class sessions are Aug. 10 for the Lab Preparation Boot Camp and Aug. 17 through 21 for the One-Week Lab Experience,” he said. “Next month the courses are Sept. 14 and Sept. 21-25. People can buy admission to the class through the online checkout system at www.ipexpert.com or by calling training advisers at 810-326-1444.”

Vassar said iPexpert’s sole focus is to help attendees prepare for CCIE certification exams.

“All of our instructors are on the same page, aiming for the same goal: we want attendees to pass these exams,” he said. “In addition to the courses that the instructors teach, iPexpert has created workbooks and video on demand solutions so that attendees can pass the lab exam strictly on their own documentation.”

About iPexpert Inc.

Launched in 2001, iPexpert Inc. is a 3-time Inc. 5000 honoree, as well as a 3-time Corp! award winner. We are committed to the highest quality training, and are passionate about our clients’ satisfaction and success. Our goal is to ensure the complete satisfaction of each of our customers. We have helped more than 4,300 CCIEs achieve their own success. We are only as successful as you are.

Purdue Research Park contact: Steve Martin, 765-588-3342, sgmartin@prf.org

Source: Andy Vassar, 219-776-4015, avassar@ipexpert.com

Please join us in congratulating the following iPexpert students who have passed their CCIE lab!

This Week’s CCIE Success Stories

• Alemneh Nigussi, CCIE #28272 (Data Center)
  (He’s a 3x CCIE! He also has Voice and Routing/Switching.)
• K.G. Pramod, CCIE #49662 (Data Center)
• Mohamed Ahmed Ali, CCIE #34760 (Security)
• Muhammad Adil, CCIE #49605 (Data Center)

We Want to Hear From You!

Have you passed your CCIE lab exam and used any of iPexpert’s self-study products, or attended a CCIE Bootcamp? If so, we’d like to add you to our CCIE Wall of Fame!

CCIE Candidates! We’re excited to announce a few updates to our CCIE Data Center, R&S, and Collaboration product portfolios!

Data Center:

1) Our Volume 1 WB (and DSG) has been overhauled. Jason now has all labs that can be done on our Technology Racks covered in this book. It’s very thorough and covers everything you’ll see on the lab from a technology basis.

2) Our Volume 2 WB (and DSG) has had a MAJOR overhaul. Quite a few updates, changes and we’re happy that all 5 labs are very up-to-date. This workbook consists of 5 Mock Labs that must be done on our Full-Scale Mock Lab Racks – which have been booked solid for several months.

3) We have just finished the addition of 5 more Full-Scale Mock Lab racks! First, they’ve cost us a fortune, but our commitment to you is to have the resources you need to prepare for your lab. There are timeslots ready and open NOW if you need time on these Full-Scale Mock Lab racks.

Routing & Switching:

1) JP has finalized an updated R&S V5 Volume 1 WB (and DSG), and it’s posted and available now.

2) We anticipate having our R&S V5 Volume 2 WB (and DSG) up within the next few days. We will announce when it’s been uploaded.

Collaboration:

1) Andy has been busy, and made some updates to our CCIE Collaboration Volume 1 WB (and DSG), and it’s posted now and available for your download.

2) He’s also wrapped up all final touches on our CCIE Collaboration Volume 2 WB (and DSG) and that’s also ready for immediate download.

It’s also important to mention that if you’re not an iPeverything™ subscriber with access to these materials, you can find track-specific bundles here.

If you need assistance locating these products or would like additional details, please feel free to reach out to a Training Advisor at sales@ipexpert.com or via the live chat applet on our website.

Stay tuned for more updates as we continue to add to our portfolio in the coming weeks and months!

Codec negotiation is a topic that gets glossed over without much consideration in the studies of most students. There’s really not much to it, right? All we have to do is slap a couple of Regions on two different system endpoints and…voila, we have successfully negotiated a codec! Can it be that simple? Like most answers to rhetorical questions in the tech world, “It depends.” A simplistic approach like the one just described above is a great place to start, but it doesn’t take into account key call flow elements such as early/delayed offer, Audio Codec Preference Lists, or call routing across CUBE, CUCM or CUCME. What if the codec should be different based on the originator of the call? These are all examples of key issues involving codec negotiation that we must wrap our mind around if we are to be successful in our CCIE Collaboration endeavors.

Let’s examine the requirement of routing a call between a 9971 Phone registered to the HQ CUCM cluster (HQ Phone 1) and a 7965 Phone registered to the SB CUCM cluster (SB Phone 1). In this example, consider that a SIP Trunk is configured directly between clusters in order to route calls to each phone. Also, assume that Regions are created for the HQ phone (HQ_PHONE_REG), the SIP trunk at HQ (HQ_SIP_REG), the SIP trunk at SB (SB_SIP_REG), and the SB phone (SB_PHONE_REG).

For the first exercise, let’s configure the call flow to use the G.729 codec. In this example, assume that the Region relationship between HQ_PHONE_REG and SB_SIP_REG must be set to 64 kbps (G.722, G.711). Assume the same between SB_PHONE_REG and SB_SIP_REG.

In this configuration, the only possible way to force the negotiation of the G.729 codec is to use an Audio Codec Preference List. This list allows us to prioritize the available codecs that will be used for negotiation. In order of priority, the possible codecs that have the ability to negotiate between the 9971 and 7965 phones using 64 kbps of bandwidth are G.722, G.711, iLBC, and G.729. This means that we must move G.729 ahead of all other options in order to successfully select that codec. The screenshot below lists the possible preferred codecs at the top of the list for brevity.

We must now simply assign the newly created Audio Codec Preference List to the existing Region Relationship and we are in business!

A quick test call between phones proves that the negotiation is successful.

We configured it correctly, which is great news, but how does it really work? Well, since we are signaling over a SIP trunk, which uses Delayed Offer (DO) by default, the media capabilities negotiation started with the HQ CUCM cluster’s reception of the “200 OK” message (containing the SDP) from the SB CUCM cluster. As you can see below, the G.729 codec is given first priority, but other codecs are still available for negotiation.

It’s not until the HQ CUCM cluster sends the “ACK” message to select its first priority codec that the negotiation process is complete and the G.729 codec is agreed upon.

How does this same call flow behave for an Early Offer (EO) call? To test it out, we must configure a SIP Profile on both the HQ and SB CUCM clusters to enable the “Early Offer support for voice and video calls (insert MTP if needed)” setting and assign it to the existing SIP trunk.

After another test call between HQ Phone 1 and SB Phone 1, we can see that the audio codec is still using G.729, as expected. This time, the initial “INVITE” message from the HQ CUCM cluster contains the SDP in order to negotiate the codecs ahead of time. Notice once again that G.729 is atop the list of available codecs.

This time, the “200 OK” message from SB is all that is needed to determine the codec for the session. Since it also prefers G.729, the codec is negotiated as such.

Next, let’s consider a scenario where we would like to negotiate the G.729 codec for calls from HQ Phone 1 to SB Phone 1, just as before. However, for calls in the reverse direction, we should utilize the iLBC codec. In this case, we really have to think about how codec negotiation works to understand the configuration. As we have observed, the originator of an EO call sends a prioritized list of supported codecs (G.729, G.722, G.711, and iLBC) in the “INVITE” message. The receiver responds (“200 OK”) with whatever codec is highest on its own prioritized list, as long as it is supported by the originating endpoint. The same is true for DO calls, except in the opposite direction. The receiver sends the initial prioritized list (“200 OK”), while the originator selects the desired codec based on its own priority (“ACK”). In both of the above cases, the first priority codecs were the same (G.729). But what happens if they are different?

Consider the case where the SB CUCM cluster has updated the Region relationship between the SB_PHONE_REG and SB_SIP_REG to prefer the iLBC codec using an Audio Codec Preference List, as shown below.

In this case, for EO calls originating from HQ, the audio codec is negotiated as iLBC. As you can see from the SDP in the initial “INVITE” message, the G.729 codec is still the preferred codec for the HQ CUCM cluster.

However, the codec is actually selected based on the preferences of the SB CUCM cluster, since it has the benefit of selecting from the available codecs in the list.

In the opposite direction, with the EO call originating from SB, the G.729 codec is negotiated. Due to the Audio Codec Preference List, the SB CUCM cluster prefers the iLBC codec as per the initial “INVITE”.

However, the HQ CUCM cluster selects the G.729 codec due to its locally configured preferences.

For DO calls, the exact opposite happens. Calls originating from HQ use the G.729 codec, due to the response in the “ACK” message, and calls originating from SB use the iLBC codec for the same reason.

The last behavior that I’d like to discuss is simply configuring the system to accept the codec preferences of any received offers, regardless of whether that offer comes in an “INVITE”, “200 OK”, or “ACK” message. The setting is called “Accept Audio Codec Preferences in Received Offer” and can be configured within a SIP Profile and assigned to a SIP trunk.

If enabled on both CUCM clusters, for a DO call, this essentially puts the onus on the remote end to select the desired codec. For EO calls, the originator decides what codec should be used. In this example, calls from HQ Phone 1 to SB Phone 1 now use the iLBC codec while calls from SB Phone 1 to HQ Phone 1 use the G.729 codec.

I hope this blog was helpful for you in your CCIE Collaboration preparation. As always, give us a call and speak with a training adviser if you’re interested in purchasing our workbooks, attending a class, or have any questions regarding your preparation. Thanks again for reading and good luck in your preparation!

Please join us in congratulating the following iPexpert students who have passed their CCIE lab!

This Week’s CCIE Success Stories

• Mohan Mayilraj, CCIE #49942 (Data Center)
• Zahari Georgiev, CCIE #49996 (Wireless)
• Mohamed Enassiri, CCIE #46237 (Collaboration)

This Week’s Testimonial

Mohan Mayilraj CCIE #49942 (Data Center)
Thank you very much for help reach my goal. Your video and training and Boot camp helped lot and your proctor lab is gem and very much useful and I used your lab most of time and workbook.This is my first attempt on CCIE. I got through it .

We Want to Hear From You!

Have you passed your CCIE lab exam and used any of iPexpert’s self-study products, or attended a CCIE Bootcamp? If so, we’d like to add you to our CCIE Wall of Fame!

Hi everyone, JP here. You know as CCIE candidates, we are faced with one of the most difficult, and grueling, exams the networking world has to offer – the CCIE lab exam. As you may or may not be aware, Frame-Relay was replaced with L3VPN and DMVPN in the R&S Version 5 blueprint update. This means not only will we need to understand our IGP’s, MPLS, and VRF Lite, but we will need to fully understand how to configure MPBGP in order to transport our VPN labels and prefixes across the service provider’s network.

Using a topology from one of our mock labs, let’s have a look into the configuration of MP-BGP and make sure we understand it. Preview the diagram in HD here.

In a Layer 3 VPN we are driven by the need to advertise customer prefixes across a service provider network, while keeping these customers isolated from one another. To do this using L3VPN, we need to carry more than just the IPv4 unicast address, which is all standard BGP is capable of. Additional information like the MPLS label, VPN label, and route-distinguisher need to be carried from one point of the network to the other. Let’s imagine for a second that we have 2 customers. In our above diagram they are Brand Office 1 and Acquisition 2. Let’s say that both of these customers use the 10.10.1.0/24 address space. How do we distinguish between these 2 different customers when these routes arrive on our PE? The route-distinguisher is the answer to that question.

The RD is an extended BGP community that creates a unique address by prepending a unique 8-octet field to our existing 4-octet IP address. This new 8-byte field will consist of a 2-byte type field followed by a 6-byte value field. For example, our 10.10.1.0/24 network might become 150:150:10.10.1.0 for the Branch Office, while Acquisition 2 might become 250:250:10.10.1.0. Now, when both customer routes reach our PE, while they are using same IPv4 address space, the addresses are globally unique per customer. It is important to understand that the RD is only used to make our addresses unique; it does not control any route redistribution. For this, we need what is known as the RT or Route-Target. The RT is used to identify which prefixes we want to import into our VRF. When we create a VRF we are going to give it two values. The RT-Import is going to look for any inbound prefixes with that route-target and then install them into our BGP VRF. The RT-Export is going to use this value for any prefix leaving our BGP VRF. The MPBGP VPN is then going to carry these prefixes and values from one PE to the other. Let’s just have a look.

So we have created a VRF using the values above. We are going to receive any VRF prefixes that were exported with the value of 150:150. Likewise, we are going to send our prefixes with a value of 150:150. Now how do we assign and carry customer routes across a provider network with this new information added to the IP header? Classic BGP only supports standard IPv4 unicast addresses, so there is no way it can handle this new 150:150:10.10.1.0/24 prefix, because it is no longer a IPv4 prefix. If we tried to use BGP it just wouldn’t work because it would ignore the additional bytes. This is where MP-BGP, or Multi-Protocol BGP comes in. MP-BGP gives us the ability to carry multiple different types of addresses simultaneously through what are called address-families. In this case we are interested specifically in the VPNv4 address-family, as well as the IPv4 VRF address-family. These new address-families between our PE routers are going to carry and assign information, such as the RD, that we need to make this work. Keep in mind that in addition to our RD and RT we are going to have our transport label, used to reach the next PE router, and the VPN label which will tell the PE which customer, or CE, the routes belong to.

Now just a quick note here. Our network is already setup with LDP peering’s between all our required P and PE routers, so we aren’t going to address the MPLS requirements. Our customer devices are already setup with BGP facing our PE with redistribution so we aren’t going to need to take care of anything there, but let’s have a look at that configuration.

R11 has a standard BGP configuration and mutual redistribution with OSPF. OSPF is being used as our IGP facing into our network. BGP is the EGP being used to advertise our prefixes out to our PE. That is the reason for the mutual redistribution. As we receive routes from our PE we need to inject them into OSPF, likewise as we receive OSPF prefixes from our internal neighbors, we need to inject them in BGP. Notice when we redistribute from OSPF into BGP we make sure to match type 1 and type 2 prefixes. By default, BGP is only going to redistribute intra area routes from OSPF. This is why we need to make it a habit of ensuring we match all types.

As we go through this configuration it is important to note that we only perform these steps on the PE routers. The rest of the provider cloud does not get any of this special treatment. Now, by default BGP will automatically enable the transport of IPv4 unicast addresses. When dealing with L3VPN and MPBGP I recommended that we disable this to give ourselves a little bit more control of IPv4 peering’s to avoid problems. Let’s go ahead and configure standard BGP with ipv4 unicast disabled.

At this point we have our standard BGP configured, but we have no peering’s established. This is due to the fact that we have disabled the default ipv4-unicast setting within BGP. We need to tell BGP how we want it to peer with the neighbor we have configured. So now we jump into creating our first address-family. If we issue the address-family command followed by the “?” we can see our available options:

For this particular piece of our configuration we are going to need the IPv4 option. As we create our address-family, I usually make it a habit of adding the send-community extended command. This is habit for me and is going to allow me to send any extended community values I want to send later on down the road. It is not required for this particular implementation.

Good, we have our IPv4 unicast peering up and running. Now take a note that we are peering with the loopback addresses. We already have full reachability due to OSPF being configured in our provider cloud for LDP. Up to this point we have not done anything out of the ordinary of what we do in a standard BGP configuration, except for the creation of the address-family to support ipv4 unicast traffic. Any BGP peer not participating in this PE-to-PE VPN will now be configured under this ipv4 address-family. Peers that are configured under this address family will have prefixes added to the global routing table. For example, if we created a loopback interface and R2 and advertised it into BGP we would see it in the global routing table of ISP3. Let’s have a look at that.

As we expected, we see this 2.2.2.2/32 route in our global routing table on ISP3. So everything is working perfect up to this point.

Our next step is to create the VPNv4 address-family for the use of carrying our customer prefixes across the network to the other PE. We do this the same way we created our last address-family except we use the VPNv4 key word instead of IPv4. Just as with our IPv4 address family, we need to activate our neighbor. Notice the additional send-community extended command. This option enables us to send the extended communities to our neighbor. If this option is not added to our configuration we will not have the capability to carry the attributes we discussed earlier when configuring our VRF.

Once we enable our VPNv4 address family our standard peering is reset. BGP tells us it is because the capabilities have changed. Nothing to be alarmed about, this is completely normal. The one thing we need to be aware of however is that it will reset our peering. If we do this in a production environment we might want to do it off hours, even though it’s only for a brief moment. I want to take a moment to introduce you to a new command that we are going to need to be aware of. We now have 2 different types of BGP peering’s between our PE routers. We have our standard IPv4 unicast peering and our VPNv4 peering. Let’s verify that both are up and running, and take a mental note to the different commands required to perform this action.

IPv4 Unicast Peering:

VPNv4 Unicast Peering:

Lastly we need to configure our VRF address-family with our CE routers. This is how our PE routers will actually receive the internal prefixes from the customer. Remember that our VRF has already been configured and placed on the proper interfaces. We already have LDP configured and have our peering’s. For example, have a look at our configuration on ISP3:

Once we configure this VRF address family, our MP-BGP is going to come together with our MPLS and give us some magic. We have already applied our VRF’s to the appropriate interfaces using the ip vrf forwarding command. As shown above we have our LDP neighbors. In theory, this is all we should need to do in order to route between our 2 offices over our MPLS VPN.

As soon as we activate our PE neighbor we instantly see our peering come up for the VRF iPexpert. Now remember the nature of a VRF. At this point our PE routers now have 2 routing tables, as well as 2 BGP tables. One is global to the PE, as seen below. Notice we have no prefixes to our customers.

Now if we look at our L3VPN output, we are going to see something much different.

We start out by issuing the same ip route command we would always use however, now we append what vrf RIB we want to view.

Ok, we are receiving our prefixes from the other PE and they are being installed into our vrf RIB for iPexpert. Notice we have the 172.16.70.0 prefixes and we also have the 172.16.8.8/32 prefix, which is the loopback 0 interface of R8 in our Acquisition office. Now let’s move into taking a look at our BGP table for our VPN.

Here we can see all of our prefixes coming into the PE from both directions. We see our 172.16.60.0 prefixes coming from our Branch Office. Remember this is being redistributed from OSPF running as the IGP in the office. We also see the prefixes coming from the other PE, which is R2. BGP even is nice enough to tell us what our RD is, before giving us any of our networks.

Finally, let’s verify our reachability and make sure that we did our job properly. When it comes time to take the lab, verification is going to be something that makes you or breaks you. We absolutely must verify that we have done our job correctly.

From our R13 customer device inside of our Branch Office, we are able to successfully reach the loopback 0 interface of R8, which is the CE router in the Acquisition 2 office. This is exactly what we expected.

I hope you enjoyed reading, keep studying!

J.P. Cedeno
Routing & Switching Instructor

Please join us in congratulating the following iPexpert students who have passed their CCIE lab!

This Week’s CCIE Success Stories

• Eric Williamson, CCIE #49880 (Collaboration)
• Paul Raffles, CCIE #49941 (Data Center)
• Fabien Roulette, CCIE #49854 (Collaboration)

This Week’s Testimonial

Eric Williamson CCIE #49880 (Collaboration)
I would absolutely recommend IPexpert and Andy Vassar for CCIE Collaboration training. One of my favorite parts of the new blueprint change was that the rack rentals went to four hours and the labs increased but they were able to be done in smaller sections. As a person who travels on the road almost every week it was important to have a phone control/view option when coming in on a software VPN. This helped me to keep on track. Thank you Andy for helping me in so many instances, I will be eternally grateful.

Fabien Roulette CCIE #49854 (Collaboration)
Thank you very much for the quality of your books and pods on proctorlabs

We Want to Hear From You!

Have you passed your CCIE lab exam and used any of iPexpert’s self-study products, or attended a CCIE Bootcamp? If so, we’d like to add you to our CCIE Wall of Fame!

Please join us in congratulating the following iPexpert students who have passed their CCIE lab!

This Week’s CCIE Success Stories

• Hesham Abdelkereem, CCIE #40790 (Dual, Wireless & Collaboration)
• Nadeem Akbar, CCIE #11610 (Wireless)
• Hugo Dantas, CCIE #49174 (Collaboration)

This Week’s Testimonial

Hesham Abdelkereem CCIE #40790 (Wireless & Collaboration)
The product that helped me was Video on Demand.

Nadeem Akbar CCIE #411610 (Wireless)
The CCIE Wireless Bootcamp helped me pass the exam.

We Want to Hear From You!

Have you passed your CCIE lab exam and used any of iPexpert’s self-study products, or attended a CCIE Bootcamp? If so, we’d like to add you to our CCIE Wall of Fame!

Please join us in congratulating the following iPexpert students who have passed their CCIE lab!

This Week’s CCIE Success Stories

• Ajay Edara, CCIE #36424 (R&S & Wireless)
• Shiv Shankar, CCIE #43675 (Routing & Switching)
• Andy Harrison, CCIE #50052 (Routing & Switching)
• Mike Burk, CCIE #50207 (Wireless)
• Tony Ilorah, CCIE #50210 (Security)
• Ahmad Nawid Azizi, CCIE #50254 (Routing & Switching)

We Want to Hear From You!

Have you passed your CCIE lab exam and used any of iPexpert’s self-study products, or attended a CCIE Bootcamp? If so, we’d like to add you to our CCIE Wall of Fame!