LVS-TUN: ifconfig mostra erros e colisões para a interface tunl0?

Question

Check_MK enviou-me um email da seguinte forma:

***** Nagios *****

Notification Type: PROBLEM

Service: Interface 5
Host: foo
Address: x.y.z.t
State: CRITICAL

Date/Time: Fri May 3 10:02:40 ICT 2013

Additional Info: CRIT - [tunl0] (up) speed unknown, in: 3.39MB/s, out: 0.00B/s, out-errors: 100.00%(!!) = 0.1

executando ifconfig , recebi:

tunl0     Link encap:IPIP Tunnel  HWaddr   
          inet addr:x.y.z.t  Mask:255.255.255.255
          UP RUNNING NOARP  MTU:1480  Metric:1
          RX packets:92101704629 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:652 dropped:0 overruns:0 carrier:0
          collisions:652 txqueuelen:0 
          RX bytes:18941091817671 (17.2 TiB)  TX bytes:0 (0.0 b)

Preste atenção nos erros e colisões. Eu sei que um valor diferente de zero do campo de colisões indica a possibilidade de congestionamento da rede. Mas:

1. Qual pode ser a causa exata? Como posso resolver problemas?
2. Existe algum similar a ethtool para a interface do túnel IPIP?

modinfo ipip

filename:       /lib/modules/2.6.18-194.17.1.el5/kernel/net/ipv4/ipip.ko
license:        GPL
srcversion:     288C625C7521D577F7AD9E4
depends:        tunnel4
vermagic:       2.6.18-194.17.1.el5 SMP mod_unload gcc-4.1
module_sig: 883f3504ca37590565662cff69dd0be11277ff0a08d3a3...

show de túneis ip

tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc

ATUALIZAÇÃO em seg 06 de maio 10:05:01 ICT 2013

@Danila Ladner : Ao pesquisar no Google, achei que este link tem a mesma opinião com você:

My tunnel does not work:

ifconfig tunl<n> reports errors and collisions

Did you use ifconfig, perhaps ifconfig ... pointopoint ... to set up your tunnel?

Shut it down; delete it; start again with ip.

Mas você poderia, por favor, elaborar mais?

@Sergey Vlasov :

tunl0     Link encap:IPIP Tunnel  HWaddr   
          inet addr:x.y.z.t  Mask:255.255.255.255
          UP RUNNING NOARP  MTU:1480  Metric:1
          RX packets:81621711099 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:692 dropped:0 overruns:0 carrier:0
          collisions:692 txqueuelen:0 
          RX bytes:16915649263419 (15.3 TiB)  TX bytes:120 (120.0 b)

Eu não entendo porque existem 2 pacotes transmitidos da interface tunl0 ? Vou configurar um manipulador de eventos para executar tcpdump sempre que collisions counter for aumentado. Vamos esperar para ver o que acontece.

ATUALIZAÇÃO no dia 7 de maio às 14:05:39 TIC 2013

@Danila Ladner : Para excluir a possibilidade, tentei sua sugestão:

ifdown tun0
modprobe -r ipip
modprobe ipip
ip addr add dev tunl0 x.y.z.t/32 brd x.y.z.t
ip link set tunl0 up

Estou esperando para ver se o problema foi resolvido:

tunl0     Link encap:IPIP Tunnel  HWaddr   
          inet addr:x.y.z.t  Mask:255.255.255.255
          UP RUNNING NOARP  MTU:1480  Metric:1
          RX packets:19630041 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4083271398 (3.8 GiB)  TX bytes:0 (0.0 b)

    

Answer 1

Como quanta observou, eu sugeri que ele retirasse o túnel se ele fosse construído com ifconfig e reconstruísse com ip . Como eu tive um problema semelhante em Centos 5 kernel 2.6.25 alguns anos atrás, No meu caso, resolveu o problema, Mas eu também estava consultando caras net e devs no IRC porque isso foi um problema que eu precisava dessa rota na caixa de produção e precisava agendar um tempo de inatividade para desativá-lo. Eu não me lembro exatamente e a partir de agora não tenho nenhuma prova, mas Kuznetsov (grande colaborador original da fonte do kernel sobre o assunto sugeriu reconstruí-lo com ip , pois ele viu problemas com ifconfig . Espero que isso ajude quanta para resolver o problema.

OFF TOPIC: Então, a questão é que eu sou muito burro usando muito ifconfig e é difícil mudar para ip , contanto que eu continue lidando com antigas caixas Solaris 8 e caixas de bsd.

    

Answer 2

O contador collisions para uma interface de túnel ipip é aumentado em dois casos:

1. Se o próximo salto do pacote encapsulado for a mesma interface de túnel: ipip.c linha 437 .

2. Se o caminho MTU do próximo salto para o pacote encapsulado for menor que 68: ipip.c linha 447 .

Ambos os casos normalmente só acontecem se o tráfego encapsulado fizer um loop no mesmo túnel (o primeiro caso é um loop direto, o segundo caso acontece quando o MTU do caminho é reduzido a zero devido a algum loop mais complicado que não foi imediatamente detectado pela primeira condição). Uma causa possível é que a rota normal para pacotes encapsulados estava temporariamente inativa e a próxima melhor rota para esses pacotes era o próprio túnel, resultando em um loop.

No entanto, no caso LVS-TUN, nada deveria ter sido enviado para o túnel (a interface do túnel neste caso é somente de recepção), a menos que algum software mal orientado tenha adicionado rotas desnecessárias em tunl0 .