L2tp-соединение — что это такое? как настроить l2tp-соединение

BGP

BGP выполняет функцию signaling и auto-discovery. PE ищет какие PE вступили в тот же VPLS и отправляет им NLRI.

Передается NLRI, аналогичный BGP L2VPN:

• label base
• label range
• site-id
• offset

То есть для работы VPLS в настройках BGP включаем тот же самый l2vpn signaling.

Licruit — метки (на выход, вход). В отличие от L2VPN каждому локальному интерфейсу назначать метку нет смысла, ведь внутри VPLS уже есть соответствие mac — interface. Поэтому в VPLS метка должна была бы назначиться целиком на RI (per instance, per site).

Но эта логика не правильная. =(

Learnig mac-адресов! делает эту схему многоточкой! Блок меток соответствует удаленному site, чтобы когда пакет придет на РЕ понимать с какого site он пришел. Это требуется, чтобы сделать правильный learning.

В остальном весь остальной процесс signaling аналогичен L2VPN.

Site-ID в данной схеме принципиального значения не имеет. Требуется только для PE для внутренних вычислений, поэтому можно просто выбрать и назначить site-id, или задать auto-site-id.

LDP

Между PE требуется full-mesh.

В случае l2circuit указывали удаленный PE. В VPLS, помимо всего прочего, потребуется добавить всех remote-site-id.

Метки

Как и у L2VPN в NLRI передается:

• label base (начальная)
• site-ID
• label range

Исходя из полученных данных PE вычисляет свою метку для связи с тем PE, кот переслал блок:

label = label base (remote) + site-ID (local) - 1 (offset) (remote)

Инкапсуляция

Ниже описанное касается CE-facing интерфейс.

Для обычного Ethernet с vlan должна стоять: vlan-vpls. Она подходит как для qinq, так и для 802.1q.

Можно ставить ее как на логический интерфейс, так и на физический.

Если это не единственный тип инкапсуляции на физическом интерфейсе, то лучше на нем сразу указать тип инкапсуляции: flexible-ethernet-services.

Vlan

В рамках vrf VPLS можно определять vlan для VPLS путем конфигурирования vlan-id | vlan-tags

• vlan-id <vlan-id> — в VPLS будет работать только один указанный vlan-id
• vlan-id none — у приходящего пакета будет сниматься vlan-id tag. У исходящего навешиваться тот vlan-id tag, который указан на исходящем из VPLS интерфейсе.
• vlan-id all — используется с logical interface, на которых настроено двойное теггирование. При этом на выходе из VPLS outer-tag будет навешиваться (push), на входе в VPLS outer-tag будет сниматься (pop). В VPLS будут бегать маки с inner vlan-id.
• vlan-tags inner <> outer <> — позволяет работать VPLS с двумя тегами.

Со стороны клиента: влан на разных site должен совпадать. Иначе связности не будет.

+/-

VPLS +:

• удобнее в трабшутинге
• в отличие от L2VPN не требует указания remote-site
• обеспечивает схему коммутации точка-многоточка

VPLS — :

бродкаст домен => защита от петель между PECE

• STP на PE<>CE
• ERP на CE
• LAG на PE <> CE
• Active/backup links on PE
• Multihomed CE with two PEs.

может передавать только ethernet

Установка и настройка Routing and Remote Access Service (RRAS)

Установка службы

1. Откройте Server Manager, в меню Manage выберите «Add Roles and Features Wizard».
2. В разделе Server Roles отметьте «Remote Access» -> «Direct Access and VPN (RAS)»
3. Завершите установку.

Настройка службы

1. В Server Manager, в меню Tools выберите «Routing and Remote Access»
2. Правой кнопкой на имени сервера, далее «Configure and Enable Routing and Remote Access»

1. Выберите пункт «Custom Configuration»

1. Далее отметьте пункт «VPN».»

1. Завершите настройку.

Протокол подключения

RRAS предлагает несколько протоколов для VPN соединений: PPTP, L2TP/IPSec и SSTP:

• PPTP является устаревшим и небезопасным;
• L2TP/IPSec и IKEv2 безопасны, но используют нестандартные порты и ваши пользователи могут испытывать проблемы при подключении из домашних и публичных сетей;
• SSTP — безопасный протокол, который использует TCP порт 443 (TLS) и является наиболее удачным вариантом.

Для того, чтоб убрать ненужные протоколы, нажмите правой кнопкой на Ports и выберите Properties.
Далее нажмите Configure для каждого типа порта кроме SSTP и снимите все флажки.

Настройка аутентификации

Нажмите правой кнопкой на имени сервера, выберите Properties. Далее на вкладке «Security» в качестве Authentication Provider укажите «RADIUS Authentication» и нажмите «Configure».
В список RADIUS серверов добавьте новый сервер:

• Server name: IP адрес компонета MultiFactor Radius Adapter
• Shared Secret: общий секрет с компонентом
• Timout: 60 секунд
• Port: 1812
• Поставьте флажок «Always use message authenticator»

Сохраните и закройте.

Далее нажмите на кнопку «Authentication methods» и оставьте один вариант — «Unencrypted password (PAP)».

Сохраните и закройте.

Выбор сертификата сервера

Для шифрования трафика между клиентом и севером, а также аутентификации сервера, необходим сертификат, выданный публичным удостоверяющем центром сертификации. Вы можете купить такой сертификат или получить бесплатно в Let’s Encrypt. Как это сделать за 5 минут — читайте в нашей статье.

Выберите сертификат в разделе SSL Certificate Binding

Иерархия ключей и схемы их распределения

_SEAFСхема с пояснениями

Обозначения:CK (англ. Cipher Key)IK (англ. Integrity Key) — ключ, использующийся в механизмах защиты целостности данных.CK’ (англ. Cipher Key) — другой криптографический ключ, созданный из CK для механизма EAP-AKA.IK’ (англ. Integrity Key) — другой ключ, использующийся в механизмах защиты целостности данных для EAP-AKA.K_AUSF — создается функцией ARPF и оборудованием пользователя из CK и IK во время 5G AKA и EAP-AKA.K_SEAF — якорный ключ, получаемый функцией AUSF из ключа K_AMFAUSF.K_AMF — ключ, получаемый функцией SEAF из ключа K_SEAF.K_NASint, K_NASenc — ключи, получаемые функцией AMF из ключа K_AMF для защиты сигнального трафика NAS.K_RRCint, K_RRCenc — ключи, получаемые функцией AMF из ключа K_AMF для защиты сигнального трафика RRC.K_UPint, K_UPenc — ключи, получаемые функцией AMF из ключа K_AMF для защиты сигнального трафика AS.NH — промежуточный ключ, получаемый функцией AMF из ключа K_AMF для обеспечения безопасности данных при хэндоверах.K_gNB — ключ, получаемый функцией AMF из ключа K_AMF для обеспечения безопасности механизмов мобильности.

Схемы выработки SUCI из SUPI и наоборот

Аутентификация

Взаимная аутентификация

CK’IK’CKIKRANDAUTNXRES*CK’IK’K_AUSFCKIK5G HE AVK_AUSFK_SEAFK_AUSFK_AMFK_SEAF

Вторичная аутентификация

• Происходит обязательная первичная аутентификация пользователя в домашней сети и вырабатывает общий с AMF контекст безопасности NAS.
• Пользователь посылает в AMF запрос на установление сессии.
• AMF посылает запрос на установление сессии в SMF с указанием SUPI пользователя.
• SMF проверяет учетные данные пользователя в UDM с использованием предоставленного SUPI.
• SMF посылает ответ на запрос от AMF.
• SMF запускает процедуру аутентификации EAP с целью получить разрешение на установление сессии от AAA-сервера внешней сети. Для этого SMF и пользователь обмениваются сообщениями с целью инициировать процедуру.
• Пользователь и AAA-сервер внешней сети далее обмениваются сообщениями, чтобы провести аутентификацию и авторизацию пользователя. При этом пользователь отсылает сообщения в SMF, который в свою очередь обменивается сообщениями с внешней сетью через UPF.

Взаимодействие между VPN

R2D2

Linkmeup_R3

R2D2TARS_2R2D2Полная конфигурация всех узлов для сценария взаимодействия между VPN.

Трассировка в MPLS L3VPN

стыд вам«time exceeded in transit»В чём же особенность трассировки через L3VPN?

1. Скопировать значение TTL из заголовка IP в MPLS (Это режим ).
2. Записать в поле TTL заголовка MPLS 255 (Это режим или ).

1. На первом шаге ничего не меняется. TARS_1 отправляет ICMP-запрос с TTL=1. R1 его получает, уменьшает TTL до нуля и отправляет на TARS_1 «time exceeded in transit». Первый хоп (R1) готов.
2. TARS_1 отправляет ICMP-запрос с TTL=2.
3. TARS_1 отправляет ICMP-запрос с TTL=3. Он доходит до R3, который видит значение MPLS TTL, равное в данный момент 1, уменьшает его до 0 и возвращает «time exceeded in transit»
4. TARS_1 отправляет ICMP-запрос с TTL=4. R3 уменьшает MPLS TTL до 1, снимает метку, копирует значение MPLS TTL в IP TTL. А дальше пакет благополучно доходит до TARS_2, тот отправляет ответ об успешном завершении. Трассировка закончена.

1. TARS_1 отправляет ICMP-запрос с TTL=1. R1 его получает, уменьшает TTL до нуля и отправляет на TARS_1 «time exceeded in transit». Первый хоп (R1) готов.
2. TARS_1 отправляет ICMP-запрос с TTL=2.
3. TARS_1 отправляет ICMP-запрос с TTL=3. Он благополучно доходит до TARS_2, тот отправляет успешный ответ. Трассировка закончена.

nano.orgособенные утилиы пинга и трассировки

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

Ладно, я лукавлю: не все, а лишь большинствоPart IPart IIRoute Distinguishers and Route TargetsLinkmeup_R2радостиАнастасия МецлерJDima

MPLS L3VPN

C3PO_1:

C3PO_2:

C3PO_2Что же касается сети провайдера.

• Настройка базовой связности магистральной сети: IP-адреса, IGP.
• Включение MPLS и LDP
• Создание VRF и привязка к интерфейсам.
• Настройка протокола маршрутизации с CE.
• Настройка BGP и MBGP

1)Linkmeup_R1:

