Servidor RedHat crasha ao tirar e/ou colocar cabos de rede (topologia específica).

Miqueloti
(usa Lubuntu)

Enviado em 31/10/2016 - 19:44h

Boa noite prezados,

Estou com um cenário que está me tirando os cabelos.

Tenho servidores RedHat 6.5 (Sim, está desatualizado e o cliente não tem suporte/licença ativa para atualizar ele), cada um com 4 interfaces de rede.

Devido a requisitos do projeto, estamos fechando túnel GRE L2 entre o servidor e outra parte da topologia. Portanto tenho interfaces criadas para fechar tunneis.

Criamos uma bridge batizada de br14 (devido a utilizar Vlan .1q 14 para uso do túnnel) que é composta dos túneis GRE + a interface eth0. Endereçamos a br14 tanto no servidor 1 quanto no servidor 2 com a mesma configuração.

Temos dois servidores para ficar com um deles de backup, então quando queremos deixar um servidor ativo, criamos um IP virtual em cima desta bridge, a br14. portanto fica desta forma:

Server 1:
greN (túnel L2 para a topologia)
eth0 (interface física)
br14 192.168.0.18/24 (Bridge entre túnel e interface física)
Quando for a maquina principal criamos:
br14:0 192.168.0.20/24

Server 2:
greN (túnel L2 para a topologia)
eth0 (interface física)
br14 192.168.0.19/24 (Bridge entre túnel e interface física)
Quando for a maquina principal (se o server 1 cair) criamos:
br14:0 192.168.0.20/24

Este IP virtual é o ip que será utilizado para acessar os serviços aos quais o servidor proverá.

O problema senhores, está no fato que, quando o servidor que está com IP virtual sofre alterações físicas de topologia (tirar e/ou colocar o cabo de rede) na eth0 o RedHat da um crash salva no /var/crash o que aconteceu e depois do crash a maquina dá um boot normal automático.

Quando isto ocorre, temos mecanismos para subir o IP virtual e serviços no server 2 (Heartbeat, todavia não é ele o causador do problema, e sim o IP virtual, já testado manualmente), só que se tirarmos o cabo do servidor 2, o mesmo também dá crash.

Existe algum bug conhecido e um fix para tal bug relativo a criarmos uma interface virtual a partir de uma bridge interface?

Desde já grato a todos, e abaixo segue um dos vmcore-dmesg.txt registrados após crashs, em comum só os modulos utilizados, as mensagens variam um pouco.

<6>igb 0000:02:00.0: eth0: igb: eth0 NIC Link is Down

<6>br14: port 1(eth0) entering disabled state

<6>br14: topology change detected, propagating

<4>------------[ cut here ]------------

<4>WARNING: at kernel/softirq.c:159 local_bh_enable+0x7d/0xb0() (Not tainted)

<4>Hardware name: ProLiant DL360e Gen8

<4>Modules linked in: ip_gre ip_tunnel autofs4 cpufreq_ondemand freq_table pcc_cpufreq bridge 8021q garp stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 iTCO_wdt iTCO_vendor_support microcode power_meter acpi_ipmi ipmi_si ipmi_msghandler hpilo hpwdt igb i2c_algo_bit i2c_core ptp pps_core serio_raw sg lpc_ich mfd_core

<1>BUG: unable to handle kernel paging request at ffffffffaf680ca0

<1>IP: [<ffffffff8105d834>] update_curr+0x144/0x1f0

<4>PGD 1a87067 PUD 1a8b063 PMD 0 

<0>Thread overran stack, or stack corrupted

<4>Oops: 0000 [#1] SMP 

<4>last sysfs file: /sys/devices/virtual/net/GRE15_97.14/carrier

<4>CPU 1 

<4>Modules linked in: ip_gre ip_tunnel autofs4 cpufreq_ondemand freq_table pcc_cpufreq bridge 8021q garp stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 iTCO_wdt iTCO_vendor_support microcode power_meter acpi_ipmi ipmi_si ipmi_msghandler hpilo hpwdt igb i2c_algo_bit i2c_core ptp pps_core serio_raw sg lpc_ich mfd_core ioatdma dca shpchp ext4 jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]

<4>

<4>Pid: 137, comm: linkwatch Not tainted 2.6.32-504.el6.x86_64 #1 HP ProLiant DL360e Gen8

<4>RIP: 0010:[<ffffffff8105d834>]  [<ffffffff8105d834>] update_curr+0x144/0x1f0

<4>RSP: 0018:ffff880049023d98  EFLAGS: 00010086

<4>RAX: ffff88092f74e080 RBX: 0000000005b500c0 RCX: ffff880930500cc0

<4>RDX: 00000000000194d0 RSI: ffff88092f9aeb18 RDI: ffff88092f74e0b8

<4>RBP: ffff880049023dc8 R08: ffffffff8160e105 R09: 0000000000000000

<4>R10: 0000000000000010 R11: 0000000000000000 R12: ffff880049036928

<4>R13: 00000000000f520c R14: 0000000000000001 R15: ffff88092f74e080

<4>FS:  0000000000000000(0000) GS:ffff880049020000(0000) knlGS:0000000000000000

<4>CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b

<4>CR2: ffffffffaf680ca0 CR3: 0000000911e15000 CR4: 00000000000407e0

<4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

<4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

<4>Process linkwatch (pid: 137, threadinfo ffff88092f758000, task ffff88092f74e080)

<4>Stack:

<4> ffff880049023da8 ffffffff81015463 ffff88092f74e0b8 ffff880049036928

<4><d> 0000000000000000 0000000000000000 ffff880049023df8 ffffffff8105dc7b

<4><d> ffff8800490368c0 0000000000000001 00000000000168c0 0000000000000001

<4>Call Trace:

<4> <IRQ> 

<4> [<ffffffff81015463>] ? native_sched_clock+0x13/0x80

<4> [<ffffffff8105dc7b>] task_tick_fair+0xdb/0x160

<4> [<ffffffff81060d71>] scheduler_tick+0xc1/0x260

<4> [<ffffffff810b0760>] ? tick_sched_timer+0x0/0xc0

<4> [<ffffffff8108760e>] update_process_times+0x6e/0x90

<4> [<ffffffff810b07c6>] tick_sched_timer+0x66/0xc0

<4> [<ffffffff810a338e>] __run_hrtimer+0x8e/0x1a0

<4> [<ffffffff810aa78f>] ? ktime_get_update_offsets+0x4f/0xd0

<4> [<ffffffff810a36f6>] hrtimer_interrupt+0xe6/0x260

<4> [<ffffffff810342fd>] local_apic_timer_interrupt+0x3d/0x70

<4> [<ffffffff81533c05>] smp_apic_timer_interrupt+0x45/0x60

<4> [<ffffffff8100bb93>] apic_timer_interrupt+0x13/0x20

<4> <EOI> 

<4>Code: 00 44 8b 35 63 ee a3 00 45 85 f6 74 32 48 8b 50 08 8b 5a 18 48 8b 90 10 09 00 00 48 8b 4a 50 48 85 c9 74 1b 48 63 db 48 8b 51 20 <48> 03 14 dd a0 06 c0 81 4c 01 2a 48 8b 49 78 48 85 c9 75 e8 48 

<1>RIP  [<ffffffff8105d834>] update_curr+0x144/0x1f0

<4> RSP <ffff880049023d98>

<4>CR2: ffffffffaf680ca0