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

DemYaN

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

    228
  • Joined

  • Last visited

Everything posted by DemYaN


  1. Думаю, что на этот вопрос будет дан ответ нет :), но все же... Есть ли реализации, что бы при использовании DHCP option 82 в circuit ID suboption вносился не номер порта, а VID. Тобишь к порту подключены через краевой свитч несколько пользователей, но каждый в уникальном вилане и в зависимости от номера вилана dhcp выдавал бы уникальный ip. Таким образом можно было бы избавиться от необходимость в использовании коммутаторов с поддержкой option 82 на аксесс уровне.
  2. fileCopyMgt ftp://ftp.vimcom.ru/Accton_Edge-Core/Switches/ES3528M-ES3552M/mibs/
  3. Ведь это только для статики, но вам ведь нужно динамику в отдельную таблицу? Если не нужно маршруты складывать в kernel, тогда возможно view'ы помогут?
  4. Народ, подскажите. Имеется пациент в виде Summit x450a-24t, который отказывается загружаться как с локальных образов (boot 1,2 и диагностика 3,4), так и посредством заливки образа используя tftp. В чем может быть проблема и возможно ли ее устранить в принципе, кроме как через TAC. Running POST... PASSED Version 1.0.3.1 Branch trunk by release-manager on Fri 04/20/07 Copyright 2003-2007, Extreme Networks, Inc. Press and hold the <spacebar> to enter the bootrom. Loading EXOS Image ...| Running Image ... Failed to determine exact hardware type for the SummitX platform! This hardware is not supported by this software release. Please see the ExtremeWare XOS Concepts Guide for information on installing a newer software release. See the Release Notes for your hardware to verify the supported ExtremeWare XOS releases.
  5. ng_nat, редирект 80-порта для table(10) на XXX.XXX.XXX.XXX:81 netgraph: mkpeer ipfw: nat 100 out name ipfw:100 nat connect ipfw: nat: 101 in msg nat: setaliasaddr YYY.YYY.YYY.YYY msg nat: setmode {flags=0x60 mask=0xff} msg nat: proxyrule "type no_encode port 80 server XXX.XXX.XXX.XXX:81 proto tcp" ipfw: netgraph tablearg ip from table(10) to any dst-port 80 netgraph 100 ip from XXX.XXX.XXX.XXX to any src-port 81
  6. Еще есть bridge из iproute2: https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=d04bc300c3e367702817fed6eea55e997a328c66
  7. Концепт-гид, раздел STP, глава Protected Ports. Коротко и предельно четко. Да видел я это... но разве это можно называть предельно четким ? : "they are affected by STP state changes and inherit the state of the carrier VLAN" Как минимум в упоминаниях о blocking port нужно было писать blocking protected vlans, потому как для 802.1d такое поведение не является таким уж тривиальным.
  8. вот-вот, поэтому таки мрак... а саппорт внятно ответить не могет?
  9. Да как бы уже перечитал :) Все равно не нахожу где бы было... все очень хорошо расписано
  10. в EXOSConcepts не наблюдаю, ткните
  11. Теперь понятно. По началу ввело в заблуждение "дискардит не порт, а по вланно" - я это понял как работу stp независимо в каждом vlan'е. А так ... мрак, в доках этому уделено надлежащего внимания.
  12. На основании чего он будет дискардить по вланно? Если 802.1d, то bpdu исходит без тега (или с нулем) из порта, в навешенные vlan'ы bpdu не рассылаются.
  13. ИМХО, в случае RSTP с инкапсуляцией dot1d нет смысла загонять все vlan'ы в protected. Нативному RSTP без инкапсуляции в dot1q фиолетово - один untagged vlan на порту или сверху еще пару тысяч tagged, в bdpu это никак не отразить.
  14. По ospf все верно + приоритет у него будет зафиксирован в 0, т.е. не быть ему DR/BDR
  15. Подскажите комбо-порты для работы в режиме 1G принимают SFP-модули любого производителя или же нужна родные алкателя? В g2 установлен 1G SFP, но линк поднимается только в режиме 100М: # sh version SW version 1.7.1.7 ( date 12-May-2010 time 16:32:04 ) # sh interfaces status Flow Link Back Mdix Port Type Duplex Speed Neg ctrl State Pressure Mode -------- ------------ ------ ----- -------- ---- ----------- -------- ------- .... g2 100M-Combo-F Full 100 Disabled Off Up Disabled Off ....
  16. в 2.6.38 еще был баг(32772) с глубиной стека в net/ipv4/inetpeer.c, фикс-патч попал в 2.6.39 и проблема была устранена
  17. Ап.Неужели нет цискарей на форуме или 3750 отстойная железка ? Да и в инете именно на ту ссылку часто ссылаются. п.с. с врфом разобрался. Часть вланов в один vrf, часть в другой. Соотвествнно в vrf1 default на первый шейпер, в vrf2 на второй шейпер + роутликинг между vrf'ами ?
  18. для вашей задачи правильней использовать vrf-lite
  19. Если оборудование доступа ставить с нуля, то нужно уже сейчас понимать что через год v6 это реальность и никуда от этого не деться. А если сейчас в качестве конечных железок выбрать те же es3528m/sps224 и окажется, что у они аппаратно не смогут DHCPv6 snooping, SAVI.... будет очень весело менять все оборудование доступа.
  20. А IPv6 ? Будут ли эти модели обеспечивать DHCPv6 snooping, IPv6 ACL, SAVI на замену IPSF/DAI?
  21. Через Static NAT 1:1 на Интернет-шлюзе.Для тех, кому нужен прямой публичный IP - отдельный VLAN. Иных вариантов нет? - Static NAT 1:1 уж больно не хочется. ИМХО в схеме vlan-на-дом для pubIP только отдельный vlan или группа vlan'ов (на каждый узел агрегации) с терминацией в ядре с автоматическим гемором в виде проброса vlan'а к нужному порту доступа. Static NAT 1:1 большинство абонов не поймет, в особенности если услуга платная.
  22. справедливо для относительно небольшого количества устройств Городская сеть, чуть больше 400 управляемых свитчей. например, был опыт с ES3526XA - вешался от arp-запросов в вилане управления...опять же при многопоточном discovery устройств, некоторым может стать плохо... да и вообще, лучше сегментировать по максимуму (в разумных пределах) - если в один участкок по ошибке попадет флуд от абонента будет не так страшно, а если во всю сеть управления...
  23. Linux, htb, около 4000 htb-классов. С переходом с версии ядра 2.6.28 на 2.6.32.8 время от времени в логи начали вываливаться сообщения: [ 792.604379] htb: too many events! [ 2777.926380] htb: too many events! [18414.947790] htb: too many events! кто-то с таким сталкивался? кусок кода ответственного кода: /** * htb_do_events - make mode changes to classes at the level * * Scans event queue for pending events and applies them. Returns time of * next pending event (0 for no event in pq, q->now for too many events). * Note: Applied are events whose have cl->pq_key <= q->now. */ static psched_time_t htb_do_events(struct htb_sched *q, int level, unsigned long start) { /* don't run for longer than 2 jiffies; 2 is used instead of 1 to simplify things when jiffy is going to be incremented too soon */ unsigned long stop_at = start + 2; while (time_before(jiffies, stop_at)) { struct htb_class *cl; long diff; struct rb_node *p = rb_first(&q->wait_pq[level]); if (!p) return 0; cl = rb_entry(p, struct htb_class, pq_node); if (cl->pq_key > q->now) return cl->pq_key; htb_safe_rb_erase(p, q->wait_pq + level); diff = psched_tdiff_bounded(q->now, cl->t_c, cl->mbuffer); htb_change_class_mode(q, cl, &diff); if (cl->cmode != HTB_CAN_SEND) htb_add_to_wait_tree(q, cl, diff); } /* too much load - let's continue after a break for scheduling */ if (!(q->warned & HTB_WARN_TOOMANYEVENTS)) { printk(KERN_WARNING "htb: too many events!\n"); q->warned |= HTB_WARN_TOOMANYEVENTS; } return q->now; }