HP N40L / Intel 82574L VLAN Vazamento

1

Esta é uma sequência de uma pergunta anterior ( Alternar o envio de pacotes DHCP para VLAN errada , mas o problema é que não é com o switch, mas sim com o hardware da NIC, acredito.

Basicamente, estou vendo o vazamento de tráfego de transmissão entre as VLANs em um HP N40L com a NIC Intel 82574L.

Primeiro, DHCPDISCOVER aparece nas duas VLANs (a 1 sem tag e a tag 10)

Jul 23 06:51:50 gateway dhcpd: DHCPDISCOVER from 90:84:0d:9c:13:df via eth0.10
Jul 23 06:51:50 gateway dhcpd: DHCPDISCOVER from 90:84:0d:9c:13:df via eth0: network 192.168.100.0/25: no free leases

DHCPOFFER é enviado de volta para a VLAN10 somente porque a VLAN1 não tem concessões gratuitas

Jul 23 06:51:51 gateway dhcpd: DHCPOFFER on 192.168.100.207 to 90:84:0d:9c:13:df (iPhone) via eth0.10

DHCPREQUEST para o mesmo endereço aparece nas duas VLANs novamente:

Jul 23 06:51:52 gateway dhcpd: DHCPREQUEST for 192.168.100.207 (192.168.100.200) from 90:84:0d:9c:13:df (iPhone) via eth0.10
Jul 23 06:51:52 gateway dhcpd: DHCPACK on 192.168.100.207 to 90:84:0d:9c:13:df (iPhone) via eth0.10
Jul 23 06:51:52 gateway dhcpd: DHCPREQUEST for 192.168.100.207 (192.168.100.200) from 90:84:0d:9c:13:df (iPhone) via eth0: wrong network.
Jul 23 06:51:52 gateway dhcpd: DHCPNAK on 192.168.100.207 to 90:84:0d:9c:13:df via eth0

O switch foi substituído desde a minha pergunta original, onde eu pensei que era o switch. Foi um switch Cisco, eu substituí-lo por um HP. Tenho dezenas de switches HP que configuro e gerencio, e tripliquei a configuração e 100% de certeza de que está correta. A configuração relevante (onde 25 é o N40L, 26 é o WAP):

vlan 1 
   name "LAN" 
   untagged 1-25 
   ip address 192.168.100.99 255.255.255.128 
   no untagged 26 
   exit 
vlan 10 
   name "WLS" 
   untagged 26 
   no ip address 
   tagged 25 
   exit 

E a configuração no servidor (CentOS 6)

gateway ~ # ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether a0:b3:cc:e7:58:2e brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.100/25 brd 192.168.100.127 scope global eth0
gateway ~ # ip a s eth0.10
4: eth0.10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether a0:b3:cc:e7:58:2e brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.200/25 brd 192.168.100.255 scope global eth0.10

Minhas perguntas são: 1) Alguém viu algum comportamento semelhante deste hardware? O Google não retorna nenhuma informação. 2) O que mais posso fazer para confirmar que esta é uma questão da NIC? 3) Qualquer solução mágica? ;)

EDIT: VLAN 10 está marcada na porta para o N40L, e desmarcada em apenas uma outra porta que definitivamente vai para o WAP (caso contrário, não veríamos concessões de leasing do iPhone) para que as VLANs não sejam acidentalmente cruzadas -patch:

hp-switch# sho vlan 10

 Status and Counters - VLAN Information - Ports - VLAN 10

  802.1Q VLAN ID : 10          
  Name : WLS         
  Status : Port-based  

  Port Information Mode     Unknown VLAN Status    
  ---------------- -------- ------------ ----------
  25               Tagged   Learn        Up        
  26               Untagged Learn        Up        

Aqui está a configuração completa para o switch; é uma configuração bem simples: link

    
por fukawi2 23.07.2013 / 01:31

1 resposta

2

Observe que, enquanto um DHCP DISCOVER é empacotado em um pacote de difusão UDP, um DHCP REQUEST é unicast - portanto, você não tem apenas o tráfego de broadcast "vazando".

Com base na sua descrição, eu faria mais investigações se você não tivesse vinculado inadvertidamente as VLANs (por exemplo, configurando incorretamente a ponte de software no N40L ou executando um patch cord de uma porta não marcada da VLAN 10 em uma porta sem tag da VLAN 1 ). Execute o tcpdump em um host diferente para ver se uma VLAN transporta tráfego "estrangeiro" para descartar isso primeiro.

Embora isso também possa ser um bug, ao contrário da crença generalizada de que a funcionalidade da VLAN não é um recurso da NIC, mas implementada na camada de software no kernel do Linux. Portanto, se fosse um bug, isso afetaria mais do que apenas um tipo de NIC / host e certamente já teria sido documentado em algum lugar.

    
por 23.07.2013 / 12:03