mellowd; the information that scottsee is working from is part of the CCNA Exploration curriculum, cribbed from a book called Cisco IP Routing by Alex Zinin.The tl;dr is pretty much this: There are level 1 routes in the routing table; default routes, summary routes, and network routes. These level 1 routes may have child routes. Scottsee has summarised how he sees the routing table lookup happening after implementing the ip classless command.At this point, I don't know the packet is getting forwarded out of the interface, it ought to be getting dropped. How about throwing a few more routes into the table so you've got more information to make a forwarding decision from?

Halo wrote:At this point, I don't know the packet is getting forwarded out of the interface, it ought to be getting dropped. How about throwing a few more routes into the table so you've got more information to make a forwarding decision from?

I added more loopbacks and made the network converge using RIPv2 but no Cigar. I'm still seeing the classfull routing table use the quad-zero default route..

Project2501 wrote:Quad four route for the win? You've got a default route in there.

Yes, but it shouldn't be seen by a classfull routing table in this situation.. I'll explain using the new routing table in this post..- R1 is sending an ICMP echo to the address 172.16.200.1 /32 2 hops away.- R1 has a classfull routing table enabled using no ip classless- R1 examines the destination address for a classfull match (172.16.0.0 - Class B)- R1 finds a parent classfull route for the destination network- R1 examines each of the child routes within the parent route- R1 finds no match for the destination 172.16.200.1 packet.** With a classless routing table a router will re-examine level 1 routes for a less specific route the what is matched by the 172.16.0.0 classfull parent route. Allowing it to find any summary routes or quad-zero routes.** With a classfull routing table, once the child routes are examined and no match is found, it will not re-examine the routing table to find a summary or default route..

That's the jist..

I'm getting sick so forgive me..

I just don't understand why these are being routed..

Last edited by scottsee on Sat Jan 22, 2011 7:12 pm, edited 1 time in total.

scottsee wrote:** With a classless routing table a router will re-examine level 1 routes for a less specific route the what is matched by the 172.16.0.0 classfull parent route. Allowing it to find any summary routes or quad-zero routes.

scottsee wrote:** With a classless routing table a router will re-examine level 1 routes for a less specific route the what is matched by the 172.16.0.0 classfull parent route. Allowing it to find any summary routes or quad-zero routes.

Wouldn't that explain why the quad zero is being used?

I can't see any routes that 172.16.3.1 would match otherwise.

When you use the R1(config)no ip classless command, it turn the routing table from classless to classfull. So, it's not suppose to search for a quad zero route (or any other supernet route) when a parent route exists in the routing table for the network destination.

Jeff wrote:try issuing "no ip cef" and see if that makes a difference.

Still able to reach the destination address 172.16.200.1 from the following routing table.. I changed over to EIGRP, at this point I'm up for suggestions..

EDIT: I just noticed EIGRP added the default route from the HUB router because of a bad network statement. I didn't know EIGRP would add static routes that match a network statement in to the routing table.

Huhh, I converged over to OSPF and the Classfull routing table works as expected.. Well at least I have a place to start. For some reason static routing & distance-vector routing aren't supporting classfull routing tables as expected... Time to figure out why..

scottsee wrote:Huhh, I converged over to OSPF and the Classfull routing table works as expected.. Well at least I have a place to start. For some reason static routing & distance-vector routing aren't supporting classfull routing tables as expected... Time to figure out why..

Something of note in regards to this route table vs the original one. In this table you have the 172.16.0.0 /16 (top of route table) and in the original it was a /30 which of course is not a classful mask.

EDIT: Nevermind just noticed your next table after that one did also have the /16 and had the ping work.

Jeff wrote:try issuing "no ip cef" and see if that makes a difference.

I must have had something configured incorrectly when I turned off Cisco express forwarding the first time. After I started the lab over and using the no ip cef command the classfullness behavior I was expecting to see using static routing occurred. I spent some time reading over the inherent differences between CEF and process switching. Like most material taught though the ICND series, the books leave out real world application. I guess it's nice to know that if you want classfull routing table behavior with static routing or RIP you'll need to disable CEF. Interestingly enough, OSPF and EIGRP both work fine CEF enabled.

Sorry, didn't I mention this in a email? Something about how Ch 8 is way beyond CCNA requirements and how the real world doesn't reflect this type of routing process?

The biggest traps for D-V labs using post-1995 gear, ip cef and long holddown timers - frequently catches out many Networking Academy instructors and students in the lab.

Like most material taught though the ICND series, the books leave out real world application.

Indicative of how the CCNA cert is caught between trying to test basics in a 21st century world. CEF is a CCNP area, though it could be mentioned in the Academy courses in my view. In CCNA Exploration 4 above-CCNA level ACLs are explained, but not assessed, to try and give more of a real world approach.

Aubrey

The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn. Alvin Toffler, "Future Shock" 1970