OSPF over Frame-Relay – Part 6: Troubleshooting (Yes, a New R&S 4.0 Topic!!)

Welcome back everybody!  Today we will be finishing up our multi-part tutorial series on OSPF & Frame-Relay.  In our past 5 articles we have covered all of the OSPF network types and how they function over a frame-relay topology. Today we are going to put it all together and create a scenario similar to what you might expect on the real CCIE lab troubleshooting section.  Because there are various network types for OSPF, and because some of them are not compatible, the technology is almost begging to be messed with to make your life miserable J Don’t get too worried though – if you followed along with the other blogs and you understand each piece individually, putting them all together is not that bad.  Most things in the CCIE lab require that you break things down to a basic level and analyze one thing at a time during troubleshooting so that you can pinpoint the issues.  This makes certain that you actually fully understand the technology, and not just a bunch of commands.

OK, let’s get started.  Check out the diagram below to get an idea of what we will be dealing with.

Now let’s introduce the limitations of this topology as you might expect to see in a lab scenario.

• R2 must use only sub-interfaces.
• R2 may only utilize a single point-to-point sub-interface.
• We may not change the OSPF network type on any R2 interface
• R4,R5 and R6 must use physical frame-relay interfaces.
• R5 and R6 must use the OSPF broadcast network type.
• R2 should be configured so that it is always the DR on the R2/R5/R6 frame-relay
• R5/R6 must never become the DR/BDR

Alrighty then!  If you do not know much about frame-relay and OSPF these requirements could cause you a significant amount of pain and suffering.  Fortunately, we are going to break this down and show you exactly what is going on to make this work J Let’s get started with our basic frame-relay configurations.  We will worry about OSPF afterwards.

R2(config)#int s0/1/0
R2(config-if)#encap frame
R2(config-if)#no frame inv
R2(config-if)#no ip add
R2(config-if)#
R2(config-if)#int s0/1/0.24 point-to-point
R2(config-subif)#frame-relay interface-dlci 204
R2(config-fr-dlci)#ip address 100.100.24.2 255.255.255.0
R2(config-subif)#
R2(config-subif)#int s0/1/0.256 multipoint
R2(config-subif)#ip address 100.100.100.2 255.255.255.0
R2(config-subif)#frame map ip 100.100.100.5 205 broad
R2(config-subif)#frame map ip 100.100.100.6 206 broad
R2(config-subif)#frame map ip 100.100.100.2 206
R2(config-subif)#
R2(config-subif)#int s0/1/0
R2(config-if)#no shut

 

R4(config)#int s0/0/0
R4(config-if)#encap frame
R4(config-if)#no frame inv
R4(config-if)#ip add 100.100.24.4 255.255.255.0
R4(config-if)#frame map ip 100.100.24.2 402 broad
R4(config-if)#frame map ip 100.100.24.4 402
R4(config-if)#no shut

 

R5(config)#int s0/1/0
R5(config-if)#encap frame
R5(config-if)#no frame inv
R5(config-if)#ip add 100.100.100.5 255.255.255.0
R5(config-if)#frame map ip 100.100.100.2 502 broad
R5(config-if)#frame map ip 100.100.100.6 502
R5(config-if)#frame map ip 100.100.100.5 502
R5(config-if)#no shut

 

R6(config)#int s0/1/0
R6(config-if)#encap frame
R6(config-if)#no frame inv
R6(config-if)#ip add 100.100.100.6 255.255.255.0
R6(config-if)#frame map ip 100.100.100.2 602 broad
R6(config-if)#frame map ip 100.100.100.5 602
R6(config-if)#frame map ip 100.100.100.6 602
R6(config-if)#no shut

Simple enough…let’s do a basic frame-relay connectivity check from a point that has a connection to everything: R2.

R2(config-if)#do ping 100.100.24.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.24.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/56 ms
R2(config-if)#do ping 100.100.100.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/44/44 ms
R2(config-if)#do ping 100.100.100.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/44/44 ms
R2(config-if)#

Excellent!  We have basic connectivity.  Now, let’s get into the fun stuff – OSPF.  With all the restrictions and requirements, your head might be spinning.  The important thing here is to first not panic.  You KNOW the technologies!  We’ve already learned them!  All we have to do now is break things down one piece at a time.  Let’s focus first on the link between R2 and R4.

OK.  What restrictions or requirements do we have that involve this particular link only?  Well, the requirement that R2 only use sub-interfaces and only a single point-to-point sub-interface is already taken care of. The requirement that R4 use only a physical interface is taken care of.  What else?  Well, we are not allowed to change the OSPF network type on R2 at all. Will this cause us issues right out of the box? This is where we need to break things down to the underlying technology and how it works.  So if we are not allowed to change the OSPF network type on R2, that implies we have to use the default.  What is the default OSPF network type on a point-to-point sub-interface?  Point-to-point.  That is one piece of our puzzle.  Now we can start thinking about how the point-to-point network type works.  Go through the three questions we learned in previous blogs.

1) Do I need a DR: No

2) Do I need neighbor commands: No, I can broadcast just fine on a point-to-point sub-interface

3) What are my timers: “fast” = 10s/40s

OK sweet – We have not changed ANYTHING yet.  Now let’s take a look at the same questions from the perspective of R4.  R4 has a physical interface, and we can’t change it.  What is the default OSPF network type on a physical or multipoint sub-interface?  Non-broadcast.  OK, let’s go over the same questions:

1) Do I need a DR: Yes

2) Do I need neighbor commands: Yes

