uTorrent+uTP=ацкие оверхеды как раз при условии забитого аплинка. pps растут как на дрожжах.
Но в данном случае умер cpu из-за ната в принципе. Т.е. будь это тупо свитчинг/роутинг, выполняемый asic-ом (не уверен полностью что оно так в 2600 серии), то при том же кол-ве pps циска ничего бы не заметила. НАТ ресурсоемкий…
Они в одном влане или в разных? Делаете аналогично как автор, только вместо 2600 ставите линуксовую машинку. Клиенты в свитч, свитч в линукс, линукс в инет. На линуксе делаете политики, секюрность и все, что вам нужно.
Дополню: в статье примерно так и сделано: 1 физический интерфейс и сабинтерфейсы (vlan если говорит про коммутаторы). А у абонентов на L2/3 свитче ставится untagged порт в соответствующий vlan.
Грустно то, что имея в наличии еще один роутер и свитч, вы начали шевелиться только тогда, когда, простите, петух в жопу клюнул, хотя 80% загрузку цпу терпели до этого.
А НАТ можно было соорудить на линуксе, так и делают когда нет денег ;)
Более гибкий и удобный инструмент для распараллеливания, а также резервирования у Cisco — Server Load Balancing (SLB). Но встречается наверняка с той же периодичностью :)
3. С бродкастом вы ограничены одной подсетью. Т.е. вы не сможете включить вашу лампу у себя на столе и мониторить сервер в Зимбабве :) С Агентом ваш комплекс был бы гибче.
> Тут я вспомнил, что есть замечательная штука IP-broadcast. Суть такова: если слать пакет на IP 192.168.1.255, то его услышат все устройства с IP вида 192.168.1.xxx.
Пара поправок, вы видимо ни разу не сетевик :)
1. Бродкаст адрес зависит от маски подсети, не факт что последний октет будет 255
2. Плохая идея спамить всю сеть. Очень плохая. Обычно сетевики очень возмущены такими разработчиками :)
А почему «в случае с одновременным использованием двух провайдеров возникают проблемы». Я сейчас на sla делаю почти аналогичную задачу: есть 2 серых сети и 2 шлюза. Одна сеть должна идти через первый, вторая через второй. В случае падения одного из них — обе через один. Настраиваем sla, tracking, а в route-map-ах пишет 2 set ip next-hop verify-availability с треком и разными AD. Для каждой сети свой роут мап и зеркальные AD и next-hop.
п.с.: оба сервера в одном vlan, на удаленном коммутаторе.
п.с.: set ip next-hop verify-availability with optional arguments to support object tracking using Internet Control Message Protocol (ICMP) ping or an HTTP GET request to verify if a remote device is reachable.
:)
:):):)
Но в данном случае умер cpu из-за ната в принципе. Т.е. будь это тупо свитчинг/роутинг, выполняемый asic-ом (не уверен полностью что оно так в 2600 серии), то при том же кол-ве pps циска ничего бы не заметила. НАТ ресурсоемкий…
При условии одинаковой производительности линуксовое решение будет в разы дешевле, чем циска, но тока тсссс, это огромный холивар :)
А НАТ можно было соорудить на линуксе, так и делают когда нет денег ;)
Ретранслятор имхо костыль, но вам виднее ;)
Пара поправок, вы видимо ни разу не сетевик :)
1. Бродкаст адрес зависит от маски подсети, не факт что последний октет будет 255
2. Плохая идея спамить всю сеть. Очень плохая. Обычно сетевики очень возмущены такими разработчиками :)
п.с.: оба сервера в одном vlan, на удаленном коммутаторе.
п.с.: set ip next-hop verify-availability with optional arguments to support object tracking using Internet Control Message Protocol (ICMP) ping or an HTTP GET request to verify if a remote device is reachable.
:)
Смотреть вчерашние новости.