CCNA certification demands that you master the basics of OSPF, and for many studying for the CCNA exam, their first exposure to OSPF is a hub-and-spoke configuration. That's a tough way to get started, because a hub-and-spoke configuration built over an NBMA technology such as Frame Relay requires quite a bit of attention to detail. Let's take a quick look at several common OSPF configuration errors and how to avoid them on your CCNA test.
Make sure the hub is the designated router and that there are no backup designated routers. This is done by setting the OSPF interface priority to zero on the spoke routers. This not only ensures that the hub wins the DR election with its default OSPF interface priority of 1, but it prevents the spokes from ever having a chance to become the DR or BDR.
Configure neighbor statements on the hub. Since we're dealing with an NBMA network, the hub cannot dynamically discover its neighbors. Neighbor statements are not needed on the spokes. (They don't hurt anything, but they don't do anything, either.)
Finally, if your OSPF adjacencies do not form as expected, make sure to use your OSI model knowledge to approach the problem. The issue may actually be at Layer Two, with your Frame Relay configuration. If you don't use the "broadcast" option on your frame relay statements, OSPF hellos will not be transmitted successfully between potential neighbors. OSPF hellos are multicast, but the "broadcast" option for Frame Relay includes multicasts.
By paying special attention to these details, you're that much close to CCNA exam day success and earning your certification. I recommend that you get some experience with configuring OSPF hub-and-spoke before taking the CCNA exam, because it's by actually performing tasks such as this that makes you supremely confident on CCNA test day.
RIP's default behavior is to send version 1 updates, but to accept both version 1 and 2 routing updates.
R2(config)#router rip
R2(config-router)#net 172.16.0.0
R2(config-router)#^Z
R2#show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 6 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Key-chain
Serial0 1 1 2
By default, RIP v2 autosummarizes routing updates sent across classful network boundaries. To disable this behavior, run no auto-summary under the RIP process.
R1#conf t
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto-summary
You do not specify a subnet mask or wildcard mask when configuring RIP ? just the classful network, even if you're running RIP v2.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto-summary
R1(config-router)#network 172.10.0.0 ?
Debug ip rip displays the routing updates and metrics as the advertisements are sent and requested. To see this in action without waiting for the next regularly scheduled update, run clear ip route *.
R1#debug ip rip
RIP protocol debugging is on
R1#clear ip route *
01:16:54: RIP: sending v1 update to 255.255.255.255 via Loopback1 (1.1.1.1)
01:16:54: network 2.0.0.0, metric 2
01:16:54: network 3.0.0.0, metric 2
01:16:54: network 172.16.0.0, metric 1
01:16:54: network 10.0.0.0, metric 2
01:16:54: RIP: sending v1 update to 255.255.255.255 via Serial0 (172.16.123.1)
01:16:54: subnet 172.16.123.0, metric 1
01:16:54: network 1.0.0.0, metric 1
01:16:54: network 2.0.0.0, metric 2
01:16:54: network 3.0.0.0, metric 2
01:16:54: network 10.0.0.0, metric 2
To see only the routes discovered by a routing protocol, run show ip route followed by the name of the protocol:
R1#show ip route rip
R 2.0.0.0/8 [120/1] via 172.16.123.2, 00:00:26, Serial0
R 3.0.0.0/8 [120/1] via 172.16.13.2, 00:00:09, Serial1
[120/1] via 172.16.123.3, 00:00:09, Serial0
R 10.0.0.0/8 [120/1] via 172.16.13.2, 00:00:09, Serial1
[120/1] via 172.16.123.3, 00:00:09, Serial0
[120/1] via 172.16.123.2, 00:00:26, Serial0
And don't forget - to turn off all currently running debugs, run undebug all.
R1#undebug all
All possible debugging has been turned off
Don't overlook RIP and IGRP when it comes to the CCNA exam. OSPF and EIGRP are more complex to configure, but you need to understand how distance vector protocols work in order to pass the CCNA!
Chris Bryant has sinced written about articles on various topics from CISCO CCNA, Personal Desktop and Cisco CCNP. Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage , home of free and CCNP tutorials! Pass Pass the. Chris Bryant's top article generates over 27100 views. to your Favourites.