O que significa * no linux para ip do gateway?

Question

Para ser mais preciso, depois de executar o netstat -r, obtive as seguintes linhas:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         199.170.12.1    0.0.0.0         UG        0 0          0 eth0
199.170.12.0    *               255.255.254.0   U         0 0          0 eth0

O motivo pelo qual eu o rodei foi que minha conexão Ethernet não estava funcionando no Linux, mesmo que estivesse trabalhando no Windows (instalado na mesma máquina). Eu estava usando ip dinâmico, a vez anterior a conexão estava funcionando bem e eu não tinha feito nenhuma alteração. Eu verifiquei pela primeira vez ifconfig e foi tudo normal. Eu verifiquei o resolv.conf e ele estava apontando para o servidor de nomes 127.0.1.1 (que estava ok também - tanto quanto eu sei).

A única coisa que achei suspeita foi o ip do gateway (pode ser normal, mas para ser honesto eu não tinha tentado esse comando antes e não sei o que * significa).

Então a conexão foi corrigida (por si só, eu não fiz nada). Mas eu queria perguntar de qualquer maneira.

    

Answer 1

Isso significa que não é necessário um gateway para alcançar essa sub-rede. Essa é uma sub-rede local, portanto, não precisa de um IP do próximo salto. Com netstat -r , parece haver melhor compatibilidade com o contexto. 0.0.0.0 na seção de destino é traduzido como default , enquanto na seção de gateway ele é traduzido como * .

rj@Latitude-E6410:~$ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         192.168.1.1     0.0.0.0         UG        0 0          0 wlan0
192.168.1.0     *               255.255.255.0   U         0 0          0 wlan0

rj@Latitude-E6410:~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     9      0        0 wlan0

    

Answer 2

No Netstat, a opção -r exibe a tabela de roteamento do kernel.

Por padrão, o netstat tenta resolver o IP com seu nome fazendo uma pesquisa reversa de DNS. Para que isso funcione (presumindo que o BIND seja o servidor DNS), deve haver um arquivo de dados de zona reversa com registros de recursos PTR que mapeiam o endereço IP para nome. Geralmente isso não é configurado em redes domésticas (e muitas redes de produção).

Quando o netstat não recebe nenhuma resposta do servidor DNS além do valor de tempo limite padrão (você pode definir um especificando a diretiva timeout:n no /etc/resolv.conf onde n medido em segundos), * aparece em locais onde a palavra-chave de rede ANY é apropriada, o que equivale a 0.0.0.0 . A interpretação de * é específica do contexto. No seu caso, como Ryan Foley disse para alcançar a rede 192.168.1.0/24 nenhum gateway é necessário como essa é a sua rede local.

Você pode aprender como interpretar a saída do netstat e seu uso lendo este blog . A opção -n desativa a pesquisa reversa de DNS, o que torna o netstat mais veloz.

A seguir estão as possibilidades que podem ter ocorrido no seu caso:

1. O cliente precisa obter o IP do servidor DHCP. Quando a máquina é inicializada, o protocolo DHCP é iniciado. Esta conversa inclui pacotes DHCP DORA (Discover, Offer, Request, Ack). Destes, o DHCP Discover é uma transmissão da máquina. Dependendo do não. de nós na rede (mesmo domínio de colisão), leva algum tempo para o servidor DHCP obter esse pacote Discover e responder com a Oferta DHCP que contém o IP.

2. Em seguida, o arp resolution . Ter endereço IP não faz com que a máquina possa se comunicar a menos que a tabela ARP seja criada. Isso tem o mapeamento de endereços IP-para-MAC. O endereço MAC é o requisito para formar o pacote e enviá-lo no cabo físico ( ether ). Mais uma vez, o aprendizado do endereço MAC das máquinas na rede local envolve broadcast ARP (solicitação) e unicasts (resposta). Isso aumenta o tempo antes do qual a máquina está pronta para se comunicar.

3. As causas do atraso incluem muitas colisões de pacotes, negociação de parâmetros TCP como tamanho da janela, inicializações do timer, tamanho da fila, etc., buffer de pacote cheio no destino, atraso de comutação entre outros.