Linkmeup_R2:

Linkmeup_R3:

Файл начальной конфигурации.2)Linkmeup_R1:

Linkmeup_R2:

Linkmeup_R3:

3)Linkmeup_R1:

Linkmeup_R2:

Linkmeup_R3:

*Пример выделения меток на Linkmeup_R1.4)Linkmeup_R1Linkmeup_R3Linkmeup_R1:

Linkmeup_R3:

both5)Linkmeup_R1:

Linkmeup_R3:

6)Linkmeup_R1:

Linkmeup_R3:

Linkmeup_R1Linkmeup_R37)Linkmeup_R2Первая частьLinkmeup_R1:

Linkmeup_R3:

Вторая частьLinkmeup_R1Linkmeup_R3Linkmeup_R1:

Linkmeup_R3:

Третья частьLinkmeup_R1:

Linkmeup_R3:

Linkmeup_R1:

Linkmeup_R3:

Подключение клиента по BGP

6)TARS_1:

Linkmeup_R1:

Linkmeup_R1TARS_17)с комментариямибезЧто же мы натворили?Linkmeup_R1Linkmeup_R3

1. Настроить IP-адреса провайдера: линковые и лупбэк. Все узлы, настроил и забыл.
2. Настроить IGP в сети провайдера, чтобы обеспечить внутреннюю связность. Все узлы, настроил и забыл.
3. Настроить MPLS + LDP (или RSVP TE, если необходимо). Все узлы, настроил и забыл.
4. Настроить MBGP внутри сети провайдера. Только те PE, где есть клиенты, настроил и забыл.
5. Настроить клиентские VRF, назначить RD, RT. Только те PE, где есть клиенты, настраиватся персонально для каждого.
6. Добавить в VRF клиентские интерфейсы, настроить на них IP-адреса. Только те PE, где есть клиенты, настраиватся персонально для каждого.
7. При необходимости поднять IGP/BGP с клиентом для обмена маршрутами. Только те PE, где есть клиенты, настраиватся персонально для каждого.
8. Готово

