Вебинар на тему: Основы STP

Ребята всем привет.

Как и обещал, я сегодня публикую информацию по пройденному вебинару по теме: «Основы STP».

Прежде всего хотелось сказать всем спасибо за интерес, проявленный к вебинару. А также извиниться за все накладки во время трансляции. Это был мой первый опыт проведения такого рода мероприятия. Поэтому мне хотелось бы, чтобы вы высказали свои мысли в опросе по ссылке. Прошу не стесняясь крыть матом   правдой маткой. Буду благодарен любой критике в свой адрес. Мне важно ваше мнение. Спасибо заранее.

Как и было обещано, публикую ссылку на видео youtube. Видео обработанное.

А здесь приведена ссылка на скачивание режиссерской версии.

Ниже ссылка на слайд

Из-за неопытности работы с платформой я пропустил многие вопросы, который были заданы во время вебинара. Поэтому наиболее интересные привожу ниже. Кроме того, вы можете также задать в комментариях интересующие вас вопросы. Вы можете присоединиться к обсуждению этих вопросов. Если они вызовут у вас затруднения, наши эксперты подключаться к их решению.

Вопросы в QA по вебинару:

  1. Что будет если между коммутаторами с STP есть несколько коммутаторов без STP?
  2. Что произойдет, если там есть кольцо?
  3. Могут ли в одной сети (VLAN) сосуществовать STP и RSTP?
  4. RSTP будет или будем гонять в 1000 раз чистый STP?
  5. Если у root switch отвалился один из линков, он сразу отправит TCN с указанием уменьшить таймер или будет ждать TCN от нижестоящих коммутаторов?
  6. При каких изменениях топологии поменяется Root Bridge? И куда тогда будут отправляться TCN?
  7. В течение какого времени коммутатор сохраняет forwarding delay =15 для aging time?
  8. Кстати по костам. Один вопрос давно мучает: есть ли какая-нибудь разница для коммутатора между прямым каналом к корневому свичу по линку в 1Gbps (cost 4) и каналом через промежуточный коммутатор с двумя линками по 10Gbps (cost 2+2 =4). Цена пути равная. Разница только в том, что в первом варианте будет MAC-адрес рута и десигнейтед один и тот же, а во втором случае разные. Как коммутатор выбирает маршрут в таком случае, чем руководствуется?
  9. Эмиль, расскажите о диаметре сети, рекомендуемое значение для которого 7, и расскажите что будет при стандартных таймерах, если диаметр более 20 устройств.
  10. Опишите ситуацию когда до крайних устройств не будет доходить Hello за MAX AGE.
  11. Было сказано что используется какой-то Cisco MAC адрес для TCN,TCA. Значит ли это что сторонние устройства не поймут такое сообщение?
  12. Можно ли уменьшить Aging timer при TC не изменяя Forwarding Delay? Чтобы ускорить очистку CAM таблицы, например сделать 1 сек.

Кроме всего прочего, вас ждет большая лабораторная работа от Наташи Самойленко. От вас мы ожидаем активного участия и ее своевременной сдачи.

 

 

