Cisco Bridging: теория

Bridge - это мост, служит для передачи данных между LAN. Есть 4-е вида мостов:

1. Transparent bridging (прозрачный мост) – применяется в основном в Ethernet сети и в основном используются для соединения сетей, с одинаковой средой передачи
2. Source-Route Bridging (SRB) – в основном используются в Token Ring сетях. Мосты только перенаправляют фреймы основываясь на routing indicator, содержащемся во фрейме. Конечные станции несут ответственность за определение и поддержание таблиц адресов назначения и routing indicator (маршрутных индикаторов)
3. Translational bridging – используется для передачи данных между различными физическими средами. Обычно это используется между Ethernet и FDDI или Token Ring и Ethernet
4. Source-Route Translational Bridging (SR/TLB) – это комбинация source-route bridging и transparent bridging, которая обеспечивает связь в смешанной среде предприятия Ethernet and Token Ring. Translational bridging без routing indicators (маршрутных индикаторов) между Token Ring и Ethernet также называется SR/TLB

Transparent bridge называется так потому, что его присутствие и работа прозрачна для хостов в сети. Когда Transparent bridge включен, он узнает расположение рабочих станций, анализирую адрес источника входящего фрейма ото всех подключенных сетей. Например, если bridge видит, что фрейм получен на порту 1 от хоста А, он решает, что хост А может быть достижим через сегмент подключенный к порту 1. В ходе этого процесса transparent bridges строит таблицу (процесс обучения) соответствий.

Bridge использует таблицу как основу для передачи трафика. Когда фрейм получен на одном из интерфейсов добавленных в bridge, тогда bridge ищет адрес назначения фрейма по своей внутренней таблице. Если в таблице содержится взаимосвязь между адресом назначения и любым из забриджеванным портом, за исключением порта, на котором фрейм был получен, то фрейм передается на соответствующий порт. Если взаимосвязь не найдена, фрейм распространяется на все порты, кроме того, на котором фрейм был получен. Броадкаст и мультикаст так же распостраняются этим способом.

Transparent bridges успешно изолирует внутрисегментный трафик, тем самым уменьшая видимый трафик на каждом отдельном сегменте. Это называется фильтрацией и происходит, когда MAC адрес источника и назначения расположены в том же интерфейсе моста. Фильтрация обычно улучшает отклик сети. Степень, до которой трафик уменьшается, а время отклика улучшается (уменьшается) зависит от объема внутрисегментного трафика по отношения к общему объему, а так же объема броадкаст и мультикаст трафика

Bridging работает на data-link уровне, который управляет потоком данных, обрабатывает ошибки передачи, предоставляет физическую адресацию и управляет доступом к физической среде. Bridges анализирует входящий фрейм, принимает решение о переадресации основываясь на этом фрейме, и передает фрейм к его адресу назначения. Иногда, например в SRB, фрейм содержит полный путь к адресу назначения. В других случаях, таких как в transparent bridging, фреймы передаются в один хоп за раз к месту назначения.

Мосты могут быть или удаленные или локальные. Локальные мосты предоставляют непосредственное соединение между несколькими сегментами LAN в той же области. Удаленные мосты соединяют сегметы LAN в различных областях, обычно через телекоммуникационные каналы.

Spanning Tree Algorithm (STA) – является важной частью transparent bridging. STA используется для динамического обнаружения loop-free подсетей в сетевой топологии. Чтобы сделать это STA ставит порты моста, которые создают петли, когда активны, в состояние ожидания или блокировки. Заблокированные порты могут быть активированы, если основной порт неисправен, также они предоставляют поддержку избыточности. Для большей информации смотри IEEE 802.1d спецификацию.

Расчет Spanning Tree происходит, когда мост создается или когда обнаружено изменение топологии. Конфигурационные сообщения называются Bridge Protocol Data Units (BPDUs), запускающие расчет.

Пока B1 был единственным мостом, все работало хорошо, но с настройкой B2, появилось два способа соединения между двумя сегментами. Это называет bridging loop network. Без STA, broadcast от хоста из LAN1 стал бы известен двум мостам, и тогда B1 и B2 отправили одно и тоже broadcast сообщение в LAN2. Оба моста (В1 и В2) уверены, что хост подключен к LAN2. В дополнение к этой основной проблемы подключения с broadcast сообщениями в сети с петлями, может быть проблема с пропускной способностью.

С STA, даже когда В1 и В2 настроены, они оба отправляют BPDU сообщения, которые содержат информацию, определяющую кто из низ является root bridge. Если В1 является root bridge, то он становится designated bridge для LAN1 и LAN2. В2 не будит бриджевать никакие пакеты, так как один из его портов будит в заблокированном состоянии.

Integrated Routing and Bridging (IRB)

IRB позволяет бриджевать и маршрутизировать протоколы одновременно и пропускать трафик от бриджеванного интерфейса к маршрутизируемому и наоборот. Например, вы можете переходить от bridged topologies к routed topologies, вам сначала может потребоваться подключить bridged segment к routed networks.

