☰

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

tag-icon • tag-icon ipv4 network-protocols
Endereço IPv4 para mapeamento de máscara de rede e viabilidade de múltiplas rotas padrão?

Nós 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)

Também,

$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

Questão 1.De acordo com a exibição acima, usando a versão iproute 2009, estou obtendo endereço IPv4 classe A contendo classe C ou B netamsk e vice-versa. é uma configuração válida?

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

Responder1

A1: Sim, perfeitamente válido. O endereçamento IP classful foi substituído por volta de 1993 porCIDR(Encaminhamento inter-domínio sem classe). Mesmo sem o CIDR isso ainda seria válido, pois você simplesmente teria '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 percorre a tabela de roteamento até encontrar uma correspondência e transmitir o pacote no link correspondente. No seu caso, a maior parte do tráfego 'padrão' será enviada para roteamento posterior 16.107.200.1em sua eth0interface.

informação relacionada