Thursday, July 3, 2008

IPExpert´s Atomic Bomb!!!!

WTH! Narbik Kocharians "JOIN" Forces with IPExpert?!! Khawar Butt and Netmetric Solutions also?!? Free Stuff* (* read the IPExpert Newsletter to check that) ?!?! What is going on!!!!

IPExpert just released their "so expected" Newsletter! And man! They were right... It´s way BIGGER than last week Scott Morris thing!!!!

It looks like a new version of the "Could War", but this time there are no Atomic Bombs! Well... in fact there are many Atomic Bombs, but those doesn´t hurt us (I cannot say the same about the competition, hahaha)! 

IPExpert´s already great portfolio is becoming Bigger, Better, UNBEATABLE! That´s AWESOME! Take a look at this (took me sometime to believe in it too):

-----

July 3, 2008

A New Way of Thinking: All CCIE Training Products FREE (Workbooks, Videos, Audio Lectures, more!)

IPexpert and Narbik Kocharians (Triple-CCIE) Join Forces

IPexpert Partners with Khawar Butt (Quad-CCIE) and Netmetric Solutions

CCIE Blog_ to Launch This Month... and We Want You to Join!

Everything IE – the Ultimate CCIE Social Community Announced

NEW Blended Learning Solution Interface ALREADY Enhanced (MUST SEE)

$100,000 Training Giveaway WINNERS Announced Here! (Watch video of the party!)

2,000 HOURS Worth of Rack Rental to be GIVEN AWAY in July!

Which Vendor has the MOST Successful Students to Its Credit?

-----

I can´t wait to see all this stuff! EverythingIE is just a genius idea! Who needs Facebook or MySpace anymore?! Hahahahah!

Narbik! I can´t believe ! That´s so cool! :)

Oooh yeah! And not forgetting, but the Blended Learning Solution is now priced at $999.00 (mine is already on the way!! )!

Who will win this battle?! Everybody! Due to the "Could War" between IPExpert, NMC, Internetwork Expert, and many others, pushing all of them to develop even greater material than they already have, customers will win, companies will win, we all win! As I stated before, competition is good, even more if it´s practice with ethics (no copycats allowed!!!!!) !!!

It´s all up to us on how to follow this path, choose the  vendor that pleases you the most, army yourself with the best Workbooks, Bootcamps, Solutions and start sweating!  I´ve already chosen mine, do I need to say anything else?! ;)

OH! Don´t forget to check the video of IPExpert´s Party! You MUST see that girl over there!!!!

Frame-Relay LMI Basics

So... continuing with our Frame-Relay stuff, let´s take a look at our friend Local Management Interface (or LMI, as it preffers to be called). ;)

LMI is the protocol that exchanges information between your Router and the Frame-Relay Switch, it´ll carry information about DLCI status, Keepalives, etc. You can monitor the LMI traffic from your Router using the "debug frame-relay lmi" command.

Follows an output from a debug:

R1#debug frame-relay lmi
*Mar 1 00:15:13:Serial1/0(out):StEnq,myseq 52,yourseen 51,DTE up
*Mar 1 00:15:13: datagramstart = 0x7A01894, datagramsize = 14
*Mar 1 00:15:13: FR encap = 0x00010308
*Mar 1 00:15:13: 00 75 95 01 01 01 03 02 34 33
*Mar 1 00:15:13:
*Mar 1 00:15:13: Serial1/0(in): Status, myseq 52, pak size 14
*Mar 1 00:15:13: RT IE 1, length 1,
type 1
*Mar 1 00:15:13: KA IE 3, length 2, yourseq 52, myseq 52

...output omitted...

*Mar 1 00:16:43:Serial1/0(out):StEnq,myseq 61,yourseen 60,DTE up
*Mar 1 00:16:43: datagramstart = 0x7C08474, datagramsize = 14
*Mar 1 00:16:43: FR encap = 0x00010308
*Mar 1 00:16:43: 00 75 95 01 01 00 03 02 3D 3C
*Mar 1 00:16:43:
*Mar 1 00:16:43: Serial1/0(in): Status, myseq 61, pak size 24
*Mar 1 00:16:43: RT IE 1, length 1, type 0
*Mar 1 00:16:43: KA IE 3, length 2, yourseq 61, myseq 61
*Mar 1 00:16:43: PVC IE 0x7 ,length 0x3 , dlci 102, status 0x2
*Mar 1 00:16:43: PVC IE 0x7 ,length 0x3 , dlci 103, status 0x2

