Статья предполагает, что у читателя уже есть понимание основ MPLS L3VPN.

Привет. Допустим, вы — ISP. И как у любого достаточно крупного ISP, ядро вашей сети построено на базе IP/MPLS. Если совсем уж упрощать, то вашу сеть можно представить схемой, изображенной выше. Давайте также допустим, что вы, как ISP, продаете своим клиентам услугу L3VPN, которая на вашей сети реализуется в соответствии с RFC 4364 (BGP/MPLS IP VPNs). И в том случае, если клиенту L3VPN на некотором сайте недостаточно directly connected сети, и он хочет анонсировать другим сайтам дополнительные маршруты, то вы поднимаете между вашим оборудованием (PE) и оборудованием клиента (CE) BGP-сессию, посредством которой клиент может анонсировать желаемые маршруты. При всем этом какие-либо фильтры/политики вы к данной сессии не применяете, руководствуясь тем, что это, дескать, VPN клиента, и он волен в нем «гонять» все, что захочет (в пределах лимита по числу префиксов, например). А теперь внимание, вопрос: что произойдет, если в рамках этой BGP-сессии клиент будет анонсировать вам (провайдеру) маршруты, добавляя к ним Route Target Community? Это может быть, к примеру, результатом ошибки, либо желанием поэкспериментировать.

Привет. Это короткая заметка про то, какие именно IP мы видим в любимом tracert/traceroute, и как это зависит от лейбла на коробках в аппаратных вашего ISP и его апстримов.

Думаю, все знают, что у маршрутизатора, как правило, множество IP-адресов (ну или хотя бы точно больше, чем 1). В условиях такого многообразия перед маршрутизатором ставится нелегкий выбор: какой именно из его IP-адресов необходимо выбрать в качестве источника сообщения ICMP TTL Exceeded, которое и является основой для вывода трассировки?

Если вы никогда ранее не задумывались над данным вопросом, то вот некоторые варианты, которые могут прийти в голову в первую очередь:

1. IP-адрес интерфейса, который являлся входящим для оригинального пакета.
2. IP-адрес интерфейса, который должен был бы являться исходящим для оригинального пакета.
3. IP-адрес интерфейса, который будет являться исходящим для ICMP-сообщения.
4. IP-адрес лупбэка.

Если вы все же задумывались об этом ранее, то не спешите давать однозначный ответ :)

Ранее я много раз слышал, что UPnP каким-то образом умеет самостоятельно открывать порты (производить Port Forwarding на роутере) по запросу от хоста из локальной сети. Однако, то, каким именно образом это происходит, и какие протоколы для этого используются, доселе было покрыто для меня пеленой тумана.

В данной статье я хочу кратко рассказать, как работают два механизма для проброса портов, а именно NAT Port Mapping Protocol и Internet Gateway Device (IGD) Protocol, входящий в набор протоколов UPnP. К своему удивлению я обнаружил, что в рунете информация по данному вопросу более чем скудна, что и сподвигло меня на написание данной заметки.

Для начала приведу краткий FAQ:

Q: Для чего нужны данные протоколы?
A: Для формирования на маршрутизаторе правила проброса определенного TCP/UDP порта (Port Forwarding) не вручную, а «автоматически», т.е. по запросу от хоста во внутренней сети.

Q: Как это реализуется?
A: Устройство за NAT отправляет маршрутизатору запрос с указанием внутреннего и внешнего номеров портов и типа протокола (TCP/UDP). Если указанный внешний порт свободен, маршрутизатор формирует у себя правило трансляции и рапортует запросившему компьютеру об успешном выполнении запроса.

Q: Проводится ли на маршрутизаторе аутентификация/авторизация запросов на открытие порта?
A: Нет, не проводится.

Теперь же рассмотрим работу данных протоколов более подробно (под катом).