VRF Basic Example

VRF на данный момент не является широко документированным и полно разобранным материалом. К тому же полносвязно и доходчиво он рассматривается и понимается -- как механизм в MPLS в курсе CCIE. Однако для "зашедших на огонёк" тут есть немного мат части. 

Virtual Routing and Forwarding (VRF) -- технология позволяющая создать несколько виртуальных маршрутизаторов на одной железке, каждый со своей таблицей маршрутизации. Каждый VRF состоит из трёх основных компонентов: 
1) RIB ( Routing Information Base ) -- таблицы маршрутизации 
2) CEF FIB ( Forwarding Information Base ), заполненной на основании RIB этой VRF ( если включен CEF) 
3) Отдельной instance или процесса протокола маршрутизации, который используется для обмена маршрутами с CE, которые должны поддерживаться этой VRF. Графический разворот трёх пунктов дан на картинке вначале. Стоит учесть, что он сильно упрощён только под данный пример. 

Дано: В нашем случае рассмотрим пример взаимодействия PE (Provider Edge) и нескольких клиентов (CE - Client Edge) 

Задача: создать для них 3 виртуальных таблицы маршрутизации типа VRF, при этом подсети и адреса клиентов будут идеентичны. 

DMVPN addons

(Опционально) Настройка аутентификации:  

Router(config-if)#ip nhrp authentication nhrppass

----------------------------------

(Опционально) Настройка флага неуникальности ip-адреса туннеля в базе nhrp на hub-маршрутизаторе:

Spoke(config-if)#ip nhrp registration no-unique

Если изменится внешний адрес spoke-маршрутизатора и этой команды не будет, то hub-маршрутизатор не обновит свою базу nhrp из-за ошибки: unique address registered already 

----------------------------------

(Опционально) Настройка holdtime:  

Spoke(config-if)#ip nhrp holdtime 222

  Tunnel2 created 00:00:02, expire 01:59:57

Дефолтное значение 2 часа. По ситуации рекомендую уменьшать до 30 минут.

EIGRP hold-time

Hub(config-subif)#ip hold-time eigrp 100 30

DMVPN HUB1(DualISP) SPOKE1(DualISP) SPOKE2(SingleISP)

Дано:
Блок одной из классических схем организации DMVPN типа HUB-and-SPOKE,
R20 -- HUB с двумя провайдерами
R21 и R22 -- SPOKE маршрутизаторы с двумя и одним провайдерами соответственно
Все линки на провайдеров даны типа default-gateway
R2...R11 -- имитируют интернет, типа OSPF area 0 процесс 77

Задача:
Построить DMVPN, типа mGRE с шифрацией трафика типа IPSec.
Динамической маршрутизацией типа EIGRP.
Свободный обмен данными между хостами xp_http_ftp_cisco, xp_http_ftp_cisco1, xp_http_ftp_cisco2 (здесь проверен icmp, http и ftp трафик)

DMVPN Basic Example

Дано:
Классическая схема DMVPN -- HUB and SPOKE
R1 -- центральный офис и логический HUB
R3, R4 -- региональные офисы логические SPOKE
R2 -- имитация интернет, с маршрутизацией типа OSPF 77
Loopback интерфейсы прописываются для упрощённой настройки OSPF (RouterID)

Схема упрощена до базового концепта DMVPN типа HUB-SPOKE,
т.е. у филиалов присутствуют белые IP и отсутствует NAT
каждая логическая единица схемы имеет только одного провайдера
вместо BGP используется OSPF ( как вариант можно было бы ещё упростить до default-gateway )

Задача:
Настроить DMVPN типа point-to-multipoint с поддержкой логических mGRE тоннелей с поддержкой шифрования IPSec
Настроить днамическую маршрутизацию между ними объединяя их в одну логическую сеть
Создать эту систему таким образом чтобы добавление нового SPOKE узла требовало настройки только с его стороны

OSPF accross multi area

Дано: Картинка немножко корявая, потому что служила для другого проекта, но смысл примерно такой логическая цепочка выглядит так:

R2[AREA 0,10] --- (( R3[AREA 10,20] --- R1[AREA 10,30] )) --- R4[AREA 20,30]

Задача: Настроить маршрутизацию так, чтобы хост [xp_http_ftp_cisco_2] мог общаться с [xp_http_ftp_cisco] в частности, и любым хостом в инфраструктуре в общем и целом. Соответственно, каждый роутер должен иметь в таблице маршрутизации живой путь до зоны backbone-area0 и обратно. 

IP SLA

Дано: 
HOST1 имитирует внутреннюю сеть
HOST2 имитирует интернет хост
R1 имитирует пограничный маршрутизатор с двумя линками на провайдера ( F0/1 и F1/0 )
R2 - R4 имитирут интернет

Задача: Обеспечить хождение трафика по дефолту через ISP1. В случае падения линка или пропадания сервиса переключится на ISP2. Всё это должно происходить автоматически без ручной перенастройки.

SNMP

SNMP — протокол, который используется для обмена сообщениями между агентом и менеджером. 

Diffie-Hellman

