yvt1974

Хм, статистика почему-то показывает обратное - где-то на общее число абонентов тратится 30-50% адресов. Да я и не спорю с этими цифрами, просто имеющийся tradeoff "экономия 50 процентов адресного пространства" vs "проблемы с идентификацией (да и тарификацией, если у клиента не голый анлим) связки IP-клиент-момент_времени" - вопрос сложный, спорный и неоднозначный, JIMHO. Для собственных нужд я таки пока склоняюсь к схеме "статический серый через НАТ" + опционально статический реальный за n денег. Спрос на эту опцию - мизерный. Причем многие не только частники, но и мелкая корпоративка (аля офис директор+бухгалтер) знать ничего о реальных ИП и ослах не знают и знать не хотят. А вот то, что их непатченую ХР сношают не из всего Интернета, а только "местные", срок жизни оной ХР малость продляет.

Гм... Не споря по сути - средний размер пакета 64 байта - не маловато ли? Или там голоса 40Гб/с будет? :)

Гм... А в чем сермяжный смысл динамического ИП на широкополосном доступе? При том, что клиент не лимитирован по времени (в отличие от диалапа) и, в принципе, может быть подключен сутками и неделями, делая, таким образом, выданный ему адрес условно постоянным. Особой экономии адресного пространства я не вижу, определенный дополнительный геморрой для системы учета вида "а кто это у нас флудил позавчера с ИП 1.2.3.4?" и "зафильтровать вот этому дятлу порт 12345 дабы не порождал пачками кляузы в abuse" - вижу крупно и ярко =).

Было у одного товарища абсолютно тоже самое.

pppd имеет, в частности, хук ip-up, из которого можно повесить любую систему qdisc.

Зайти-то через компорт можно, но пароль и там ввести придется.

К оранжевым соседям придется и норвежцев отнести =))

А мы не с точки зрения российских смотрели :) Со стороны Украины трасса умирала на телии, смотрел с LG таида (looking-glass.taide.net) - аналогично. При этом ни от нас, ни с таида (там интерфейс к dig есть) даже сайт МХ не резолвился.

Нет, впрочем, мы это выяснили в привате. до этого момента понятно. А вот с этого места поподробнее :) sh 1q table бы глянуть :)

Гм... Это приведено не у меня, а в лежащей передо мной документации на Asotel1908 :) "2. Trunk. If two switches are cascaded together, the bottleneck will happen at the cascading connection. If more cables could be used for the cascading connection, it will reduce the bottleneck problem. [skip] If the switches support trunk function, they are can treat these cables as one connection between them. [skip] This switch support trunk function..." Я не буду цитировать весь раздел 6.1.2, но ни слова о VLAN в нем нет. :) Собственно, поэтому вопрос и возник. Что в данном случае подразумевается под термином "соединение"? Насколько я знаю, терминология cisco отличается от терминологии, принятой другими производителями... В частности, в отношении термина "транк" Ж) Вы в своих постингах используете понятие транк в терминах циски, в то время как в документации на свич принята другая терминология -)

Коллега, а поясните, пожалуйста, эти строки конфигурации. Если судить по документации, то в данном свитче под транком понимается объединение нескольких пар портов в логический порт большей пропускной способности, короче, то что циска называет Etherchannel :) Если это так - то каким боком ЭТО к вланам? Тем более, что несколько тегированных вланов вполне проходят через порт на другой свитч или роутер, поддерживающий .1q, и без создания транковой группы. Можно ли пояснить ситуацию?