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
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 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 1.1.1.1/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 1.1.1.1/32 via 10.0.1.2, ospf metric [110/21] *Mar 1 00:30:48.251: RT: NET-RED 1.1.1.1/32 R3# *Mar 1 00:35:01.703: RT: del 1.1.1.1/32 via 10.0.1.2, ospf metric [110/21] *Mar 1 00:35:01.707: RT: delete subnet route to 1.1.1.1/32 *Mar 1 00:35:01.707: RT: NET-RED 1.1.1.1/32 *Mar 1 00:35:01.707: RT: delete network route to 1.0.0.0 *Mar 1 00:35:01.707: RT: NET-RED 1.0.0.0/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.
