Posts from ‘Uncategorized’


This course is part of INE’s CCIE Security v5 Technology Series. This series consists of several modules focused on many different aspects of the Group Encrypted Transport VPN (GETVPN) technology, such as operations, configuration, and redundancy. The course covers all important and exam-relevant topics and technologies, including GETVPN Data & Control Plane Components, Registration, IPv6 support, COOP KS, G-IKEv2, implementation, verification, and more, such as design considerations.


This course is taught by Poitr Kaluzny and is 2 hours and 38 minutes long. For those who are INE All Access Pass members, you can watch this course on the streaming site. This course is also available for purchase at

About The Instructor

Piotr Kaluzny started his networking career during his studies. He was able to get his first job in production right after graduating in 2007 (Piotr holds MSc in Computer Science). He progressed his career by working in different routing & switching and security roles, with responsibilities ranging from operations and engineering to consulting and management. Since the beginning, Piotr has focused heavily on the security track. He passed the CCIE Security certification exam (#25565) in 2009 on his first attempt.

Piotr already has an extensive background as a senior technical instructor. For the past several years he has designed, developed and taught CCNA, CCNP and CCIE training courses for one of the largest, and most respected Cisco training companies in the world.


Join 4 time CCIE Brian McGahan for our 2 new online live sessions, CCIE Service Provider v4.1 Advanced Technologies. These live sessions are available to All Access Pass members via our live classroom interface, which you can access through your members account. For those who are not All Access Pass members, you can view and purchase AAP packages here. Read on to learn more about these online live classes.

When: Tuesday, February 13th & Wednesday, February 14th at 8 am PDT (11 am EST)

Why You Should Watch: This SPv4.1 class will complete the SPv4.1 courses and bring us current for the Cisco Service Provider Blueprints.

Instructor info: Brian McGahan, CCIEx4 #8593, CCDE #2013::13

About the Instructor:

At the age of 20, Brian McGahan earned his first CCIE in Routing & Switching, and became known as the “youngest engineer in the world.” He continued on to earn CCIE certifications in Security, Service Provider, and Data Center. Brian has developed and taught for INE since 2002, setting the bar for CCIE training and helping thousands of engineers obtain their own certifications–we’re proud to have such an accomplished and driven instructor on the INE team. When he is not developing new products for INE, he consults with large ISPs and enterprise customers.


For those of you that are looking to familiarize yourself with the Google Cloud Platform, you’re in luck! we have just released Google Cloud Platform: PaaS with App Engine. This course is now available to All Access Pass members through your members account, and to everyone else through purchase at

This course is just one of a growing collection of Google classes offered by INE, we also plan on releasing a Google Data Storage course later this week. Until then, read on to learn about Joseph Holbrook’s latest addition to our Google video course library.


Why Study Google App Engine?
Google App Engine is an extremely useful tool; it is a fully managed platform that completely abstracts away infrastructure so you can focus only on code.

About the Course:
This course covers Google App Engine PaaS and more specifically the history, features and functions of Google App Engine. The instructor will explain the benefits of using Google App Engine with live examples and demos.

The course is 4 hours and 5 minutes long and is taught by Joseph Holbrook.

What You’ll Learn:
Students will dive into both deployment models of the App Engine and learn how to decide which model is right for your organization.

Whether you’re a developer or architect, this course will help you understand the basic capabilities and some of the useful advanced features of the Google App Engine.

About the Instructor:
Joe Holbrook has been in the IT field since 1993 when he was exposed to several HPUX systems on board a US Navy flagship. He has migrated from UNIX world to Storage Area Networking(SAN) and then on to Enterprise Virtualization and Cloud Architecture. Joseph has worked for numerous companies such as HDS, 3PAR Data, Brocade, Dimension Data, EMC, Northrup Grumman, ViON,,, SAIC and Siemens Nixdorf. Joe currently works as a Subject Matter Expert specializing in Cloud/IT Security focused on Data Storage infrastructure services and Data migrations to the Cloud.

Joseph holds Industry leading certifications from Amazon Web Services, Google Cloud Platform, Brocade, Hitachi Data Systems, EMC, VMWare, CompTIA, HP 3PAR ASE, Cloud Credential Council and other orgs. He is now working on the Google Cloud Platform for several organizations.

Joe is married with children and lives in Jacksonville, Florida. In his free time, Joseph enjoys traveling to South America, spending time with his 5 year old daughter and learning about cryptocurrencies.  Joe is also an avid hockey fan and takes pleasure in skiing whenever he can get out of Florida.


Hello everyone!
I recently received an email from a learner who is studying for his CCNA Routing-and-Switching Certification and he had a few excellent questions about the OSI model and how, exactly data moves from one-layer to the next. I figured my response might prove valuable to others studying for their CCNA so…here it is!

  1. Learner-Question: In video of the osi model, you said that the session layer should provide the source and destination port number but the fields of those ports are at the transport header- my question is how does the session layer put this number on field which does not exist in that time (when i send the date the encapsulation process goes down from the app layer)?

    In order to thoroughly answer all of your questions below, one really needs to know about computer programming, APIs, etc…which frankly, I know very little about. But what I do know, I’ll try to explain. From my understanding, there are some kind of software “links” or “hooks” which are used to allow a program at one layer of the OSI model to communicate with a program at another layer. Many applications have software built-in that provide multi-layer functionality. For example, imagine that you open some kind of Terminal Client (like Hyperterminal, SecureCRT, PuTTY, etc). That software you’ve opened technically does not reside at ANY of the OSI layers. That software just provides the graphical display such as the buttons you can press, the pulldown menus available, etc. Now imagine that within PuTTY or Hyperterminal you press a button to initiate a Telnet connection. At that moment, the PuTTY software informs your CPU that the CPU must start the Telnet program. PuTTY provides the interface so you can see…and control…what is going on, but PuTTY itself is NOT Telnet. It’s simply the user-interface so you can control Telnet.

    The functionality of Telnet actually is actually composed of an Application-Layer process as well as a Session layer process, all rolled into one. At the Application layer, the Telnet protocol answers such questions as, “what is a “username” and what is a “password” and is that required? Shall it send data downstream to lower-levels of the OSI model one-bit-at-a-time or several bytes-at-a-time? How is the user supposed to know when Telnet is waiting for input, versus currently transmitting output?” etc etc. The Session-Layer component of Telnet knows that it should be “listening” for incoming sessions on port-23. And when initiating outgoing sessions, it should use a destination port-23. At some point, the Telnet protocol creates a hook (I think these are called APIs) that allows it to invoke the Transmission Control Protocol (TCP). TCP knows that as part of the datastructure it creates, it must reserve 2-bytes for a “destination port-number” field and another 2-bytes for a “source port-number field” but what TCP DOESN’T know is what numbers to place in those fields. So this API (or whatever it is) allows the Session-Layer component of Telnet to convey to TCP that it place the value of “23” in either the Source or Destination Port Number field (depending on who is initiating the Telnet session).

    You may now be thinking, “but what about the Presentation Layer? You didn’t include that in the Telnet process?”. I believe that once SecureCRT (or PuTTY or Hyperterminal) invoke your Application-Layer protocol (such as Telnet or SSH) that SecureCRT/Hyperterminal will provide the Presentation Layer-component. SecureCRT knows if, when you press a keystroke on your keyboard, that key should be represented by ASCII or EBCDIC, SecureCRT/Hyperterminal also knows if you pressed the button indicating that encryption should be used. So it kind of “merges” or “blends” all of that information into Telnet thus providing the Presentation-Layer components. I’m not sure HOW it does this…but it does.

  2. This question is about the type code field which lays at the llc sublayer, I understood that it purpose is to provide the upper layers what protocol is “talking”‘, how does it happens if the nic strips off the frame header in the decapsulation process?

    Basically what I wrote above happens in reverse here. There is some kind of internal software “hook” (probably another API) that allows your Layer-2 protocol (Ethernet) to communicate the value in the EtherType field to the CPU. In this way the CPU knows if it needs to invoke a Layer-3 procoess (like IP) or…if that process is already running…to take the Data from the Telnet frame and forward it to the correct layer-3 process. So IP itself does NOT see that Ethernet frame or any of the fields within it. But that “hook” (API???) provides the interface so that Ethernet data can be transferred upstream to the IPv4 process. At this point, my knowledge of the specific details of how this works ends.

  3. If the type code provides the protocol(and its version), why does the IP header has “vers” field?

    Once again, to answer this question I believe it’s all about the APIs that allow protocols at different layers to talk to each other. Moving downstream (from Layer-3 to Layer-2) when IPv4 (as an example) has created a full IP Packet, it will “call” the API that allows it to hook into the Layer-2 protocol. IP doesn’t even CARE what that Layer-2 protocol is. It probably does something like, “Hey Layer-2 hooking API!! I’ve got some data here. Please pass it on to whatever protocol is operating at the Datalink Layer for me!!” The API, because it is talking to IPv4 will then invoke whatever layer-2 protocol is running (Ethernet, HDLC, Frame-Relay, etc) and say, “I’ve got some Layer-3 data for you!!”. At that point, the Layer-2 protocol (Ethernet in this case) will say, “Great! Can you give me some number that I can shove into my Ethertype field that indicates WHICH Layer-3 protocol created the data?? I don’t really care personally…but the device at the other end of the link receiving this data will need to know!”. So the API (that was originally called by the IPv4 process and was DESIGNED to be an interpreter between IPv4 and Ethernet) will say, “sure…the number you need is 0×800!” and thus…Ethernet places that value into the Ethertype field. Receiving an Ethernet frame would work the same way but in reverse. This time the Layer-2 protocol would “call” that L2-to-L3 API and provide the data, ALONG WITH the value of the Ethertype field to that API. In turn, the API would then know it needs to call-out to IPv4 and transfer the data upstream.



Troubleshooting Lab 1 has been added to the CCIE Routing & Switching v5 Workbook. This is in addition to Full Scale Lab 1 which was posted yesterday. More Foundation, Troubleshooting, and Full Scale Labs will be added soon to the workbook. More information about additional content and its release schedule will be available shortly.

This lab uses a 20 router topology which will be available through our rack rental system shortly.  In the meantime if you have your own lab built on CSR1000v, IOU/IOL, etc. the initial configs are available to download on the lab 1 tasks page.  For technical discussion of this lab, please visit the Troubleshooting Labs section of our Online Community here.


Recently a group named Graffiti4Hire from London came to our Bellevue Washington headquarters to create a graffiti mural for us.  From what I hear the finished product looks amazing.  I’m looking forward to our CCIE Data Center Nexus class at the end of the month so I can see the final result in person!  Here is a time lapse video of their work that our video crew put together:


Hi Brian,

What is the major difference in using an E1 route over an E2 route in OSPF?

From what I’ve observed, if you redistribute a route into OSPF either E1 or E2, the upstream router will still use the shortest path to get to the ASBR regardless of what is shown in the routing table.

The more I read about this, the more confused I get. Am I missing something?


Hi Matt,

This is actually a very common area of confusion and misunderstanding in OSPF. Part of the problem is that the vast majority of CCNA and CCNP texts teach the theory that for OSPF path selection of E1 vs E2 routes, E1 routes use the redistributed cost plus the cost to the ASBR, while with E2 routes only use the redistributed cost. When I just checked the most recent CCNP ROUTE text from Cisco Press, it specifically says that “[w]hen flooded, OSPF has little work to do to calculate the metric for an E2 route, because by definition, the E2 route’s metric is simply the metric listed in the Type 5 LSA. In other words, the OSPF routers do not add any internal OSPF cost to the metric for an E2 route.” While technically true, this statement is an oversimplification. For CCNP level, this might be fine, but for CCIE level it is not.

The key point that I’ll demonstrate in this post is that while it is true that “OSPF routers do not add any internal OSPF cost to the metric for an E2 route”, both the intra-area and inter-area cost is still considered in the OSPF path selection state machine for these routes.

Continue Reading

Tags: , , , , , , , ,


As you may know, I will be the lead instructor for our New CCIE R&S Advanced Technologies Class.  The class runs online, and will start Monday April 11th at 07:00 PDT (GMT -7).  If you have an All Access Pass subscription or purchased the live version of the R&S ATC in the past you can attend the live class free of charge by contacting sales. Space is limited so if you want to attend the live version you need to contact sales ASAP.

The class will run least 10 days (not consecutively), but may run as long as 12 – 15 days.  Each class day will run about 8 hours, but may run as long as 10 – 12 hours.  Right now the length of the class is open ended, because there is *so much* content that I’m going to be covering.  I don’t want to rush through topics or skip key topics just to make the class fit into a normal template.  Class length will also it depend on how many questions I get from students during the class.

The purpose of this post is to announce that I am taking student submitted topic requests for the class.  If there is something that you’re having trouble understanding during your studies, or have found something that is not covered in enough depth in other classes or products, submit your requests here as a comment, or directly to me via email at

I look forward to seeing you in class!


Summer was in full swing, and it was over 105 degrees Fahrenheit outside.   Bob was told it was a “dry heat”, but he thought “so is my oven”.  Needless to say, Bob was glad to be in the data center, where the temperature and humidity controls kept it very cold.   He had been asked to setup up a basic route-map with BGP, and here is the diagram he worked from.

BGP Triangle
The goal, was to modify BGP,  so that all traffic going towards the network (which is sourced from AS1), traveling either from or through AS23, would only use the segment (between R3 and R1), and not use the segment (between R2 and R1) as a transit path.
Bob reviewed some of the BGP topics he had recently learned.   Here is the list he made of possibilities: Continue Reading

Tags: ,


Join us Friday, June 25th at 11AM Pacific / 2PM Eastern for another installment in the Open Lecture Series.

The topic that will be covered is Privilege Levels and Role Based CLI.

We look forward to seeing you there. Seats are limited.

Tags: , , ,


CCIE Bloggers