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!

Mar
17

In an effort to make our CCIE Data Center Rack Rentals have a better fair scheduler, we’ve implemented a new QoS policy for them as follows:

  • Users can have a maximum of 3 concurrent sessions scheduled
  • Sessions can be a maximum of 9 hours apiece
  • Maximum hours per month limit is now removed
  • Base sessions (Nexus 7K/5K) and add-ons (UCS/SAN & Nexus 2K/SAN) are now 8 tokens per hour

Note that these changes will only affect new session bookings, not any sessions that you already have reserved.

For those of you looking for more dedicated rack time I would suggest to look into our CCIE Data Center Bootcamp, where students get 12 days of 24/7 access to all hardware platforms in our racks (Nexus 7K/5K/2K, MDS, & UCS).

Happy Labbing!

Feb
25

Do you think you have what it takes to become a featured instructor at INE? We are looking for talented individuals to propose and execute new courses across multiple domains including: networking, programming, systems administration, and security. If you’re an expert in any of these domains, or related topics, then it’s time to share your knowledge with the world! Speak a language other than English? That’s great! We’re open to ideas for courses in different languages.

Click here for more information and to submit an application.

Not interested in becoming an instructor but have some ideas for content you’d like to see us cover? Drop us a line at topics@ine.com.

Feb
04

Troubleshooting Lab 3 and Full Scale Lab 3 have now been added to the CCIE RSv5 Workbook!

The new Troubleshooting Lab 3 uses the Full Scale Lab 1 logical topology, but breaks all of the protocols you’ve previously built. I suggest you take your time with each ticket so that you can fully digest why each fault occurs. Practice your time and knowledge skills by taking the Troubleshooting Lab 3 challenge!

Full Scale Lab 3 is built on a brand new logical topology, and has a strong focus in MPLS and BGP technologies. The solution guide features detailed breakdowns of each topic domain to give you a better understanding of the solutions used to solve each task. Keep in mind that there are multiple ways to solve most problems.

For discussion on these new labs visit our online community, IEOC.

Enjoy!

Tags: , ,

Dec
16

Foundation Lab 2 has now been added to the CCIE RSv5 Workbook.  This lab is great for working on your configuration speed and accuracy when combining multiple technologies together.  It also has a great redistribution section that I hope you’ll all enjoy ;)  More Full Scale, Troubleshooting, and Foundation labs are in progress and will be posted soon.  I’ll post another update about them when they are available.

In addition to this we’ve added some feature enhancements to the workbook in response to customer requests and feedback.  First, there is a new Table of Contents for the workbook that allows you to view all tasks, and to check off tasks that you’ve already completed.  This will help you track your progress as you’re going through the workbook.

You can additionally check off the progress of a task in the upper right hand portion of the individual lab page.

Multiple bookmarks are now supported, and will be added to a section under the Table of Contents.  When you open the workbook it will now also prompt you to load your latest bookmark.

Lastly, configuration solutions are now hidden by default when you open a lab.  This will help prevent “spoilers” in the config before you’ve had a chance to attempt the lab.  To see the solution configs, click the Expand button as seen below.

If you want to hide the configuration solution again you can click to collapse.

We’re always looking for additional ways to improve our products, so if you have any suggestions you can submit feedback through the workbook labs themselves, post on our Online Community, or feel free to send me an email directly at bmcgahan@ine.com.

Happy labbing!

Tags: , , ,

Dec
04

Click here to download the INE VIRL topology and initial configs

After long anticipation, Cisco’s Virtual Internet Routing Lab (VIRL) is now publicly available. VIRL is a network design and simulation environment that includes a GNS3-like frontend GUI to visually build network topologies, and an OpenStack based backend which includes IOSv, IOS XRv, NX-OSv, & CSR1000v software images that run on the built-in hypervisor. In this post I’m going to outline how you can use VIRL to prepare for the CCIE Routing & Switching Version 5.0 Lab Exam in conjunction with INE’s CCIE RSv5 Advanced Technologies Labs.

