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

DemYaN

Активный участник
 Просмотреть профиль  Активность

  • Публикации

    228

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

  • Посещение

 Тип публикации 

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

  2. Опубликовано · Жалоба на ответ

    Во, прелесть какая, видимо оно. Спасибо.

    Да, имел ввиду аналог из iproute2 - "ip route add default via 1.2.3.4 table 1234"

    Ведь это только для статики, но вам ведь нужно динамику в отдельную таблицу?

    Если не нужно маршруты складывать в 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. Опубликовано · Жалоба на ответ

    Я имел в виду, что не получится конструкция с fwd и дальнейшим redirect_port.

    Сейчас курю маны на предмет ng_nat и proxyrule.

     

    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

  7. Опубликовано · Жалоба на ответ

    Protected VLANs are all other VLANs that are members of the STPD. These VLANs “piggyback” on the

    carrier VLAN. Protected VLANs do not transmit or receive STP BPDUs, but they are affected by STP

    state changes and inherit the state of the carrier VLAN. Protected VLANs can participate in multiple

    STPDs, but any particular port in the VLAN can belong to only oneSTPD. Also known as non-carrier

    VLANs.

    Концепт-гид, раздел 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. Опубликовано · Жалоба на ответ

    Суслика таже не видно... - Но он есть...

    вот-вот, поэтому таки мрак...

     

    P.s. а на вопрос касающийся количества протектнутых вланов похоже никто не ответит.

    а саппорт внятно ответить не могет?

  11. Опубликовано · Изменено пользователем DemYaN · Жалоба на ответ

    Eсли extreme не является корнем, а перед ним, например, стоит длинк и льет в два порта одно и тоже, и у вас разрисован штатный rstp, то extreme будет discard на alternate/backup порту пакеты только тех вланов, которые перечислены в participate vlans в описании действующего dot1d/dot1w домена. Таким образом, если вы с длинка в оба порта вольете влан, который на экстриме не учавствует в действующем stpd, а на экстриме этот влан естественно добавлен на оба порта - длинку нахер свернет мозги :D Потому как на экстриме в данном влане образуется неразорванное кольцо. Увы и ах - это нюанс работы stpd на extreme. Зарубежный саппорт экстрима (который кстати традиционно будет слать лесом, или к местному саппорту), настоятельно рекомендует в случае использования dot1d/dot1w включать все вланы в auto-bind/participate действующего stp домена.

    Тобишь для stp/rstp на extreme в шаблон создания влана лучше будет сразу добавить строчку:

    configure stpd s0 add vlan vlan%vlanid% ports %ports% dot1d

     

    Если все еще не верите - собираете простейший стенд - экстрим + длинк (conf stp prio 8192 inst 0) и соединяете двумя патчкордами.

    Теперь понятно. По началу ввело в заблуждение "дискардит не порт, а по вланно" - я это понял как работу stp независимо в каждом vlan'е.

    А так ... мрак, в доках этому уделено надлежащего внимания.

  12. Опубликовано · Жалоба на ответ

    Это не верно. - Представь, что Экстрим не корень дерева.

    Он дискардит не порт, а по вланно.

    Сответственно протектить вланы приходится.

    На основании чего он будет дискардить по вланно? Если 802.1d, то bpdu исходит без тега (или с нулем) из порта, в навешенные vlan'ы bpdu не рассылаются.

  13. Опубликовано · Жалоба на ответ

    Ну как то так:

    
create stpd kinobyl
configure stpd kinobyl mode dot1w
configure stpd kinobyl hellotime 1
configure stpd kinobyl priority 0
configure stpd kinobyl default-encapsulation dot1d
configure stpd kinobyl add vlan stp-kinobyl ports 15 dot1d
configure stpd kinobyl add vlan mgmt-kino ports 15 dot1d
--- skip ---
configure stpd kinobyl ports mode dot1d 15
configure stpd kinobyl ports cost 200000 15
configure stpd kinobyl ports port-priority 128 15
configure stpd kinobyl ports link-type point-to-point 15
configure stpd kinobyl ports edge-safeguard disable 15
enable stpd kinobyl ports 15
configure stpd kinobyl tag 503
enable stpd kinobyl

    ИМХО, в случае RSTP с инкапсуляцией dot1d нет смысла загонять все vlan'ы в protected.

    Нативному RSTP без инкапсуляции в dot1q фиолетово - один untagged vlan на порту или сверху еще пару тысяч tagged, в bdpu это никак не отразить.

  14. Опубликовано · Жалоба на ответ

    Подскажите пожалуйста для

    Advanced Edge License, хватит для полноценной поддержки ospf и pim-sm

    или верно то что написано в документации:

    OSPFv2-Edge (limited to max of 4 active interfaces)

    PIM-SM-Edge (limited to max of 2 active interfaces),

    а pim-dm вообще токо в core lic присутствует.

    По ospf все верно + приоритет у него будет зафиксирован в 0, т.е. не быть ему DR/BDR

  16. Опубликовано · Изменено пользователем DemYaN · Жалоба на ответ

    Подскажите комбо-порты для работы в режиме 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
