Igor009 писал(а):
Спасибо за пример!
Примерно я так себе всё представлял, но есть вопросы:
1) Зачем в linksys_rule указываем Service=sip-udp, если SourceNetwork=192.168.0.11? Наверное можно Service=all_services, т.к. мы приоритезируем весть трафик in/out для Linksys.
Логично. Можно и all_services.
Igor009 писал(а):
2) По поводу уменьшения LimitKbpsTotal на 5%.
Мне сечас провайдер даёт 5 Мб/сек. Speedtest.net показывает 4.65-4.75 Мб/сек.
Хочу ограничить канал до 2 Мб/с.
Делаю трубы с LimitKbpsTotal=2000 (правильно ли это, м.б. надо 2048?) + правила для all_service.
После этого Speedtest.net показывает 1.8-1.85 Мб/сек. Т.е. DFL Traffic shaping и так ограничивает мой канал относительно 2 Мб/с на 5-10%! Зачем ещё искуственно его урезать, ведь суммарная скорость доступа уменшиться ещё на 5%.
Ну вот, а писали, что физический канал 2/2МБит. Тогда ставьте total 2000 или 2048, как нравится.
speedtest.net - это перегруженный сервер у черта на куличиках в США. Туда пинги под 200 мс. Это не показатель скорости. Идеал - iperf, близко к идеалу - торренты с большим числом сидов. И не стоит забывать, что даже Speedtest.net показывает полезные данные пакетов, исключая заголовки пакетов, которые как раз составят 5% сверху. Короче, в торрентах проверяйте.
Igor009 писал(а):
3)
http://dlink.ru/ru/faq/85/758.htmlЗачем они создают четыре раззные IP-правила, которые отличаются только полем Service?
Потому что хотят иметь разные приоритеты и разные лимиты на три разных сервиса (http, ftp, smtp). Четвертое правило для всего остального трафика, чтобы он мимо трубы не прошел, а тоже участвовал в распределении полосы. У Вас два правила - для шлюза и всех остальных.
Igor009 писал(а):
а) Name: SMTP_BW_Control
Action: NAT Service: smtp
Source Interface: lan Source Network: lannet
Destination Interface: wan1 Destination Network: all-nets
б) Name: HTTP_BW_Control
Action: NAT Service: http-all
Source Interface: lan Source Network: lannet
Destination Interface: wan1 Destination Network: all-nets
в) Name: FTP_BW_Control
Action: NAT Service: ftp-passthrough
Source Interface: lan Source Network: lannet
Destination Interface: wan1 Destination Network: all-nets
г) Name: Others_BW_Control
Action: NAT Service: all_services
Source Interface: lan Source Network: lannet
Destination Interface: wan1 Destination Network: all-nets
Я думаю, что если оставить только последнее, всё будет работать точно также. В чём здесь сакральный смысл
Честно? Ни в чем
Феншуй
))
На самом деле у первых трех сервисов можно применить ALG. И, кажется, у ftp-passthrough он по умолчанию применен.
Igor009 писал(а):
4) По поводу SIP ALG (глава 6.2.7, примеры - стр. 219 и дальше)
Я его пока не использую, т.к. не понимаю, какие преимущества он мне даст по сравнением с обычным NAT.
Он удобен, когда звонят извне на шлюз, т.е. на порт 5060, без SIP-прокси, т.е. peer-to-peer. При ответе шлюза командой SIP/2.0 183 Call progress, он сообщает в поле Connection Information: IN IP4 х.х.х.х свой IP адрес за NATом, а в поле Media Port: хххх свой порт для RTP потока. Звонящий пытается соединиться с этим IP:портом, но куда стучаться, если адрес из подсети приватных адресов? Вы пробовали позвонить себе на шлюз со стороны WAN роутера без использования SIP-прокси? Попробуйте.
Если звонить будете не с Линксиса, то ничего не услышите на стороне шлюза. А с Линксиса (например, аппаратного IP-телефона) получится, потому что когда он поймет через 1-2 секунды, что к нему данные RTP от голосового шлюза идут с одного адреса, а ему их предлагают отправить по другому IP, он станет слать их на тот порт, откуда получает, т.е. на WAN-порт роутера по открытому UDP-соединению со стороны LAN. Защита от дурака, можно сказать.
В итоге разговор все-таки состоится.
А вот что касается софтовых телефонов, я их перепробовал с десяток, что нарыл в Инете, - нигде нельзя прописать внешний IP. Они либо сами предлагают его узнать, либо предлагают STUN. А где мне взять в локалке провайдера круглосуточно работающий STUN? Негде. Вот тут на помощь и приходит SIP ALG. Когда мой софтовый телефон отвечает, что RTP ему надо слать на адрес 192.168.0.4:12345, то DFL подменяет в этом месте пакета SIP/SD на свой IP и произвольный порт, и соответственно открывает у себя этот порт на данном интерфейсе. Звонящий получает эту информацию ничего не подозревая о подмене и начинает слать туда RTP, который благополучно пробрасывается самим DFL до 192.168.0.4:12345. Супер удобная вещь, когда используешь IP-телефонию без прокси.
Igor009 писал(а):
5)
Цитата:
В IP Rules sip-udp с ALG делайте отдельно, выше всяких там all-services.
По-моему, местоположение IP-правила по отношению к другим IP-правилам никаких преимуществ (в смысле приоритезации или гарантирования полосы пропускания) не даёт, а влияет только на порядок обработки трафика: сначала проверяется верхнее правило - если трафик ему соответсвует, дальнейшие правила не обрабатываются, а если нет - к нему применяется следующее правило и т.д.
Теоритечески понятно, чем меньше правил, тем выше производительность роутера, но я нигде не видел объективных или хотя бы субъективных данных: насколько, например, снижают производительность роутера 100 правил по сравнению с 10 (в среднем).
Я это знаю. Я просто не уверен в правильности срабатывания шейпинга в случае ALG. Ведь фактически, как я сказал выше, порт для RTP открывается динамически. И происходит это в момент прохождения пакета через IP Rules. Но ведь там all_services. В правилах шейпинга стоит сервис sip-udp, но где гарантия, что ALG в этом случае тоже сработает и динамический открываемый порт для RTP будет также участвовать в пайпе, несмотря на то, что в сервисе sip-udp сказано лишь про UDP/5060?
Вход
Регистрация
FAQ
Поиск
