After many painstaking hours of effort and dedication, finally you’ve learned how to find almost every topic in Cisco’s IOS Security Configuration Guide. Congratulations, someone at Cisco thought that the CCIE Security was already too easy (even with a major blueprint revision) so just to make it a bit more fun they broke the IOS 12.4T Security Configuration Guide into 4 separate guides recently, which means we’ll have to go and learn what was added where.

If you go to the IOS 12.4T Configuration Guide home page you’ll notice that there are now four separate documents:

IOS Security Configuration Guide: Secure Connectivity

IOS Security Configuration Guide: Securing the Control Plane

IOS Security Configuration Guide: Securing the Data Plane

IOS Security Configuration Guide: Securing User Services

Each of these documents has been designed to closely group similar technologies so finding most of the information should be pretty easy.

Read Full Entry »

One of the functions in IOS 12.4T is support for high availability NAT, to enable a pair of HSRP routers both running NAT to maintain state information and share it about both static and dynamic NAT translations. This means that should the active HSRP router fail, the standby router can continue to allow existing NAT sessions to succeed by already having the translation information passed to it by the active HSRP router.

What I’m going to show below is a simple setup for this scenario. Full configuration for each router (and the Catalyst switch) is available for download at the end of the post (so you can test it yourself).

I’m going to use four routers: R6, R7, R8 and R9. R7 and R8 are configured as an HSRP pair with sub-interfaces in VLAN 6 (inside) and VLAN 9 (outside). R6 is a member of VLAN 6 and R9 is a member of VLAN 9. R7 and R8 will be configured with HSRP on the inside interfaces. VLAN 6 uses the 10.0.0.0/24 network and VLAN 9 uses the 9.0.0.0/24 network.

In this example I’m configuring HSRP with R7 as the active router, by using a higher priority on R7 than R8. Additionally, I define the standby group name “HSRP” so that it can be referenced by the stateful NAT process in the “redundancy” command.

What I want to achieve is for all telnet traffic from the inside to the outside network to be matched against ACL 101 (referenced in route-map “SNAT”) and translated to an address in the NAT pool “SNATp”.

On R7, we configure HSRP and SNAT as follows:

interface FastEthernet0/1.6
 encapsulation dot1Q 6
 ip address 10.0.0.7 255.255.255.0
 ip nat inside
 standby 1 ip 10.0.0.254
 standby 1 priority 110
 standby 1 preempt
 standby 1 name HSRP

 

interface FastEthernet0/1.9
 encapsulation dot1Q 9
 ip address 9.0.0.7 255.255.255.0
 ip nat outside

 

ip nat Stateful id 1
 redundancy HSRP
 mapping-id 10
 protocol   udp

 

ip nat pool SNATp 9.0.0.20 9.0.0.29 prefix-length 24
 ip nat inside source route-map SNAT pool SNATp mapping-id 10

 

access-list 101 permit tcp any any eq telnet
 route-map SNAT permit 10
 match ip address 101

On R8, we configure HSRP and SNAT as follows:

interface FastEthernet0/1.6
 encapsulation dot1Q 6
 ip address 10.0.0.8 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 standby 1 ip 10.0.0.254
 standby 1 preempt
 standby 1 name HSRP


interface FastEthernet0/1.9
 encapsulation dot1Q 9
 ip address 9.0.0.8 255.255.255.0
 ip nat outside
ip nat Stateful id 2
 redundancy HSRP
 mapping-id 10
 protocol   udp
ip nat pool SNATp 9.0.0.20 9.0.0.29 prefix-length 24
 ip nat inside source route-map SNAT pool SNATp mapping-id 10
access-list 101 permit tcp any any eq telnet
 route-map SNAT permit 10
 match ip address 101

In the configuration, you’ll notice that each router is configured with a Stateful NAT ID: these values have to be unique to each router. In the configuration, the stateful NAT process is associated with a HSRP redundancy group and given a mapping ID. Linking to a redundancy group enables the stateful NAT process on each router to leverage HSRP to identify its stateful NAT peer address for the exchange of SNAT messages. The mapping ID is used to reference which NAT entries on the router need to have their state exchanged between the SNAT peers by the SNAT process.
You’ll notice that the inside policy-based NAT that I’ve configured references the mapping-id at the end of the command. Additionally, each router needs to have the same route-map, pool and access-list so that they can both provide the same services to clients.

To test my configuration, I’ll establish a telnet session from R6 to R9.