MP-BGP (Multi Protocol BGP)

We will use BGP between the PE routers so that they can share information from the VRFs. Here’s how it works:

• One of the CE routers advertises something to the PE router, this can be done through OSPF, EIGRP, BGP or any other routing protocol (static routing is also possible).
• The PE router uses a VRF for the customer so it will store everything it learns in the routing table of the customer’s VRF.
• The PE router will then redistribute everything in BGP.
• The PE router will advertise to to the other PE router through iBGP.

There’s a couple of problems though. First of all, our two customers are using overlapping address space. Let’s say that our PE1 router is advertising 192.168.1.0 /24 from customer A to the PE2 router on the other side. Here’s what happens:

The PE2 router will learn 192.168.1.0 /24 from the PE1 router but it has no clue to what customer it will belong. There is no way to differentiate if something belongs to customer A or B.

What we need is something to make all prefixes that we learn unique.

RD (Route Distinguisher)

To fix this issue, we will use a RD (Route Distinguisher). We will add something to the prefix of the customer so that it will become unique:

The RD is a 8 byte (64 bit) field. You can use any value you want but typically we use the ASN:NN format where ASN is the service provider’s AS number and NN is a number we pick that identifies the site of the customer.

The RD and the prefix combined is what we call a VPNv4 route. We now have a method to differentiate between the different prefixes of our customers. Here’s an example:

Let’s say that we use RD 123:10 for customer A and RD 123:20 for customer B. By adding these values, we have unique VPNv4 routes.

How do we advertise these VPNv4 routes? That’s what we need MP-BGP for.

MP-BGP supports IPv4 unicast/multicast, IPv6 unicast/multicast and it has support for VPNv4 routes. To exchange VPNv4 routes, MP-BGP uses a new NLRI (Network Layer Reachability Information) format that has the following attributes:

• RD (Route Distinguisher)
• IPv4 prefix
• Next Hop
• VPN Label

This is how PE routers exchange VPNv4 routes with each other. This NRL also has an attribute called the VPN label, we’ll get back to this one later in this lesson.

RT (Route Target)

When a PE router learns these VPNv4 routes, what will it do with it? Take a look at the picture below:

Our PE2 router has learned the two VPNv4 routes, one for each customer. You might think that the PE2 router will automatically export each VPNv4 route in the correct customer VRF but that’s not going to happen.

Настройка сервера PPPoE на Микротик

Нам необходимо создать адресное пространство (IP пул). Подключимся к NetworkCore и перейдем в IP – Pool.

Создадим новый. Задаем понятное название и диапазон адресов.

Сохраняем и переходим к следующему пункту.

Создание профиля

Переходим к созданию профиля. Открываем PPP – Profiles.

• Задаем понятное имя профиля;
• Local Address – 172.16.25.1;
• Remote Address – ранее созданный пул;
• DNS – в качестве примера 8.8.8.8;
• Change TCP MSS – yes;
• Use UPnP – no.

Переходим в Protocols.

• Use MPLS – no;
• Use Compression – no;
• Use Encryption – yes.

Открываем Limits.

Only One – no.

Сохраняем и идем далее.

Создание пользователей

Т.к. PPPoE требует аутентификацию по логину и паролю, нам необходимо создать два пользователя, по одному для каждого офиса. Последовательно открываем PPP – Secrets.

