IPv4 address to Netmask mapping and Multiple default routes feasibility?

Question

We have,

Class   Range      NetMask         Bits    Bits   hosts#
----------------------------------------------------------
A        0-127    255.0.0.0         8      24     16777216   (i.e. 114.0.0.0)

B      128-191    255.255.0.0      16      16        65536   (i.e. 150.0.0.0)

C      192-254    255.255.255.0    24       8          256   (i.e. 199.0.0.0)

Also,

$cat /proc/version 
Linux version 2.6.32-amd64 (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 SMP Tue Jul 1 18:36:07 UTC 2011

$ip route show
114.0.0.0/24 dev eth1  scope link 
114.0.0.0/16 dev eth1  scope link 
114.0.0.0/8 dev eth1  scope link 
199.0.0.0/8 dev eth1  scope link 
122.0.0.0/8 dev eth1  scope link 
default via 16.107.200.1 dev eth0
default via 16.107.200.1 dev eth1 
default via 16.107.200.20 dev eth1 
default via 16.107.200.21 dev eth1 
default via 16.107.200.22 dev eth1 
default via 16.107.200.23 dev eth1 

Question1. As per the above display, using iproute 2009 version I am getting IPv4 class A address holding class C or B netamsk and vice-versa. is it a valid configuration ?

Question2. As per the above display, if iproute allow to add multiple default routes, then what would be the behavior of packet flow when packet need to be routed using only one default route (where many default routes exist) ? also how the iproute filter multiple default routes ? also, is it a valid feature that iproute should allow multiple default routes in a server setup ?

Answer 1

A1: Yes, perfectly valid. Classful IP Addressing was superseded in around 1993 by CIDR (Classless Inter-Domain Routing). Even without CIDR this would still be valid, as you would simply have 'subnets' defined.

A2: In most cases, the 'default' route used will be the first listed in the routing table. In (very) simplistic terms, the kernel walks 'down' the routing table until it finds a match and transmits the packet on the matching link. In your case, most 'default' traffic will be sent for onward routing to 16.107.200.1 on your eth0 interface.