3) What are my timers: “slow” = 30s/120s

So what are our options at this point?  Well, we can’t do anything on R2 really at all due to the restrictions.  So what can we do on R4 to make things good?  To match with R2 we need to make sure we do not expect a DR, we don’t need neighbor commands, and our timers are “fast”.  There was no restriction on changing the OSPF network type on R4!  Let’s just make it network type point-to-point…then we have a perfect match!  This demonstrates that even though the interface itself is physical, we can make the network type whatever we want! With that in mind, let’s configure OSPF between R2 and R4.

R2(config)#router ospf 1
R2(config-router)#router-id 2.2.2.2
R2(config-router)#network 100.100.24.2 0.0.0.0 area 0

 

R4(config)#int s0/0/0
R4(config-if)#ip ospf network point-to-point
R4(config-if)#
R4(config-if)#router ospf 1
R4(config-router)#network 100.100.24.4 0.0.0.0 area 0
R4(config-router)#
*Aug  3 13:09:49.599: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0/0 from LOADING to FULL, Loading Done

Great!  Our neighbor came up just as predicted.  Let’s verify on R4 the network type is what we set it to.

R4(config-router)#do sh ip ospf int s0/0/0 | i Network|Timer
Process ID 1, Router ID 100.100.24.4, Network Type POINT_TO_POINT, Cost: 64
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

It’s a beautiful thing!  Now, on to our main frame-relay cloud of R2, R5 and R6. Again, what are the limitations here? Again, we are not allowed to change the network type on R2.  We are also told R2 MUST be the DR and that R5 and R6 should NEVER be the DR. Finally, R5 and R6 must utilize the broadcast OSPF network type. Let’s break it down.  Start with R2.  We can’t change the network type so we are stuck with the default.  What is the default network type on a physical or multipoint sub-interface?  Non-broadcast.  OK, let’s run through our questions again.

1)Do I need a DR: Yes

2)Do I need neighbor commands: Yes

3)What are my timers: “slow” = 30s/120s

The wording on the restriction about the DR leads us to some other conclusions.  Since it must ALWAYS be the DR we need to set R2 to the highest possible priority.  Since R5 and R6 can NEVER be the DR, that is the lab subtly telling us to make sure the priority is set to 0.

From the R5 and R6 side, let’s look at the same exact questions.

1)Do I need a DR: Yes

2)Do I need neighbor commands: No

3)What are my timers: “fast” = 10s/120s

If you can answer just these three questions for every network type you should be able to deduce what issues you will run into!!!  In this case, we see we will have issues with timers.  All we need to do is simply tweak the timers on one end so that they match.  Note that the network types can be different, as long as they agree on timers and the need for a DR.  You might even get a neighbor to come up with one side thinking there is a DR and the other not, but bad things will happen J  OK, let’s do this thing!

R2(config-router)#int s0/1/0.256
R2(config-subif)#ip ospf priority 255
R2(config-subif)#ip ospf hello-interval 10
R2(config-subif)#
R2(config-subif)#router ospf 1
R2(config-router)#network 100.100.100.2 0.0.0.0 area 0
R2(config-router)#neighbor 100.100.100.5
R2(config-router)#neighbor 100.100.100.6

 

R5(config-if)#int s0/1/0
R5(config-if)#ip ospf priority 0
R5(config-if)#ip ospf network broadcast
R5(config-if)#
R5(config-if)#router ospf 1
R5(config-router)#network 100.100.100.5 0.0.0.0 area 0

 

R6(config)#int s0/1/0
R6(config-if)#ip ospf priority 0
R6(config-if)#ip ospf network broadcast
R6(config-if)#
R6(config-if)#router ospf 1
R6(config-router)#network 100.100.100.6 0.0.0.0 area 0

Verify!

R2#sh ip ospf neigh
Neighbor ID     Pri   State           Dead Time   Address         Interface
100.100.100.5     0   FULL/DROTHER    00:00:34    100.100.100.5   Serial0/1/0.256
100.100.100.6     0   FULL/DROTHER    00:00:34    100.100.100.6   Serial0/1/0.256
100.100.24.4      0   FULL/  -        00:00:30    100.100.24.4    Serial0/1/0.24
R2#sh ip ospf int s0/1/0 | i Network|Timer
R2#sh ip ospf int s0/1/0.256 | i Network|Timer
Process ID 1, Router ID 2.2.2.2, Network Type NON_BROADCAST, Cost: 64
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

On R2 we see all of our neighbors.  We note that the priority is “0″ for all the neighbors.  In the case of R4 it is because there IS NO DR.  In the case of R5/R6 it is because we hard set it to 0.  We also note that the state for R5/R6 is “FULL/DROTHER” meaning we are the DR on the frame-relay cloud between R2, R5 and R6.  Perfect.  Finally, we check our timers and network type.  By default our timers would be 30/120 on a non-broadcast network, but we tweaked them out to match the broadcast network type.

That is how it is done. Remember, the most important part of troubleshooting is to break things down into smaller pieces.  Understanding those smaller pieces should already be water under the bridge.  All you need to do at that point is put the pieces together.  When you are troubleshooting frame-relay and OSPF, go through and ask yourself the three key questions we learned about in this series.  If you can answer them accurately, you will be just fine.

Thanks!

Joe (Post contributed by Joe Astorino – CCIE #24347 R&S)

Tags: ccie lab, CCIE R&S, CCIE R&S 4.0 Lab, CCIE R&S Lab Troubleshooting, Frame Relay, ipexpert, Joe Astorino, OSPF, Troubleshooting