CCIE: The Begining Of A New Task

This is the new beginning of a long and arduous task. After considering hard and taken a long time doing that, I have decided to go for this exclusive and yet at times elusive certification, the grand mama of all Cisco certifications, the Cisco Certified Internetwork Expert (CCIE). Ok it was some time ago, but this blog only started today ;-).

I have just bought IPExpert's Blended Learning Solution for the CCIE R&S track. I spoke to Matt Brooks who was nice enough to spend time answering my many questions. After doing a bit of more research and also gotten a cool discount from Mike Down's blog, I took the plunge to spend over USD 900 for the package.

I am now waiting impatiently to receive the portable hard disk drive from IPExpert and start studying a little :-). Let's hope they arrive within this week?

As some of you may be aware, I am yet to complete my CCNP (ONT left). However, I figure that since the CCIE R&S track depends mostly on the BSCI and BCMSN part, I would like to study further into this area.

I have gotten myself 13 USB LAN adaptors which will complement my Dynamips setup on my Core2Duo laptop for the labs to link up with the 4 units of Cisco 3560 switches (8-ports model unfortunately). It will be a challenge itself to get this setup but I have gotten a head start by utilizing Scott Vermillion's topologies (Scott happens to use just a Mac Mini plus 4 units of Cisco 3560 switches to pass his CCIE R&S exam).

As of now, I am flipping through my BSCI books to try and refresh all the routing protocols in my head especially my favourite routing protocol, EIGRP.

Read More

The Release Of Cisco IOS V 15.0

Cisco is playing with numbers again and this time its IOS is the victim ;-). Jumping from 12.4 to 15 lets you know that Cisco is 'afraid' of the numbers 13 and 14 (number 13 is considered unlucky in the Western culture and number 14 (because of the 4) in Asian culture).

IOS release 15.0
This is not an April 1st post: I’ve just realized that Cisco quietly released IOS 15.0M (mainstream). Haven’t tested it yet, but the images for a large variety of platforms are already available on CCO. The new features listed in the documentation include:

    Full BFD support, including static routes, BFD-in-VRF and BFD-over-Frame Relay (next step: test it on a 2800-series router);
    DHCP authentication;
    DMVPN tunnel health monitoring;
    EEM 3.1 (whatever that is, the EEM documentation hasn’t been updated yet);
    Interaction between IS-IS and LDP;
    BGP local convergence in MPLS VPN networks (the feature has already been available 12.2 SRC, now it’s available on more platforms);
    OSPF graceful shutdown and OSPF TTL security check features are available on more platforms;
    Intra-zone traffic inspection in zone-based firewall.

It looks like (as expected) the 15.0 release is a grand merge of all previous IOS trains (with a few extra features). Good job; finally we have something new to play with :)

Read More

Learning Unicast Reverse Path Forwarding - URPF

Unicast Reverse Path Forwarding is a small security feature
When configured on an interface, the router checks the incoming packet’s source address with its routing table. If the incoming packet’s source is reachable via the same interface it was received on, the packet is allowed. URPF provides protection again spoofed packets with unverifiable source.
Though basically a single line command, URPF can be a little confusing when used with access-list feature if order of operation is not understood completely.
We’ll use this simple topology to demonstrate URFP.

R1 and R2 are connected through frame-relay and a Ethernet connection.
We test our basic connectivity.

R2#ping 150.1.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/93/192 ms

R1#ping 150.1.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/45/84 ms

R1#ping 150.1.21.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.21.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/54/100 ms

All right we have reachability on both Ethernet and frame relay interfaces.
In order to demonstrate URPF we use two static routes on R1 and R2.
R1 uses frame-relay to reach R2’s loop back (2.2.2.2/24) and R2 user Ethernet to reach R1’s Loopback (1.1.1.1/24)

R1(config)#ip route 2.2.2.0 255.255.255.0 150.1.12.2
R2(config)#ip route 1.1.1.0 255.255.255.0 150.1.21.1