So, what can we understand about this output!? Hmmm... good question! Just checking it, we can identify that the first part is just a normal Keepalive, and the second one means a Full Status Update... Here is how we checked it:

Type 1 - is a Normal Keepalive (sent every 10 seconds by default)

Type 0 - is a Full Status Update, it is sent every 6th Keepalive, that means, if you don´t change the defaults, it´ll be sent every 60 seconds, and it´ll include the DLCI status, which can be:

-> 0x0 means "inactive"

-> 0x2 means "active" (the status we normally want!)

-> 0x3 means that the active DLCI cannot accept more traffic without drops ocurring - kind of a flow-control code

-> 0x4 means "deleted" 

So, checking the previous output we can see dlci 102, status 0x2, that means DLCI 102 is Active!

We can also check that using the "show frame-relay pvc" command:

R1#sh frame-relay pvc

PVC Statistics for interface Serial1/0 (Frame Relay DTE)

              Active      Inactive      Deleted       Static
  Local          2            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI=102, DLCI USAGE=LOCAL, PVC STATUS=ACTIVE,INTERFACE=Serial1/0

  input pkts 11            output pkts 7            in bytes 1074
  out bytes 588            dropped pkts 0       in pkts dropped 0
  out pkts dropped 0       out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0         out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 2         out bcast bytes 68
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:07:21, last time pvc status changed 00:07:11

DLCI=103, DLCI USAGE=LOCAL, PVC STATUS=ACTIVE,INTERFACE=Serial1/0

  input pkts 1             output pkts 4            in bytes 34
  out bytes 136            dropped pkts 0       in pkts dropped 0
  out pkts dropped 0       out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0         out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 4         out bcast bytes 136
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:07:22, last time pvc status changed 00:07:12

There are some good fields to be checked in this output, for example, the PVC STATUS and the DLCI USAGE.

The PVC Status can can have four possible states:

ACTIVE - PVC is up and functioning normally.

INACTIVE - PVC is not up end-to-end. This can be caused by several problems, like incorrect mapping (or no mapping at all) for the local DLCI in the frame-relay cloud, or the remote end of the PVC is Deleted!

DELETED - Either there´s no LMI being exchanged between the router and the local frame-relay switch (normally from PTT), or the frame-relay switch (again, normally this frame-relay switch belongs to the PTT) doesn´t have this specific DLCI configured.

STATIC - No keepalive configured on the frame-relay interface of the router.

And finally, the DLCI USAGE field can have one of the following entries:

SWITCHED - that means, this router is been used as a Frame-Relay Switch.

LOCAL - the Router is used as a Data Terminal Equipment (DTE).

UNUSED - the DLCI is not configured on the router (that means, you haven´t configured this DLCI under any interface).

Some good references at Cisco´s Website are:

http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_cfg_frm_rly_ps6350_TSD_Products_Configuration_Guide_Chapter.html

http://www.cisco.com/en/US/tech/tk713/tk237/technologies_tech_note09186a008014f8a7.shtml

Wednesday, July 2, 2008

Proctor Labs R&S eBook first thoughts and interesting Frame-Relay task

This morning I was checking the Proctor Labs R&S eBook, from IPExpert... very nice. I was just taking a quick look to check it, to see how it´s organized, not with the intention of performing the full-scale lab right now!

Solutions guide (ok, I´m not supposed to, but I just  "had" to take a  look inside, just to check how it looks like, and I only saw the very first tasks, I swear!!!). I really liked the way the tasks were depicted over there, it looks like the guy who wrote it is "talking to you", very, very nice way to do it! :)

Regarding the frame-relay tasks (the ones that I saw), it gives you commands, including outputs and what to check in it! Also, it shows how to approach the task, with very informative explanations in each section!

One of the tasks in particular "called" my attention...:

2.2 Frame-Relay full status updates should take place every 10 seconds.

Hmmm... interesting! Tricky one... By default a full status update in Frame-Relay is done every 6th Keepalive!

