Протокол IP : Универсальная инкапсуляция маршрутизации (GRE)

Сообщения поддержки активности туннеля с общей инкапсуляцией маршрутов (GRE)

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Перевод, выполненный профессиональным переводчиком (13 августа 2008) | Английский (22 августа 2015) | Отзыв


Содержание


Введение

В данном документе содержится описание принципов работы сообщений поддержки активности (keepalive). Пакеты Keepalive Туннеля GRE не поддерживаются в сочетании с командой tunnel protection ipsec profile. Этот документ обсуждает эту проблему.

Примечание:  Сообщения поддержки активности GRE не поддерживаются вместе с защитой Туннеля IPSec ни при каких обстоятельствах.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Технические рекомендации Cisco. Условные обозначения.

Механизм сообщений поддержки активности туннеля GRE

Туннели GRE

Функциональность туннелей GRE не зависит от состояния. Это значит, что конечная точка каждого туннеля не хранит никаких данных о состоянии или доступности другой удаленной конечной точки этого туннеля. Вследствие этого маршрутизатор локальной конечной точки туннеля не в состоянии отключить линейный протокол интерфейса туннеля GRE, если удаленный конец туннеля недоступен. Возможность помечать интерфейс, как отключенный, когда удаленный конец соединения недоступен, используется для удаления маршрутов (а именно, статических маршрутов) в таблице маршрутизации, которая используется интерфейсом исходящей связи. В частности, если линейный протокол интерфейса отключается, то любые статические маршруты, которые указывают на этот интерфейс, удаляются из таблицы маршрутизации. Это позволяет выбрать альтернативный следующий переход (участок) или интерфейс при установке альтернативного (плавающего) маршрута или при использовании маршрутизации на основе политик (PBR).

Обычно интерфейс туннеля GRE включается сразу после настройки и остается активным до тех пор, пока имеется действительный адрес источника туннеля или интерфейс в активном состоянии. IP-адрес назначения туннеля также должен быть доступным для маршрутизации. Это обязательно даже в том случае, если не задана конфигурация для другого конца туннеля. Это означает, что статический маршрут или PBR-пересылка пакетов через интерфейс туннеля GRE работает даже в том случае, если пакеты туннеля GRE не достигают другого конца туннеля.

До внедрения сообщений активности GRE туннель GRE отключался по трем причинам:

  • Отсутствует маршрут, соответствующий адресу назначения туннеля.

  • Отключен интерфейс, привязанный к источнику туннеля.

  • Маршрут по адресу назначения туннеля проходит по данному туннелю.

Эти три правила (отсутствие маршрута, отключение интерфейса и несоответствие туннельного маршрута назначения) являются локальными проблемами маршрутизатора на конечных точках туннеля, и проблемы работоспособности промежуточных сетей ими не ограничиваются. Например, эти правила не объясняют случай, когда пакеты успешно передаются по туннелю GRE, но теряются до прихода на конечную точку туннеля. Из-за этого пакеты данных, проходящие через туннель GRE, попадают в "черные дыры", даже если альтернативный маршрут, использующий PBR, или плавающий статический маршрут через другой интерфейс потенциально доступен. Сообщения поддержки активности в интерфейсе туннеля GRE используются для того, чтобы решить проблему аналогично тому, как сообщения используются на физических интерфейсах.

С Cisco Выпуск ПО IOS� 12.2 (8) T, возможно настроить пакеты Keepalive на Туннельном интерфейсе GRE "точка-точка". Это изменение, в свою очередь, позволяет динамически отключать интерфейс, если сообщения поддержки активности отсутствуют в течение некоторого периода времени. В последующих разделах общие механизмы функционирования сообщений поддержки активности GRE рассматриваются более подробно.

Общие механизмы сообщений поддержки активности

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

Сообщения поддержки активности Ethernet

В широковещательной среде, такой как Ethernet, сообщения поддержки активности немного отличаются. Поскольку количество возможных соседей в Ethernet велико, сообщения поддержки активности не предусматривают определения доступности пути по кабелю к какому-то определенному соседу. Данные сообщения позволяют только выполнить проверку доступа локальной системы к кабелю Ethernet для чтения и записи. Маршрутизатор создает Ethernet-пакет, который содержит MAC-адрес источника и назначения самого маршрутизатора и специальный код Ethernet, равный 0x9000. Оборудование Ethernet отправляет этот пакет по кабелю Ethernet и затем немедленно получает этот пакет обратно. Таким образом, выполняется проверка аппаратных средств приема и передачи в адаптере Ethernet, а также проверка целостности кабеля.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-a.gif