The first step of course is to get a copy of VIRL. VIRL is currently available for purchase from virl.cisco.com in two forms, a “Personal Edition” for a $200 annual license, and an “Academic Version” for an $80 annual license. Functionally these two versions are the same. Next is to install VIRL on a hypervisor of your choosing, such as VMWare ESXi, Fusion, or Player. Make sure to follow the installation guides in the VIRL documentation, because the install is not a very straightforward process. When installing it on VMWare Player I ran into a problem with the NTPd not syncing, which resulted in the license key not being able to register. In my case I had to edit the /etc/ntp.conf file manually to specify a new NTP server, which isn’t listed as a step in the current install guide. If you run into problems during install check the VIRL support community, as it’s likely that someone has already run into your particular install issue, and a workaround may be listed there.

Once VIRL and VM Maestro (the GUI frontend) is up and running, the next step is to build your topology. For the INE CCIE RSv5 Advanced Technology Labs, this topology will be 10 IOS or IOS XE instances that are connected to a single vSwitch. All you need to do to build this is to add the 10 IOS instances, and then connect them all to a single “Multipoint Connection”. Logical network segments will then later be built based on the initial configurations that you load on the routers for a specific lab. The end result of the topology should look something like this:

You may also want to add some basic customization to the topology file and the VM Maestro interface. I set the hostnames of the devices to R1 – R10 by clicking on the router icon, then setting the “Name” under the Properties tab.

Next under the File > Preferences > Terminal > Cisco Terminal you can set the options to use your own terminal software instead of the built in one. In my case I set the “Title format” variable to “%s”, which makes it show just the hostname in the SecureCRT tab, and set the “Telnet command” to “C:\Program Files\VanDyke Software\SecureCRT\SecureCRT.exe /T /N %t /TELNET %h %p”, which makes it spawn a SecureCRT tabbed window when I want to open the CLI to the routers. Your options of course may vary depending on your terminal software and its install location.

Next, click the “Launch Simulation” button on the topology to start the routers. Assuming everything is correct with your install, and you have enough CPU & memory resources, the instances should boot and show the “ACTIVE” state, similar to what you see below:

If you right click on the device name you’ll see the option to telnet to the console port. Note that the port number changes every time you restart the simulation, so I found it easier just to launch the telnet sessions from here instead of creating manual sessions under the SecureCRT database.

You should now be able to connect to the consoles of the routers and see them boot, such as you see below:

R1 con0 is now available

Press RETURN to get started.

**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS  *
* education. IOSv is provided as-is and is not supported by Cisco's      *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any       *
* purposes is expressly prohibited except as otherwise authorized by     *
* Cisco in writing.                                                      *
**************************************************************************
R1>
R1>enable
R1#show version
Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Experimental Version 15.4(20141119:013030) [jsfeng-V154_3_M 107]
Copyright (c) 1986-2014 by Cisco Systems, Inc.
Compiled Tue 18-Nov-14 20:30 by jsfeng

ROM: Bootstrap program is IOSv

R1 uptime is 46 minutes
System returned to ROM by reload
System image file is "flash0:/vios-adventerprisek9-m"
Last reload reason: Unknown reason

This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Cisco IOSv (revision 1.0) with  with 484729K/37888K bytes of memory.
Processor board ID 9B2DD0A36JBLXZY7SLJTF
2 Gigabit Ethernet interfaces
DRAM configuration is 72 bits wide with parity disabled.
256K bytes of non-volatile configuration memory.
2097152K bytes of ATA System CompactFlash 0 (Read/Write)
0K bytes of ATA CompactFlash 1 (Read/Write)
0K bytes of ATA CompactFlash 2 (Read/Write)
1008K bytes of ATA CompactFlash 3 (Read/Write)

Configuration register is 0x0

R1#

With this basic topology you should have the 10 IOSv instances connected on their Gig0/1 interface to the same segment. The Gig0/0 interface is used for scripting inside the VIRL application, and can be shutdown for our purposes. The end result after the images boot should be something similar to this:

R1#show cdp neighbor
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay 

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
R9.openstacklocal
                 Gig 0/1           177              R B   IOSv      Gig 0/1
R8.openstacklocal
                 Gig 0/1           167              R B   IOSv      Gig 0/1
R3.openstacklocal
                 Gig 0/1           155              R B   IOSv      Gig 0/1
R2.openstacklocal
                 Gig 0/1           177              R B   IOSv      Gig 0/1
R7.openstacklocal
                 Gig 0/1           156              R B   IOSv      Gig 0/1
R6.openstacklocal
                 Gig 0/1           146              R B   IOSv      Gig 0/1
R5.openstacklocal
                 Gig 0/1           129              R B   IOSv      Gig 0/1