Also, we know that Keepalives in Frame-Relay (by default) are set to 10 seconds! So, how can we achieve the goal in this task?! Simple, just setting the "full status pooling interval" to be 1! That means, Full Status Update will be done every Keepalive exchange (10 seconds!).

The command achieve this task´s request is:

frame-relay lmi-n391dte <keep-exchanges>, where the <keep-exchanges> means the number of times Keepalives needs to be exchange before the Full Status Update! For this specific task we used the command: frame-relay lmi-n391dte 1

More information about this can be found at the DocCD:

http://www.cisco.com/en/US/docs/ios/wan/command/reference/wan_f2.html#wp1011630

I haven´t read the full workbook, or even tried it in real equipments yet, but I´m very happy with what I´ve saw so far! :D

Tuesday, July 1, 2008

New Life, New way of Study, New Friends!

Last friday I blogged about a decision I had to made! And today (finally) I was able to make it!

Starting from now I´ll be using IPExpert´s Workbooks, Video on Demand, Audio Books, everything! It´s an exciting new path to follow towards my CCIE.

IPExpert is a Leading Company in the market, founded in 2001, with  "AMAZING" products, and now they´re also my friends, my partners,  my coachs  towards this difficult road I decided to follow! The CCIE R&S road!

I´ve just ordered their Blended Learning Solutions for the Cisco CCIE R&S, which consists in a 100GB HardDrive, with "everything" in it! It´s so cool! Nice, good looking, portable and I can plug it anywhere! Can´t wait to put my hands in this little baby!

Also according to the IPExpert Twitter, tomorrow we´ll have great news in the Newsletter! Wait and see!!!

Thank YOU all!!!

Cute little OSPF Problem crashing a Network!

This morning I received a ticket to check a network down issue...

According to the description, customer had an isolated site, represented in the diagram bellow by Router R3 (by the way, here I´m working in a fictitious network, to avoid showing our customer data):

OSPF Router ID

First things first... it could be a link failure (there´s only one  exit from R3 to the core´s network, and that´s S1/0, and as far as the site is isolated,  any engineer would check the link first) and that was exactly what I did. To my surprise link was UP!

Ok, so link is up... I was able to ping to other side of the link, also a good sign... just did a quick check at the router configuration, and found that it´s running OSPF.

Checked the neighbor relationship between it (R3) and it´s neighbor router R2. Again, everything looks pretty much fine so far!

The real problem began to reveal itself when I checked R3 routing table... R3´s routing table only had it´s connected network, plus the network 192.168.1.0... Hmmm... it seens to be an OSPF related issue!

R3#sh ip route
.

output omitted

.

Gateway of last resort is not set

    20.0.0.0/24 is subnetted, 1 subnets
C      20.3.3.0 is directly connected, Loopback1
    10.0.0.0/32 is subnetted, 1 subnets
C      10.3.3.3 is directly connected, Loopback0
O   192.168.1.0/24 [110/128] via 192.168.3.2, 00:00:02, Serial1/0
C   192.168.3.0/24 is directly connected, Serial1/0
    30.0.0.0/24 is subnetted, 1 subnets
C      30.3.3.0 is directly connected, Loopback2

Quick jumped to R2 to check it´s routing table... I´ve just found entries to R1´s network, plus it´s directed connected networks, nothing related to router R3.

R2#sh ip route
.

output omitted

.

Gateway of last resort is not set

     20.0.0.0/32 is subnetted, 1 subnets
O       20.1.1.1 [110/65] via 192.168.1.1, 00:00:02, Serial1/0
     10.0.0.0/32 is subnetted, 1 subnets
O       10.1.1.1 [110/65] via 192.168.1.1, 00:00:02, Serial1/0
C    192.168.1.0/24 is directly connected, Serial1/0
C    192.168.3.0/24 is directly connected, Serial1/1
     30.0.0.0/32 is subnetted, 1 subnets
O       30.1.1.1 [110/65] via 192.168.1.1, 00:00:02, Serial1/0

Ok, now I´ve found the problem... take a look at the neighbor relationship in R2 (using the show ip ospf neighbor command):

R2#sh ip ospf neighbor

