"no ip classless" and "ip cef"

Hi All,

Does anyone have any idea if "no ip classless" still works in recent IOSes? I have observed on Cisco 2801 that even after turning "no ip classless" IOS still uses classless ruting behavior. The routing table looks like this:

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

172.16.0.0/24 is subnetted, 3 subnets R 172.16.1.0 [120/1] via 172.16.2.2, 00:00:12, Serial0/1/0 C 172.16.2.0 is directly connected, Serial0/1/0 C 172.16.3.0 is directly connected, FastEthernet0/0 C 192.168.1.0/24 is directly connected, Serial0/1/1 S* 0.0.0.0/0 is directly connected, Serial0/1/1

No matter if "no ip classless" or "ip classless" is in use, the ping to the network 172.16.4.0 succeed (but with classfull behaviour shouldn't):

Router#ping 172.16.4.1

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/16 ms

I don't need classfull behaviour in production, I'm just wondering if command "no ip classless" have any meaning in current IOSes and if process switching can be enabled in other way than turning "ip cef" off.

Thanks for any clues, Pawel

Would be a surprise if it did not. I have avoided the need to worry about classful routing so can't really comment but I might have a read of Doyle in a minute.

I don't need classfull behaviour in production, I'm just wondering if

I would use classless routing 'cos that is what everyone else is doing and you are less likely to run into bugs.

You do need to turn off cef, but not globally.

int x no ip route cache

turns off fast (i.e. cache) switching.

if CEF is enabled globally then the interface section of sh run has the following meaning This applies to the *input* interface I seem to recall.

- uses CEF ip route-cache flow - uses netflow sw ip route-cache - uses fast switching no ip route-cache - uses provcess switching

If cef is NOT enabled or if using older IOS that does not have CEF.

- uses fast sw ip route-cache flow - uses netflow sw no ip route-cache - uses process switching

I have not verified the above but I think it must be true:)

This is one case where the cisco practise of not displaying the "default" configuration is confusing. By default I mean the configuration that is active of no configuration is displayed.

I've never used "ip classless" before so I don't know exactly how it works but it probably affects how routes are created in the routing table like "auto-summary" does for EIGRP. If it works similar to "auto-summary", a classfull route to Null0 would be added to the routing table for any routes that are learned via a routing protocol or a static.

In your particular case I don't think it would do anything anyway because you have only one route defined (the static default) and the rest are directly connected. Add a static route like "ip route 10.1.1.0

255.255.255.0 172.16.2.2" and then look at the routing table again. Check to see if you have a route for 10.0.0.0/8 that points to Null0. Add "ip classless" again and see if that route disappears. You should reload after adding "ip classless" because sometimes the Null0 routes are not always removed as they should be. Let us know what you find out.

"ip classless" makes the router do strictly CIDR longest-match routing. Before classless routing, and I'd guess "no ip classless" reverts to this behaviour, there was an assumption that all networks were contiguous - you couldn't have a subnet that was disconnected from the rest of the (classful) network. The routers made the assumption that only known subnets of any network were reachable. In the example below subnets 172.16.4.0/24 to 172.16.254.0/24 inclusive would all be unreachable and traffic for those addresses would NOT be forwarded along the default route. At the time there was no messing around with Null0 routes, but that may have changed in later implementations.

For the record subnets 172.16.0.0/24 and 172.16.255.0/24 were invalid and could not be used. There was also an uneasy situation regarding variable length subnet masking (precursor to CIDR) - some IGPs supported it (OSPF, notably) and others didn't (RIPv1, IGRP). Routers using RIPv1 or IGRP had to assume that the same subnet mask applied to all subnets of a (classful) network.

Sam

Sam Wilson said the following on 05/06/2009 03:38 PM:

as far as I remember ip classless should be used with ip subnet-zero which makes the router take in consideration cidr subnets boundaries Am I right ?

