Conflito de IPs

Boa noite!

Agrupei 2 servidores q tinha num só: um usava a rede 192.168.1.XXX e outro 192.168.10.XXX.... Mantive a rede 1.XXX e criei um alias pra eth2 com a rede 192.168.10.XXX. Mas aconteceu de começar hoje a dar conflito de ips em clientes variados. Tenho certeza q não são "espertinhos" tentando acessar a rede, o que mais poderia ser? Todos os clientes tem ips fixos nessas 2 classes e embora eu tenha outras classes na mesma máquina, em outras eth´s, somente gerou conflito nessa eth q tem essas 2 classes citadas!

Qualquer luz fico muito agradecido!

Verifique se não está cometendo esses erros fatais:

1 - ligar duas ou mais placas de rede no mesmo equipamento ativo (hub, swith, ap)

2 - proxy_arp ativo

Verifique também sua tabela ARP e veja se não aparece o mesmo mac com interfaces diferentes.

Ja vi isso acontecer em um cliente meu e ele usava no caminho um AP + Bridge que não se deram bem!

Citação:

---

Postado originalmente por PatrickBrandao

Verifique se não está cometendo esses erros fatais:

1 - ligar duas ou mais placas de rede no mesmo equipamento ativo (hub, swith, ap)

2 - proxy_arp ativo

Verifique também sua tabela ARP e veja se não aparece o mesmo mac com interfaces diferentes.

Ja vi isso acontecer em um cliente meu e ele usava no caminho um AP + Bridge que não se deram bem!

---

Patrick

proxy_arp no AP2000 vc fala? Se for, está desativado... às vezes conflita os ips da classe 1 com a classe 1 mesmo, às vezes da classe 1 com a 10, da 10 com a 1... Estou ficando louco! Os clientes não param de ligar!

Alexandre,

confligo de ip acontece assim:

Para se comunicar via enlace de dados (camada 2 - csma/cd=ethernet ou csma/ca=802.11b) a camada 3 associa mac a ip para poder encapsular os pacotes na camada de baixo (MAC). Essa associação é feita pelo ARP.

Para enviar um pacote ip a camada 3 precisa do endereço da camada 2 (mac), o arp consulta a tabela de cache para localizar o mac

Linux: # arp -n
Win: > arp -a

Se o mac não estiver no cache, ele envia um broadcast de mac (destino FF:FF:FF:FF:FF:FF, origem (MAC da placa que fez o pedido), esse pedido é chamado de ARP REQUEST, as máquinas que recebem esse pacote consultam sua tabela de ips locais e se o ip procurado estiver na tabela, ele responde com um ARP REPLY, senão ignora. Dessa forma uma maquina descobre o mac de outra.

O windows, quando iniciado com um ip (por exemplo: 10.0.0.20) ele envia um ARP REQUEST na rede perguntando pelo MAC desse ip. Ele espera que ninguem responda pois afinal esse ip é dele. Se alguem responder, significa que o ip já está em uso e para evitar conflitos de ARP REPLY (pois varios computadores responderiam ao ARP REQUEST) ele enche o saco!

Normalmente algumas bridges ou hosts com proxy_arp que possuem varias interfaces de rede respondem a ARP REQUEST de uma rede para outra para fazer um efeito de transparencia, esse normalmente é o problema que gera o conflito: responder pela pergunta de proxy arp na mesma rede.

Para detectar o causador do problema, normalmente eu ligo um linux na rede e uso o utilitario "arping" (envia um arp request e aguarda por um arp reply, muito bom pra detectar uma maquina ligada que nao responde a ping por causa de firewall!).

Suponha que o cliente 10.0.0.30 reclama de confligo, vc liga o linux na rede com um ip que não esteja na rede pois o arping nao depende de rotas ou ips, faça um arping pelo ip do cliente:

# arping -I eth0 10.0.0.30

Agora desligue um a um seus equipamentos de rede, quando o arping parar, vc achou o culpado!

boa sorte!

Patrick!

A topologia da rede está assim:

eth2 -> cabo de rede -> ap2000 (1 cartão omni 15 hyperlink) -> wds -> ap2000 (2 cartões - (B) Direcional wds e (A) omni 15 hiperlink)

A eth2 ta com ip 192.168.1.XXX e a eth2:1 com ip 192.168.10.XXX

O primeiro ap2000 esta com ip 192.168.10.253 e o segundo com ip 192.168.1.253...

Além do proxy arp no ap2000, teria mais alguma configuração para sanar este problema? Axo q vc citou exatamente o q pode estar causando a confusão, mas como sou inexperiente em tcp/ip fico meio perdido em procurar este problema... Como comentei, acontece somente nesta eth2, será q se eu mudasse todos os clientes q usam os ips 192.168.10.XXX pra 192.168.1.XXX resolveria e desativasse a classe 192.168.10.XXX? Axo q não né?

Tente desligar algum dos AP's no WDS e veja se resolve.

Tente adicionar mais um ip na eth2 e teste com um cliente e veja se continua o conflito:

# ifconfig eth2:1 172.16.0.1 netmask 255.255.255.0 broadcast 172.16.0.255

no cliente:
ip: 172.16.0.X
mascara: 255.255.255.0
gatewa: 172.16.0.1

testa lá!

Citação:

---

Postado originalmente por PatrickBrandao

Tente desligar algum dos AP's no WDS e veja se resolve.

Tente adicionar mais um ip na eth2 e teste com um cliente e veja se continua o conflito:

# ifconfig eth2:1 172.16.0.1 netmask 255.255.255.0 broadcast 172.16.0.255

no cliente:
ip: 172.16.0.X
mascara: 255.255.255.0
gatewa: 172.16.0.1

testa lá!

---

Aparentemente consegui resolver o problema... pelo menos por enquanto ninguém mais reclamou! Tinha um ovislink WL5460 q instalei num cliente por coincidência no mesmo dia q efetuei a mudança. Comecei a perguntar o MAC q o Windows informava aos clientes sempre q alguém ligava e percebi q era sempre esse mac. Bom pensei q ele estive com o servidor de DHCP ativo, fui no cliente verificar e estava desativado. Retirei o ovislink e estou montando um servidorzinho linux pra colocar no lugar. Como disse, até o momento ninguém reclamou mais, se acontecer alguma coisa volto a postar pra deixar o pessoal informado caso alguém passe algum dia por um problema semelhante.

Obrigado pelas informações, Patrick! E quando q sai o novo myauth?

ABs!

Que bom que resolveu!

Quando ao novo MyAuth, estou trabalhando 17 horas por dia nele! Te mando e-mail quando ficar pronto!

abraços