Without URPF, we should be able to ping R2’s loopback from R1’s loopback.

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/48/80 ms

Now we enable URPF on frame-relay interface on R2.
Now when the incoming packet arrives at the frame interface, R2 checks the source address (1.1.1.1/24) in its routing table.
Since the interface used to reach this address is Ethernet0/0 , URPF checks fail and ping is not successful.

interface S1/0
ip address 150.1.12.2 255.255.255.0
ip verify unicast reverse-path

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)


All right!
This was the most simple part.
Now we use URPF with an access-list.

Understanding URPF Order of Operation:

Here we have to understand the order of operations.

1) When packet arrives at the interface, URPF check is done. If the check is successful, the packet is transmitted, and ACL doesn’t come into play
2) If the check is failed, ACL is consulted. Traffic is allowed or denied based on ACL entries.
3) The thing to understand here is that an ACL with deny any any will not mean that all traffic is denied. It won’t come into play unless the URPF check is failed. If URPF check is successful all traffic is allowed. If it is failed then ACL is checked an traffic is allowed or denied based on the ACL.

R2:
!
interface Serial1/0
ip address 150.1.12.2 255.255.255.
ip verify unicast reverse-path 101

access-list 101 permit tcp any any
access-list 101 deny ip any any log-input

Here we are allowing the TCP traffic and denying all other traffic in ACL.
It means that a telnet sourced from the LoopBack 0 of R1 to LoopBack 0 of R2 will be successful, but all other traffic will be denied.

From R1:
R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 ... Open


Password required, but none set

[Connection to 2.2.2.2 closed by foreign host]

Success rate is 0 percent (0/5)
R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)


Below is the log generated by ACL.

*Mar 1 00:16:40.171: %SEC-6-IPACCESSLOGDP: list 101 denied icmp 1.1.1.1 (Serial1/0 ) -> 2.2.2.2 (0/0),

Now lets ping the loopback with source frame-relay interface.

R1#ping 2.2.2.2 source S1/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 150.1.12.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/48/80 ms

As you can see that though ACL is denying all ICMP traffic our ping is successful.
For the simple reason that ACL won’t be checked until URPF check is failed. And in the above case, it’s successful.


Now lets change the ACL.
Now our intention is to allow HTTP traffic between the loopbacks as well as ICMP traffic and deny all other traffic.

R2:
access-list 101 permit tcp any any eq www
access-list 101 permit icmp any any
access-list 101 deny ip any any log-input

We’ll be able to ping or telnet at port 80 but regular telnet will fail

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/57/80 ms
R1#telnet 2.2.2.2 80 /source-interface loopback 0
Trying 2.2.2.2, 80 ... Open


R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 ...
% Connection timed out; remote host not responding

R2: (:Log)
*Mar 1 00:20:18.895: %SEC-6-IPACCESSLOGP: list 101 denied tcp 1.1.1.1(35617) (S
erial1/0 ) -> 2.2.2.2(23), 1 packet


Well thats about it for URPF.
In lab exam if the feature shows up, be careful, as it can break connectivity if routers have asymmetrical routing.
Asymmetrical routing is not a problem in LAB generally as long as we have connectivity, but with URPF enabled, asymmetrical routing will break connectivity.
In that case,we can either tune unicast routing table or use the access-list with URPF to allow for connectivity.

Read More

Early Impressions of IEWB VOL 1 VER 5

A lot of people work differently, and when it comes to preparing for CCIE lab everyone has a different strategy.

Me, I am more of a reader than a handyman :) that is to say, I spend most of the time reading and far less time labbing. Even in the time I lab, I spend most of time making short labs, testing technologies than doing full scale labs. One reason is that I only have 10 dynamips IEWB full scale labs and I already did them twice anyway.