Сообщения поддержки активности HDLC

Другой хорошо известный механизм сообщений поддержки активности — серийные сообщения для HDLC. Серийные сообщения поддержки активности пересылаются от одного маршрутизатора к другому (и обратно) и подтверждаются. Каждый маршрутизатор отслеживает отправленные и подтвержденные пакеты поддержки активности с помощью последовательных номеров. Таким образом, удаленные маршрутизаторы могут проанализировать сообщения поддержки активности друг друга и определить, получены ли отправленные сообщения.

На рисунке показано, как работают серийные сообщения поддержки активности: маршрутизатор 1 (Router 1) и маршрутизатор 2 (Router 2) подключены напрямую через интерфейсы Serial0/0 и Serial2/0, соответственно. В выходных данных маршрутизатора Router 1 интерфейс Serial 0/0 отключен намеренно. Это вынуждает маршрутизатор Router 2 пропустить три сообщения поддержки активности, для того, чтобы показать, как вследствие этой ошибки маршрутизатор Router 2 отключает интерфейс Serial2/0, если не поступают сообщения поддержки активности.

Здесь приведен пример выходных данных команды debug serial interface для соединения HDLC, когда сообщения поддержки активности включены. Когда разность значений в полях myseq и mineseen на маршрутизаторе Router 2 превышает 3, линия отключается и интерфейс перезагружается.

Маршрутизатор 1
17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up 
17:21:19.725: Serial0/0: HDLC myseq 1, mineseen 1*, yourseen 2, line up
17:21:29.753: Serial0/0: HDLC myseq 2, mineseen 2*, yourseen 3, line up
17:21:39.773: Serial0/0: HDLC myseq 3, mineseen 3*, yourseen 4, line up
17:21:49.805: Serial0/0: HDLC myseq 4, mineseen 4*, yourseen 5, line up
17:21:59.837: Serial0/0: HDLC myseq 5, mineseen 5*, yourseen 6, line up
17:22:09.865: Serial0/0: HDLC myseq 6, mineseen 6*, yourseen 7, line up
17:22:19.905: Serial0/0: HDLC myseq 7, mineseen 7*, yourseen 8, line up
17:22:29.945: Serial0/0: HDLC myseq 8, mineseen 8*, yourseen 9, line up
Router1 (config-if)#shut
17:22:39.965: Serial0/0: HDLC myseq 9, mineseen 9*, yourseen 10, line up
17:22:42.225: %LINK-5-CHANGED: Interface Serial0/0, changed state 
to administratively down

17:22:43.245: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, 
changed state to down

Маршрутизатор 2
*Sep 24 17:21:04.929: Serial2/0: HDLC myseq 0, mineseen 0, yourseen 0, line up 
*Sep 24 17:21:14.941: Serial2/0: HDLC myseq 1, mineseen 1*, yourseen 1, line up 
*Sep 24 17:21:24.961: Serial2/0: HDLC myseq 2, mineseen 2*, yourseen 2, line up 
*Sep 24 17:21:34.981: Serial2/0: HDLC myseq 3, mineseen 3*, yourseen 3, line up 
*Sep 24 17:21:45.001: Serial2/0: HDLC myseq 4, mineseen 4*, yourseen 4, line up 
*Sep 24 17:21:55.021: Serial2/0: HDLC myseq 5, mineseen 5*, yourseen 5, line up 
*Sep 24 17:22:05.041: Serial2/0: HDLC myseq 6, mineseen 6*, yourseen 6, line up 
*Sep 24 17:22:15.061: Serial2/0: HDLC myseq 7, mineseen 7*, yourseen 7, line up 
*Sep 24 17:22:25.081: Serial2/0: HDLC myseq 8, mineseen 8*, yourseen 8, line up 
*Sep 24 17:22:35.101: Serial2/0: HDLC myseq 9, mineseen 9*, yourseen 9, line up 
*Sep 24 17:22:45.113: Serial2/0: HDLC myseq 10, mineseen 10*, yourseen 10, line up 
*Sep 24 17:22:55.133: Serial2/0: HDLC myseq 11, mineseen 10, yourseen 10, line up 
*Sep 24 17:23:05.153: HD(0): Reset from 0x203758
*Sep 24 17:23:05.153: HD(0): Asserting DTR 
*Sep 24 17:23:05.153: HD(0): Asserting DTR and RTS 
*Sep 24 17:23:05.153: Serial2/0: HDLC myseq 12, mineseen 10, yourseen 10, line up 
*Sep 24 17:23:15.173: HD(0): Reset from 0x203758
*Sep 24 17:23:15.173: HD(0): Asserting DTR 
*Sep 24 17:23:15.173: HD(0): Asserting DTR and RTS 
*Sep 24 17:23:15.173: Serial2/0: HDLC myseq 13, mineseen 10, yourseen 10, line down 
17:23:16.201: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, 
changed state to down
Router2#
17:23:25.193: Serial2/0: HDLC myseq 14, mineseen 10, yourseen 10, line down