Использую IRB функцию вы можете маршрутизировать определенный протокол между routed interfaces и bridge groups в пределах L3 коммутатора. В частности, локальный или немаршрутизируемый трафик будит передаваться через bridged interfaces в той же bridge group, в то время как маршрутизироуемый трафик будит передаваться через routed interfaces или bridge groups

BVI – это виртуальный интерфейс в L3 коммутаторе, который действует как обычный маршрутизируемый интерфейс (routed interface). BVI не поддерживает bridging, но на самом деле представляет соответствующие bridge group для маршрутизируемого интерфейса L3 коммутатора. Номер интерфейса является связующим звеном между BVI и bridge group.

Программное обеспечение L3 коммутатора поддерживает маршрутизацию IP и IPX между routed interfaces и bridged interfaces на том же L3 коммутаторе.

Перед настройкой IRB необходимо учитывать:

1. Поведение по умолчанию route/bridge в находящихся в bridge group (когда IRB включен) это bridge всех пакетов. Необходимо убедится, что маршрутизация настроено точно на BVI для протоколов, которые необходимо маршрутизировать
2. Пакеты не маршрутизируемых протоколов, такие как local-area transport (LAT) всегда бриджуются. Нельзя отключить бриджинг для не маршрутизируемых протоколов.
3. Bridge соединяет несколько сетевых сегментов в одну большую плоскую сеть. Для прохождения пакета идущего от маршрутизируемого интерфейса среди bridged interfaces, вся bridge group должна быть представлена одним интерфейсом.

Когда на BVI настроена и включена маршрутизация, пакеты пришедшие на маршрутизируемый интерфейс, который является адресом назначения для хоста в сегменте bridge group, перенаправляются к BVI. От BVI пакеты перенаправляются к механизму бриджевания (bridging engine), который направляет их через bridged interface. Это перенаправление основывается на MAC адресе назначения. Аналогично, пакеты, которые пришли на bridged interface, но адрес назначения расположен в маршрутизируемой сети, сперва попадает на BVI. Затем BVI передает пакеты на механизм маршрутизации (routing engine), который направляет их через routed interface. На одном физическом интерфейсе, IRB может быть создан с двумя VLAN (802.1Q tagging) подинтерфейсами; одни VLAN подинтерфейс с IP адресом, используемым для маршрутизации, и другой VLAN подинтерфейс и другим физическим интерфейсом на маршрутизации.

Полезные ссылки:

• Transparent Bridging
• 1) Configuring Transparent Bridging
• 2) Configuring Bridging
• Understanding and Configuring VLAN Routing and Bridging on a Router Using the IRB Feature
• Troubleshooting Transparent Bridging Environments

P.S. Если кто будит пользоваться данной публикацией. Она сосавлена в первую очередь для себя, для лучшего понимания данной тематики, это перевод нескольких цисковских мануалов. Обратите внимание, что точность и правильность перевода не гарантируется, в тексте могут присутствовать орфографические, пунктуационные и другие ошибки. За более полной информацией необходимо обратится к официальной документации. Дополнения, исправления, указания на неточности преветсвуются.

Процесс инициализации Cisco IP Phone: часть 4

Поиск и устранение неисправностей при межкластерном вызове между Cisco IP Phone

В этом разделе рассматривается пример, когда Cisco IP Phone совершает вызов на другой Cisco IP Phone, расположенный в другом кластере (межкластерный вызов).
Для примера возьмем следующую топологию:два кластера, каждый имеет два CUCM, а также Cisco IOS Gateways и Cisco IOS Gatekeeper.

Intercluster H.323 Communication

Cisco IP Phone в Cluster 1 звонит на Cisco IP Phone in Cluster 2. Межкластерное соединения CUCM происходит с использование протокола H.332 версии 2. Cisco IOS Gatekeeper служит для контроля доступа.

Cisco IP Phone может соединятся с CUCM используя Skinny Station протокол (SCCP), а CUCM может соединятся с Cisco IOS Gatekeeper, используя H.323 RAS протокол. Admission request message (ARQ)[2] посылается к Cisco IOS Gatekeeper, который посылает Admission confirmed message (ACF)[3], убедившись, что межкластерный вызов будит совершаться с использованием протокола H.323 версии 2. После этого происходит установление звукового тракта между Cisco IP Phones в разных кластерах, с использованием RTP протокола.

Trace потока вызова

В этом разделе рассматривается поток вызова, на примере использования SDI trace, записанного в файле CCM000000000. Traces, рассматриваемый в этом примере, содержит информацию только этого конкретного вызова (рассматриваемого в примере).

В данном случае, Cisco IP Phone (2002), расположенный в Cluster 2, звонит на Cisco IP Phone (1001), расположенный в Cluster 1. Помните, что вы можете следить за устройством с использованием trace, просматривая значения TCP handle, time stamp или имени устройства. Значение TCP handle для устройства не изменяется, пока оно не будет перезагружено или не будит выведено из сети.

