Apr
28

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.

Tags:

Apr
15

Edit: The recording of this session is now available here

This coming Tuesday, April 19th 2016, at 09:00 PDT (17:00 UTC) I will be joining the VIRL team for a discussion and demo of using cloud hosted servers, VIRL, and INE material for CCIE preparation, with a focus on large topologies (30+ devices). The Webex signup link is here. The session will also be simulcast on live.ine.com.

Specifically in this session I will be covering:

  • How to deploy VIRL on cloud servers
  • Loading INE topology files into the VIRL cloud instance through GIT
  • Launching and managing multiple large topologies

Attendees will also have an opportunity to submit questions to me as well as the VIRL team.

Hope to see you there!

Tags: ,

Apr
13

Rack Rentals for INE’s CCIE Service Provider v4 topology are now available at rentals.ine.com.

Both CCIE RSv5 Full Scale Labs and CCIE SPv4 now share the same topology in the scheduler, which consists of the following devices:

  • 20 x IOS XE virtual machine instances (R1 – R20)
  • 4 x IOS XRv virtual machine instances (R21 – R24)
  • 4 x Catalyst 3560 physical switches (SW1 – SW4)

IOS XRv instances can be managed through the control panel similar to other devices in the topology, as seen below:

Nov
18

Cisco has just announced CCIE Data Center Written and Lab Exam Content Updates.Important dates for the changes are:

  • Last day to test for the v1.0 written – July 22, 2016
  • First day to test for the v2.0 written – July 25, 2016
  • Last day to test for the v1.0 lab – July 22, 2016
  • First day to test for the v2.0 lab – July 25, 2016

Key hardware changes in the v2.0 blueprint are:

  • APIC Cluster
  • Nexus 9300
  • Nexus 7000 w/ F3 Module
  • Nexus 5600
  • Nexus 2300 Fabric Extender
  • UCS 4300 M-Series Servers

Key technical topic changes in the v2.0 blueprint are:

  • VXLAN
  • EVPN
  • LISP
  • Policy Driven Fabric (ACI)

More details to come!

Tags: , ,

Jul
01

As we reported last April, Cisco changed the CCIE Lab Exam retake policy to an exponential backoff, meaning that the more attempts you took at the lab the more time you had to wait between attempts.

In a sudden change of heart, today Cisco announced that they are reversing their policy change until at least December 31st 2015. Per Cisco:

“For a limited time, we will waive the current lab retake policy so that all lab candidates will be able to retest for their lab exam with only a 30-day wait period.” “If you register for any CCIE lab exam between now and December 31, 2015, you will have the option of retaking the exam with only a 30-day wait regardless of the number of attempts you may have already made.”

Frequently Asked Questions about the policy changes:

Q: Does this mean that between now and December 31, I can take the lab every 30 days?
A: Yes.

Q: Is the original policy back in place after December 31?
A: What happens after December 31 is dependent on the results of our research from now until that date.

Q: What does this mean if my current wait period is 90 days and I’m in the middle of the waiting period? Can I sign up now or do I have to continue to wait?
A: Yes, you can sign up now. You do not have to wait. The policy that is active at the time you schedule your lab will determine the time you have to wait. If you are beyond the 30-day wait period, you can book the earliest available seat you find.

Q: What if I’m already scheduled for a lab that I had to schedule out 90 days because of the original policy?
A: You will have the option to reschedule your lab attempt to an earlier date through the system.

Tags: ,

Jul
01

INE’s CCIE Service Provider v4 Advanced Technologies Class continues today at 08:00 PDT (15:00 UTC) with Inter-AS MPLS L3VPN. All Access Pass subscribers can attend at http://live.INE.com. Recordings of some of the previous class sessions up to this point are now available via AAP library here.

Additionally, INE’s CCIE SPv4 Workbook is now available in beta format here.

Hope to see you in class!

Jun
30

INE CCIE RSv5 Lab Cram Session is now available for viewing in our All Access Pass Library. This course includes over 35 hours of new content for CCIE Routing & Switching Version 5, including both technology review sessions as well as a step-by-step walkthrough of two new CCIE RSv5 Mock Lab Exams. These new Mock Labs are available here as part of INE’s CCIE RSv5 Workbook.

This class is designed as a last minute review of technologies and strategy before taking the actual CCIE RSv5 Lab Exam. Each of the two Mock Labs covered in class are subdivided into three sections – just like the actual exam – Troubleshooting, Diagnostics, and Configuration.

