«

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

On 4 May, 19:40, Pawe³ Damian <pawel@__dowywalenia__sz-ek.pl> wrote:
> 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:

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.

<snipped?
> I don't need classfull behaviour in production, I'm just wondering if
> command "no ip classless" have any meaning in current IOSes

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

> process switching can be enabled in other way than turning "ip cef" off.

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.

<no cache related line> - 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.

<no cache related line> - 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.


"Pawe³ Damian" <pawel@__dowywalenia__sz-ek.pl> wrote in message
news:gtncq0$sur$...
> 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

In article <gtnhfs$5ft$>,
"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

Sam Wilson said the following on 05/06/2009 03:38 PM:
> In article <gtnhfs$5ft$>,
> "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 ?

In article <4a10127e$0$5021$>, free-news_no-replyATcasylde.fr (Daniel-G) writes:
| Sam Wilson said the following on 05/06/2009 03:38 PM:
| > In article <gtnhfs$5ft$>,
| > "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

http://www.cisco.com/en/US/tech/tk36...80094823.shtml



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.

In article <7bde496d-c1f9-4270-8e01->, (Ladybug) writes:

| http://www.cisco.com/en/US/tech/tk36...80094823.shtml
|
|
|
| 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

In article <4a10127e$0$5021$>,
Daniel-G <free-news_no-replyATcasylde.fr> wrote:

> 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 ?

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.