Вопросы Теги

Как к диагностическому отказу доступа в Интернет в системе Linux?

У меня есть a VM работа Xen. Виртуальная машина хорошо работала в течение многих месяцев и suddently, который сломал доступ к сети. 

             Dom0                           DomU

.-------.  bridge  .-------. virtual link .------.
| eth0  |----------| vif55 |-------x------| eth0 |
'-------'          '-------'       |      '------'
                                   |
Seems to be broken somewhere here /

Однако я могу все еще xm console от Dom0 и получите доступ VM.

Я хотел бы понять то, что является источником проблемы. Что я знаю, наверняка это, если я перезапускаю мой VM все вернется к нормальному (я знаю это, потому что это не первый раз, когда это происходит)...

Вот то, что я сделал до сих пор:

От DomU

xm console domu
$ sudo su
$ ifconfig

Сетевое соединение смотрит хорошо. IP в порядке, но любая из этих команд перестанет работать:

$ ping dom0
$ ping 8.8.8.8

Ошибка, которую я получил:

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
ping: sendmsg: No buffer space available
^C
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 24002ms

Мой fail2ban не выглядит поврежденным: 

$ tail -n2 fail2ban.log
2015-07-31 19:41:52,851 fail2ban.actions[1854]: WARNING [ssh] Ban 218.65.30.61
2015-07-31 19:51:53,618 fail2ban.actions[1854]: WARNING [ssh] Unban 218.65.30.61

$ iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-apache  tcp  --  anywhere             anywhere             multiport dports http,https
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain fail2ban-apache (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Chain fail2ban-ssh (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Доступное дисковое пространство, данное df взгляды хорошо.

От Dom0

VM работает:

$xmlist | grep domu
domu                                   55  4096     4     -b---- 670393.8

Это подключено с vif55:

$iptables -L | grep domu
ACCEPT     all  --  domu            anywhere            PHYSDEV match --physdev-in vif55.0

vif55 доступно:

$ ifconfig | grep vif55.0
vif55.0   Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff
          inet6 addr: xxxx::fcff:ffff:xxxx:ffff/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:60965324 errors:0 dropped:0 overruns:0 frame:0
          TX packets:130097868 errors:0 dropped:22 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:3441407339 (3.2 GiB)  TX bytes:161037189 (153.5 MiB)

vif55 подключен к сетевому мосту:

$ brctl show
bridge name     bridge id               STP enabled     interfaces
eth0            8000.10604ba1432a       no              peth0
                                                        vif1.0
                                                        vif10.0
                                                        vif11.0
                                                        vif48.0
                                                        vif51.0
                                                        vif55.0
                                                        vif56.0
                                                        vif57.0
                                                        vif58.0
                                                        vif59.0
                                                        vif60.0
                                                        vif9.0
0
задан 1 August 2015 в 16:38
1 ответ

Ключ к разгадке этой загадки - ошибка, которую вы получаете от ping : sendmsg: Нет доступного буферного пространства . Это означает, что пакеты не просто куда-то сбрасываются, они фактически где-то «забиваются» в гостевой системе. На физической машине это означает, что драйвер ядра и / или оборудование неисправны; аналогично, в виртуальной машине это означает, что у вас где-то есть низкоуровневый сетевой код с ошибками.

Во-первых, убедитесь, что вы в курсе обновлений, особенно на хосте. Если вы используете очень старую версию своей ОС, возможно, сейчас самое время ее обновить - в Xen за последние годы исправлено множество ошибок.

Вы можете , временно устраните его, увеличив sysctl net.core.wmem_max . Однако это не «исправление», а просто обходной путь; предположительно, большее буферное пространство в конечном итоге снова заполнится, и вы вернетесь туда, где находитесь сейчас.

Вы не указываете, как вы запускаете гостя. Если он полностью виртуализирован, возможно, в используемой вами эмулированной сетевой карте есть ошибка; virtio one - ваш лучший выбор, но если вы уже используете его, попробуйте вместо него e1000 .

1
ответ дан 4 December 2019 в 16:52

Теги

Похожие вопросы