Rack rentals are available for these mock labs here. Technical discussion of the labs is through our Online Community, IEOC.

Happy Labbing!

Tags: , ,

May
15

 

The following question was recently sent to me regarding PPP and CHAP:

 

At the moment I only have packet tracer to practice on, and have been trying to setup CHAP over PPP.

It seems that the “PPP CHAP username xxxx” and “PPP CHAP password xxxx” commands are missing in packet tracer.

I have it set similar to this video… (you can skip the first 1 min 50 secs)

https://www.youtube.com/watch?v=5ltNfaPz0nA

As he doesn’t use the missing commands, if that were to be done on live kit would it just use the hostname and magic number to create the hash?

 

Also, in bi-directional authentication, do both routers have to use the same password or can they be different as long as they match what they expect from the other router?

Thanks, Paul.

 

Here was my reply:

Hi Paul,

When using PPP CHAP keep in mind four fundamental things:

  1. The “magic number” that you see in PPP LCP messages has nothing to do with Authentication or CHAP.  It is simply PPPs way of trying to verify that it has a bi-directional link with a peer. When sending a PPP LCP message a random Magic Number is generated.  The idea is that you should NOT see your own Magic Number in LCP messages received from your PPP Peer.  If you DO see the same magic number that you transmited, that means you are talking to yourself (your outgoing LCP CONFREQ message has been looped back to you).  This might happen if the Telco that is providing your circuit is doing some testing or something and has temporarily looped-back your circuit.
  2. At least one of the devices will be initiating the CHAP challenge.  In IOS this is enabled with the interface command, “ppp authentication chap”.  Technically it only has to be configured on one device (usually the ISP router that wishes to “challenge” the incoming caller) but with CHAP you can configure it on both sides if you wish to have bi-directional CHAP challenges.
  3. Both routers need a CHAP password, and you have a couple of options on how to do this.
  4. The “hash” that is generated in an outgoing PPP CHAP Response is created as a combination of three variables, and without knowing all three values the Hash Response cannot be generated:
  • A router’s Hostname
  • The configured PPP CHAP password
  • The PPP CHAP Challenge value

I do all of my lab testing on real hardware so I can’t speak to any “gotchas” that might be present in simulators like Packet Tracer.  But what I can tell you, is that on real routers the side that is receiving the CHAP challenge must be configured with an interface-level CHAP password.

The relevant configurations are below as an example.

ISP router that is initiating the CHAP Challenge for incoming callers:

username Customer password cisco
!
interface Serial1/3
 encapsulation ppp
 ppp authentication chap
 ip address x.x.x.x y.y.y.y
!

Customer router placing the outgoing PPP call to ISP:

hostname Customer
!
interface Serial1/3
 encapsulation ppp
 ppp chap password cisco
 ip address x.x.x.x y.y.y.y
!

If you have a situation where you expect that the Customer Router might be using this same interface to “call” multiple remote destinations, and use a different CHAP password for each remote location, then you could add the following:

 

Customer router placing the outgoing PPP call to ISP-1 (CHAP password = Bob) and ISP-2 (CHAP password = Sally):

hostname Customer
!
username ISP-1 password Bob
username ISP-2 password Sally
!
interface Serial1/3
 encapsulation ppp
 ppp chap password cisco
 ip address x.x.x.x y.y.y.y
!

Notice in the example above, the “username x password y” commands supercede the interface-level command, “ppp chap password x”. But please note that the customer (calling) router always needs the “ppp chap password” command configured at the interface level.  A global “username x password y” in the customer router does not replace this command.  In this situation, if the Customer router placed a call to ISP-3 (for which there IS no “username/password” statement) it would fallback to using the password configured at the interface-level.

Lastly, the “username x password y” command needs to be viewed differently depending on whether or not it is configured on the router that is RESPONDING to a Challenge…or is on the router that is GENERATING the Challenge:

  • When the command “username X password Y” is configured on the router that is responding to the CHAP Challenge (Customer router), the router’s local “hostname” and password in this command (along with the received Challenge) will be used in the Hash algorithm to generate the CHAP RESPONSE.

 

  • When the command “username X password Y” is configured on the router that is generating the CHAP Challenge (ISP Router), once the ISP router receives the CHAP Authentication Response (which includes the hostname of the Customer/calling router) it will match that received Hostname to a corresponding “username X password Y” statement. If one is found that matches, then the ISP router will perform its own CHAP hash of the username, password, and Challenge that it previously created to see if its own, locally-generated result matches the result that was received in the CHAP Response.