R6#telnet 9.0.0.9
 Trying 9.0.0.9 ... Open
User Access Verification
Password:
 R9>en
 Password:
 R9#

Whilst that telnet session is open, we’ll look at the NAT translations and the SNAT information on R7 and R8. We see that R7 is showing as ACTIVE and that both routers have identical information showing in their NAT translations table.

R7#sh ip nat translations
 Pro Inside global      Inside local    Outside local   Outside global
 tcp 9.0.0.20:24114     10.0.0.6:24114     9.0.0.9:23       9.0.0.9:23
R7#sh ip snat distributed ver
Stateful NAT Connected Peers
SNAT: Mode IP-REDUNDANCY :: ACTIVE
 : State READY
 : Local Address 10.0.0.7
 : Local NAT id 1
 : Peer Address 10.0.0.8
 : Peer NAT id 2
 : Mapping List 10
 : InMsgs 400, OutMsgs 0, tcb 0xB8898888, listener 0x0
R8#sh ip nat tra
 Pro Inside global      Inside local    Outside local   Outside global
 tcp 9.0.0.20:24114     10.0.0.6:24114     9.0.0.9:23       9.0.0.9:23

R8#sh ip snat distributed verbose
Stateful NAT Connected Peers
SNAT: Mode IP-REDUNDANCY :: STANDBY
 : State READY
 : Local Address 10.0.0.8
 : Local NAT id 2
 : Peer Address 10.0.0.7
 : Peer NAT id 1
 : Mapping List 10
 : InMsgs 398, OutMsgs 0, tcb 0xB8898888, listener 0x0

When I shut down the F0/1.6 subinterface on R7, let’s look at the information shown on R8.

*Mar 11 17:17:18.767: %HSRP-5-STATECHANGE: FastEthernet0/1.6 Grp 1 state Standby -> Active
 R8#sh ip snat distributed verbose
Stateful NAT Connected Peers
R8#sh ip nat translations
 Pro Inside global      Inside local     Outside local   Outside global
 tcp 9.0.0.20:24114     10.0.0.6:24114     9.0.0.9:23        9.0.0.9:23

On R8, we lose information about our connected SNAT peer (namely because the peer is dead) and we also see R8 become the active HSRP router. The telnet session from R6 to R9 is still available and working, too.

I’ll bring the R7 F0/1.6 link back up now, and we’ll look at R8 again:

*Mar 11 17:21:24.599: %HSRP-5-STATECHANGE: FastEthernet0/1.6 Grp 1 state Active -> Speak
 *Mar 11 17:21:35.447: %HSRP-5-STATECHANGE: FastEthernet0/1.6 Grp 1 state Speak -> Standby
 R8#sh ip snat distributed verbose
Stateful NAT Connected Peers
SNAT: Mode IP-REDUNDANCY :: STANDBY
 : State READY
 : Local Address 10.0.0.8
 : Local NAT id 2
 : Peer Address 10.0.0.7
 : Peer NAT id 1
 : Mapping List 10
 : InMsgs 2, OutMsgs 0, tcb 0xB8898888, listener 0x0

We see that the SNAT relationship came back up. The telnet session from R6 to R9 is still up, too.

So now we’ve seen how to use HSRP to provide Stateful NAT services for dynamic entries. Before I finish, there’s one more function worth looking at: namely Stateful NAT for static entries. The process is slightly different as you’ll see.

What I’m going to create is a static entry translating R6 from its IP of 10.0.0.6 to 9.0.0.6 as it passes via either R7 or R8 (whichever is the active HSRP router). I’m going to leave the previous configuration on R7 and R8 (as the policy-based entry will retain precedence over the static entry).

R7(config)#ip nat inside source static 10.0.0.6 9.0.0.6 redundancy HSRP mapping-id 10
%NAT: System busy. Try later

Great – my command is correct, but the router errors. This, unfortunately, is normal when configuring SNAT – the solution is to either reboot the router or to shutdown the HSRP interface, configure the command, and bring the interface back up (which works sometimes but not always).

R7(config)#int f0/1.6
 R7(config-subif)#sh
 SNAT: interface FastEthernet0/1.6 with address 10.0.0.7 is down
 R7(config-subif)#exi
 R7(config)#
 *Mar 11 17:39:48.475: %HSRP-5-STATECHANGE: FastEthernet0/1.6 Grp 1 state Active -> Init
 *Mar 11 17:39:48.479: %SNAT-5-PROCESS: Id 1, System fully converged
 R7(config)#ip nat inside source static 10.0.0.6 9.0.0.6 redundancy HSRP mapping-id 10
R7(config)#int f0/1.6
 R7(config-subif)#no sh

Now to repeat this on R8. Note, I had to reload R8 as even shutting down the interfaces didn’t remove the NAT error, so I reloaded with the F0/1.6 subinterface on R8 shutdown so that the HSRP and SNAT process couldn’t start before I wanted it to.

R8(config)#ip nat inside source static 10.0.0.6 9.0.0.6 redundancy HSRP mapping-id 10
R8(config)#int f0/1.6
R8(config-subif)#no sh
*Mar 11 17:39:22.967: %HSRP-5-STATECHANGE: FastEthernet0/1.6 Grp 1 state Speak -> Standby
*Mar 11 17:39:29.007: %SNAT-5-PROCESS: Id 2, System starts converging
*Mar 11 17:39:47.391: %SNAT-5-PROCESS: Id 2, System fully converged

Now I’ll start an SSH session from R6 to R9.

R6#ssh -l ipexpert 9.0.0.9
Password:
R9>

Let’s look at the NAT entries on R7 and R8.

R7#clear ip nat translation *
%NAT: System busy. Try later
R7#sh ip nat translations
Pro Inside global      Inside local    Outside local   Outside global
tcp 9.0.0.6:13931      10.0.0.6:13931     9.0.0.9:22        9.0.0.9:22
tcp 9.0.0.20:24114     10.0.0.6:24114     9.0.0.9:23        9.0.0.9:23
tcp 9.0.0.6:44528      10.0.0.6:44528     9.0.0.9:22        9.0.0.9:22
tcp 9.0.0.6:46832      10.0.0.6:46832     9.0.0.9:22        9.0.0.9:22
--- 9.0.0.6            10.0.0.6           ---                ---

You’ll notice the large number of entries on R7 and R8 – I setup the session a few times to test it and couldn’t clear the NAT table due to the error message (sure I could reload my router, but I think you’ll forgive the excess entries).

R7#sh ip snat distributed verbose
Stateful NAT Connected Peers
SNAT: Mode IP-REDUNDANCY :: ACTIVE
 : State READY
 : Local Address 10.0.0.7
 : Local NAT id 1
 : Peer Address 10.0.0.8
 : Peer NAT id 2
: Mapping List 10
: InMsgs 59, OutMsgs 0, tcb 0xB8898888, listener 0x0

R8:

R8#sh ip nat translations
 Pro Inside global      Inside local     Outside local   Outside global
 tcp 9.0.0.20:13842     10.0.0.6:13842     9.0.0.9:23        9.0.0.9:23
 tcp 9.0.0.6:13931      10.0.0.6:13931     9.0.0.9:22        9.0.0.9:22
 tcp 9.0.0.20:24114     10.0.0.6:24114     9.0.0.9:23        9.0.0.9:23
 tcp 9.0.0.6:44528      10.0.0.6:44528     9.0.0.9:22        9.0.0.9:22
 tcp 9.0.0.6:46832      10.0.0.6:46832     9.0.0.9:22        9.0.0.9:22
 --- 9.0.0.6            10.0.0.6           ---               ---
R8#sh ip snat distributed verbose
Stateful NAT Connected Peers
SNAT: Mode IP-REDUNDANCY :: STANDBY
 : State READY
 : Local Address 10.0.0.8
 : Local NAT id 2
 : Peer Address 10.0.0.7
 : Peer NAT id 1
 : Mapping List 10
 : InMsgs 65, OutMsgs 0, tcb 0xB8898888, listener 0x0

Now to test by shutting down the F0/1.6 interface on R7. The SSH session is still up and on R8 we see the translations remain, but the SNAT peer entry is lost. To save space, I haven’t shown the failback (it does work), but I encourage you to lab this up and test it out.

R8#sh ip nat translations
 Pro Inside global      Inside local    Outside local   Outside global
 tcp 9.0.0.20:13842     10.0.0.6:13842     9.0.0.9:23        9.0.0.9:23
 tcp 9.0.0.6:13931      10.0.0.6:13931     9.0.0.9:22        9.0.0.9:22
 tcp 9.0.0.20:24114     10.0.0.6:24114     9.0.0.9:23        9.0.0.9:23
 tcp 9.0.0.6:44528      10.0.0.6:44528     9.0.0.9:22        9.0.0.9:22
 tcp 9.0.0.6:46832      10.0.0.6:46832     9.0.0.9:22        9.0.0.9:22
 --- 9.0.0.6            10.0.0.6           ---                ---
R8#sh ip snat distributed
 Stateful NAT Connected Peers
 R8#

So now we’ve seen how to implement both policy-based and static NAT leveraging HSRP for high availability. We’ve also seen the potential errors that may occur even when you do everything right (handy to know if they occur in the actual lab).

The configurations are available for you to test this out yourself. If you have any questions, post them in the comments or send me an email.

Configuration Files

Well, I’ve had a lot of requests for the follow up to my post last year, So Much Information: Part One. The focus of that post, which I strongly recommend you read, was on how to properly prepare for the CCIE Written exam for the Routing and Switching track so that you take away from that preparation enough knowledge to begin practicing for your lab exam.

The purpose of this post is to articulate the various resources that I would suggest the use of in preparing for your lab exam. This includes a variety of resources including the Cisco online documentation, various Cisco Press titles that didn’t fit in to my previous article and of course, IPexpert training materials.

I’d like to create a study path here to reference, that continues on from the point of passing the written exam and would be a feasible pace for most students. I am aware that it’s difficult to make a one size fits all plan as everyone has their own constraints with respect to their path, so I’ve opted to articulate a plan that is very similar to the path that I’ve taken for each of my CCIE labs, tailored to the R&S track. Using this approach let’s consider how to go from passing the written, to taking the lab.

So let’s assume that you’ve just returned home from the testing center, with your written exam results in hand and it’s time to consider setting aside the time and money to convert that written exam into a CCIE number. Before scheduling a lab date, take some time to get a sense of the cost of the lab exam. By that I don’t just mean the cost of the lab exam itself. I mean the cost of the materials, the travel, the accommodation, the training and the costs of potentially taking multiple attempts (the average is around 3 attempts to pass). These costs can add up, but remember the other cost – time.

The journey from the written exam to the lab can take anywhere from 3 months to many years. The amount of time you can commit on a daily or weekly basis will play a large role in how long that process will take. Everyone has different family, work and social commitments that factor into their calculation of time and different expectations for how long the process may take. Understand what time horizons are acceptable for you and keep them in the back of your mind as you design a study path. Set yourself a rough date (i.e October 2009) for when you’d like to achieve your lab and then read through this article to work out what methods may assist to prepare you in that time.

The first study tool I’d suggest using, as I did, is the IPexpert Blended Learning Solution, which contains all of our self study products – technology focused labs, multiprotocol labs, mock labs, video and audio classes on demand, video solutions, the works. Every CCIE student needs a set of lab workbooks written to give them opportunities to learn both specific technologies and how they’ll integrate together into a mock lab. From IPexpert, I generally recommend purchasing the complete set of workbooks bundled together with the other self-study products due to the savings associated with bundling.

Phase One: Once your workbooks arrive open them up and skim through them to get a grasp of the topics that you’ll be learning in the coming months. Focus predominantly on the technology focused workbook, reading through the different topics and noticing the topics where you have strengths and those where you need practice. To begin your preparation I suggest starting on those labs that correlate to your weaker topics as that will give you the most value from your study hours.

Work through the technology focused labs, allow yourself to refer to the accompanying solution guide (IPexpert provides these with each lab) when you get stuck or aren’t sure of the answer to a question. Configure each section as required using each of the “show” commands to verify your answers. As you configure each section, look up each and every command in the Command Reference and where possible, the Configuration Guide for that topic on the Cisco Documentation starting from http://www.cisco.com/web/psa/products/index.html just like in your actual lab.

While you repeat this process for each technology focused lab, over a month or two you’ll gain significant benefits both from comfort with the commands for each technology and from fluency in navigating the documentation. When you’ve done this for each technology you need configuration experience with, read through the solutions guide for each of the other technology focused labs that you don’t need to configure as you may find a few unfamiliar commands buried within them.

Phase Two: The purpose of Phase One was to gain fluency with the documentation whilst simultaneously gaining experience in unfamiliar topics. The purpose of Phase Two is to start integrating technologies together and to hone in on weaknesses and supplement them. The products I’d suggest you use here are multiprotocol labs in an 8-hour format similar to your actual lab. These are included inside IPexpert’s Blended Learning Solution and can be purchased separately. Work through each of these labs starting from the first one. As you discover new commands look each of them up on Cisco’s website as was done in Phase One. Pay attention to the areas that catch you out. In addition to the books listed in my prior article, there are a few that will offer some supplemental benefit at this stage of your preparation.

