Endereço IPv4 para mapeamento de máscara de rede e viabilidade de várias rotas padrão?

Question

Temos,

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)

Além disso,

$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. De acordo com a exibição acima, usando a versão 2009 do iproute Estou recebendo o endereço de classe A do IPv4 contendo classe C ou B netamsk e vice-versa. é uma configuração válida?

Question2. De acordo com a exibição acima, se iproute permitir adicionar várias rotas padrão, qual seria o comportamento do fluxo de pacotes quando o pacote precisar ser roteado usando apenas uma rota padrão (onde muitos rotas padrão existem)? também como o iproute filtra múltiplas rotas padrão? também, é um recurso válido que o iproute deve permitir várias rotas padrão em uma configuração de servidor?

    

Answer 1

A1: Sim, perfeitamente válido. Endereçamento IP classful foi substituído em torno de 1993 por CIDR (roteamento entre domínios sem classe). Mesmo sem o CIDR, isso ainda seria válido, já que você teria simplesmente 'sub-redes' definidas.

A2: Na maioria dos casos, a rota 'padrão' usada será a primeira listada na tabela de roteamento. Em termos (muito) simplistas, o kernel desce a tabela de roteamento até encontrar uma correspondência e transmite o pacote no link correspondente. No seu caso, a maior parte do tráfego "padrão" será enviado para encaminhamento para 16.107.200.1 na interface eth0 .