In article , free-news_no-replyATcasylde.fr (Daniel-G) writes: | Sam Wilson said the following on 05/06/2009 03:38 PM: | > In article , | > "Thrill5" wrote: | > | >> I've never used "ip classless" before so I don't know exactly how it works | >> but it probably affects how routes are created in the routing table like | >> "auto-summary" does for EIGRP. If it works similar to "auto-summary", a | >> classfull route to Null0 would be added to the routing table for any routes | >> that are learned via a routing protocol or a static. | > | > "ip classless" makes the router do strictly CIDR longest-match routing. | > Before classless routing, and I'd guess "no ip classless" reverts to | > this behaviour, there was an assumption that all networks were | > contiguous - you couldn't have a subnet that was disconnected from the | > rest of the (classful) network. The routers made the assumption that | > only known subnets of any network were reachable. In the example below | > subnets 172.16.4.0/24 to 172.16.254.0/24 inclusive would all be | > unreachable and traffic for those addresses would NOT be forwarded along | > the default route. At the time there was no messing around with Null0 | > routes, but that may have changed in later implementations. | > | > For the record subnets 172.16.0.0/24 and 172.16.255.0/24 were invalid | > and could not be used. There was also an uneasy situation regarding | > variable length subnet masking (precursor to CIDR) - some IGPs supported | > it (OSPF, notably) and others didn't (RIPv1, IGRP). Routers using RIPv1 | > or IGRP had to assume that the same subnet mask applied to all subnets | > of a (classful) network. | > | >>> Gateway of last resort is 0.0.0.0 to network 0.0.0.0 | >>>

| >>> 172.16.0.0/24 is subnetted, 3 subnets | >>> R 172.16.1.0 [120/1] via 172.16.2.2, 00:00:12, Serial0/1/0 | >>> C 172.16.2.0 is directly connected, Serial0/1/0 | >>> C 172.16.3.0 is directly connected, FastEthernet0/0 | >>> C 192.168.1.0/24 is directly connected, Serial0/1/1 | >>> S* 0.0.0.0/0 is directly connected, Serial0/1/1 | > | > Sam | as far as I remember ip classless should be used with ip subnet-zero | which makes the router take in consideration cidr subnets boundaries | Am I right ?

It allows subnet 0 to be used. But it may not matter. I did some testing after the original posting on this subject and it seems to be true that "no ip classless" no longer works at least as of 12.4(23). Similarly for

12.4(15)T though I didn't test as carefully. I used only static routes so it is not a case of the classless "override" for things liks OSPF-learned routes.

Dan Lanciani ddl@danlan.*com

Where the ip classless configuration command falls within the routing and forwarding processes is often confusing. In reality, IP classless only affects the operation of the forwarding processes in IOS; it doesn't affect the way the routing table is built. If IP classless isn't configured (using the no ip classless command), the router won't forward packets to supernets. As an example, let's again place three routes in the routing table and route packets through the router.

Note: If the supernet or default route is learned via IS-IS or OSPF, the no ip classless configuration command is ignored. In this case, packet switching behavior works as though ip classless were configured.

router# show ip route .... 172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks D 172.30.32.0/20 [90/4879540] via 10.1.1.2 D 172.30.32.0/24 [90/25789217] via 10.1.1.1 S* 0.0.0.0/0 [1/0] via 10.1.1.3 Remembering that the 172.30.32.0/24 network includes the addresses 172.30.32.0 through 172.30.32.255, and the 172.30.32.0/20 network includes the addresses 172.30.32.0 through

172.30.47.255, we can then try switching three packets through this routing table and see what the results are.

A packet destined to 172.30.32.1 is forwarded to 10.1.1.1, since this is the longest prefix match.

A packet destined to 172.30.33.1 is forwarded to 10.1.1.2, since this is the longest prefix match.

A packet destined to 192.168.10.1 is forwarded to 10.1.1.3; since this network doesn't exist in the routing table, this packet is forwarded to the default route.

A packet destined to 172.30.254.1 is dropped.

The surprising answer out of these four is the last packet, which is dropped. It's dropped because its destination, 172.30.254.1, is within a known major network, 172.30.0.0/16, but the router doesn't know about this particular subnet within that major network.

This is the essence of classful routing: If one part of a major network is known, but the subnet toward which the packet is destined within that major network is unknown, the packet is dropped.

The most confusing aspect of this rule is that the router only uses the default route if the destination major network doesn't exist in the routing table at all.

|

| | | | Where the ip classless configuration command falls within the routing | and forwarding processes is often confusing.

The problem here isn't that it is confusing but that classful routing no longer works (as pointed out by the original poster). I confirmed this for 12.4(23).

Dan Lanciani ddl@danlan.*com

IIRC ip subnet-zero predates ip classless - it was a non-standard (-ish[1]) cisco[2] hack which allowed you to used subnet zero.

Sam

[1] I think it predated RFC 1122 section 3.2.1.3 which codified the common understanding that all-ones and all-zeroes were invalid subnet fields. Not all implementors agreed. [2] Not Cisco. Old hands will understand.