В следующем trace показано: Cisco IP Phone (2002) снимает трубку, TCP handle и номер вызывающего абонента. Так же показан номер вызываемого абонента (набранный номер) (1001), H.225 запрос на соединение и H.245 подтверждающие сообщения. Тип кодеков - выбран G.711 mu-law.

16:06:13.921 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x1c64310
16:06:13.953 CCM|Out Message -- H225ConnectMsg -- Protocol= H225Protocol
16:06:13.953 CCM|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06 
16:06:13.953 CCM|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=2002, 
CalledPartyName=1001, CalledParty=1001, tcpHandle=0x1c64310
16:06:14.015 CCM|H245Interface(2) OLC indication chan number = 2
16:06:14.015 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x1c64310 myIP: 
e74610ac (172.16.70.231)
16:06:14.015 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
16:06:14.062 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID 
tcpHandle=0x1c64310, Status=0, IpAddr=0xe74610ac, Port=20444, PartyID=2
16:06:14.062 CCM|H245Interface(2) paths established ip = e74610ac, port = 20444
16:06:14.187 CCM|H245Interface(2) OLC outgoing confirm ip = fc4610ac, port = 29626

Представлены номера вызывающего и вызываемого абонентов, которые связаны с IP адресами и шестнадцатеричными значениями.

16:06:14.187 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
16:06:14.187 CCM|StationD - RemoteIpAddr: fc4610ac (172.16.70.252)

Далее представлен trace, показывающий размер пакетов и MAC адрес Cisco IP Phone (2002), затем идет разъединение, сообщение о том, что трубку положили.

RemoteRtpPortNumber: 29626 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:06:16.515 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
16:06:16.515 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x1c64310 myIP: 
e74610ac (172.16.70.231)
16:06:16.515 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x1c64310 myIP: 
e74610ac (172.16.70.231)
16:06:16.531 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
16:06:16.531 CCM|Ie - Q931CauseIe -- IEData= 08 02 80 90 
16:06:16.531 CCM|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06 
16:06:16.531 CCM|Locations:Orig=1 BW=64Dest=0 BW=-1 (-1 implies infinite bw available)
16:06:16.531 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect 
to (64,2) and remove connection from list
16:06:16.531 CCM|MediaManager - wait_AuDisconnectReply - received all disconnect replies, 
forwarding a reply for party1(16777219) and party2(16777220)
16:06:16.531 CCM|MediaCoordinator - wait_AuDisconnectReply - removing MediaManager(2) from 
connection list
16:06:16.734 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x1c64310

Поток вызова с ошибкой

В следующем разделе рассматривается межкластерный поток вызова с ошибкой. Cisco IP Phone (1001) снимает трубку. TCP handle присваивается Cisco IP Phone.

16:05:33.468 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:33.468 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001 
16:05:33.484 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn 
tcpHandle=0x4fbbc30

Пользователь набирает номер вызываемого абонента (2000), и процесс анализа цифр пытается сопоставить номер (с шаблоном).

16:05:33.484 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:33.484 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:35.921 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2")
16:05:35.921 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.437 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="20")
16:05:36.437 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.656 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="200")
16:05:36.656 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.812 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2000")

Trace, представленный ниже, результат завершившегося процесса анализа цифр. Обратите внимание, что PotentialMatches=NoPotentialMatchesExist сообщает, что CUCM не может найти соответствие этому абонентскому номеру. В завершении, посылается сигнал занятости линии вызывающему абоненту (1001), за которым следует сообщение «трубка повешена».

16:05:36.812 CCM|Digit analysis: analysis results
16:05:36.812 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=2XXX
|DialingRoutePatternRegularExpression=(2XXX)
|PotentialMatches=NoPotentialMatchesExist
|CollectedDigits=2000
16:05:36.828 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, 
CallingParty=1001, CalledPartyName=, CalledParty=2000, tcpHandle=0x4fbbc30
16:05:36.828 CCM|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4fbbc30
16:05:37.953 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Скорее всего имеется ввиду, что для набранного номера имеется несколько перекрывающихся шаблонов (например, 2ХХХ и 20ХХ). Номер будит выбран по условиям Closest Match Routing. После соединения с абонентом, выбранным по условиям Closest Match Routing, вызывающий слышит сигнал о занятости линии потому, что вызываемый абонент разговаривает (всего лишь предположение).

[2]Запрос на разрешение об участии в разговоре от конечной точки к gatekeeper. [3]Положительный ответ от gatekeeper, разрешающей конечной точке принимать участие в разговоре.

Ссылка на первую часть и на вторую, на третью

P.S. Это перевод части официальной документации,если кто будит пользоваться обратите внимание, что точность и правильность перевода не гарантируется. В тексте могут присутствовать орфографические, пунктуационные и другие ошибки. За более полной информацией необходимо обратится к официальной документации.