• Name – учетная запись, регистр имеет значение;
• Password – пароль;
• Service – можно выбрать any, но я предпочитаю указывать конкретные сервисы;
• Profile – раннее созданный профиль.

По аналогии создаем пользователя для офиса SPB.

Включение сервера

Для ограничения широковещательного трафика я не стал создавать bridge и добавлять в него порты, связанные с офисами. Так же я создал одну сеть, что не рекомендуется для production сети. Сервер настраивается в PPP – PPPoE Servers. Создадим первый, подключенный к московскому офису.

Задаем параметры:

• Service Name — указываем уникальное имя сервиса;
• Interface – ether2 для офиса в Москве;
• Default profile – раннее созданный профиль;
• One Session Peer Host – ставим галочку;
• Authentication – оставляем только MSCHAPv1 и MSCHAPv2.

Есть возможность указать задержку ответа в параметре PAD0 Delay. Данный параметр будет полезен для сценариев с несколькими серверами. Его мы не изменяем.

Сохраняем и создаем еще один, но только указываем другое имя сервиса и порт ether3 в параметре interface.

Настройка клиента PPoE на Микротик

Необходимо настроить таким образом, чтобы был доступ в интернет. На московском роутере я покажу как это сделать. Для начала проверим что на нем нет никаких IP адресов и маршрутов.

Далее переходим в PPP – Interface и добавляем новый.

В создании интерфейса на вкладке General зададим:

• Name – понятное название интерфейса;
• Interface – тот интерфейс, который подключен к провайдеру, в нашем случае ether1.

Предлагаю воспользоваться утилитой PPPoE Scan – она позволяет без подключения и аутентификации просканировать эфир на наличие каких-либо серверов. Особенно полезная штука для поиска неисправностей доступности крупнейшего провайдера нашей страны. После нажатия кнопки Start утилита начинает сканирование. На скриншоте ниже, виден наш сервер с заданным именем сервиса и AC Name – он берется из Identity в меню System. При желании можно сменить.

Закрываем утилиту и переходим во вкладку Dial Out.

• Service – for-MSC (можно не указывать);
• AC Name – NetworkCore (можно не указывать);
• User – MSC – обязательный параметр;
• Password – обязательный параметр;
• Use Peer DNS – ставим галочку;
• Allow – снимаем галочки с chap и pap.

Add Default Route нужен для автоматического добавления маршрута 0.0.0.0/0 в нашу таблицу маршрутизации. Данная запись обеспечит выход в интернет

Обращаю внимание, что она устанавливается на клиентской стороне. Сохраняем и проверяем на вкладке Status

Мы видим внизу статус – connected, что символизирует об успешном подключении. Исходя из скриншота выше можно сказать, что, последний раз соединение поднялось 05.02.2020 в 19:51, время жизни 44 секунды, получили адрес 172.16.25.20, Service Name — for-MSC, AC Name — NetworkCore. Попробуем проверить доступность интернета.

Отправив ping запрос по доменному имени, мы убедились, что имя преобразуется – это означает что DNS сервер добавился без проблем и получаем ответы на запросы — работает интернет-соединение. Не ленимся и перепроверим в соответствующих консолях.

Проделаем аналогичные действия на Mikrotik в Питере и посмотрим, что происходит на главном роутере NetworkCore.

Как мы видим, на интерфейсах ether2 и ether3 появились дополнительные соединения. Далее мы можем из этих интерфейсов сделать статические адрес листы и в зависимости от ситуации, разрешать или запрещать определенный трафик. В данном примере я продемонстрировал как с помощью PPPoE на роутере Mikrotik разрешить доступ в интернет, вы же можете предоставлять с его помощью доступ к иным службам или сетям

Спасибо за внимание

Принципы работы технологии MPLS

В зависимости от этапа трансляции данных маршрутизаторы в системе MPLS могут реализовывать различные функции коммутации и управления пакетами.