Сообщения поддержки активности туннеля с общей инкапсуляцией маршрутов (GRE)

Механизм сообщений поддержки активности туннеля GRE немного отличается от механизма Ethernet или последовательных интерфейсов. Он позволяет одной из сторон отправлять пакеты поддержки активности удаленному маршрутизатору и получать их от него даже в том случае, если удаленный маршрутизатор не поддерживает сообщения поддержки активности GRE. Поскольку GRE является механизмом туннелирования пакетов для IP-туннелирования внутри IP-протокола, пакет IP-туннеля GRE может быть создан внутри другого пакета IP-туннеля GRE. Для сообщений поддержки активности GRE отправитель предварительно создает ответный пакет внутри исходного пакета-запроса сообщения поддержки активности, таким образом, удаленной стороне необходимо только выполнить стандартную декапсуляцию GRE внешнего IP-заголовка GRE и затем передать внутренний IP-пакет GRE. Из-за особенностей данного механизма ответные сообщения поддержки активности передаются не по туннельному, а по физическому интерфейсу. Это означает, что функции на выходе туннельного интерфейса, такие как "защита туннеля ...", качество обслуживания (QoS) и так далее, не оказывают влияния на ответный пакет поддержки активности GRE.).

Примечание: Если входящий ACL на Туннельном интерфейсе GRE настроен, то пакет keepalive Туннеля GRE, который должны быть разрешены противоположные передачи устройства. В противном случае Туннель GRE противоположного устройства не работает. (хост gre разрешения на <number> access-list <точка начала туннеля> хост <назначение туннеля>)

Другой атрибут сообщений поддержки активности туннеля GRE — независимость счетчиков сообщений поддержки активности и отсутствие необходимости их соответствия друг другу. Проблема конфигурации сообщений поддержки активности на одной стороне туннеля заключается в том, что только один маршрутизатор, у которого настроены сообщения поддержки активности, помечает свой туннельный интерфейс как отключенный, если время ожидания счетчика сообщений поддержки активности истекло. Интерфейс туннеля GRE на другой стороне, где отсутствует конфигурация сообщений поддержки активности, остается активным, даже если другая сторона туннеля отключена. Туннель может стать черной дырой для пакетов, направленных в туннель стороной, не имеющей конфигурации сообщений поддержки активности. В большой сети туннелей GRE с топологией "звезда" следует выполнить только настройку конфигурации сообщений поддержки активности на стороне оконечных устройств, но не стороне концентратора. В большинстве случаев для оконечных устройств более важна возможность определять недостижимость концентратора и переключаться на резервный путь (например, для резервирования соединений).

Принципы работы сообщений поддержки активности туннеля

Туннель GRE — это расположенный на маршрутизаторе Cisco логический интерфейс, который предоставляет механизм для инкапсулирования пакетов, переносимых внутри транспортного протокола (passenger packet). Данный механизм предоставляет сервисы, которые позволяют реализовать схему инкапсуляции "от точки к точке".

На примере ниже представлены концепции IP-туннелирования, где GRE — протокол инкапсуляции, а IP — транспортный протокол. Протокол переноса также является IP-протоколом (однако он может быть другим протоколом, например Decnet, IPX или Appletalk).

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-b.gif

  • IP является транспортным протоколом.

  • GRE является протоколом инкапсуляции.

  • IP является протоколом переноса.

Для более полного понимания общих механизмов функционирования сообщений поддержки активности GRE ниже рассматриваются пример туннельной топологии и конфигурации. Физические интерфейсы маршрутизаторов Router A и Router B обозначены соответственно как S1 и S2, туннельные интерфейсы обозначены Tu0. Имеется магистральная IP-сеть между двумя конечными маршрутизаторами туннеля GRE.

Это пример пакета поддержки активности, который отправлен из маршрутизатора Router A и назначен маршрутизатору Router B. Ответ на сообщение поддержки активности, который маршрутизатор Router B возвращает маршрутизатору Router A, уже находится во внутреннем IP-заголовке. Маршрутизатор Router B просто декапсулирует пакеты поддержки активности и отправляет их обратно на физический интерфейс (S2). Тот, в свою очередь, обрабатывает пакеты поддержки активности GRE подобно любым другим IP-пакетам данных GRE.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-1.gif

Ниже показаны выходные данные команд, используемых для конфигурации сообщений поддержки активности в туннелях GRE.

Router# configure terminal
Router(config)#interface tunnel0
Router(config-if)#keepalive 5 4          

!--- The syntax of this command is keepalive [seconds [retries]].



!--- Keepalives are sent every 5 seconds and 4 retries.
!--- Keepalives must be missed before the tunnel is shut down.
!--- The default values are 10 seconds for the interval and 3 retries.

Примечание: Пакеты Keepalive туннеля GRE только поддерживаются на Туннелях GRE "точка-точка". Сообщения поддержки активности туннеля могут быть настроены на многоточечных туннелях GRE (mGRE), однако это не даст ощутимого эффекта.

В таблице показана конфигурация маршрутизаторов Router A и Router B, на каждом из которых присутствует конфигурация сообщений поддержки активности туннеля.

Имя хоста маршрутизатора Router-A Hostname RouterB
interface loopback 0
  ip address 129.9.9.9 255.255.255.255
interface tunnel 0
  ip address 1.1.1.1 255.255.255.240
  tunnel source loopback0
  tunnel destination 128.8.8.8
  keepalive 5 4
interface loopback 0
  ip address 128.8.8.8 255.255.255.255
interface tunnel 0
  ip address 1.1.1.2 255.255.255.240
  tunnel source loopback0
  tunnel destination 129.9.9.9
  keepalive 5 4 

Если сообщения поддержки активности на конечной точке туннеля маршрутизатора Router A включены, маршрутизатор в каждом интервале <период> создает внутренний IP-заголовок и заголовок GRE с нулевым типом протокола (PT). Затем он отправляет этот пакет туннельному интерфейсу, в результате чего происходит инкапсуляция пакета с внешним IP-заголовком и заголовком GRE с PT, равным IP. Маршрутизатор Router A увеличивает значение счетчика сообщений поддержки активности туннеля на единицу. Если предположить, что способ достижения конечной точки туннеля на дальнем конце существует, а линейный туннельный протокол по каким-то причинам не отключен, то пакет поступает на маршрутизатор Router B. Затем он сопоставляется с туннелем 0, декапсулируется и направляется по IP-адресу назначения, который является IP-адресом источника туннеля на маршрутизаторе Router A. Когда пакет поступает на маршрутизатор Router A, он декапсулируется, и проверка PT дает в результате 0. Это означает, что данный пакет является пакетом поддержки активности. Происходит сброс значения счетчика сообщений проверки активности на 0 и пакет отбрасывается.

В случае, когда Маршрутизатор B недостижим, Маршрутизатор A продолжает создавать и передавать пакеты keepalive, а также обычный трафик. Если сообщение поддержки активности не возвращается, линейный протокол туннеля остается включенным до тех пор, пока значение счетчика сообщений поддержки активности меньше, чем число <попыток>. Если данное условие не соблюдено, то в следующий раз при попытке маршрутизатора Router A отправить пакет поддержки активности маршрутизатору Router B, линейный протокол отключается.

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

Примечание: Если должный к отбрасыванию поддержки активности туннель переходит к состоянию включения/отключения, включите туннель отладки и отладьте проверку подлинности туннеля.

Эта таблица показывает пример выходных данных проверки подлинности туннеля отладки на Маршрутизаторе A:

Имя хоста маршрутизатора Router-A
debug tunnel keepalive
        Tunnel keepalive debugging is on
        *Mar  1 01:19:16.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=15
        *Mar  1 01:19:21.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=16
        *Mar  1 01:19:26.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=17

На схеме показан пример сценария, когда маршрутизатор Router A отправляет сообщения поддержки активности GRE маршрутизатору Router B:

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-2.gif

На схеме показан пример сценария, когда маршрутизатор Router B отправляет сообщения поддержки активности GRE маршрутизатору Router A:

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-3.gif

IPsec и сообщения поддержки активности GRE

Туннели GRE с протоколом IPSec

