маршрутизатор на linux
Поставили этот мост, тестируем, вроде пока все как адо, тьфу, тьфу...
Только вот сразу появилось "узкое место" в месте моста.
Скорость ориентировочная через бридж: 20-30 Мбит/с. Хотелось бы больше, может у кого есть какия предположения куда копать?
Может процесора нехватает? (хотя загрузка при скачивании с той скоростью 20-30 мбит до 5%). может шина данных на PCI-слоте (хотя врядле)??
P.S.: celeron 400, 256Mb RAM, 3 сетевых, 2 из которых должны работать на 100мбит в half-дуплексе в идеале (3Com 3c905), ну и оставшаяся инет раздает (до 10мбит в идеале).
Только вот сразу появилось "узкое место" в месте моста.
Скорость ориентировочная через бридж: 20-30 Мбит/с. Хотелось бы больше, может у кого есть какия предположения куда копать?
Может процесора нехватает? (хотя загрузка при скачивании с той скоростью 20-30 мбит до 5%). может шина данных на PCI-слоте (хотя врядле)??
P.S.: celeron 400, 256Mb RAM, 3 сетевых, 2 из которых должны работать на 100мбит в half-дуплексе в идеале (3Com 3c905), ну и оставшаяся инет раздает (до 10мбит в идеале).
Debian GNU/Linux 3.1 Sarge
Kernel 2.6.16
Kernel 2.6.16
Llama, есть ли возможность удаленно, т.е. средствами Linux это узнать?
С одной только маршрутизацией, если не ошибаюсь, то скорость в районе 10 мбит/с была, замер делался на клиентах WinXP, включенных ест-но по разные стороны маршрутизатора, с помощью утилиты netCPS производился замер.
С одной только маршрутизацией, если не ошибаюсь, то скорость в районе 10 мбит/с была, замер делался на клиентах WinXP, включенных ест-но по разные стороны маршрутизатора, с помощью утилиты netCPS производился замер.
Debian GNU/Linux 3.1 Sarge
Kernel 2.6.16
Kernel 2.6.16
Офигеть, страшную тайну мне удалось узнать недавно...
Оказывается что дальнейшая судьба пакетов на брутере решается в таблице ebtables (broute), все зависит от того какое действие к тому или иному пакету будет применено здесь, будет ли он DROP или ACCEPT.
Если мне не изменяет память, то на офсайте писалось что при DROP пакеты будут routing при ACCEPT - briging.
До этого недели две работало все в режиме моста, ARP, IPv4 были открыты в таблицах broute (все цепочки Iptables находились под политикой ACCEPT), все работало прекрасно, но можно было админить по куче(!) протоколов семейства TCP\IP, что конечно же было не очень хорошо, т.к. хотелось в полной мере использовать и iptables и ebtables.
Вобщем мои предположения в итоге оказались неправильны! (месяц заблуждений, блин...). Включил опцию ip_forward и политику выставил для FORWARD DROP - все, всех повыкидывало по таймаутам не из нашей части.
Хорошо что еще для INPUT (или OUTPUT, что равносильно в моей ситуации) не ляпнул DROP.... Хотя, возможно офсайт был и прав, просто я не к тому те слова применил, ведь у нас брутер стоит между 2 сегментами с одинаковой маской, т.е. маршрутизровать ничего не надо, получается сеть как бы сохраняет свою логическую целостность, буд-то на месте брутера стоит обычный коммутатор (имхо отличие лишь в том, что коммутатор обрабатывает данные параллельно на каждом порту, а мост послед-но).
Сделаю все, напишу отчет от и до, надеюсь пригодиться кому-нить...
P.S.: в очередной раз подтвердилось, что опыт полученный практическим путем во много раз ценнее теоретического...
Оказывается что дальнейшая судьба пакетов на брутере решается в таблице ebtables (broute), все зависит от того какое действие к тому или иному пакету будет применено здесь, будет ли он DROP или ACCEPT.
Если мне не изменяет память, то на офсайте писалось что при DROP пакеты будут routing при ACCEPT - briging.
До этого недели две работало все в режиме моста, ARP, IPv4 были открыты в таблицах broute (все цепочки Iptables находились под политикой ACCEPT), все работало прекрасно, но можно было админить по куче(!) протоколов семейства TCP\IP, что конечно же было не очень хорошо, т.к. хотелось в полной мере использовать и iptables и ebtables.
Вобщем мои предположения в итоге оказались неправильны! (месяц заблуждений, блин...). Включил опцию ip_forward и политику выставил для FORWARD DROP - все, всех повыкидывало по таймаутам не из нашей части.
Хорошо что еще для INPUT (или OUTPUT, что равносильно в моей ситуации) не ляпнул DROP.... Хотя, возможно офсайт был и прав, просто я не к тому те слова применил, ведь у нас брутер стоит между 2 сегментами с одинаковой маской, т.е. маршрутизровать ничего не надо, получается сеть как бы сохраняет свою логическую целостность, буд-то на месте брутера стоит обычный коммутатор (имхо отличие лишь в том, что коммутатор обрабатывает данные параллельно на каждом порту, а мост послед-но).
Сделаю все, напишу отчет от и до, надеюсь пригодиться кому-нить...
P.S.: в очередной раз подтвердилось, что опыт полученный практическим путем во много раз ценнее теоретического...
Debian GNU/Linux 3.1 Sarge
Kernel 2.6.16
Kernel 2.6.16
Доброго дня, коллеги!
Я понимаю, что тема набила оскомину, но я никак не могу разобраться, а все больше запутываюсь...
Имеется сеть под offtopic-ом.
В сети два сегмента с адресами из диапазонов:
1-сегмент 172.16.15.ХХХ
2-сегмент 192.168.1.ХХХ
В сегменте 172.16.15.ХХХ адрес шлюза 172.16.15.1
Хотелось бы объединить эти 2 сегмента.
Имею машину с установленным Debian Sarge.
на машине с debian только одна сетевая карта. Ей присвоен ip 172.16.15.219
я присваиваю интерфейсу eth0 второй ip адрес
ifconfig eth0:0 192.168.1.1
======================
======================
и разрешаю пересылку пакетов между интерфейсами.
======================
Т.е. если я все правильно понял, то на сервере никаких дополнительных действий производить не нужно.
======================
Теперь вопрос в том, чтобы правильно настроить маршрутизацию в обоих сегментах сети на клиентских машинах.
Насколько я понял на linux клиентах это делается так.
======================
Теперь бьюсь над настройкой машин под windows xp
======================
единственное чего добился - в обоих сегментах пингуются адреса моей debian машины. 172.16.15.219 и 192.168.1.1.
Прошу помощи - как добиться доступа к обоим сегментам сети.
Я совсем запутался.
Я понимаю, что тема набила оскомину, но я никак не могу разобраться, а все больше запутываюсь...
Имеется сеть под offtopic-ом.
В сети два сегмента с адресами из диапазонов:
1-сегмент 172.16.15.ХХХ
2-сегмент 192.168.1.ХХХ
В сегменте 172.16.15.ХХХ адрес шлюза 172.16.15.1
Хотелось бы объединить эти 2 сегмента.
Имею машину с установленным Debian Sarge.
на машине с debian только одна сетевая карта. Ей присвоен ip 172.16.15.219
я присваиваю интерфейсу eth0 второй ip адрес
ifconfig eth0:0 192.168.1.1
======================
Код: Выделить всё
eth0 Link encap:Ethernet HWaddr 00:50:22:40:10:92
inet addr:172.16.15.219 Bcast:172.16.15.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21461 errors:0 dropped:0 overruns:0 frame:0
TX packets:4041 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1940827 (1.8 MiB) TX bytes:735043 (717.8 KiB)
Interrupt:11 Base address:0x6400
eth0:0 Link encap:Ethernet HWaddr 00:50:22:40:10:92
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:11 Base address:0x6400
и разрешаю пересылку пакетов между интерфейсами.
Код: Выделить всё
echo 1 > /proc/sys/net/ipv4/ip_forward
Т.е. если я все правильно понял, то на сервере никаких дополнительных действий производить не нужно.
======================
Теперь вопрос в том, чтобы правильно настроить маршрутизацию в обоих сегментах сети на клиентских машинах.
Насколько я понял на linux клиентах это делается так.
Код: Выделить всё
ip route add 172.16.15.0/24 via 192.168.1.1
(для 2 сегмента)
ip route add 192.168.1.0/24 via 172.16.15.219
(для 1 сегмента)
Теперь бьюсь над настройкой машин под windows xp
======================
единственное чего добился - в обоих сегментах пингуются адреса моей debian машины. 172.16.15.219 и 192.168.1.1.
Прошу помощи - как добиться доступа к обоим сегментам сети.
Я совсем запутался.
Ах, да - вывод iptables на машине с debian....
iptables -L
iptables -L
Код: Выделить всё
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination