Сетевому администратору может понадобиться использовать туннелирование в том случае, кода имеются «несоприкасающиеся» сети, которые не используют IP и которые разделяются IP-магистралью. Если такие «несоприкасающиеся» сети используют протокол DECnet, то администратор по каким-либо причинам может отказаться соединять эти сети посредством настройки протокола DECnet в магистральной сети. Администратор может не захотеть, чтобы маршрутизация DECnet использовала пропускную способность магистрали по той причине, что это может повлиять на производительность сети IP. В качестве возможной альтернативы можно осуществить туннелирование DECnet в магистральной IP-сети.
В ходе туннелирования пакеты DECnet инкапсулируются в IP и пересылаются по магистрали к конечной точке туннеля, где после удаления инкапсуляции пакеты DECnet маршрутизируются к пункту назначения по сети DECnet. Механизм инкапсулирования трафика в другой протокол дает следующие преимущества: Конечные точки используют свои частные адреса (RFC 1918 ), а магистраль не поддерживает маршрутизацию этих адресов. Возможно организовать виртуальные частные сети (VPN) в сетях WAN или в Интернете. Возможно объединение двух несоприкасающихся многопротокольных сетей посредством магистрали, которая использует один протокол. Используется шифрование трафика, передаваемого по магистральной сети или Интернету.
Далее во всех примерах IP будет использоваться как транспортируемый протокол (passenger protocol), а также как транспортный протокол. Замечания, касающиеся туннельных интерфейсов Далее приведены некоторые соображения по туннелированию. Функция быстрой коммутации GRE-туннелей впервые была реализована в программном обеспечении Cisco IOS 11.1, а коммутация CEF (Cisco Express Forwarding) впервые появилась в версии 12.0. Коммутация CEF для многоточечных GRE- туннелей впервые была реализована в версии 12.2(8)T. В более ранних версиях ПО IOS, которые поддерживали только коммутацию процессов, быстродействие функций инкапсуляции и декапсуляции было невысоким.
При туннелировании пакетов необходимо учитывать вопросы безопасности и топологии. Туннели обладают способностью беспрепятственно миновать списки управления доступом (ACL) и брандмауэры. Если туннель проходит через брандмауэр, то это означает в сущности, что любой транспортируемый протокол беспрепятственно проходит через этот брандмауэр. По этой причине в конечных точках туннеля рекомендуется включить функцию брандмауэра, чтобы в принудительном порядке подвергать транспортируемые протоколы действию установленных политик.
В связи с увеличением продолжительности задержки в процессе туннелирования могут возникнуть проблемы с транспортными протоколами, для которых предусмотрены ограничения по времени (например DECnet) Туннелирование в условиях работы с различными скоростями соединения, например быстрые кольца FDDI в сочетании с медленными (9600 бит/с) телефонными линиями, может вызывать проблемы с переупорядочиванием пакетов. Некоторые транспортируемые протоколы очень плохо работают в сетях со смешанными сетевыми носителями. PTP-туннели могут использовать всю пропускную способность физического канала.
При использовании протоколов маршрутизации на нескольких PTP-туннелях необходимо помнить, что каждый туннельный интерфейс имеет пропускную способность и что физический интерфейс, через который проходит этот туннель, так же имеет свою пропускную способность. Например, если на 10-мегабитный канал приходится 100 туннелей, то требуется установить пропускную способность туннеля равную 100 кбит/с. Стандартная полоса пропускания для туннеля равна 9 кбит/с. Для протоколов маршрутизации предпочтительнее установка туннеля в «реальном» канале, поскольку в противном случае