Jump to content
Калькуляторы

G.Y.S.

Активный участник
  • Content Count

    141
  • Joined

  • Last visited

Everything posted by G.Y.S.


  1. на свиче конфигурим два порта: 9 и 17 ( к примеру) они принадлежат к VLAN5 (как untaged) и vlan14 (taged) на VLAN5 повешен ip 10.13.13.1/24 к 9 порту подлючена машинка(1), на ней заведен субинтерфейс с VLAN14 и на нем 10.13.13.2/24 (умешленно!) пинга машинка(1) --- 10.13.13.1 есс-но нет, но! свич в arp на vlan5! добавил запись 10.13.13.2 -- мак машинки(1) ? #снифером видно что машинка(1) посылает arp запросы только в vlan14 если на свиче сделать clear arp, подлючить к порту 17 машинку(2) и на ней задать 10.13.13.2/24, то пинг машинка(2) --- 10.13.13.1 есс-но есть, при этом свич в arp на vlan5 добавит запись 10.13.13.2 -- мак машинки(2) начинаем пинговать с машинки(1) - 10.13.13.1 (свич) пинга не есс-но нет, но! свич в arp на vlan5! изменил запись 10.13.13.2 -- мак машинки(1!!) подскажите где грабли...
  2. Проблема решилась в тотже день. Петля. Заметил IP over ethernet поустойчивее будет PPP over ethernet. IP глючил но работал -))
  3. MPD - вдруг перестал работать принимать соединения от клиентов в одном из VLAN-в (ранее работал пол-года без проблем) На клиенте возникает ошибка - удаленный компьютер не отвечает. НА сервере - PPPoE connection timeout after 9 seconds. Другие клиенты в др-х vlan-ы работают с темже сервером без проблем. Физически связь клиент-сервер - ок (пинги ходят (по ip при выкл mpd). Железо полностью менялось.
  4. упр коммутатор --- неупр коммутатор (в нем петля) как в таком случае реализована защита от такой в управляемом коммутаторе?
  5. AT- многомодовые - у нас висли (10 штук), от незначительного удара по корпусу(?) или просто достаточно пошевелить медный (хорошо обжатый провод), после этого их уже не покупали. Сейчас работают 10 dlink - уже 2 года - проблем - 0. С Dlink - недостаток - сильно греются (намного сильнее чем планеты FT-806/706) Плюс - у них одна линеейка! и одно шасси, в отличии от планеты с 2-мя разными линейками FT/WFT Подозреваю что планеты WFT и Длинк - также взаимозаменяемы и одинакого сильно греются.
  6. 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) хотелось бы услышать как обстоят дела у свичей других контор-производителей.
  7. имхо в 90х годах почти все приватизировано незаконно :)
  8. Уже не раз замечаю странный глюк, который не могу побороть. На ПК 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 Проблемма однозначно в системе, т.к. стоящий рабом ноутбук - с теми же настройками работатет...
  9. на счет роутинга - не понимаю что не понятного ;-) ADSL модем - 1 PPPOE ADSL модем - 2-ой PPPOE а от модемов то куда ?
  10. 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
  11. 2ThinkMaster - а какой железкой вы прицепляться к провайдеру будете ? + будет ли он вам роутить доп. ip адреса в ваш туннель ?
  12. up (или народ их не юзал - или знает но молчит)
  13. есть ли тунели? машинка что с трафиком делает? загрузка cpu не нормальная. У меня 30 мегибит пень 1 пропускает не напрягаясь. см man polling
  14. Привет jab. Я тоже так думал. Но когда вижу 35% - на ненагруженном пк-роуторе + idle = 50%, наводит на размышления... А у тебя какая загрузка? Я сделал вывод, что mpd жрет ресурсы в зависимости от количества созданных ng. А не от кол-ва подключенных ПК и/или проходящего трафика. Что немного странно.
  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. настройка стрима тут не обсуждается по "моральным" соображениям =)
  17. ОК У нас 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.
  18. Сообщите пожалуйста о результатах.
  19. #----Краткое лирической отступление---- Использовать ли PPPoE ? + 1) нет проблемм присущих "ip протоколу" в сети Ethernet: конфликты и подмена ip адресов. Необходимость их контроля. 2) прекрасная система авторизации. Нет необходимости контролировать абонентсикий порт, привязываться к макам и проч... что экономит время, также уменьшает число звонков в саппорт. 3) можно контролировать не только доступ в Интрнет но и доступ к другим vlan-м (подсети, сервисы, пиринговые сети) -: 1) оч. большой трафик через ядро сети. 2) стоимость машинок, которые терминируют pppoe 3)...не получается задействованы ресурсы L3 коммутации (l3 свичи) - а "мир" развивается в этом направлении #----Итак схема----- в core стоит гигабитный коммутатор (l2!), к нему подключены: 1. гигабитные линии на мирорайоны (к примеру штук 5-7) 2. 3-4 pppoe сервера, присоединены к коммутатору транковыми (taged) линкам - транком:2xгигабит etherchannel (простите за каламбул=) Эти 3-4 машинки делют между собой лоад-банансинг +роутят между юзеров между vlan-ми. На одной их них поднят DHCP, который раздает ip абонентам в VLAN-ы. Это нам нужно для того, чтобы абоненты внутри влана, могли гонять трафик между собой (а не через core, немного разгружая его) Машинки с PPPoE мошут быть как PC-роутеры, так и аппаратные (cisco 3845) 3. центральный маршрутизатор (можно ether-channelx2GB)(между ним и pppoe серверами поднят ospf). 4. vlan серверов телематики (барахло больших объемов+web и проч) 5. бордерный роутер в интернет ----# дополнение при разрастании vlan-а (микрорайона) более чем 500-1000 компов для того чтобы уменьшить кол-во броудкаста в нем --- машинка с пппое двигается в этот "большой влан", далее он делиться на 2-3 маленьких влана, которые роутятся этой машинкой. Роутить полученные 2-3 маленьких влана в core -- нельзя, - жадко полосы - гигабтного аплинка на этот микрорайон Нужна конструктивная критика.. =)
  20. стр.1 имхо плохо. 1. тогда не забудте написать програмку под мак и линукс. 2. многие пользователи не захотят у себя запускать програмку неизвестного происхождения. А зачем вы тунели используете если почти везде упр свичи ? Влан (.1q) на пользователя давать не хотите ? =)
  21. interface in->bpf->ipnat->ipfilter->ipfw->pkt pkt->ipfilter->ipnat->ipfw->bpf->interface out pf - будет работать на тоже уровне что и ipfilter даже лечить не стали. Через машинки ходил большой трафик. ipnat быстро удалили, поставив natd. Загрузка проца вырасла с 5-10% до 45-50% =)) ipfilter на FreeBSD - теперь даже ставить боюсь
  22. Да ну ;-) Коммутатор спрашивает у радиуса - можно ли мне работать с этим маком. Радиус отвечает Если смотреть шире - учитывая что абонент может сменить мак - то ты прав. В качестве "авторизации" mac-base HP не подходит. Вы пробовали тестировать HP port-base 802.1x: интересно вот что: 1. к порту 802.1x port based - поключено 4 юзера (через неупр свич), юзер 1 - авторизовался по 802.1x - порт открыт (или таки мак открыт?) смогут ли юзеры2-4 ходит через этот порт?
  23. Да! Может и так! =)) --А не думали ли Вы что: l3 - вероятнее всего тоже будет спускаться на уровень доступа. Тем более, если следовать имхо утопичной идеи: 1 юзер - 1 влан, последний лучше роутить сразу (чтобы понапрасну не грузить аплинк). --На заметку: надо понимать что деление уровни - логическое и условное --ЗЫ: развиваются технологии, дорогое железо становиться дешевым, двигаясь ближе к абоненту -- в случае с пппое - такой необходимости нет.