Комментарии (33)
  1. Спасибо за вебинар!
    Вопрос 8: Сравнение идет по следующим параметрам:
    1)Root Bridge ID
    2)Root Path Cost
    3)Sender Bridge ID
    4)Sener Port ID
    Значит после проверки RPC коммутатор проверит чей sender Bridge ID лучше, если одинаковые то перейдет к проверке по PortID

    1. В данном конкретном случае, пункт 1 не будет выполнятся, т.к. Root Brigde уже выбран, а до пункта 4 не дойдет, т.к BID рута приоритетнее чем BID промежуточного свитча, на то он и рут :) . А еще пункт 1 выполняется только при выборах Root Bridge, остальные 3, при выборах рут и дезигнейтид портов.

  2. Хочу заострить внимание на популярном заблужении:
    Если все параметры до этого (RBID, RPC, SBID) равны, то выбор лучшего BPDU определяется по port id соседа (а не по нашему собственному port id), и только лишь в случае, если они одинаковые, то мы смотрим на собственный port id

    1. Это легко запомнить, потому что мы можем приоритетом своего порта манипулировать блокировкой порта с другой стороны (в случае, когда между коммутаторами 2 линка друг в друга). Ещё, многие путают на кого влияет cost, а на кого port-id — я запомнил по поведению stp — стоимость прибавляется на входящем интерфейсе, а значит cost влияет на тот же коммутатор, на котором и изменяется.

    2. Да, есть такое дело про PortID. Я перестал сомневаться, «свой» или «чужой» PortID используем, когда осознал, что коммутатор смотрит пришедший Configuration BPDU, и именно из BPDU берёт все значения, по которым выбирает root port и root path cost. А в пришедшем BPDU-то написать PortID соседа!

  3. Если правильно помню, то в ходе вебинара так и не был дан ответ на вопрос- что происходит с BPDU на blocked ports? BPDU сохраняются или отбрасываются? Правильно ли ответил Север, сказав, что BPDU сразу же отбрасываются, если не включена функция UplinkFast?

    1. Нет, это неверно.
      Switches store the most recent STP BPDUs (Bridge Protocol Data Units) with every port that receives them, even blocked ports. Only the best information is relayed downstream.
      Aging out old information.
      Every configuration BPDU contains two fields: Max_Age and Message_Age. The Message_Age field is incremented every time a BPDU traverses a bridge. When a bridge stores the BPDU with the respective port, it will count the time in seconds, starting from Message_Age up to the Max_Age. If during this interval, no further BPDUs are received, the current BPDU information is expired and the port is declared designated. This procedure ensures that the old root information is eventually aged out of the topology.
      Blocked порт хранит BPDU, и если BPDU не придет в течении, грубо говоря Max_Age, он станет дезигнейтид и перейдет в состояние форвардинг, что может создать L2 петлю, например при появлении однонаправленного линка.

  4. На вебинаре я задавал вопрос по STP, который меня мучает, не могу сам придумать ответ на него.

    В книге Radia Perlman «Interconnections: Bridges, Routers, Switches, and Internetworking Protocols (2nd Edition)» (http://www.amazon.com/Interconnections-Bridges-Switches-Internetworking-Protocols/dp/0201634481) в главе про STP есть такой вопрос в Homework:
    Recently there was a proposal for a modification to the spanning tree algorithm to get rid of preforwarding delay in certain cases. The modification is that if the spanning
    tree algorithm tells you that link L should now be your in-link (path to the root), you are allowed to immediately start forwarding on L provided that you immediately stop
    forwarding on your previous in-link. The claim is that this modification will not introduce loops.
    b. Show that this proposal would introduce loops if the Designated Bridge adds the cost of the link into its Hello message—that is, the cost advertised is the
    cost to the LAN rather than the cost to the bridge. In other words, if B thinks it is 5 from the Root R and that link L has cost 2, B will advertise (R, 7, B, …) in
    its Hello. (Isn’t it amazing that such a seemingly arbitrary choice of who adds in the link cost could make a difference here?)

    Кратко по-русски:
    Есть предложение, что если у нас падает root port, мы мгновенной поднимаем «запасной» root port и при этом выключаем старый root port. Покажите, что если при этом cost в root path cost будет прибавляться не на root port при получении BPDU, а на designated port при отправке BPDU, то могут быть петли.

    Мне кажется, надо придумать такую топологию и такую ситуацию «поднятия/выключения» линков/коммутаторов, что при указанных допущениях возникла бы петля. Не знаю, как подступиться к этой задаче. Попробовал мысленно посоединять 3-4 коммутатора между собой и моделировать ситуации, но пока не получилось.
    Может быть, эксперты придумают пример с петлёй?

    По-моему, это интересный вопрос, стимулирующий подумать, как работает STP.:)

  5. 7.В течение какого времени коммутатор сохраняет forwarding delay =15 для aging time?
    Ответ на вопрос 7:
    Коммутатор получает уведомление о необходимости уменьшить aging time до продолжительности forward_delay = 15 seconds by default на период времени равный max_age + forward_delay.

    1. Абсолютно верно, грубо говоря, в течении 20+15=35 сек (значения дефолтные) рут рассылает cofiguration BPDU с установленным TC флагом, что заставляет все свитчи изменить aging-time в CAM (дефолтное 300сек ) на 15 сек, т.е. в течении 35 сек MAC адреса будут устаревать быстрее в 20 раз, что вызовет больший поток unicaslt flooding и нагрузку на сеть.

        1. Topology Changes have serious impact on traffic forwarding. Fast aging of MAC address tables results in extensive unicast flooding and may cause intermittent traffic storms in bridged segments. It is possible to reduce amount of TC events by marking all edge (non-transit) connections as STP “PortFast”. Such connections do not generate TC event when they go up or down, which significantly reduces amount of unicast flooding as a result of fast aging of MAC
          address tables. You should plan to use this feature as much as possible with any Layer 2 domain. Additional features are available on high-end Cisco bridges, such as 6500, to limit aggregate rate of unicast flooding or improve MAC-address table refresh. However, the problem is inherent to Ethernet and cannot be completely resolved without changing the protocol itself. You may read more about STP topology changes in the following document:
          http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094797.shtml

          1. В большинстве случаев это не будет _большой_ проблемой, потому что при STP TC маки в CAM не стираются. Это будет являться проблемой для heavy unidirectional flows (как в примере), которых на сегодняшний день не так много. И мой коммент был к тому, что в RSTP TC имеют бОльший негативный эффект, чем в STP из-за того, что CAM таблица полностью очищается. Это значит, что в RSTP настройка edge портов ещё более важна, чем в STP.

            1. Дмитрий, я согласен, что на сегодняшний день это уже не так актуально, но протокол реализовывали не вчера и видимо в те времена, сети и приложения были другие, что возможно при TC приводило к тем проблемам, которые описаны выше. Тот же костыль в виде Portfast был придуман не просто так. Про RSTP я в курсе и спасибо за комментарий.

  6. 11. Было сказано что используется какой-то Cisco MAC адрес для TCN,TCA. Значит ли это что сторонние устройства не поймут такое сообщение?
    В Cisco PVST+, для рассылки BPDU, используется 2 MAC адреса: IEEE мультикаст MAC адрес назначения 0180.c200.0000 (CST -Common Spanning-Tree) и PVST+ MAC адрес 0100.0ccc.cccd (SSTP-Shared Spanning Tree Protocol BPDUs).
    Если порт находится в режиме access, то:
    Коммутатор посылает STP BPDU на IEEE MAC адрес (0180.c200.0000), пакет без тега.
    Коммутатор посылает STP BPDU на PVST+ MAC адрес (0100.0ccc.cccd), пакет без тега.
    Если порт находится в режиме транк, то:
    Коммутатор, в native VLAN , посылает STP BPDU на IEEE MAC адрес (0180.c200.0000), пакет без тега.
    Коммутатор, в native VLAN, посылает STP BPDU на PVST+ MAC адрес (0100.0ccc.cccd), пакет без тега.
    Коммутатор, в каждом тэгированом VLAN, посылает STP BPDU на PVST+ MAC адрес (0100.0ccc.cccd), пакет c тегом и с полем TLV.
    В STP есть 2 типа BPDU: Configuration и TCN. Configuration генерирует только Root Bridge, а TCN только non-root Bridge, когда у него происходит изменение состояния FWD портов, или Blocked порт переходит в FWD. TCN BPDU не содержит в себе никакой доп информации, только тип протокола и тип BPDU, и генерится с интервалом hello time настроенным локально на свитче и не зависит от root BPDU. TCN BPDU отправляется только через root порт и принимается только на дезигнейтид портах. TC и TCA — это флаги configuration BPDU, TC устанавливаются только рутом, а TCA любым upstream свитчем который получил TCN. Когда рут получил TCN, он отравляет одну configuration BPDU с обоими флагами TCN и TC, а затем только TC в течении max_age + forward_delay.
    Т.к. Cisco использует свой проприетарный протокол PVST+, то если оборудование другого вендора его не поддерживает, то максимум что заработает это STP в navite VLAN. Но в настоящий момент использовать PVST+/STP можно ну в очень редких сценариях.

  7. 5. Если у root switch отвалился один из линков, он сразу отправит TCN с указанием уменьшить таймер или будет ждать TCN от нижестоящих коммутаторов?
    Root свитч не отправляет TCN BPDU, ему некого извещать :)
    И TCN BPDU отправляется только с root порта, которых нет у root свитча. TCN BPDU отправляют только downstream свитчи. Опять же отвались порт может из-за физики, которю можно обнаружить, или по другим причинам, тогда работают таймеры STP. Если отвалился дезигнейтид порт, то свитч вообще ничего делать не будет, это задача для того, у кого пропал root.
    If the port was designated, local bridge does nothing. However, downstream bridge may detect the loss of a root port and start reconverging.

      1. Hello c TCA называется configuration BPDU с установленным TCA флагом и отправляется в ответ на полученный TCN BPDU. Если у рута отвалились порты, сам он не отправит TCN BPDU, а configuraton BPDU с флагом TCA, он отправит только тогда, когда получит TCN BDP от downstream свитча. Cnfiguraton BPDU с флагом TCA никак не влияет на таймеры, это подтверждение о приеме TCN BPDU для downstream свитчей и команда им заткнуться и больше не его не слать.

        1. А как же вотэтовотвсе: «При получении сообщения hello с флагом TCA, коммутатор использует короткий таймер (Forward Delay time) для того чтобы обновить записи в таблице коммутации.» (цэ) xgu.ru ???

            1. Возможно имелось следующее, что когда рут получил TCN, он отравляет одну configuration BPDU с обоими флагами TCA и TC, а затем только TC в течении max_age + forward_delay.

  8. 3. Могут ли в одной сети (VLAN) сосуществовать STP и RSTP?
    Могут, но это зависит от реализации STP/RSTP вендорами и их совместимости. Есть вендоронезависимый MST, который может сосуществовать со всеми, нужно просто его правильно готовить.

    1. Могут, BPDU STP и RSTP различаются полем Message Type. Если порт свитча(был RSTP) получает STP BPDU, он переходит в режим STP(порт, не свитч).
      Сосуществовать со всеми, это все таки к CST :)

  9. 6. При каких изменениях топологии поменяется Root Bridge? И куда тогда будут отправляться TCN?
    1. Отвалились все линки до рута.
    2. Сдох свитч.
    3. Добавили свитч и его BID оказался ниже/приоритетнее, чем у текущего (кто-то не умеет пользоваться priority).
    4. На свитче с PVST+ создали VLAN, но для него приоритет не был установлен заранее, а для других изменен.
    5. Кто-то на руте, на портах к downstream свитчам включил BPDU Filter и/или BPDU Guadr.
    6. И т.д.
    TCN никуда не будет отправляться, т.к. отправляется он через root порт, а на свитчах подключенных к рут свитчу, рут порт «отвалился». Начнутся выборы Root Bridge, а затем выборы рут и дезигнейтид портов. Сеть будет стоят колом.

  10. 12. Можно ли уменьшить Aging timer при TC не изменяя Forwarding Delay? Чтобы ускорить очистку CAM таблицы, например сделать 1 сек.
    Непонятен смысл данной процедуры. Т.е. нам нужно убивать валидные MAC адреса в CAM таблице каждую секунду? И так делать на протяжении 35 сек. Зачем? Свич превращаем в хаб?

  11. Все же выделю несколько неверных на мой взгляд высказываний.
    1. Утверждение про выборы Root’a и портов — в STP нет механизма выборов, как например в OSPF. В начале работы STP коммутатор считает себя root’om и отсылает на порты соответствующие BPDU таймер Hello установлен в 2 сек., запоминает превосходящую супериор BPDU на каждом порту. После отправки супериор BPDU начинает слушать, и именно после отправки иначе сравнивать будет не с чем, после получения BPDU от соседа происходит сравнение, и тут возможны два варианта : 1. супериор BPDU — моя и 2. не моя а соседа (вариант не получен BPDU от соседа — это 1 вариант). И все, да да именно ВСЕ, по истечению 2 сек все коммутаторы знают кто рут какие порты в каком состоянии. Дальше ждем таймер чтобы ну прям все все и прям точно срослось.
    2. Утверждение о сравнении BPDU по параметрам — BPDU так не сравнивается, сравниваются BPDU, а именно 22 байта root bridge id 8 + root path cost 4 + sender bridge id 8 + port id 2 и + 2 байта port id на котором был получен BPDU — мой порт итого = 24 байта это колбаса из 24 байт и именно 24 байтовая колбаса моя и 24 байтовая колбаса соседа сравнивается. Наши шаловливые ручки могут поиграться с каждым из параметров влияя тем самым на BPDU в целом.

  12. Точнее
    И все, да да именно ВСЕ, по истечению 2 сек все соседние коммутаторы знают кто рут какие порты в каком состоянии. Дальше ждем таймер чтобы ну прям все все и прям точно срослось.

Добавить комментарий

Войти с помощью: