Friday, April 25, 2014

Thanks for all your shares and Google +1s for this new series!    Due to the great response, you'll now see these several times a week on the Bulldog Blog!

If you missed Part 1 of this discussion, just click that link to get caught up.   

CCNA And CCNP In-Depth Command Reference And Lab:

show ip ospf neighbor ---  Part Two!

In part 1 of this CCNA / CCNP command discussion, we tackled the Neighbor ID and Pri fields of the show ip ospf neighbor command's output (along with a review of the RID!).

Today, we'll start with the State field, and a curious little symbol we saw for one of our adjacencies.

Here's the network we're using for this discussion.  R3 has two adjacencies to R1 -- one via the NBMA network, and one via a point-to-point connection.  R2 isn't involved in this particular discussion.




Here's the current output of show ip ospf neighbor on R3:

R3#show ip ospf neighbor

Neighbor ID  Pri   State  Dead Time   Address    Interface
172.12.13.1   1   FULL/DR 00:01:53  172.12.123.1  Serial0


172.12.13.1   1   FULL/ - 00:00:38  172.12.13.1   Serial1


We see FULL/DR for the adjacency that goes through the cloud (interface Serial0).  Let's chat about that before we get to that funny little dash.

The first value, FULL, is the state of the adjacency.   While you may see different adjacency states there while the adjacency is being built, you're typically going to see FULL here once the network converges.   (If you don't, you're typically going to do some troubleshooting until it does say FULL.)  

FULL = GOOD.

The second value is the OSPF role of the neighboring router on that particular network segment -- not the role of the local router.   In this case, that particular neighbor is the Designated Router of that segment (DR).   

A fully adjacent neighbor will almost always be seen as having one of these three OSPF roles:

DR -- Designated Router

BDR -- Backup Designated Router

DROther --  Router other than the DR or BDR

Since this was an NBMA network and R1 is the hub, we needed to make sure that R1 was elected the DR and that no BDR was elected on that same network.  You never want a spoke router to become the DR or BDR, and we ensured that with the ip ospf priority command in Part 1.

Note that no adjacency is formed between our two spoke routers, R2 and R3.   Spoke routers on an OSPF NBMA network form adjacencies only with the hub, not with each other.


So..... if the DR / BDR / DROther concept is so important, why don't we have either of those on the other adjacency between R1 and R3?  What's the deal with that dash?


R3#show ip ospf neighbor

Neighbor ID  Pri   State 
172.12.13.1   1   FULL/DR

172.12.13.1   1   FULL/ -


The difference is that OSPF sees the adjacency formed through the frame relay cloud as a Non-Broadcast network, which will have DR / BDR elections....

R3#show ip ospf interface serial 0
Serial0 is up, line protocol is up
  Internet Address 172.12.123.3/24, Area 0
  Process ID 1, Router ID 172.12.123.3, Network Type NON_BROADCAST, Cost: 64

  Transmit Delay is 1 sec, State DROTHER, Priority 0

... and OSPF sees the adjacency formed through Serial1 as a point-to-point network, since there's a direct connection between the routers and no frame cloud between them.

R3#show ip ospf interface serial 1
Serial1 is up, line protocol is up
  Internet Address 172.12.13.3/24, Area 13
  Process ID 1, Router ID 172.12.123.3, Network Type POINT_TO_POINT, Cost: 64

  Transmit Delay is 1 sec, State POINT_TO_POINT,

I hear you asking "Hey, that's great, but what's that got to do with that dash?"


Stick with me.  : )

When OSPF was developed, there were really two choices when it came to spreading the word about a change in the network:

Possibility 1:  Let the router that detects the change scream about it to every other router on the segment, and then every router that hears about it can then scream about it, resulting in a lot of unnecessary screaming on the segment.

