• Because it's only part of the written exam.

  • There’s IS-IS videos in the CCIE Service Provider series if you’re interested in learning more about it.


    Brian McGahan, 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13
    [email protected]
    Internetwork Expert, Inc.


    From: [email protected] [mailto:[email protected]] On Behalf Of maschumach
    Sent: Sunday, March 29, 2015 4:47 AM
    To: Brian McGahan
    Subject: Re: [CCIE R&S General] ISIS on the exam


    Because it's only part of the written exam.

    INE - The Industry Leader in CCIE Preparation

    Subscription information may be found at:

  • ISIS is a very good protocol and quite simple to ocnfigure. Not messy like OSPF :-) It's good that Cisco put in RS written and i would like this to be a part of the lab as well :-(


    If u ask me , IS IS should not be on RS exam.


  • JoeMJoeM ✭✭✭

    I have been reviewing the written exam while I prepare for another lab attempt.   I was thinking the same thing.  Just my opinion.  I think that ISIS clouds the R&S track.  I have never worked with ISIS in a company network, but I have had plenty of opportunity to work with most of the other R&S LAB topics in real-life.

    As I remember it, an older version of the CCNP R&S exam had ISIS, and then they removed it.  I remember that it did seem easier to configure and was similar to OSPF, but I have completely forgotten the subject now. 

    I guess that my point is that there is so much to study with the current R&S track, why cloud it with an SP centric topic?  This is just a doubt that I had while reviewing the written topics.   

    I am interested in hearing opinions of this from people who actually work with ISIS outside of service providers.  Thanks.

  • From what I can tell, ISIS is being revived becaus of SDN.  I am not sure about Cisco's point of view, but other vendors are using it in their SND offerings. 

  • in the late 90's, I was a paper CCNP - basically studying to get the certs to get out of Microsoft work and into Networking - when I got layed off after the Y2k wind down, a friend recommended me to a contract position - first thing the guy said was "Well, we run IS-IS and DecNet" - I mentioned that I didn't know ISIS very well, and he said "Yah, no one does - but you'll learn, right?" - so it was literally my first serious Routing protocol - LOL

    The logic at the time was it integrated very well with DecNet and since they had Co-Lo's in Europe, Asia, and the US, it seemed easier to run a L2 backbone instead of an Area 0 backbone - I wasn't there for that decision making but I remember they also ran DecNet IV as teh Compaq Alphas didn't really like DecNet V.  I remember we had to be careful after a point as the L2 backbone got so big 2501's couldn't run as an L2 anymore without maxing the CPU at 99% - ah the good old days.   

    It's pretty easy to pick up the basics and just roll with it.


  • Cisco is using it in OTV for DC networks!


    From what I can tell, ISIS is being revived becaus of SDN.  I am not sure about Cisco's point of view, but other vendors are using it in their SND offerings. 


  • [;)]


    Cisco is using it in OTV for DC networks!

    Ugh, I feel like they come out with stuff faster than I can even find out about it, let alone learn it.  I don't know how these people with 3-4X CCIEs + JNCIEs find the time...


  • Not just OTV, but FabricPath as well. 

  • peetypeety ✭✭✭

    If u ask me , IS IS should not be on RS exam.

    Why not? You're an expert, right? You should be ready to demonstrate that you're an expert.

    I've taken at least two labs with ISIS on them, back in older days. Life goes on.

    It's OSPF all over again, but with distance-vector behavior out of the box (since every link has a metric of 10), and with a "strange" _net_ value that's a lot like the EIGRP process ID (where it has to [semi-]match between neighbors). I'd also argue that OSPF becomes distance vector on any network of FastEthernet and up, unless you're on Nexus gear.

  • peetypeety ✭✭✭

    I work at Microsoft, and our core engineers gave us a little briefing about why they decided to change.

    From my memory it included:

    - Faster convergence

    - ISIS can do dual stack, but with OSPF you need to run two versions on the same router.

    - ISIS played well with our RSVP tunnels and TE.

    - Required less router resources than OSPF once the core grew to be fairly large.


    I of course really can't speak to any of that, it's just what we were told.  I just need to get up to having a decent understanding so I can troubleshoot it if something goes wrong.

    From what I've heard, OSPF vs ISIS is a bit of a flame war, but maybe somebody with deep knowledge of both could speak to it?

    (I do too!) If ISIS converges faster, that's probably just an artifact of better coding, as the algorithm is the same (Djikstra [sp?]). ISIS can do dual stack, but at least in the Cisco world you'd better configure ISIS for multi-topology BEFORE you attempt to dual-stack your ISIS, or you're going down hard.

    I can't confirm (or deny) that ISIS plays better with TE or that it requires more/less resources. I can't imagine it's that significant.

    Back in perhaps '06, I switched a production network from OSPF to ISIS. It was 100% seamless. I did it to learn, but also on three somewhat logical assumptions: it would be more stable (as Cisco's engineers were a little more careful with their ISIS code, knowing that so many huge networks use it), it would be "different" than OSPF in case any of our MPLS VPN customers wanted to exchange routes with us using OSPF (none ever did, and eventually we decided we'd only do static or BGP anyway), and that no one could "packet bomb" us, since CLNS packets don't flow over the Internet and therefore couldn't be spoofed in.

    Back in perhaps '09, I switched that same network back to OSPF. We were exploring the use of Cat3550s as multi-tenant building breakout routers, and they didn't do ISIS no matter what code/feature set we used. The switch back was seamless, though not as easy: between '06 and '09, I'd deployed MPLS TE, and I discovered that TE autoroute ignores administrative distance. As a result, even though OSPF had a (temporary) high AD, the tunnels preferred to rely on OSPF information, and autoroute essentially stopped working. I ended up fast-tracking the cutover, and that got me out of a jam.

  • also, I should tell this story - We were a large international company that used the IS-IS and merged with another company that used OSPF - the plan eventually was to team up the international sites - so instead of two 256k ckts to Jakarta, one for us, and one for them, we'd have one circuit and then use a local ckt between the two sites to provide connectivity.

    And what I was TOLD was (and I don't think it's true anymore) you can't redistribute OSPF into ISIS or vice versa.  This was 2001, and it's possibly you couldn't do it back then - I checked the other day and I sure think you can now.

    SO the solution was two great big Central Core routers running BGP - and OSPF/ISIS were both redistributed into the BGP - and BGP back into them - and should we acquire another company, the same solution would work wonders for bringing them in.   Ah, memories.


  • I just want to point out humourously that in 2001 when we tried to merge our ISIS network with an OSPF one, we had to apparently redistribute OSPF into BGP and same with ISIS and then back out - I guess you couldn't redistribute OSPF into ISIS and vice versa back then.

    I just checked the 15.3 code and it says I can now :)

Sign In or Register to comment.