....

  17. Опубликовано · Жалоба на ответ

    На .38 ведре помогает стабилизировать работу параметр slub_nomerge=1 в загрузку.

    У меня все также - 2.6.38.6, x86_64, бондинг и интеловые сетевухи. Правда не igb, а e1000.

    в 2.6.38 еще был баг(32772) с глубиной стека в net/ipv4/inetpeer.c, фикс-патч попал в 2.6.39 и проблема была устранена

  18. Опубликовано · Жалоба на ответ

    п.п.с. Также, хочется узнать, ПОЧЕМУ НЕ РАБОТАЕТ вышеприведенный пример про два match, хотя в статье пишут, что все ок ??
    Ап.

    Неужели нет цискарей на форуме или 3750 отстойная железка ?

    Да и в инете именно на ту ссылку часто ссылаются.

    п.с. с врфом разобрался.

    Часть вланов в один vrf, часть в другой. Соотвествнно в vrf1 default на первый шейпер, в vrf2 на второй шейпер + роутликинг между vrf'ами ?

  20. Опубликовано · Жалоба на ответ

    как говорит наш архитектор - IPv6 на коммутаторах доступа это самое меньшее зло с которым столкнетесь при переводе всей сети :)

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

    пока мы придерживаемся принципа "каждому по потребности" и белые адреса абонентам предлагаются опционально, по дефолту серые с NAT.

    что будет дальше, например 8 июня 2011 года понаблюдаем, самому интересно.

    Если оборудование доступа ставить с нуля, то нужно уже сейчас понимать что через год v6 это реальность и никуда от этого не деться. А если сейчас в качестве конечных железок выбрать те же es3528m/sps224 и окажется, что у они аппаратно не смогут DHCPv6 snooping, SAVI.... будет очень весело менять все оборудование доступа.

  21. Опубликовано · Жалоба на ответ

    ....

    Доступ - управляемые коммутаторы средней ценовой категории с операторским функционалом (Opt82, PrivateVLAN, DHCP Snooping, IP Source guard), например edge-core es3528m, linksys sps224

    ....

    А IPv6 ? Будут ли эти модели обеспечивать DHCPv6 snooping, IPv6 ACL, SAVI на замену IPSF/DAI?

  22. Опубликовано · Жалоба на ответ

    в сеть будут выдаваться серые адреса.

     

    Вопрос - как в таком случае выдать белые?

    Через Static NAT 1:1 на Интернет-шлюзе.

    Для тех, кому нужен прямой публичный IP - отдельный VLAN.

    Иных вариантов нет? - Static NAT 1:1 уж больно не хочется.

    ИМХО в схеме vlan-на-дом для pubIP только отдельный vlan или группа vlan'ов (на каждый узел агрегации) с терминацией в ядре с автоматическим гемором в виде проброса vlan'а к нужному порту доступа. Static NAT 1:1 большинство абонов не поймет, в особенности если услуга платная.

     

  23. Опубликовано · Жалоба на ответ

    Я, например, выделил на управление отдельный диапазон серых адресов, подальше от действующих.

    Все свитчи находятся в managment vlan`e который не участвует в маршрутизации. Соответственно каждому свитчу на управляющий влан вешается айпишник. Собсно все. Причем вне зависимиости где они стоят: в ядре, на агрегации или еще где...

    справедливо для относительно небольшого количества устройств

    Городская сеть, чуть больше 400 управляемых свитчей.

    например, был опыт с ES3526XA - вешался от arp-запросов в вилане управления...

    опять же при многопоточном discovery устройств, некоторым может стать плохо...

    да и вообще, лучше сегментировать по максимуму (в разумных пределах) - если в один участкок по ошибке попадет флуд от абонента будет не так страшно, а если во всю сеть управления...

  24. Опубликовано · Жалоба на ответ

    Я, например, выделил на управление отдельный диапазон серых адресов, подальше от действующих.

    Все свитчи находятся в managment vlan`e который не участвует в маршрутизации. Соответственно каждому свитчу на управляющий влан вешается айпишник. Собсно все. Причем вне зависимиости где они стоят: в ядре, на агрегации или еще где...

    справедливо для относительно небольшого количества устройств

  25. Опубликовано · Жалоба на ответ

    А show proc cpu что говорит?
    Не загружен - от 1 до 5%

     

    flow control отключите на гиговом порту 3550, он таки его там поддерживает.

    flowcontrol send off

     

    и на ежгоре тоже.

    А вот это очень похоже на источник проблемы. Отключил на 3550 - пока нормально, жду роста трафика. На еже по умолчанию fc отключен.