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

G.Y.S.

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

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

  • Посещение

Все публикации пользователя G.Y.S.


  1. Проблема решилась в тотже день. Петля. Заметил IP over ethernet поустойчивее будет PPP over ethernet. IP глючил но работал -))
  2. AT- многомодовые - у нас висли (10 штук), от незначительного удара по корпусу(?) или просто достаточно пошевелить медный (хорошо обжатый провод), после этого их уже не покупали. Сейчас работают 10 dlink - уже 2 года - проблем - 0. С Dlink - недостаток - сильно греются (намного сильнее чем планеты FT-806/706) Плюс - у них одна линеейка! и одно шасси, в отличии от планеты с 2-мя разными линейками FT/WFT Подозреваю что планеты WFT и Длинк - также взаимозаменяемы и одинакого сильно греются.
  3. 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) хотелось бы услышать как обстоят дела у свичей других контор-производителей.
  4. упр коммутатор --- неупр коммутатор (в нем петля) как в таком случае реализована защита от такой в управляемом коммутаторе?
  5. имхо в 90х годах почти все приватизировано незаконно :)
  6. MPD - вдруг перестал работать принимать соединения от клиентов в одном из VLAN-в (ранее работал пол-года без проблем) На клиенте возникает ошибка - удаленный компьютер не отвечает. НА сервере - PPPoE connection timeout after 9 seconds. Другие клиенты в др-х vlan-ы работают с темже сервером без проблем. Физически связь клиент-сервер - ок (пинги ходят (по ip при выкл mpd). Железо полностью менялось.
  7. на счет роутинга - не понимаю что не понятного ;-) ADSL модем - 1 PPPOE ADSL модем - 2-ой PPPOE а от модемов то куда ?
  8. 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
  9. Уже не раз замечаю странный глюк, который не могу побороть. На ПК 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 Проблемма однозначно в системе, т.к. стоящий рабом ноутбук - с теми же настройками работатет...
  10. 2ThinkMaster - а какой железкой вы прицепляться к провайдеру будете ? + будет ли он вам роутить доп. ip адреса в ваш туннель ?
  11. up (или народ их не юзал - или знает но молчит)
  12. есть ли тунели? машинка что с трафиком делает? загрузка cpu не нормальная. У меня 30 мегибит пень 1 пропускает не напрягаясь. см man polling
  13. Привет jab. Я тоже так думал. Но когда вижу 35% - на ненагруженном пк-роуторе + idle = 50%, наводит на размышления... А у тебя какая загрузка? Я сделал вывод, что mpd жрет ресурсы в зависимости от количества созданных ng. А не от кол-ва подключенных ПК и/или проходящего трафика. Что немного странно.
  14. настройка стрима тут не обсуждается по "моральным" соображениям =)
  15. 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%. Кто сталкивался ? Как побороть ?
  16. ОК У нас 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.
  17. ФСБ навязывают свой СОРМ

    Сообщите пожалуйста о результатах.
  18. стр.1 имхо плохо. 1. тогда не забудте написать програмку под мак и линукс. 2. многие пользователи не захотят у себя запускать програмку неизвестного происхождения. А зачем вы тунели используете если почти везде упр свичи ? Влан (.1q) на пользователя давать не хотите ? =)
  19. interface in->bpf->ipnat->ipfilter->ipfw->pkt pkt->ipfilter->ipnat->ipfw->bpf->interface out pf - будет работать на тоже уровне что и ipfilter даже лечить не стали. Через машинки ходил большой трафик. ipnat быстро удалили, поставив natd. Загрузка проца вырасла с 5-10% до 45-50% =)) ipfilter на FreeBSD - теперь даже ставить боюсь
  20. нормально ли работает ? у кого есть опыт ? раньше пробовали использовать связку: ipnat(ipfilter)+ipfw при большой нагрузке системы стали виснуть (4.10,5.2.1,5.3) на разном железе. Использовать только pf - проблематично. Всеже интересует subj
  21. Да ну ;-) Коммутатор спрашивает у радиуса - можно ли мне работать с этим маком. Радиус отвечает Если смотреть шире - учитывая что абонент может сменить мак - то ты прав. В качестве "авторизации" mac-base HP не подходит. Вы пробовали тестировать HP port-base 802.1x: интересно вот что: 1. к порту 802.1x port based - поключено 4 юзера (через неупр свич), юзер 1 - авторизовался по 802.1x - порт открыт (или таки мак открыт?) смогут ли юзеры2-4 ходит через этот порт?
  22. Да! Может и так! =)) --А не думали ли Вы что: l3 - вероятнее всего тоже будет спускаться на уровень доступа. Тем более, если следовать имхо утопичной идеи: 1 юзер - 1 влан, последний лучше роутить сразу (чтобы понапрасну не грузить аплинк). --На заметку: надо понимать что деление уровни - логическое и условное --ЗЫ: развиваются технологии, дорогое железо становиться дешевым, двигаясь ближе к абоненту -- в случае с пппое - такой необходимости нет.
  23. А я думаю, что уже в следующем году появятся средние коммутаторы (l3), которые кроме роутинга прекрасно будут терминировать 200-500 PPPoE на каждом порту (аля Рапир от АТ - только мощнее и обкатаннее) с учетом трафика И вопрос с ПППоЕ для широкополоски будет решен уже окончательно. ;-)))