В некоторых случаях туннели GRE совмещаются с IPSec, поскольку IPSec не поддерживает многоадресную рассылку IP-пакетов. Это не позволяет протоколам динамической маршрутизации успешно работать в сетях VPN IPSec. Поскольку туннели GRE поддерживают многоадресную рассылку IP-пакетов, протокол динамической маршрутизации может быть реализован в туннеле GRE. Соответственно, для IP-пакетов одноадресной рассылки GRE может применяться шифрование IPSec.

Существует два способа выполнения шифрования IPSec пакетов GRE. Один из них заключается в использовании криптокарты, другой — в использовании команды tunnel protection. Особенность обоих методов состоит в выполнении шифрования IPSec после добавления инкапсуляции GRE. Криптокарта применяется к исходящему физическому интерфейсу (интерфейсам) для пакетов туннеля GRE. Если используется команда tunnel protection, она настраивается в интерфейсе туннеля GRE. Команда tunnel protection доступна в ПО Cisco IOS версии 12.2(13)T.

Примечание: Сообщения поддержки активности GRE не совместимы с tunnel protection.

На данной схеме показаны зашифрованные пакеты, поступившие на маршрутизатор через интерфейс туннеля GRE. Маршрутизатор имеет криптокарту, которая применяется на физическом интерфейсе. Дешифрованные и декапсулированные пакеты передаются по IP-адресу назначения как открытый (незашифрованный) текст.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-4.gif

На следующей схеме показан случай применения команды tunnel protection на интерфейсе туннеля GRE. Пакеты поступают через интерфейс туннеля на маршрутизатор зашифрованными, дешифруются и декапсулируются, а затем передаются по IP-адресу назначения как открытый (незашифрованный) текст.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-5.gif

Существуют два основных отличия в использовании криптокарты и команды защиты туннеля:

  • Криптокарта IPSec привязана к физическому интерфейсу и проверяется при отправке из него пакетов.

    Примечание: Туннель GRE уже имеет GRE, инкапсулировал пакет этой точкой.

  • Защита туннеля привязывает функцию шифрования к туннелю GRE; она проверяется после GRE-инкапсуляции пакета, но до того, как пакет передан на физический интерфейс.

Проблемы с сообщениями поддержки активности при совмещении IPSec и GRE

Проблема возникает, если используется криптокарта (настроенная в физическом интерфейсе) на одной стороне туннеля GRE IPSec, а защита туннеля установлена на другой стороне. При этом конфигурация защиты туннеля присутствует только в интерфейсе (не физическом) туннеля. Такой тип конфигурации может быть установлен в топологии типа "звезда". Защита туннеля устанавливается на концентраторе-маршрутизаторе с целью уменьшения размера конфигурации, и статическая криптокарта используется на каждом их оконечных устройств. Если выполнить настройку сообщений поддержки активности туннеля GRE на оконечном устройстве в данном сценарии, передача этих сообщений не выполняется. Причина заключается в том, что ответное сообщение поддержки активности от КОНЦЕНТРАТОРА проходит через физический интерфейс, в котором криптокарта не настроена. Поэтому ответное сообщение поддержки активности не шифруется и принимающий маршрутизатор (который отправил данный пакет) отбрасывает ответные сообщения, так как они не имеют защиты IPSec (незашифрованы).

Представленная схема иллюстрирует данную проблему:

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-9.gif

Этой проблемы можно избежать, если настроить сообщения поддержки активности GRE на маршрутизаторе с установленной защитой туннеля. Это показано на следующей схеме:

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-10.gif

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

Хотя интерфейс туннеля GRE на концентраторе остается активным, соседи по маршрутам и сами маршруты потеряны, а установка альтернативных маршрутов невозможна. На луче факт, что туннельный интерфейс выключился, может вызвать его для внедрения интерфейса номеронабирателя и обратного вызова к концентратору (или другой маршрутизатор в концентраторе), затем установить новое соединение.

Если и маршрутизаторы настроены с криптокартами, проверки подлинности туннеля могут пройти в обоих направлениях и Туннельных интерфейсах GRE, может завершить или в или в оба направления и вызвать резервное подключение, которое будет сделано. Данный вариант обеспечивает наибольшую гибкость.

Если оба маршрутизатора настроены с tunnel protection тогда, Туннель GRE keeaplives не может использоваться ни в одном направлении. В этом случае необходимо использовать протокол маршрутизации или другой механизм, такой как Service Assurance Agent, чтобы обнаружить, что туннель не функционален.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 64565