R4.openstacklocal
                 Gig 0/1           153              R B   IOSv      Gig 0/1
R10.openstacklocal
                 Gig 0/1           146              R B   IOSv      Gig 0/1

Total cdp entries displayed : 9

Next you can load your initial configs for the lab you want to work on, and you’re up and running! I’ve taken the liberty of converting the CSR1000v formatted initial configs for our Advanced Technologies Labs to the IOSv format, as the two platforms use different interface numbering. Click here to download these initial configs as well as the .virl topology file that I created.

For further discussions on this see the IEOC thread Building INE’s RSv5 topology on VIRL.

Tags: , , , , , ,

Nov
24

A long time student of INE, Neil Moore has done it again, last time becoming the worlds first 7x CCIE, and this time becoming the worlds first and only 8x CCIE. And no, he doesn’t work for Cisco.

As a side note, INE has been experiencing phenomenal growth, and tremendous passing rates for people that have been sitting our R&S, Data Center and Collaboration bootcamps. In fact, of just the bootcamps we’ve held this year, nearly all of our students have reported back to us a pass in the 3-4 weeks following their bootcamp experience. Now mind you, these folks come to us studied up and prepared for the bootcamp, but they all credit us as being the deciding factor in their pass.

We’re also adding new content all the time, including Python scripting, Openstack and SDN such as OVS. Check out our Black Friday deals and grab an All Access Pass or sign up for a bootcamp and check out what’s new!

Tags:

Oct
28

Cisco has announced their plans to transition the CCIE Service Provider certification blueprint from Version 3.0 to Version 4.0 starting May 22nd, 2015.  The official announcement for the Written and Lab Exam Content Updates can be found here.

There are four key points to this announcement, which are:

  • Lab Exam format changes
  • Hardware & software version changes
  • New technical topics added
  • Old technical topics removed

CCIE SPv4 Lab Exam Format Changes

The Lab Exam format of SPv4 has been updated to follow the same format as the new CCIE Routing & Switching Version 5.0.  This means the exam now consists of three sections: Troubleshooting, Diagnostic, and Configuration.

CCIE SPv4 Hardware & Software Version Changes

Following along with the current CCIE RSv5, CCIE SPv4 now uses all virtual hardware as well.  Specifically the new hardware and software variants are as follows:

  • ASR 9000 running Cisco IOS XR 5.2
  • ASR 1000 running Cisco IOS XE 3.13S.15.4(3)S
  • Cisco 7600 running Cisco IOS 15.5(3)S
  • Cisco ME 3600 running Cisco IOS 15.5(3)S

Both the IOS XR and IOS XE variants are already available as virtual machines that you can download from cisco.com and deploy yourself on VMWare ESXi 5.5 and other similar hypervisors.  The current IOS XRv release is 5.2.0, and CSR1000v (IOS XE) is 3.13S/15.4(3)S.  As for the 7600 and ME 3600 images, I would assume these will run as L2 IOU/IOL images, however I haven’t personally seen either of these complies yet.  The key functionality of them will be based around L2VPN for Ethernet, such as EVC and VPLS, which is not covered in depth in the current SPv3 blueprint.

CCIE SPv4 New Technical Topics Added

With the new IOS XR, IOS XE, and Catalyst IOS code versions used, the following is some of the key new features that have been added to the SPv4 Blueprint:

  • Ethernet VPN (EVPN)
  • Provider Backbone Bridging EVPN (PBB-EVPN)
  • Multicast Label Distribution Protocol (mLDP)
  • Unified MPLS (Seamless MPLS)
  • Locator/ID Separation Protocol (LISP)
  • mGRE VPN
  • IPv6 NAT44/NAT64/6RD
  • MPLS OAM & Ethernet OAM

CCIE SPv4 Old Technical Topics Removed

Frame Relay and ATM, the old holdouts for years, have finally been removed from the CCIE Service Provider Blueprint.  This was expected, as most L2VPN services now focus on Ethernet last mile (EVC, VPLS, L3VPN over Ethernet) vs. legacy Frame Relay and ATM.

More information about our plans for content updates will be available as we get closer to the official release date of the new blueprint.  In the meantime for those of you that want to get in before the Blueprint change I would recommend to book a lab date as soon as possible, and start reviewing our CCIE Service Provider v3 Advanced Technologies Class and CCIE Service Provider v3 Workbook.

Tags: , ,

Categories

CCIE Bloggers