One debug command that comes up when preparing for your CCIE Lab is debug ip routing. This is a very powerful command that you would not really run in a live environment, in fact we are not allowed to run any debug commands!
For learning redistribution the debug ip routing command is a great way to actually see what is happening.
There are also two points of view on if this is a command you would run in the lab exam.
The plus side is that when you do a redistribution command you can instantly see if you are getting any feedback or not, as you can easily see routes leaving and entering the routing table.
The negative argument is that if you fully understand what you are doing with your redistribution and can interpret the show ip route commands you shouldn’t need to be running debug ip routing.
For some it is like a reassurance that everything is stable.
Lets take this very simple example below with 3 routers running OSPF area 0
R3#sh ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS lev ia - IS-IS inter area, * - candidate default, U - per-user static o - ODR, P - periodic downloaded static route Gateway of last resort is not set 220.127.116.11/32 is subnetted, 1 subnets C 18.104.22.168 is directly connected, Loopback0 10.0.0.0/24 is subnetted, 2 subnets O 10.0.0.0 [110/20] via 10.0.1.2, 00:00:19, FastEthernet0/0 C 10.0.1.0 is directly connected, FastEthernet0/0 R3#
Now we are going to enable the debug ip routing and add Loopback0 on Router 1 into OSPF area 0 – what we should see is the route coming into ospf
R3#debug ip routing IP routing debugging is on R3#
Now hop over to Router 1 and bring Loopback0 into ospf
R1(config)#int lo0 R1(config-if)#ip ospf 1 area 0 R1(config-if)#
Now we are going back to R3 and hopefully we should see the 22.214.171.124/32 get added into OSPF – as you can see it does get added, I then removed the interface from ospf and you can see that the prefix was then deleted.
R3# *Mar 1 00:30:48.247: RT: add 126.96.36.199/32 via 10.0.1.2, ospf metric [110/21] *Mar 1 00:30:48.251: RT: NET-RED 188.8.131.52/32 R3# *Mar 1 00:35:01.703: RT: del 184.108.40.206/32 via 10.0.1.2, ospf metric [110/21] *Mar 1 00:35:01.707: RT: delete subnet route to 220.127.116.11/32 *Mar 1 00:35:01.707: RT: NET-RED 18.104.22.168/32 *Mar 1 00:35:01.707: RT: delete network route to 22.214.171.124 *Mar 1 00:35:01.707: RT: NET-RED 126.96.36.199/8 R3#
This is the kind of output you would expect to see of a route being learned and then removed, learned and then removed. This would indicate a possible routing loop
This command is great for learning how redistribution works and monitoring routes going into the routing table, but as to if you want to use it in the lab that is up to you.
I have also started experimenting with Video – this short clip below will show the debug ip routing command in action – there is no audio.