Recently I requested Brian Mcghann and Petr from InternetworkExpert to allow me access to their Vol 1 Beta labs and very generously they did. I am a customer of IE but due to financial constraints, I bought only first 10 dynamips labs and so the vol 1 beta access wasn’t automatically there for me.
While I am going through the labs, I must say I am impressed and there is also a feeling of déjà vu. My company financed Narbik’ bootcamp and hence I received his advance technologies workbook. I loved that. Basically Narbik took a technology and beat that to death. Quite similar approach of these Beta labs. When it comes to me, I’d prefer such approach above all other that is to learn everything about a technology rather than doing 40 full scale labs. Even before I went to Narbik’s bootcamp, my method of preparation was to read say 15 pages of documentation a day, and lab them up in small labs on dynamips. Narbik’s labs saved time I spent for cooking up a topology to test a feature.

I have not seen existing versions of Vol 1, but from what I heard those were very basic. These beta labs are not.

Though I am waiting for OSPF, security and QOS Vol 1 labs, and only after that I can rate these VOL 1 labs completely, I have to admit, I really liked these labs up till now. I even learned one new feature of EIGRP which is EIGRP stub routing with leak maps. If I were to advise anyone on how to prepare, my advice would be to go through Narbik’s Advance Technologies Workbook or( if by that time these VOL 1 labs are out) these VOL 1 beta labs, very slowly.

Do each technology in a week, and not only do the labs, read documentation about every feature and learn it properly. And at the end, do 10-20 full scale labs.

Anyway here are my initial impressions of the labs.



Bridging and Switching:

As I mentioned, my idea of technology labs is to cover all about a technology.

I feel bridging and switching sections should include small labs on following topics

IRB (Integrated Routing and Bridging). Of course, we’ll use routers for this J but technology wise the feature should be here
DAI (Dynamic Arp Inspection) (Though this topic can be potentially included in security. As I mentioned I need to see the security and QOS, before having a complete idea, as many feature I’d like to see can fall under switching as well as under these two topics. For me, DAI is more of a switching topic.)
MVR (Multicast VLAN Registration) And IGMP snooping, IGMP Profile commands etc. But then again, these features may have been covered in Multicast sections. Also IGMP snooping and DAI are inter-related, so for me these should be a part of switching.
SDM Templates
More explanation in lab 1.18. Trunk ether channel over DOT 1 Q tunnel can cause a lot of problems, if we are not sure of STP and VTP paths throughout our network. Instead of shutting down the links that can cause problems, these problems should be explored.
Port Security. ( Again, can be covered in security beta labs)


Frame Relay:

I again learned a new feature, bridging over frame relay and I thought I knew everything about frame relay.

Excellent


RIP:



Excellent labs,

Covering all the topics I think are necessary to learn RIP.



EIGRP:

I learned a new feature here. I can’t make it work though on dynamics unless I add the match interface option in Eigrp Stub Leak Route map.

This needs more research on my part though.

I’ll lab this up over the weekend, and maybe right a tutorial after understanding the feature completely.


Also, I believe strategy wise, IE is on right track.

I’ve known people going through full scale labs rigorously. This approach of learning everything, before doing full scale labs is what I’d recommend and I’ve followed.

I am really looking forward to QOS section, especially Catalyst QOS.

Read More

TTL Security Vs eBgp-Multihop

To understand the relation first lets explore what each feature job and purpose in life:
eBgp-multihop – like in IGP the default ttl for packets is 1 and that is to ensure delivery only to the directly connected network node, but unlike IGP eBgp is often (in real networks) established via interface loopback and because packet generated / sourced from Interface loopback going out the router using its next hop interface that break the communication as 1-1 = 0 and 0 TTL mean packet can’t be delivered to destination,

so what to do?
increase TTL (is the answer :-))
using the eBgp-multihop is like simply indicating what TTL should be set to the packet to ensure delivery to the desired network

ttl-security – so we now understand the eBgp affect packet going out of our system by manipulating its TTL,
How do I prevent neighbor coming 10 hops away from me?!
you set the ttl-security.

Now you will say, if you didn't want to be neighbor do not set him up on your side and that would be also ok, but lets say you have neighbor relation with 2 router and each is 3 hops away (normally)  now one router experienced a link fail causing it to change route to reach you and now he is 5 hops away, and your policy is to maintain neighbor relation with no more then 3 hops away.

but again you would say, so set the eBgp-multihop to 3 (or 4 if using the loopback) and you would be again correct.

so why ttl-security, mainly it is to prevent DoS attack!

hope this helped in some way to understand the difference and each feature job in life.

Read More

Cisco Introduced Changes to CCIE Lab, Scoring And Written Exam Question Format

Effective February 1, 2009, Cisco will introduce a new type of question format to CCIE Routing and Switching lab exams. In addition to the live configuration scenarios, candidates will be asked a series of four or five open-ended questions, drawn from a pool of questions based on the material covered on the lab blueprint. No new topics are being added. The exams are not been increased in difficulty and the well-prepared candidate should have no trouble answering the questions. The length of the exam will remain eight hours. Candidates will need to achieve a passing score on both the open-ended questions and the lab portion in order to pass the lab and become certified.  Other CCIE tracks will change over the next year, with exact dates announced in advance.

Effective February 17th, 2009, candidates will also see two other changes in CCIE written exams. First, candidates will now be required to answer each question before moving on to the next question; candidates will no longer be allowed to skip a question and come back to it at a later time. Second, there will be an update to the score report. The overall exam score and the exam passing score will now be reported as a scaled score, on a scale from 300-1000. This change will not affect the difficulty of the current set of exams and will assure CCIE written exams will be consistent with Cisco’s other career certification exams.”

My view -> The written exam changes are logical, the lab exam ‘interview’ could result in protests if fails are handed-out based on it…

Read More

CCIE Collaboration Transition Technologies

I put together a new playlist on our All Access Pass geared toward helping those that have decided to study primarily with the new CCIE Collaboration in mind. What will be included in this playlist is primarily new technologies, specifically those that haven’t yet been covered elsewhere in our CCIE Voice v3 products. As the weeks go on, I will continue to update this list with more and more videos covering new technologies in UC v9.1. Keep in mind that until I have this list complete with everything that is newer than UCM 7.x, that you can and should still study all of our CCIE Voice v3 products, as everything except for H.323 RAS/Gatekeeper will still be completely relevant and a very much needed base for your understanding.


Once I complete this list, I will probably leave it up for those only wanting to learn the new stuff, like those of you that are already CCIE Voice v3 certified (if you certified on CCIE Voice v2 or v1, and haven’t really used it in a while, you’re going to want to watch all the material over again as quite a LOT changed from v2 to v3). Also, once I complete this playlist with all the new technologies, I will be recording a completely new top-to-bottom CCIE Collaboration Advanced Technologies Class, that will include everything. And of course, the workbook is being completely re-written as well in our new online format, which you can see a sample of here and here. This video playlist is meant to not only hold you over until then, but also to be able to release material to you in a timely, incremental fashion.

To start with, here is 4.5 hours of material on Call Control Discovery over Service Advertisement Framework (CCDoSAF). At a most basic description, this is dynamic routing of DNs over an enhanced version of EIGRP. It is much more detailed and complex than ILS (a newer built-in dynamic routing in UCM), but it is also far more powerful and allows for things like powerful SRST configurations as well as cluster-to-cluster PSTN failover, should the primary SIP trunk become un-usable. Cisco pushes ILS much more in production, but given my last statement, and the fact that no CCIE Lab exam has ever been that much interested in real-world design -favoring complexity over ease of configuration and good design- and the fact that it is very much on the new blueprint, I’d say you best get used to it now. Who knows, you might even like it once you see what it can do. Also, I recorded these videos on a UCM v8.5 cluster, but that shouldn’t matter as this feature hasn’t changed much since then.

Read More