Перейти к содержимому
Калькуляторы

G.Y.S.

Активный участник
  • Публикации

    141
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные пользователем G.Y.S.


  1. AT- многомодовые - у нас висли (10 штук), от незначительного удара по корпусу(?) или просто достаточно пошевелить медный (хорошо обжатый провод), после этого их уже не покупали.

     

    Сейчас работают 10 dlink - уже 2 года - проблем - 0.

    С Dlink - недостаток - сильно греются (намного сильнее чем планеты FT-806/706)

    Плюс - у них одна линеейка! и одно шасси, в отличии от планеты с 2-мя разными линейками FT/WFT

     

    Подозреваю что планеты WFT и Длинк - также взаимозаменяемы и одинакого сильно греются.

  2. 1) Каталист 2950 при такой петле сначала лег (потерял управление) потом переслала работь сетевые уст-ва к нему подлюченные.

     

    После

    interface FastEthernet0/1

    storm-control broadcast level 20.00

    storm-control action shutdown

     

    стал отрубать порт на котором петля

     

    c2950(config-if)#storm-control ?

    action Action to take for storm-control

    broadcast Broadcast address storm control

    multicast Multicast address storm control

    unicast Unicast address storm control

     

    видно что можно защититься от разних типов "шторма".

    Минус - это то что коммутатор не включает порт при исчезновении петли (а должен??)

    Хотя впрочем его можно включить по snmp, отловив это событие.

    2) Длинк (модели кроме 3526) же зараза даже при влюченном storm-control - при наличии петли ничего не делает

    о чем некий grig написал тут:

    http://www.dlink.ru/phorum/viewtopic.php?t...?t=9500&start=0

     

    Вопрос к сотрудникам длинк - ПОЧЕМУ ?

     

    Описание фичи loopback guard приводимой сотрудником длинк в тех документации на сайте длинк я не нашел. Из e-mail от длинк - понятно лишь что это фича относиться к stp (?) Хотелось здесь бы услышать механизм ее подробной работы.

     

    3) HP

    гашел лишь фунцию storm-control где можно задать пороговоре знаечине, при превышении которого коммутатор начнет дропать пакеты. Спасет ли это от приведенной петли в HP сказали - не знаем - нужно тестить? Кто нибудь знает ?

     

    4) хотелось бы услышать как обстоят дела у свичей других контор-производителей.

  3. MPD - вдруг перестал работать принимать соединения от клиентов в одном из VLAN-в (ранее работал пол-года без проблем)

    На клиенте возникает ошибка - удаленный компьютер не отвечает.

    НА сервере - PPPoE connection timeout after 9 seconds.

     

    Другие клиенты в др-х vlan-ы работают с темже сервером без проблем.

    Физически связь клиент-сервер - ок (пинги ходят (по ip при выкл mpd).

    Железо полностью менялось.

  4. Подключаться будем через ADSL модем в режиме бриджа.

    насчёт роутинга не понял ...

     

    на счет роутинга - не понимаю что не понятного ;-)

     

    ADSL модем - 1 PPPOE

    ADSL модем - 2-ой PPPOE

     

    а от модемов то куда ?

  5. 2Saenara - а что вы там хотите найти ? (инетересно чтобы ход мысле проследить=))

    C:Documents and SettingsАдминистратор>ipconfig /all

     

    Настройка протокола IP для Windows

     

    Имя компьютера . . . . . . . . . : User

    Основной DNS-суффикс . . . . . . :

    Тип узла. . . . . . . . . . . . . : смешанный

    IP-маршрутизация включена . . . . : нет

    WINS-прокси включен . . . . . . . : нет

     

    Подключение по локальной сети - Ethernet адаптер:

     

    DNS-суффикс этого подключения . . :

    Описание . . . . . . . . . . . . : Intel® PRO/100 VE Network Connection

    Физический адрес. . . . . . . . . : 00-08-0D-9B-2C-D1

    Dhcp включен. . . . . . . . . . . : нет

    IP-адрес . . . . . . . . . . . . : 172.16.16.177

    Маска подсети . . . . . . . . . . : 255.255.248.0

    Основной шлюз . . . . . . . . . . : 172.16.16.1

    DNS-серверы . . . . . . . . . . . : xxx.xxx.xxx.xxx

    xxx.xxx.xxx.xxx

  6. Уже не раз замечаю странный глюк, который не могу побороть.

    На ПК Windows XP. Очень редко, но метко возникает следующее:

    icmp (пинги) пакеты ходяти.., НО

    система отказывается работать с доменными именами + браузер также не проглатывает ip хостов! Вот пример

     

    ПК 172.16.16.177/21 подключен кабелем к маршрутеру (172.16.16.1/21).

     

    # ПК набрал в IE адрес или ip работающего хоста (или сделал nslookup в ком. строке) - картина:

    13:57:49.403768 IP 172.16.16.177.137 > 172.16.23.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

    13:57:50.153663 IP 172.16.16.177.137 > 172.16.23.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

    13:58:11.675663 IP 172.16.16.177.137 > 172.16.23.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

    13:58:12.422259 IP 172.16.16.177.137 > 172.16.23.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

    13:58:13.173157 IP 172.16.16.177.137 > 172.16.23.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

     

    Пробуем пинговать - ВСЕ ОК:

    13:58:41.005930 IP 172.16.16.1 > 172.16.16.177: icmp 9: echo request seq 63173

    13:58:41.006904 IP 172.16.16.177 > 172.16.16.1: icmp 9: echo reply seq 63173

     

    #ping www.ya.ru в ком. сроке ПК:

     

    13:59:02.894576 IP 172.16.16.177.137 > 172.16.23.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

    13:59:03.631471 IP 172.16.16.177.137 > 172.16.23.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

    13:59:04.382344 IP 172.16.16.177.137 > 172.16.23.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

    13:59:24.641261 IP 172.16.16.177.137 > 172.16.23.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

    13:59:25.384156 IP 172.16.16.177.137 > 172.16.23.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

    13:59:26.135040 IP 172.16.16.177.137 > 172.16.23.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

     

    #ping 213.180.204.8 (тот же ya.ru) в ком. сроке ПК:

     

     

    13:59:48.765594 IP 172.16.16.177 > 213.180.204.8: icmp 40: echo request seq 256

    13:59:48.778884 IP 213.180.204.8 > 172.16.16.177: icmp 40: echo reply seq 256

    13:59:49.778434 IP 172.16.16.177 > 213.180.204.8: icmp 40: echo request seq 512

    13:59:49.794556 IP 213.180.204.8 > 172.16.16.177: icmp 40: echo reply seq 512

    13:59:50.778312 IP 172.16.16.177 > 213.180.204.8: icmp 40: echo request seq 768

     

    Проблемма однозначно в системе, т.к. стоящий рабом ноутбук - с теми же настройками работатет...

  7. Привет jab. Я тоже так думал.

    Но когда вижу 35% - на ненагруженном пк-роуторе + idle = 50%,

    наводит на размышления... А у тебя какая загрузка?

    Я сделал вывод, что mpd жрет ресурсы в зависимости от количества созданных ng.

    А не от кол-ва подключенных ПК и/или проходящего трафика. Что немного странно.

  8. FreeBSD 5.4 + MPD 3.18 на P4 c 512 DDR

     

    нужно затерминировать 400 сессий (по 100 в каждом VLAN).

    делаем конфики на 400 ng:

    кусок mpd.links

    PPPoE099:

    set link type pppoe

    set pppoe iface vlan10

    PPPoE100:

    set link type pppoe

    set pppoe iface vlan11

     

    после запуска машинки (в тестовых целях) к ней подключилось 15-20 ПК. Видим загрузку mpd 20-35%! Крутили ручки, смотрели нагрузку искали флудеров - без эффектов. Загрузка могла с 30% упась в 0. Спонтанно.

    Далее сконфикурили ровно 100 ng. По 25 в каждый vlan. После запуска машинки (в тестовых целях) к ней подключилось теже 15-20 ПК. Загрузка mpd от 0 до 2%.

     

    Кто сталкивался ? Как побороть ?

  9. ОК

    У нас 2 дня - тоже полет нормальный

    pf.conf

    no nat on em0 from any to 10.0.0.0/8

    no nat on em0 from any to 172.16.0.0/12

    no nat on em0 from any to 192.168.0.0/24

    nat on em0 from 10.68.0.0/16 to any -> xxx.xxx.xxx.xxx/31 source-hash

     

    Сейчас думаю переписать правила на роутерах под pf.

  10. А можно узнать по какой?

    стр.1

    Пишется сейчас программа под винду - панель доступа ко всем сервисам, устанавливает маршруты, создает ярлык соединения, выдает настройки чтобы потом можно было суппорту их тупо прочитать

    имхо плохо.

    1. тогда не забудте написать програмку под мак и линукс.

    2. многие пользователи не захотят у себя запускать програмку неизвестного происхождения.

     

    А зачем вы тунели используете если почти везде упр свичи ? Влан (.1q) на пользователя давать не хотите ? =)

  11. А мне вот интерестно если фключить оба фильтра, то в какой фильтр попадёт пакет с начала?

    interface in->bpf->ipnat->ipfilter->ipfw->pkt

    pkt->ipfilter->ipnat->ipfw->bpf->interface out

     

    pf - будет работать на тоже уровне что и ipfilter

     

    у меня была похожая проблема

    вылечилось так:

    net.inet.ipf.fr_icmptimeout=35

    net.inet.ipf.fr_udptimeout=90

    net.inet.ipf.fr_tcphalfclosed=300

    net.inet.ipf.fr_tcpclosed=60

    net.inet.ipf.fr_tcptimeout=240

    net.inet.ipf.fr_tcplastack=120

    net.inet.ipf.fr_tcpclosewait=120

    net.inet.ipf.fr_tcpidletimeout=7200

    net.inet.ipf.fr_defnatage=300

    даже лечить не стали. Через машинки ходил большой трафик. ipnat быстро удалили, поставив natd. Загрузка проца вырасла с 5-10% до 45-50% =))

    ipfilter на FreeBSD - теперь даже ставить боюсь

  12. нормально ли работает ?

    у кого есть опыт ?

    раньше пробовали использовать связку: ipnat(ipfilter)+ipfw

    при большой нагрузке системы стали виснуть (4.10,5.2.1,5.3) на разном железе.

    Использовать только pf - проблематично.

    Всеже интересует subj

  13. Вот только в HP mac-based авторизация...

    Да ну ;-)

    Коммутатор спрашивает у радиуса - можно ли мне работать с этим маком. Радиус отвечает

    Если смотреть шире - учитывая что абонент может сменить мак - то ты прав. В качестве "авторизации" mac-base HP не подходит.

    Вы пробовали тестировать HP port-base 802.1x:

    интересно вот что:

    1. к порту 802.1x port based - поключено 4 юзера (через неупр свич),

    юзер 1 - авторизовался по 802.1x - порт открыт (или таки мак открыт?)

    смогут ли юзеры2-4 ходит через этот порт?

  14. Ага, а потом эти коммутаторы спустятся на access level..

     

    Да! Может и так! =))

    --А не думали ли Вы что:

    l3 - вероятнее всего тоже будет спускаться на уровень доступа. Тем более, если следовать имхо утопичной идеи: 1 юзер - 1 влан,

    последний лучше роутить сразу (чтобы понапрасну не грузить аплинк).

    --На заметку:

    надо понимать что деление уровни - логическое и условное

    --ЗЫ:

    развиваются технологии, дорогое железо становиться дешевым, двигаясь ближе к абоненту

    --

    и PPPoE будет действовать между абонентским компьютером и абонентским портом коммутатора ;-))))

    И наступит всеобщий ПППоЕздец....

    в случае с пппое - такой необходимости нет.

  15. Вообще, думаю что уже в следующем году появятся средние коммутаторы с подсчетом трафика (мне так какжется, почему-то). Что-то типа 4-5к стоить будут.

    И вопрос с ПППоЕ для широкополоски будет решен уже окончательно. ;-)))

     

    А я думаю, что уже в следующем году появятся средние коммутаторы (l3), которые кроме роутинга прекрасно будут терминировать 200-500 PPPoE на каждом порту (аля Рапир от АТ - только мощнее и обкатаннее) с учетом трафика

    И вопрос с ПППоЕ для широкополоски будет решен уже окончательно. ;-)))