If you thought this behavior was odd before, this will really bake your
noodle. I did some more experiments as we discussed in the thread earlier
today. Here's another short recap to catch everyone up.
I have two routers, A and B, running OSPF. The link between them is
10.1.1.0/24, and A is originating a default into B. Router B has 'no ip
classless' configured. This means that by Cisco's explanations, if I were
to ping any unknown subnet of 10.0.0.0/8 it would fail and debugging would
show that it was unroutable. However, that wasn't happening. If I used
OSPF to originate a 0.0.0.0/0 default route, it would be installed as GOLR
and router B would behave classlessly.
I tried this using 0.0.0.0/0, 10.0.0.0/8, and 8.0.0.0/5. In all cases, when
using OSPF to originate the route, router B would behave classlessly. This
behavior would not occur when I used RIP v1 or v2, IGRP, or EIGRP. (If I
understood IS-IS, I'd try that too.)
Tonight I changed tactics and tried some new things. First, I ran two
routing protocols, OSPF and RIP, but I let RIP advertise the default
0.0.0.0/0 to B. As expected, B behaved classfully and would not use the
supernet route. This shows us that it's not merely the presence of OSPF on
a router that can cause it to override 'no ip classless'.
Next, I configured a manual static default 0.0.0.0/0 route on B while Router
A was also advertising the same route. Of course the OSPF route would not
be installed into the table because of the higher AD, but I wanted to verify
Router B's behavior. In this case, it was classfull.
Next, I set the AD of the static route to 120, higher than the 110 AD of the
OSPF route. This means that the new GOLR, even thought it looks *exactly*
the same in the routing table, was installed by OSPF. Guess what? Yep,
classless behavior!
Now for the really interesting part (if you've read this far and are still
awake!) I set a static 0.0.0.0/0 route on Router B but then also advertised
10.1.0.0/16 from router A. Now Router B behaved classlessly but only for
subnets of 10.1.0.0/16! If I tried to ping 10.2.1.1, for instance, it was
unroutable, but any subnet of 10.1.0.0/16--even the unknown ones--would be
routed based on the OSPF-installed supernet route. I then added 10.2.0.0/16
to the advertisement and saw what I expected: packets destined for either
of those two subnets would be routed, all others failed.
This means that the router behaves classlessly if there is a supernet route
that was installed by OSPF...but only up to that point! In the situation I
just mentioned, remember that there was also a static default route that was
being ignored!
So, the new rule is this: a router with 'no ip classless' configured will
not forward traffic to unknown subnets of known major networks UNLESS THERE
IS A VALID SUPERNET ROUTE INSTALLED BY OSPF. (sorry for the caps. <g>)
Yikes, can this thread die now? :-) I know, I keep it going, but I wanted
to really chase this down. I think I chased it down, kicked it, hit it with
a stick, and now it's gone belly up not unlike the Norwegian Blue. As for
me, I think I'm through with my 'no ip classless' experiments. Now maybe I
can finally get to those NAT labs I've been trying to get to for a week!
Regards,
John
_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
