OriNet 5 Posted 2011-08-18 20:54:28 Share Posted 2011-08-18 20:54:28 натолкните на мысль, в чем может быть причина... иногда, ни с того ни с сего, линух начинает считать трафик на некоторых интерфейсах "наоборот", т.е. тот трафик что должен быть входящим на eth0 оказывается входящим на eth3 (всего на сервере 4 интерфейса, линух - АСП-Линукс, ядро 2.6.24.1), при том что исходящий трафик остается на своих местах. Кроме того, похоже что правила iptables применяются тоже на перепутанных интерфейсах не правильно. Вывод команды ifconfig дает вполне адекватные результаты - адреса соответствуют номерам интерфейсов. Такое поведение возникает не известно от чего, а потом так же внезапно все становится на свои места, может продлиться пол часа, может три. Перезагрузка сервера помогает на некоторое время, но это ж не метод Во время этого глюка инет работает нормально, биллинг, и все сервисы вроде в порядке. Только напрягает то что невозможно отследить загрузку каналов и что удаленный доступ с инета на сервер к некоторым функциям перестает работать. В /var/log/messages ничего необычного не нашел... вобщем помогите пожалуйста мне выйти из тупика Link to post Share on other sites
Melanxolik 63 Posted 2011-08-19 05:44:14 Share Posted 2011-08-19 05:44:14 ну в обще не понятно чем считаете что делаете. что в выводах ip a чем графики строите. Link to post Share on other sites
OriNet 5 Posted 2011-08-19 07:07:26 Author Share Posted 2011-08-19 07:07:26 трафик считаю с помощью cban (v. 1.6.0, Current BANdwidth by Nicu Pavel), он же дает входную информацию для построения графиков с помощью MRTG. но мне кажется, подсчет трафика это уже следствие проблемы, а не причина, т.к. во время проявления этого глюка невозможно зайти с инета на Микротик (DNAT срабатывает не на тот интерфейс) ниже даю выхлоп "ip a", только на момент его снятия все работает нормально, но во время проявления глюка эти показания были такими же. пояснения: интерфейсы 0 и 2 смотрят в инет через 2х разных провайдеров (0 в данный момент не используется), 1 и 3 - абоненты (1 по кабелю, 3 по вайфаю) 1:1 и 3:1 используются для вспомогательных целей, когда нужно удаленно зайти на абонентское оборудование с другой группой адресов. основной интерес представляет трафик на 2м интерфейсе (загрузка канала провайдера). Вот когда входящий трафик eth2 показывает как входящий eth3 - проявляется все то безобразие, о котором говорилось выше. 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1492 qdisc htb qlen 1000 link/ether 00:30:4f:17:66:43 brd ff:ff:ff:ff:ff:ff inet 10.38.99.1/28 brd 10.38.99.15 scope global eth0 inet6 fe80::230:4fff:fe17:6643/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000 link/ether 00:30:4f:1c:f2:86 brd ff:ff:ff:ff:ff:ff inet 10.1.41.1/16 brd 10.1.255.255 scope global eth1 inet 10.0.0.254/24 brd 10.0.0.255 scope global eth1:1 inet6 fe80::230:4fff:fe1c:f286/64 scope link valid_lft forever preferred_lft forever 4: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000 link/ether 1c:af:f7:76:33:a9 brd ff:ff:ff:ff:ff:ff inet 80.254.1.242/30 brd 80.254.1.243 scope global eth2 inet6 fe80::1eaf:f7ff:fe76:33a9/64 scope link valid_lft forever preferred_lft forever 5: eth3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000 link/ether 1c:af:f7:76:33:7f brd ff:ff:ff:ff:ff:ff inet 10.0.3.1/24 brd 10.0.3.255 scope global eth3 inet 192.168.1.1/24 brd 192.168.1.255 scope global eth3:1 inet6 fe80::1eaf:f7ff:fe76:337f/64 scope link valid_lft forever preferred_lft forever Link to post Share on other sites
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now