Демонстрация работы обмена ключами Diffie-Hellman 
Хорошая картинка и сразу под рукой :)

MARC. NetFlow.

Кратко об общем или что нужно видеть не вставая с дивана.
Для начала нужно понимать, что мониторинг сетей – штука довольно щепетильная и тонкая, и внедрить её в уже работающий проект, не спроектированный с учётом требований и возможностей мониторинга является очень затратной статьей расходов, которая далеко не всегда может, в конечном итоге, удовлетворить требованиям заказчика. Зачастую, потребность в мониторинге появляется у довольно прилично разросшейся инфраструктуры, и потом начинаются танцы с бубном в борьбе за рациональный бюджет и максимальную эффективность сбора данных.
Поэтому best practice является планирование и внедрение мониторинга на стадии проектирования и продажи её вместе с проектом.


NetFlow — проприетарный открытый протокол, разработанный Cisco для мониторинга трафика в сети. Netflow предоставляет возможность анализа сетевого трафика на уровне сеансов, делая запись о каждой транзакции TCP/IP.

Архитектура системы строится на сенсоре, коллекторе и анализаторе:

SCTP Stream Control Transmission Protocol

Прекрасная статья на wiki
http://ru.wikipedia.org/wiki/SCTP
На мой взгляд просто очень вкусный протокол

Несколько вкусностей сразу

Протокол SCTP защищен от DoS с помощью механизма четырёхэтапного квитирования (four-way handshake) и вводом маркера (cookie). По протоколу SCTP клиент начинает процедуру установления соединения посылкой пакета INIT. В ответ сервер посылает пакет INIT-ACK, который содержит маркер (уникальный ключ, идентифицирующий новое соединение). Затем клиент отвечает посылкой пакета COOKIE-ECHO, в котором содержится маркер, посланный сервером. Только после этого сервер выделяет свои ресурсы новому подключению и подтверждает это отправлением клиенту пакета COOKIE-ACK.

Рассмотрим отличия между процедурой закрытия сокетов протокола SCTP и процедурой частичного закрытия (half-close) протокола TCP.
В протоколе TCP возможна ситуация частичного закрытия соединения, когда один узел закончил передачу данных (выполнив посылку пакета FIN), но продолжает принимать данные по этому соединению. Другой узел может продолжать передавать данные до тех пор, пока сам не проведёт закрытие соединения на своей стороне. Состояние частичного закрытия используется приложениями крайне редко, поэтому разработчики протокола SCTP посчитали нужным заменить его последовательностью сообщений для разрыва существующей ассоциации. Когда узел закрывает свой сокет (посылает сообщение SHUTDOWN), оба корреспондента должны прекратить передачу данных, при этом разрешается лишь обмен пакетами, подтверждающими прием ранее отправленных данных.


Достоинства использования SCTP включают в себя:

• Использование множественных интерфейсов (англ Multihoming)
  Допустим, у нас есть два хоста. И хотя бы один из них имеет несколько сетевых интерфейсов, и соответственно несколько IP-адресов. В TCP, понятие «соединение» означает обмен данными между двумя точками, в то время, как в SCTP имеет место концепция «ассоциации» (англ. association), обозначащая всё происходящее между двумя хостами

• Многопоточность
  Данные приходят в точку по независимым потокам. Это позволяет устранить феномен en:Head-of-line blocking, которым так страдает TCP
• Поиск пути с мониторингом
  Протоколом выбирается первичный маршрут передачи данных, а также производится проверка и мониторинг связности пути.
• Механизмы валидации и проверки подлинности
  Защита адресата от flood-атак (технология 4-way handshake), и уведомление о потерянных пакетах и нарушенных цепочках.
• Улучшенная система контроля ошибок, подходящая для jumbo-пакетов в Ethernet.

Часть достоинств вытекает из того факта, что изначально разработчики SCTP проектировали протокол под нужды передачи телефонии (SS7) по протоколу IP.

Протокол TCP предоставляет основные средства для передачи данных по сети Internet по надежному пути. Однако TCP накладывает некоторые ограничения на транспорт данных:

• TCP предоставляет надежную передачу данных в строгой последовательности. Тем не менее одни приложения требуют передачу без управления и контроля последовательности, а другие будут вполне удовлетворены частичной упорядоченностью данных. Оба этих случая страдают из-за ненужных задержек, связанных с восстановлением и упорядочиванием нарушенных последовательностей TCP.
• Природа TCP ориентирована на поток байт, что вызывает неудобства. Приложения вынуждены самостоятельно добавлять собственные маркеры в пакеты, чтобы распараллелить передачу собственных сообщений, а также использовать дополнительные ухищрения, чтобы убедиться в том, что целое сообщение было доставлено за определенное время.
• Ограниченные рамки возможностей TCP-сокетов ещё более усложняют задачу предоставления возможности параллельной передачи информации к хостам по нескольким каналам связи (см. multi-homing выше).
• TCP относительно уязвим к атакам класса «Отказ в обслуживании» (DoS), таким как SYN-flood.

Все эти ограничения наносят ущерб производительности работы телефонных сетей через IP.