d_kalinin
Рейтинг
+2.11
Сила
2.27

d_kalinin

avatar
Нет.
По схеме (http://lanta.opentmb.ru/static/nagios.png), упавший — earl. А этот трудится и проблем не знает :)
avatar
После недолго лирического отступления, почему все OS говно в общем, и FreeBSD в частности, весьма аргументированного и доказательного, продолжаем ждать пример конфига для балансировки трафика и множественных таблиц маршрутизации, не больше-ни меньше, а как на самой огого циске :)
avatar
Сложнее чем? Чем OSPF :)
avatar
Но по ссылке статическая маршрутизация на одном из узлов без балансировки…
avatar
но это же никакого отношения не имеет к заданному вопросу…
avatar
Ну я не сомневаюсь в реальных пацанах, просто интересно посмотреть на конфиг для такой простой задачи :)
Поясню еще раз:
В сети есть несколько маршрутизаторов, который завязаны в один сегмент. Каждый из них обменивается между собой маршрутами, пусть будет OSPF.
Необходимо:
1. Группе компьютеров A обеспечить доступ только к локальным сетям всех подключенный провайдеров
2. Остальным — балансировать трафик между маршрутизаторами, но локальный отправлять к ближайшему.

PS: Linux/*BSD это проблему решают на раз
avatar
Ну для примера: подключены несколько провайдеров.
Ряду пользователей Интернет раздается от одного провайдера, другим — от другого провайдера.
Ну и гибкие схемы маршрутизации — например третьей группе пользователей — доступны только пиринговые подсети провайдеров.
avatar
Проблема не в том, что «создатели брандмауэров экранируют пакеты icmp-redirect», а в том — «because these versions do not support asymmetric routing.»
Например, у Вас есть сеть 10.1.1.0/24, в сети находятся два маршрутизатора, 10.1.1.254 и 10.1.1.253. Есть рабочая станция — 10.1.1.1. Пусть на ней в качестве шлюза по умолчанию прописан 10.1.1.254. Так же есть некая сеть, 10.2.2.0/24, как в которую попадать знает 10.1.1.253.
Т.е., как должно работать:
1. Клиент (10.1.1.1) отсылает пакет на 10.1.1.254.
2. 10.1.1.254 перекидывает пакет на 10.1.1.253, попутно сообщая клиенту — что ходить надо через 10.1.1.253 (именно этот злополучный icmp-redirect)
3. Клиент обрабатывает этот редирект и дальше ходит через 10.1.1.253

Что было до версии 8.2 (2009 год):
Маршрут до узла назначения:
10.1.1.1 -> 10.1.1.254 -> 10.1.1.253 -> 10.2.2.0/24
Обратный маршрут:
10.2.2.0/24 -> 10.1.1.253 -> 10.1.1.1
Т.е. видно, что один хоп выпадает, со всеми вытекающими последствиями.
avatar
Note: ASA/PIX supports ICMP redirects from version 8.2(1) and later. ICMP redirects is not supported in ASA versions prior to 8.2(1) because these versions do not support asymmetric routing.
www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml

Q. When will the Cisco ASA Software Release 8.2 be orderable?
A. The target order date for Cisco ASA Software Release 8.2 is May 2009.
www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml

Ваша правда, с мая 2009 года таки это стало возможно:)
avatar
Ну все люди взрослые, надо понимать, что коммутационное оборудование существует только для того, чтоб предоставлять сервисы, работающие на любом куске говна железе :) Или у Вас сферическая сеть только из свичей и роутеров? :)
avatar
… который спокойно на винтах держит 6Тб :)

PS: Кстати, как там icmp-redirect в аса/пиксах починили? а то 2011 год уже :)
avatar
Она слишком крута, чтоб дружить с каким-то там реалтеком :)
Могу посоветовать отключить циску и положить ее в какое-нибудь уютненькое местечко, типа recycle bin :)
avatar
Иногда полезно читать новости в оригинале :) По существу: Интел признали, что в P(H)67 чипах присутствует ошибка при проектировании, в некоторых случаях вызывающая снижение скорости обмена с устройствами на SATA-портах.

В любом случае — без технических причин этой ошибки и способа ее проявления рано делать какие-либо выводы. На многих сайтах указывается информации о наличии транзисторов для SATA2 портов, ТТХ которых подобраны неверно. Но! До официального заявления Интел — это все только догадки.

Если придерживаться версии о таких транзисторах — то ошибка проявляется как наличии большого кол-ва ошибок чтения/записи на порту, в результате чего падает быстродействие. Самое страшное в этой ситуации — это вполне вероятное загаживание SMART на HDD.

PS: У меня пока подобные проблемы не замечены, ~250MB/s с пула снимаются без проблем.
avatar
i7 — необоснованный перебор :)
avatar
Боюсь про такие тонкости штатного sed не смогу ответить. Но если он Вам так действительно неприятен — то всегда можно доставить гнутый sed :)
Port:   gsed-4.2.1_2
Path:   /usr/ports/textproc/gsed
Info:   The GNU stream editor
Maint:  gabor@FreeBSD.org
B-deps: gettext-0.18.1.1 gmake-3.81_4 libiconv-1.13.1_1
R-deps: gettext-0.18.1.1 libiconv-1.13.1_1
WWW:    http://www.gnu.org/software/sed/sed.html
avatar
Извиняюсь, это из man grep. man sed говорит следующее:
-r      Same as -E for compatibility with GNU sed.
avatar
Ну нельзя быть таким принципиальным в своих выводах:)
Во-первых, и таки да, пользовательская утилита sed (заметьте, к ОС она имеет довольно посредственное отношение имеет) поддерживает ключ "-r":
-R, -r, --recursive
              Read all files under each directory, recursively; this is equiv‐
              alent to the -d recurse option.

Во-вторых — надо хоть как-то приучать себя пользоваться документацией :)
avatar
40мбит
avatar
avatar
ну я этой херней давно не пользуюсь :)