If you are finding that you are having challenges with routing protocols, the following book is excellent with respect to its methodology and detail in helping troubleshoot routing protocol issues.

Troubleshooting IP Routing Protocols (CCIE Professional Development Series) by Zaheer Aziz, Johnson Liu, Abe Martey, Faraz Shamim.

If you are finding that you are having challenges with WAN technologies, the following book is a great resource by providing a process for troubleshooting them and detailed explanations.

Troubleshooting Remote Access Networks (CCIE Professional Development) by Plamen Nedeltchev.

Finally, for additional help with switching read the latest IOS Configuration Guide for the 3560 switch (and the QOS section for the 3550 switch).

This phase involves the configuration of about 5 to 10 multiprotocol labs over the course of a few weeks to a few months depending on how comfortable you become.

Phase Three: The third phase of lab preparation is where the prior preparation gets integrated into lab readiness. For those who can afford to this is where I’d highly recommend attendance in a boot camp. Whilst I have an inherent bias towards the IPexpert Instructor Led Boot Camp which I used both as a student and teach now, there are a few things to look for from a course. The purpose of a boot camp at this point in your preparation is to tie together the knowledge and experience you have already gained and to polish and prepare you for the final stage before your lab exam. Ideally, the course will be about 4-8 weeks prior to your real lab date so that you have time to polish or rectify any areas identified by yourself and the instructor after the course that you need improvement on.

A boot camp should provide you with a detailed strategy for taking the lab exam, it should explain to you the many different technologies you’ll encounter in the lab and how they interact with other protocols and it should give you a chance to demonstrate configuration of each technology with an instructor to assist you. This environment combining theory, hands-on and strategy is the best way to integrate your knowledge and prepare you to be ready to take a lab exam.

For those of you who don’t have the opportunity to take a class, I’d suggest continuing to work through multiprotocol labs and additionally watching the Video Class on Demand utilizing frank self assessment to recognize your progress or knowledge gaps.

Phase Four: The final phase which normally lasts 2-8 weeks is the period after a boot camp or immediately prior to your exam where you should polish any topics that you feel least comfortable on. This might require going back to your textbooks for additional reading, posting questions in forums (such as www.onlinestudylist.com) or configuring some ad hoc labs to specifically test and understand the technologies you need confidence on. I generally spend most of this phase reading through lab solutions guides to get comfortable with the wording of questions and to maintain my fluency at recognizing commands and what function they achieve. I’d suggest doing a handful (maybe 5 to 10) of the most difficult mock labs you can find during this period to ensure that you’ve tested yourself as strictly as possible prior to your lab date.

This approach I’ve articulated should take about 2-8 weeks for Phase One, about 2-8 weeks for Phase Two, about 2-4 weeks for Phase Three and about 2-8 weeks for Phase Four. That’s a timeline of about 3 to 7 months from passing the written exam to passing your lab exam.

If you have any questions please email me at jscrivener@ipexpert.com.

Cheers,

Jared

Most of us are familiar with the concept of an OSPF Router ID – namely that it is used to uniquely identify a router within an OSPF topology. Each LSA a router originates will have the Router ID in the “advertising router” field. In fact, every OSPF packet will hold the Router ID of the sending router in its header. This has great benefits – if two peering routers have the same Router ID they won’t peer – a quick and obvious sign that we probably made a typo when configuring either our interface addresses or our Router IDs. Which brings me to the implications for a CCIE lab…

OSPF Router IDs are automatically assigned to a router as being either the highest IP address of a loopback address, or if in the unlikely case you have no loopback address, the highest IP address of any active interface at the time that OSPF starts up. If your router ID conflicts with another router in the same area (or in the case of an ASBR in a different area) you’ll probably receive a similar error to this:

%OSPF-4-DUP_RTRID1: Detected router with duplicate router ID 10.0.0.2 in area 0

That’s an error message that’s pretty easy to interpret. However, due to the nature of your lab, you can’t configure everything simultaneously – your Layer 2 protocols need to work before you start on your IGPs, your IGPs should work before you do BGP, your multicast depends on your IGPs – get the idea?

So what would happen if you setup OSPF and then later on a BGP or multicast question required you to add loopbacks? Simple, the Router ID would change after your router is reloaded (which the proctors will do before they grade your lab, although hopefully you did this yourself at the end of the day when you were verifying your configuration). In most cases, your Router ID changing shouldn’t be a big deal (unless you have questions that require certain devices to have certain router IDs) from the perspective of your network. I mean, how often would a later question intentionally require you to configure duplicate IP addresses? Well, how often is Anycast RP tested…

With Anycast RP, two routers create the same loopback address and advertise it into the routing protocol before setting up MSDP peering, so that clients can easily find their closest RP. This alone may not cause a problem, unless that new loopback address is HIGHER than any currently configured on your routers. The problem itself wouldn’t even appear until OSPF was restarted (by the proctors, for example, when reloading your devices). Assuming you chose to reload your own devices (a wise move), you may not see the nice message from earlier – you might see something like this:

%OSPF-4-FLOOD_WAR: Process 1 flushes LSA ID 10.1.2.2 type-5 adv-rtr 10.0.0.2 in area 50

Yep, that’s the flood war the heading referred to. It means that a router in a different area has the same router ID as the one you see this message on and is advertising a network that the local router isn’t advertising(and hence withdraws). Put simply, it is caused by duplicate Router IDs.

The easy solution to this is to manually configure the Router ID on every OSPF router when you first setup OSPF – do this EVERY time (unless your lab directs you not to) and you’ll never suffer from duplicate addresses.

Well unless you’ve been living in a cave like a hermit (perhaps studying for your CCIE lab) you are probably aware that the global economy is in either a severe recession or depression, depending on which news source you read. Globally, unemployment numbers are increasing dramatically as businesses cut expenses enabling themselves to become more efficient. The unfortunate ramification of this is that employer funding for training is becoming increasingly scarce. That’s the bad news.

There is a silver lining to this though: demand for knowledgeable workers is increasing for similar reasons. If a company can only afford to employ fewer people, then they need each of those people to be as highly skilled and adaptable as possible. Knowledge is power, and one of the many attributes of a CCIE is knowledge – after all, we’re the best of the best. In the past few months, myself and many CCIEs that I know have received more job opportunities than at any time in the past 18 months. Initially I assumed this to be an anomaly due to the contracting economy and then something clicked for me – CCIE demand by employers is booming.

The most common reasons I hear amongst students aiming for CCIE certification when I ask them why they are pursuing it include: sense of accomplishment; increased salary; better job performance; increased job security and a desire to achieve a higher level of knowledge in their chosen field. Generally I hear them in roughly that order. The average CCIE wage is over $100k in good times – in many cases significantly higher. The average CCNP wage is around $70-80k in good times.

What happens in bad economic times? As companies cut back, those at the top of their field, the CCIEs, either stay where they are whilst their team dwindles in size, or move to another company that needs the most talented workers. This effectively keeps the average CCIE wage at about the same level, with perhaps a slight decline. However, for the lower skilled CCNP level workers (and more so for the CCNA level and so on down the line) jobs become more scarce, both due to the reduction in overall networking positions and the increased competition for senior as CCIEs gradually move to take up the top roles in each organization’s network teams.

Now, this might seem bad – but there is good news. With such a large demand for CCIEs, there has probably never been a better time since the dot-com bubble burst to push yourself to upgrade your knowledge and ability to CCIE level. At IPexpert we provide the CCIE training industry’s foremost programs in the R&S, Voice, Security and Service Provider track to enable you to achieve this certification in the most compressed timeframe possible, whilst ensuring that you have that powerful level of knowledge that your job may require. Our labs and courses are designed to ensure that your time is spent most optimally with the goal of making the CCIE lab exam achievable in 3 to 6 months (after completion of the written exam).

As someone who self funded both my purchase of IPexpert’s self study products and instructor led boot camps for both my R&S and Security CCIE tracks (as well as the international flights to attend them), I fully understand the financial and time challenges that come with making a commitment to achieve CCIE certification. I can also say that from a personal development, a financial and a work lifestyle choice that was the best decision I ever made.

If you are interested in attaining your CCIE, so that you can also benefit from the additional level of security and satisfaction that comes with it, please send an email to sales@ipexpert.com and one of our Training Advisers will gladly talk to you about tailoring a program to your needs. After all, knowledge is power.

Cheers,

Jared