Neighbor ID   Pri   State     Dead Time  Address      Interface
10.1.1.1       0    FULL/  -  00:00:33   192.168.3.3  Serial1/1
10.1.1.1       0    FULL/  -  00:00:37   192.168.1.1  Serial1/0

Can you see the problem?! Off course you can! Both routers(R1 and R3) have the SAME ROUTER ID!

I didn´t belived what I saw! Customer told me that "nobody" touched the router, at least for the last couple weeks!

Ok, just doing a debug ip ospf hello at R2 you can see the same issue... both routers (R1 and R3) using 10.1.1.1 as it´s Router ID.

R2#debug ip ospf hello
*Mar  1 00:11:16.039: OSPF: Rcv hello from 10.1.1.1 area 0 from Serial1/0 192.168.1.1
*Mar  1 00:11:16.043: OSPF: End of hello processing
*Mar  1 00:11:16.403: OSPF: Rcv hello from 10.1.1.1 area 0 from Serial1/1 192.168.3.3
*Mar  1 00:11:16.407: OSPF: End of hello processing

Taking a look at the routers ID, I´ve found R1 RID: 10.1.1.1, R2 RID: 10.1.1.2 and R3 RID: 10.1.1.1, asked the customer if I could change R3´s RID to 10.1.1.3 or if he had any other RID to be used, and received his GO-AHEAD to change it!

After entering the router-id 10.1.1.3 command in R3´s OSPF configuration, and off course, using a clear ip ospf process (in R3) things looked a lot better!

Take a look at R2´s neighbor table right now:

Rack1R2#sh ip ospf neighbor

Neighbor ID    Pri  State      Dead Time  Address     Interface
10.1.1.3       0    FULL/  -   00:00:33   192.168.3.3 Serial1/1
10.1.1.1       0    FULL/  -   00:00:37   192.168.1.1 Serial1/0

And finally, R2´s Routing Table with all posible routes:

Rack1R2#sh ip route
.

output omitted

.

Gateway of last resort is not set

     20.0.0.0/32 is subnetted, 2 subnets
O       20.1.1.1 [110/65] via 192.168.1.1, 00:00:05, Serial1/0
O       20.3.3.3 [110/65] via 192.168.3.3, 00:00:05, Serial1/1
     10.0.0.0/32 is subnetted, 2 subnets
O       10.3.3.3 [110/65] via 192.168.3.3, 00:00:05, Serial1/1
O       10.1.1.1 [110/65] via 192.168.1.1, 00:00:05, Serial1/0
C    192.168.1.0/24 is directly connected, Serial1/0
C    192.168.3.0/24 is directly connected, Serial1/1
     30.0.0.0/32 is subnetted, 2 subnets
O       30.3.3.3 [110/65] via 192.168.3.3, 00:00:05, Serial1/1
O       30.1.1.1 [110/65] via 192.168.1.1, 00:00:05, Serial1/0

So... with a 5 minute troubleshooting everything was fine! But this little issue kept our customer´s network down for a while, due to a mistake some "ghost" made in their router configuration!

You might be asking how the RID is selected / configured...:

1 - If you configure the RID with the command router-id <address> (example: router-id 10.1.1.1) under OSPF configuration mode, this manually configured RID is used;

2 - If no RID is configured, the router tries to use the higher Loopback IP Address it founds in the OSPF startup process;

3 - If no Loopbacks are configured, the routers uses the higher IP Address configured in any physical interface;

4 - If no RID is configured, and the router has no IP configured interfaces, the OSPF process cannot start!

Just be carefull while using OSPF RID, it has to be unique in your network! Otherwise, you can have huge problems! Keep your network well documented, and do not make changes in a live enviroment without studying the side-effects before actually doing it!

Friday, June 27, 2008

IPExpert response after Scott Morris move to Internetwork Expert?!

Take a look on what I´ve found while "surfing" the internet:

image

You can check it by yourself at IPExpert Twitter, it seens that they´re working fast in a response! Good! As I said in my earlier post, competition is one of the best things in the industry! Keeps everybody motivated!

Well... I think we´ll have to wait till monday to see what is going to be the big surprise! :)

In the mean time I´ll take the weekend off to make some decisions that will affect my studies, and my life directly... I just wonder why it has to be so hard ?! :( and no... I´m not giving up if that´s what you thought! hahaha!