Как было отмечено выше, MPLS работает только в P Network, в то время как C Network работает как обычная IP-сеть. Технология MPLS начинает действовать с того момента, как IP-пакет попадает в клиентские сети.

Граничные маршрутизаторы выполняют функции назначения и удаления меток. Так, например, на рис. 3 входной граничный маршрутизатор LER1 вставляет метку в пакет, поступивший из внешней сети, между заголовком IP и заголовком уровня 2. Кроме того, LER1 устанавливает класс эквивалентности пересылки пакета (Forwarding Equivalency Class, FEC), определяющий пакеты, пересылаемые одинаково. Маршрут, проходящий через один или более LSR, по которому следуют пакеты одного и того же класса FEC, называется скоммутированным по меткам маршрутом LSP. Этот путь определяется полным набором меток во внутренних маршрутизаторах (LSR1–LSR6), через которые передается пакет в домене MPLS. В технологии MPLS также используется понятие LSP-tunnel, под которым подразумевается последовательность маршрутизаторов, в которой первый маршрутизатор является входным, а последний — выходным пунктом некоего виртуального туннеля.

Внутренние маршрутизаторы LSR пересылают пакет с меткой от одного узла к другому. При этом метка заменяется в зависимости от задачи.

Информация о маршруте пакета передается на все подключенные PER с использованием любого протокола, поддерживаемого системой протокола. Такой процесс часто называют термином PER–CER при описании сетей MPLS VPN. Информация о клиенте сохраняется в исполнительной копии программы в виде виртуальной маршрутизации вместо стандартной таблицы маршрутов. Данная процедура обозначается как Virtual Routing & Forwarding (VRF).

Каждому клиенту присваиваются свои собственные уникальные метки-ярлыки. При этом разграничители маршрутов (Route Distinguishers, RD) позволяют выделить нужный сайт клиента среди всех остальных, доступных данному РЕR. Обмен информацией с целевым устройством реализуется с помощью протоколов IGP (Interior Gateway Protocols), в качестве которых могут быть использованы OSPF, RIP, EIGRP и др.

В большинстве случаев замена меток осуществляется с помощью LDP (Label Distribution Protocol). Однако необходимо иметь в виду, что в случае использования MPLS/BGP VPN применяется многофункциональный протокол BGP (MP–BGP).

Для дополнительной протокольной сигнализации и трафик-инжиниринга в сетях MPLS, как правило, применяется протокол резервирования сетевых ресурсов (Resource ReSerVation Protocol, RSVP).

Следует упомянуть режим работы маршрутизаторов MPLS, связанный с созданием таблицы пересылки (Label Information Base, LIB), которая содержит входную метку и дополнительные вложенные записи. Вложенная запись может нести информацию о назначенной выходной метке, номере выходного интерфейса и адресе следующего внутреннего маршрутизатора LSR.

Выходной граничный маршрутизатор LER2 (рис. 3) снимает метку и направляет пакет во внешнюю сеть .

Рис. 3. Пример простой сети MPLS

Функции контроля, управления и пересылки данных технологии MPLS схематически показаны на рис. 4.

Рис. 4. Уровни управления и пересылки данных технологии MPLS

Архитектура MPLS имеет двухуровневую структуру — уровень управления (Control Plane) и уровень пересылки данных (Data Plane). В процессе пересылки пакета по сети MPLS от одного узла к другому метки могут меняться. При этом роутеры на каждом этапе обмениваются соответствующей информацией и выполняют определенные функции.

Сеть MPLS может конфигурироваться с помощью специальных программных средств.

Сразу после появления IP-пакета в сети MPLS ему присваивается метка, которая вставляется между заголовком канального уровня и заголовком IP.

Если сеть имеет несколько транзитных узлов, то при попадании данных в сеть MPLS первый граничный маршрутизатор присваивает IP-пакету свою метку. Затем этот пакет направляется к заданному узлу, и каждый следующий маршрутизатор меняет одну метку на метку другого узла. После выхода из сети MPLS метка снимается и дальше транслируется непосредственно IP-пакет, в том неискаженном виде, каким он был на входе в эту сеть. При этом IP-пакеты могут направляться как в сети пользователя, так и в другие магистральные сети с поддержкой MPLS.

Как видно из рассмотрения рис. 4, последовательность выполнения конкретной операции для определенного маршрутизатора определяется отрабатываемыми на данный момент времени управляющими командами.

PAP против CHAP

PAP в основном работает как нормальная процедура входа в систему. Клиент
опознает себя, посылая имя пользователя и пароль серверу, который сравнивает
их с базой данных. Этот метод легко уязвим для посторонних наблюдателей,
которые могут попытаться получить пароль, слушая последовательную линию.

CHAP не имеет этих недостатков. С CHAP аутенфикатор (сервер) посылает
беспорядочно сгенерированную «challenge»-строку клиенту, наряду с именем
хоста. Клиент использует имя хоста (hostname) для того, чтобы искать
соответствующий шифр, объединяет его с challenge и шифрует строку, используя
однонаправленную hash-функцию. Результат будет возвращен на сервер наряду с
hostname клиента. Сервер теперь выполняет те же самые вычисления и
опознает клиента.

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

Пакет pppd хранит секретные ключи для CHAP и PAP в
двух отдельных файлах, называемых соответственно
/etc/ppp/pap-secrets и
/etc/ppp/chap-secrets. Записывая удаленный хост в
один или другой файл, Вы имеете хороший контроль над CHAP или PAP.

По умолчанию pppd не требует установления
подлинности удаленной машины, но соглашается опознавать себя, когда она
запросит опознание. Так как CHAP намного более совершенен, чем PAP,
pppd пробует использовать его всякий раз, когда это
возможно. Если удаленная машина этого не поддерживает, или если
pppd не может найти CHAP-шифр для удаленной системы в
файле chap-secrets, он возвращается к PAP. Если он
не имеет также и PAP-шифра, то связь закроется.

Это поведение может быть изменено. Например, когда дается ключевое слово
auth, pppd требует, чтобы
другой конец линии опознал сам себя. pppd согласится
использовать CHAP или PAP для этого, как только будет имеет соответствующий
шифр в базе данных CHAP или PAP соответственно. Имеются другие опции, чтобы
включить или выключить частный опознавательный протокол, но я не буду
описывать их здесь.

Если все системы, с которыми Вы работаете по PPP соглашаются опознавать
самих себя, Вы должны поместить опцию auth в
глобальный файл /etc/ppp/options и определить
пароли для каждой системы в файле chap-secrets.
Если система не поддерживает CHAP, добавьте запись к файлу
pap-secrets. Таким образом, Вы можете
удостовериться в том, что никакая неопознанная система не соединяется с
Вашим хостом.

VRF (Virtual Routing and Forwarding)

Let’s start with VRFs. This is the first step in separating traffic from different customers. Instead of using a single global routing table, we use multiple routing tables. Each customer of the service provider will use a different VRF. Let’s take a closer look:

Above we have our PE1 router with the two customer sites. Each customer will use a different VRF so the overlapping address space is no problem. Now you might be wondering, why don’t we use VRFs everywhere instead of MPLS? We could but there’s one downside to using VRFs. Take a look at the following picture:

The problem with VRFs is that you have to create them everywhere. When our goal is to have connectivity between CE1 and CE3 then we will have to add a VRF on the PE1, P and PE2 router. Also, all the service provider routes will have to participate with routing. For example, when customer A wants to run OSPF between their two sites then it means that we have to configure OSPF on the PE1, P and PE2 router of the service provider for their VRF.

When customer B wants to run EIGRP between their sites, we have to participate…we’ll have to configure EIGRP on all service provider routers for the VRF of customer B.

This is not a scalable solution so it’s not going to happen. Instead, we will configure the VRFs only on the PE routers. The core of the service provider network (P router) will only do switching based on labels.

To share information about VRFs between PE routers, we will use BGP.