G.Y.S.
-
Публикации
141 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем G.Y.S.
-
-
AT- многомодовые - у нас висли (10 штук), от незначительного удара по корпусу(?) или просто достаточно пошевелить медный (хорошо обжатый провод), после этого их уже не покупали.
Сейчас работают 10 dlink - уже 2 года - проблем - 0.
С Dlink - недостаток - сильно греются (намного сильнее чем планеты FT-806/706)
Плюс - у них одна линеейка! и одно шасси, в отличии от планеты с 2-мя разными линейками FT/WFT
Подозреваю что планеты WFT и Длинк - также взаимозаменяемы и одинакого сильно греются.
-
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) хотелось бы услышать как обстоят дела у свичей других контор-производителей.
-
упр коммутатор --- неупр коммутатор (в нем петля)
как в таком случае реализована защита от такой в управляемом коммутаторе?
-
имхо в 90х годах почти все приватизировано незаконно :)
-
MPD - вдруг перестал работать принимать соединения от клиентов в одном из VLAN-в (ранее работал пол-года без проблем)
На клиенте возникает ошибка - удаленный компьютер не отвечает.
НА сервере - PPPoE connection timeout after 9 seconds.
Другие клиенты в др-х vlan-ы работают с темже сервером без проблем.
Физически связь клиент-сервер - ок (пинги ходят (по ip при выкл mpd).
Железо полностью менялось.
-
up
- неужели никто не сталкивался ?
-
Подключаться будем через ADSL модем в режиме бриджа.
насчёт роутинга не понял ...
на счет роутинга - не понимаю что не понятного ;-)
ADSL модем - 1 PPPOE
ADSL модем - 2-ой PPPOE
а от модемов то куда ?
-
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
-
WINS Отключен, ДНС прописаны (есс-но)
-
Уже не раз замечаю странный глюк, который не могу побороть.
На ПК 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
Проблемма однозначно в системе, т.к. стоящий рабом ноутбук - с теми же настройками работатет...
-
2ThinkMaster - а какой железкой вы прицепляться к провайдеру будете ? + будет ли он вам роутить доп. ip адреса в ваш туннель ?
-
up
(или народ их не юзал - или знает но молчит)
-
есть ли тунели? машинка что с трафиком делает?
загрузка cpu не нормальная. У меня 30 мегибит пень 1 пропускает не напрягаясь.
см man polling
-
Привет jab. Я тоже так думал.
Но когда вижу 35% - на ненагруженном пк-роуторе + idle = 50%,
наводит на размышления... А у тебя какая загрузка?
Я сделал вывод, что mpd жрет ресурсы в зависимости от количества созданных ng.
А не от кол-ва подключенных ПК и/или проходящего трафика. Что немного странно.
-
настройка стрима тут не обсуждается по "моральным" соображениям =)
-
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%.
Кто сталкивался ? Как побороть ?
-
ОК
У нас 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.
-
Сообщите пожалуйста о результатах.
-
А можно узнать по какой?
стр.1
Пишется сейчас программа под винду - панель доступа ко всем сервисам, устанавливает маршруты, создает ярлык соединения, выдает настройки чтобы потом можно было суппорту их тупо прочитатьимхо плохо.
1. тогда не забудте написать програмку под мак и линукс.
2. многие пользователи не захотят у себя запускать програмку неизвестного происхождения.
А зачем вы тунели используете если почти везде упр свичи ? Влан (.1q) на пользователя давать не хотите ? =)
-
А мне вот интерестно если фключить оба фильтра, то в какой фильтр попадёт пакет с начала?
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 - теперь даже ставить боюсь
-
нормально ли работает ?
у кого есть опыт ?
раньше пробовали использовать связку: ipnat(ipfilter)+ipfw
при большой нагрузке системы стали виснуть (4.10,5.2.1,5.3) на разном железе.
Использовать только pf - проблематично.
Всеже интересует subj
-
Вот только в HP mac-based авторизация...
Да ну ;-)
Коммутатор спрашивает у радиуса - можно ли мне работать с этим маком. Радиус отвечает
Если смотреть шире - учитывая что абонент может сменить мак - то ты прав. В качестве "авторизации" mac-base HP не подходит.
Вы пробовали тестировать HP port-base 802.1x:
интересно вот что:
1. к порту 802.1x port based - поключено 4 юзера (через неупр свич),
юзер 1 - авторизовался по 802.1x - порт открыт (или таки мак открыт?)
смогут ли юзеры2-4 ходит через этот порт?
-
Ага, а потом эти коммутаторы спустятся на access level..
Да! Может и так! =))
--А не думали ли Вы что:
l3 - вероятнее всего тоже будет спускаться на уровень доступа. Тем более, если следовать имхо утопичной идеи: 1 юзер - 1 влан,
последний лучше роутить сразу (чтобы понапрасну не грузить аплинк).
--На заметку:
надо понимать что деление уровни - логическое и условное
--ЗЫ:
развиваются технологии, дорогое железо становиться дешевым, двигаясь ближе к абоненту
--
и PPPoE будет действовать между абонентским компьютером и абонентским портом коммутатора ;-))))И наступит всеобщий ПППоЕздец....
в случае с пппое - такой необходимости нет.
-
Вообще, думаю что уже в следующем году появятся средние коммутаторы с подсчетом трафика (мне так какжется, почему-то). Что-то типа 4-5к стоить будут.
И вопрос с ПППоЕ для широкополоски будет решен уже окончательно. ;-)))
А я думаю, что уже в следующем году появятся средние коммутаторы (l3), которые кроме роутинга прекрасно будут терминировать 200-500 PPPoE на каждом порту (аля Рапир от АТ - только мощнее и обкатаннее) с учетом трафика
И вопрос с ПППоЕ для широкополоски будет решен уже окончательно. ;-)))
не работает MPD (PPPoE connection timeout after 9 seconds)
в Программное обеспечение, биллинг и *unix системы
Опубликовано · Жалоба на ответ
Проблема решилась в тотже день. Петля.
Заметил IP over ethernet поустойчивее будет PPP over ethernet.
IP глючил но работал -))