Lastly, you asked, “ Also, in bi-directional authentication, do both routers have to use the same password or can they be different as long as they match what they expect from the other router?”

Hopefully from my explanations above it is now clear that in the case of bi-directional authentication, the passwords do indeed have to be the same on both sides.

 

Hope that helps!

Keith

 


 

 

Tags: , ,

May
10

Edit: Thanks for playing! You can find the official answer and explanation here.

I had an interesting question come across my desk today which involved a very common area of confusion in OSPF routing logic, and now I’m posing this question to you as a challenge!

The first person to answer correctly will get free attendance to our upcoming CCIE Routing & Switching Lab Cram Session, which runs the week of June 1st 2015, as well as a free copy of the class in download format after it is complete.  The question is as follows:

Given the below topology, where R4 mutually redistributes between EIGRP and OSPF, which path(s) will R1 choose to reach the network 5.5.5.5/32, and why?

Bonus Questions:

  • What will R2′s path selection to 5.5.5.5/32 be, and why?
  • What will R3′s path selection to 5.5.5.5/32 be, and why?
  • Assume R3′s link to R1 is lost.  Does this affect R1′s path selection to 5.5.5.5/32? If so, how?

Tomorrow I’ll be post topology and config files for CSR1000v, VIRL, GNS3, etc. so you can try this out yourself, but first answer the question without seeing the result and see if your expected result matches the actual result!

 

Good luck everyone!

Tags: , ,

Apr
13

Edit: Recordings of these video series are now available per the below links.

This week I will be running the following free online classes:

*Free for AAP Members

INE will also be offering the following free upcoming online classes:

  • CCNA R&S Overview and Preparation – Tues April 21st @ 09:00 PDT (16:00 UTC)
  • CCNP R&S Overview and Preparation – Thurs April 23rd @ 09:00 PDT (16:00 UTC)
  • CCNP R&S TSHOOT Overview and Preparation – Thurs April 30th @ 09:00 PDT (16:00 UTC)

More information on these classes can be found here.


 

CCIE Service Provider v4 Kickoff

This class marks the kickoff of INE’s CCIE SPv4 product line for the New CCIE Service Provider Version 4 Blueprint, which goes live May 22nd 2015!  In this class we’ll cover the v3 to v4 changes, including exam format changes and topic adds and removes, recommended readings and resources, INE’s new CCIE SPv4 hardware specification and CCIE SPv4 Workbook, and the schedule for INE’s upcoming CCIE Service Provider Version 4 Advanced Technologies Class.  Class runs tomorrow, Tuesday April 14th at 09:00 PDT (16:00 UTC), and is free to attend.  Simply sign up for an INE Members account or visit this direct link for the class.


 

CCIE Routing & Switching v5 Overview and Preparation

This class is an update for our previous How to pass the CCIE R&S with INE’s 4.0 Training Program write-up. This session covers in detail the recommended process of preparing for, and ultimately passing, the CCIE R&Sv5 Lab Exam. Class topics include how to develop a study plan, recommended readings and resources, how to get the most out of INE’s CCIE RSv5 Workbook & Advanced Technologies Class (ATC), an overview of our new upcoming CCIE Routing & Switching Lab Cram Session, and final strategy for the actual day of the Lab Exam. Class runs Thurs April 16th at 09:00 PDT (16:00 UTC), and is free to attend.  Simply sign up for an INE Members account or visit this direct link for the class.


 

Intro to IPv4 & IPv6 Multicast

This class is for engineers looking to get their feet wet in learning why and how to implement IP Multicast Routing for both IPv4 and IPv6 based networks. This one-day class will focus on IPv4 & IPv6 Multicast practical use cases, how Protocol Independent Multicast (PIM), IPv4 Internet Group Management Protocol (IGMP), & IPv6 Multicast Listener Discovery (MLD) work from a theory point of view, and implementation examples of configuring and verifying multicast routing operations on Cisco IOS based platforms. This class will also benefit candidates preparing for the CCIE RSv5 or CCIE SPv4 certifications. Class runs Friday April 17th at 09:00 PDT (16:00 UTC), and is free to attend for All Access Pass members. More information on All Access Pass subscriptions and benefits can be found here. AAP members will find the link to this class on Friday via their INE Members account, or via this direct link for the class.

I hope to see you all in class this week!

Categories

CCIE Bloggers