(Those screams are technically called "broadcasts", of course.  Don't call them "screams" in a job interview.)

Possibility 2: Let the router that detects the change report the change to the DR and BDR only, and then let only the DR let every other router on the segment know about it.

I'm sure you'll agree with me that approach #2 is much more efficient.   

So... what does this have to do with our point-to-point network?

By definition, a point-to-point network can only have two hosts. Whether it's R1 notifying R3 of a network change over that segment...

OSPF Point-To-Point Network


... or whether R3's telling R1 about a change....

Same OSPF Point-To-Point Network



... there's no other router on that segment to tell.   When that's the case, why have the overhead of a DR / BDR election when there's no need for one?  

That's where the dash comes in.  The router's telling us that the neighbor is neither a DR, a BDR, nor a DROTHER, because there was never an election on that segment in the first place!

There's a lot of information that goes into that little dash, isn't there?

We'll press on with our look at this command right after this very brief message from yours truly about your CCNA success!

The following is a time-sensitive offer!

We're contributing 20 meals to the Central Virginia Food Bank for every paid signup in April to any single-exam course, and a whopping 100 meals for every CCNP All-In-One Video Boot Camp.

Every single one of my single-exam courses is only $44, and my CCNP All-In-One course is only $99.  That includes unlimited access to every video in the course, and every video is also downloadable!

Click these banners to join us right now, and ignore the prices you see -- with these links, you save over 65%!



























ROUTE, TSHOOT, and SWITCH all in one course, and it's just $99 to join...


... and we'll donate 100 meals to the FoodBank!





























From all of us at TBA and everyone at the Central Virginia Food Bank -- thank you!

Now let's take a look at those Dead Times...

R3#show ip ospf neighbor

Neighbor ID  Pri   State  Dead Time
172.12.13.1   1   FULL/DR 00:01:53  

172.12.13.1   1   FULL/ - 00:00:38


Quite a difference here as well!   OSPF will set the Hello Timer to 30 seconds for a serial interface that's part of an NBMA network.....

R3#show ip ospf interface serial 0
Serial0 is up, line protocol is up
  Internet Address 172.12.123.3/24, Area 0
  Process ID 1, Router ID 172.12.123.3, Network Type NON_BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State DROTHER, Priority 0
  Designated Router (ID) 172.12.123.1, Interface address 172.12.123.1
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5

    Hello due in 00:00:10


... and OSPF will set a point-to-point link to a hello time of 10 seconds by default.

R3#show ip ospf interface serial 1
Serial1 is up, line protocol is up
  Internet Address 172.12.13.3/24, Area 13
  Process ID 1, Router ID 172.12.123.3, Network Type POINT_TO_POINT, Cost: 64
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

    Hello due in 00:00:02


That's all fine, but what about the DEAD timers, you ask?   

Well, OSPF Dead Timers are set to 4 times the Hello Timer by default, so you can always look at the Hello Timer and determine the Dead Timer setting.   

Or, perhaps on an exam or job interview question, you could see the output of show ip ospf neighbor and determine the Hello Timer by dividing the Dead Timer by 4 -- because this command shows you a lot of info, but nothing directly about the Hello Timer!

BONUS INFORMATION!

Quit yelling, already!

You can change either the OSPF Hello or Dead Timer directly with the ip ospf hello-interval and ip ospf dead-interval commands.  

R3(config-if)#ip ospf hello-interval ?
  <1-65535>  Seconds

R3(config-if)#ip ospf dead-interval ?

  <1-65535>  Seconds

Two important pointers about those commands:

1.  They're interface-level commands (ahem).

2.  When you change the Hello Timer with ip ospf hello-interval, the Dead Timer will dynamically adjust to four times the value you enter for the Hello Timer, as shown here:

R3(config-if)#ip ospf hello-interval 60


R3#show ip ospf int serial 0
Serial0 is up, line protocol is up
  Internet Address 172.12.123.3/24, Area 0
  Process ID 1, Router ID 172.12.123.3, Network Type NON_BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State DROTHER, Priority 0
  Designated Router (ID) 172.12.123.1, Interface address 172.12.123.1
  No backup designated router on this network

  Timer intervals configured, Hello 60, Dead 240, Wait 240, Retransmit 5

You'll also lose your adjacencies soon, since OSPF neighbors must agree on the Hello and Dead Timers in order to form an adjacency -- and in order to keep one!

11:51:22: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.1 on Serial0 from FULL to DOWN, Neighbor Down: Dead timer expired 

We'll wrap up right after this quick mention of some VERY important CCNA and CCNP success tools!


My CCNA Success! Study Guides are Amazon Best Sellers --

-- and if you don't have yours, NOW is the time to start reading!

Working on the single CCNA exam?  Grab them both!

personally guarantee you'll be glad you did. - Chris B.








And for you CCNP bulldogs, get your hands on the highest-rated CCNP SWITCH and CCNP ROUTE Study Guides on Amazon!

I guarantee it's the best $10 you'll ever spend prepping for either exam!







Thank you for your purchases! 

We've covered a lot of ground here, so let's "cool down" with the last two fields of show ip ospf neighbor:

R3#show ip ospf neighbor

Neighbor ID  Pri   State  Dead Time   Address    Interface
172.12.13.1   1   FULL/DR 00:01:53  172.12.123.1  Serial0

172.12.13.1   1   FULL/ - 00:00:38  172.12.13.1   Serial1


Address is simply the address on the remote router through which the adjacency is formed.  This may match the Neighbor ID field for that entry, or it may not - and we see it both ways in this output.

Finally, Interface simply refers to the local router interface through which the adjacency is formed.   That's it!

I told you this was the "cool down"!  : ) 

The response to this new Command Reference series has been tremendous!  The first part of this one is the most-viewed blog post I've ever written, and I'm so appreciative that I'll be adding these on a regular basis.   I'll see you VERY soon with a new one, and the countdown is on to our May 30 website refresh!


Thanks for making The Bryant Advantage part of your CCENT, CCNA, and CCNP success story!

Sincerely,

Chris Bryant
CCIE #12933
"The Computer Certification Bulldog"



No comments:

Blog Archive