Часть 1.
Введение. Преимущества LISP протокола. Роли устройств в LISP архитектуре.
Введение.
Что такое LISP ?
LISP (Locator/ID Separation Protocol) — это новая сетевая технология, которая привносит новую семантику в текущую IP адресацию. Архитектура LISP cоздает два пространства имен и использует для этого два раздельных IP адреса в отличии от того, что существует в настоящем времени (одно адресное пространство):
EID (Endpoint Identifiers) – это IP адреса, которые присваиваются конечным хостам и RLOC ( Routing Locators) IP адреса, которые присваиваются главным образом машрутизаторам, а если быть точным, их внешним интерфейсам, смотрящим в global routing table.
По сути , RLOC – это адресное пространство, которое существует сегодня на сети в глобальной таблице маршрутизации, а EID – это новое адресное пространство, которое привносит LISP. Адреса из EID адресного пространства напрямую не объявляются в глобальную таблицу, то есть не видны в RLOC пространстве.
Преимущества LISP протокола.
Основные преимущества использования LISP протокола, которые я бы хотел выделить :
- Support multi-homed routing (Ingress traffic engineering without BGP) – Поддержка мультихоминга с регулированием входящего трафика без использования BGP протокола.
- Support data center virtual machine mobility – Поддержка мобильности виртуальных машин между дата-центрами.
- Support IPv6 transition functionality — Поддержка плавного перехода на IPv6 протокол.
- Support Large scale segmentation (Multi-Tenancy and VPNs) – Поддержка виртуализации сайтов с помощью связывания LISP instance-id в EID VRF.
Эти преимущества более нагляднее отображены на рисунке:
Наиболее важным компонентом архитектуры LISP является – LISP mapping database system (связующая база данных).
LISP mapping system – это база данных, которая отслеживает (tracking) связь между префиксами RLOC и EID. В частности, когда один из LISP сайтов не имеет знаний (отсутствует запись в кэше) о новом EID префиксе определенного LISP сайта и хочет послать данные на этот EID префикс другого LISP сайта, он будет запрашивать именно ее.
Как я писал выше, EID адреса не объявляются в RLOC пространство, но они объявляются непосредственно в связующую базу данных LISP (mapping database system), путем инкапсуляции пакетов полученных от хостов в EID пространстве на роутере.
Роли устройств в LISP архитектуре.
Настало время вкратце поговорить о ролях, которые существуют в LISP архитектуре.
ITR – Ingress Tunnel Router (Входящий туннельный роутер)
Это роутер, как правило, CE-роутер (машрутизатор на стороне клиента), который принимает пакеты из EID адресного пространства , где находятся хосты, инкапсулирует их и посылает в RLOC адресное пространство как LISP пакет.
ETR — Egress Tunnel Router
Как правило, это также СE-роутер (машрутизатор на стороне клиента) , который получает инкапсулированный LISP пакет приходящий из RLOC адресного пространства, декапсулирует пакет и посылает его в EID адресное пространство.
xTR — Это роутер, который совмещает в себе две функции и может быть как ETR , так и ITR роутером одновременно.
PxTR — РxTR (Proxy xITR) роутеры, которые позволяют LISP и non-LISP сайтам общаться между собою. Также у PxTR роутеров есть свои роли – PITR и PETR , которые, мы рассмотрим немного позднее.
MS – Map Server
Он является компонентом LISP mapping database system (связующей базы данных LISP). LISP ETR роутеры регистрируют свои EID префиксы на MS, для которых он является авторитативным. MS строит отдельную LISP политику для каждого из LISP сайтов.
MR – Map Resolver
Это другой компонент mapping database system, который получает Map-Requests сообщения от ITR роутеров о EID-to-RLOC mappings.
Как правило, роли MS/MR могут быть совмещены на одном устройстве, без необходимости их разделения на отдельных устройствах. Надо сказать, что LISP mapping database system напоминает нам известную распределенную систему DNS, где DNS сервера преобразуют URL адреса в IP адреса, в то время как LISP mapping database system преобразуют (резолвят) RLOC адреса для запрошенных EID префиксов.
Часть 2.
Практика.
А теперь перейдем к наиболее интересной и практической части нашей темы, для этого нарисуем простую топологию и настроим простейший роутинг на каждом из роутеров данной схемы, а также заведем соответствующие loopbacks адреса на роутерах R2 и R4:
Настройка роутера R2:
hostname R2
aaa new-model
!
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface FastEthernet1/0
description To Core
ip address 10.0.0.2 255.255.255.252
duplex auto
speed auto
!
ip forward-protocol nd
no ip http server
no ip http secure-server
ip route 0.0.0.0 0.0.0.0 10.0.0.1
Core Router:
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface FastEthernet1/0
description to R2
ip address 10.0.0.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet1/1
description to R4
ip address 10.0.0.5 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
description to R5
ip address 10.0.0.9 255.255.255.252
duplex auto
speed auto
!
ip forward-protocol nd
Настройка роутера R4:
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 192.168.2.1 255.255.255.0
!
interface FastEthernet1/0
description to Core
ip address 10.0.0.6 255.255.255.252
duplex auto
speed auto
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.0.0.5
Настройка роутера R5:
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface FastEthernet1/0
description to Core
ip address 10.0.0.10 255.255.255.252
duplex auto
speed auto
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip route 0.0.0.0 0.0.0.0 10.0.0.9
Проверим доступность наших роутеров, используя для этого команду ping на соответствующий линковый адрес нужного роутера.
R2#ping 10.0.0.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/65/88 ms
R4#ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/158/296 ms
R2#ping 10.0.0.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/76/100 ms
Как видно из результатов, все работает хорошо и все наши линковые адреса доступны по базовому роутингу , используя простейший static default route.
А теперь, проверим доступность наших loopbacks адресов, используя команду ping с роутера R2 до loopback интерфейса на роутере R4 и наоборот.
R2#ping 192.168.2.1 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1 …..
Success rate is 0 percent (0/5)
R4#ping 192.168.1.1 source 192.168.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1 …..
Success rate is 0 percent (0/5)
Видим, что не работает. И это правильно, ведь c точки зрения маршрутизации им ничего неизвестно о соседних loopbacks, нет IGP, который бы рассказал бы о них соседу.
Настало время настроить LISP протокол на соответствующих роутерах.
Назначим роли нашим роутерам: Назовем роутер R2 — LISP1-site, R4 роутер — LISP2-site, R5 — будет исполнять роль map servera и map resolvera одновременно.
Настроим map server (R5):
hostname mapserver
router lisp
site LISP1
description Site LISP1
authentication-key LISP1
eid-prefix 192.168.1.0/24
exit
!
site LISP2
description LISP2
authentication-key LISP2
eid-prefix 192.168.2.0/24
exit
!
ipv4 map-server
ipv4 map-resolver
exit
Здесь мы объявляем, что роутер одновременно выступает в качестве map-server так и map-resolver, а также настраиваем site конфигурацию, показывая, какие сайты могут подсоединяться к данному map-serverу, настраивая соответствующую аутентификацию для каждого из сайтов.
Выполним команду : show lisp site , чтобы посмотреть какие сайты зарегистрированы на нем.
mapserver#show lisp site
LISP Site Registration Information
Site Name Last Up Who Last Inst EID Prefix
Register Registered ID
LISP1 never no — 192.168.1.0/24
LISP2 never no — 192.168.2.0/24
Здесь видно, что наш map-server знает о двух сайтах из своей конфигурации, но они пока на нем не зарегистрированы.. Исправим это, настроив последовательно каждый из LISP сайтов.
Роутер R2 (LISP1):
conf t
router lisp
database-mapping 192.168.1.0/24 10.0.0.2 priority 100 weight 100
ipv4 itr map-resolver 10.0.0.10
ipv4 itr
ipv4 etr map-server 10.0.0.10 key LISP1
ipv4 etr
exit
Команда database-mapping описывает EID префикс — 192.168.1.0/24, который известен R2 роутеру выступающего в роли ITR, а также IP адрес (RLOC) внешнего интерфейса, который находится на нем же. Команды priority and weight дают нам возможность гибко настраивать трафик инжиниринг для соответcтвующих префиксов.
Команда ipv4 itr map-resolver 10.0.0.10 говорит нам, какой map-resolver сервер будет использовать наш ITR роутер.
Команда ipv4 etr map-server 10.0.0.10 key LISP1 говорит нам , что наш роутер также является ETR роутером, который должен знать адрес map-serverа, при этом настраивается аутентификация между ним и ETR роутером , говоря , что только подходящий ETR роутер может регистрироваться на map-server.
Настройка R4 (LISP2) выглядит аналогично:
router lisp
database-mapping 192.168.2.0/24 10.0.0.6 priority 100 weight 100
ipv4 itr map-resolver 10.0.0.10
ipv4 itr
ipv4 etr map-server 10.0.0.10 key LISP2
ipv4 etr
exit
Регистрация EID префиксов на нашем map serverе будет выглядеть следующим образом:
Для первого сайта LISP1:
*Jun 10 11:55:27.883: LISP: Processing received Map-Register message from 10.0.0.2 to 10.0.0.10
*Jun 10 11:55:27.895: LISP: Processing Map-Register no proxy, map-notify, no merge, no security, no mobile-node, not to-RTR, ID-included, 1 record, nonce 0xA5632EE5-0xF3ECFBB8, key-id 1, auth-data-len 20, hash-function sha1, xTR-ID 0x17F0F62C-0x86DB84D3-0xA0D6DADD-0x4B5C3D65, site-ID unspecified
*Jun 10 11:55:27.899: LISP: Processing Map-Register mapping record for IID 0 192.168.1.0/24, ttl 1440, action none, authoritative, 1 locator 10.0.0.2 pri/wei=100/100 LpR
*Jun 10 11:55:27.899: LISP-0: MS registration IID 0 prefix 192.168.1.0/24 10.0.0.2 site LISP1, Created.
*Jun 10 11:55:27.903: LISP-0: MS registration IID 0 prefix 192.168.1.0/24 10.0.0.2 site LISP1, Adding locator 10.0.0.2.
*Jun 10 11:55:27.903: LISP-0: MS EID IID 0 prefix 192.168.1.0/24 site LISP1, Map-Notify, to registering ETRs due to changed registration.
*Jun 10 11:55:27.903: LISP-0: Map-Notify IID 0 prefix 192.168.1.0/24 to 10.0.0.2, scheduled with nonce 0xA5632EE5-0xF3ECFBB8.
*Jun 10 11:55:27.903: LISP-0: AF IPv4, Control packet parsing, Map-Register message has trailing data (24).
*Jun 10 11:55:27.903: LISP-0: MS EID IID 0 prefix 192.168.1.0/24 site LISP1, ALT route update/create.
*Jun 10 11:55:27.903: LISP-0: ALTroute IID 0 prefix 192.168.1.0/24 <-> created.
*Jun 10 11:55:27.903: LISP-0: ALTroute IID 0 prefix 192.168.1.0/24 <-> add source MS-EID.
*Jun 10 11:55:27.907: LISP: Executing work item Net_tx:_0_v4_MS_Map-Notify[normal]
*Jun 10 11:55:27.907: LISP-0: Map-Notify to 10.0.0.2, sending with 1 prefix, nonce 0xA5632EE5-0xF3ECFBB8.
*Jun 10 11:55:27.915: LISP-0: ALTroute IID 0 prefix 192.168.1.0/24 <MS-EID> RIB route ignore create, nline con 0
Для второго сайта LISP2:
*Jun 10 13:43:04.583: LISP: Processing received Map-Register message from 10.0.0.6 to 10.0.0.10
*Jun 10 13:43:04.595: LISP: Processing Map-Register no proxy, map-notify, no merge, no security, no mobile-node, not to-RTR, ID-included, 1 record, nonce 0x3261E29E-0xC8EC5DB1, key-id 1, auth-data-len 20, hash-function sha1, xTR-ID 0xD9BC96C8-0x654B5025-0x7B4A0371-0x9FC081F3, site-ID unspecified
*Jun 10 13:43:04.599: LISP: Processing Map-Register mapping record for IID 0 192.168.2.0/24, ttl 1440, action none, authoritative, 1 locator 10.0.0.6 pri/wei=100/100 LpR
*Jun 10 13:43:04.599: LISP-0: MS registration IID 0 prefix 192.168.2.0/24 10.0.0.6 site LISP2, Created.
*Jun 10 13:43:04.599: LISP-0: MS registration IID 0 prefix 192.168.2.0/24 10.0.0.6 site LISP2, Adding locator 10.0.0.6.
*Jun 10 13:43:04.599: LISP-0: MS EID IID 0 prefix 192.168.2.0/24 site LISP2, Map-Notify, to registering ETRs due to changed registration.
*Jun 10 13:43:04.599: LISP-0: Map-Notify IID 0 prefix 192.168.2.0/24 to 10.0.0.6, scheduled with nonce 0x3261E29E-0xC8EC5DB1.
*Jun 10 13:43:04.599: LISP-0: AF IPv4, Control packet parsing, Map-Register message has trailing data (24).
*Jun 10 13:43:04.599: LISP-0: MS EID IID 0 prefix 192.168.2.0/24 site LISP2, ALT route update/create.
*Jun 10 13:43:04.603: LISP-0: ALTroute IID 0 prefix 192.168.2.0/24 <-> created.
*Jun 10 13:43:04.603: LISP-0: ALTroute IID 0 prefix 192.168.2.0/24 <-> add source MS-EID.
*Jun 10 13:43:04.603: LISP: Executing work item Net_tx:_0_v4_MS_Map-Notify[normal]
*Jun 10 13:43:04.603: LISP-0: Map-Notify to 10.0.0.6, sending with 1 prefix, nonce 0x3261E29E-0xC8EC5DB1.
*Jun 10 13:43:04.603: LISP-0: ALTroute IID 0 prefix 192.168.2.0/24 <MS-EID> RIB route ignore create, no ALT RIB.
Итог, все сайты зарегистрированы на mapserver:
mapserver#sh lisp site
LISP Site Registration Information
Site Name Last Up Who Last Inst EID Prefix
Register Registered ID
LISP1 00:00:06 yes 10.0.0.2 192.168.1.0/24
LISP2 00:00:52 yes 10.0.0.6 192.168.2.0/24
Нy, а теперь самое интересное, настало время проверить работоспособность LISP протокола, для этого пропингуем соответствующий loopback адрес c одного сайта LISP2 до другого , находящийся на LISP1.
LISP2#ping 192.168.1.1 source 192.168.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1 ..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 76/89/112 ms
LISP2#ping 192.168.1.1 source 192.168.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/78/96 ms
Работает!
Потеря первых пакетов связана с lookup запросом между LISP2 сайтом и map server.
В это же время на map-server можно увидеть следующее:
*Jun 10 13:55:01.347: LISP: Processing received Encap-Control message from 10.0.0.6 to 10.0.0.10
*Jun 10 13:55:01.351: LISP: Processing received Map-Request message from 10.0.0.6 to 192.168.1.1
*Jun 10 13:55:01.363: LISP: Received map request for IID 0 192.168.1.1/32, source_eid IID 0 192.168.2.1, ITR-RLOCs: 10.0.0.6, records 1, nonce 0x9B670164-0x2239058F
*Jun 10 13:55:01.367: LISP-0: MS EID IID 0 prefix 192.168.1.0/24 site LISP1, Forwarding map request to ETR RLOC 10.0.0.2.
*Jun 10 13:55:03.419: LISP: Processing received Encap-Control message from 10.0.0.2 to 10.0.0.10
*Jun 10 13:55:03.423: LISP: Processing received Map-Request message from 10.0.0.2 to 192.168.2.1
*Jun 10 13:55:03.435: LISP: Received map request for IID 0 192.168.2.1/32, source_eid IID 0 192.168.1.1, ITR-RLOCs: 10.0.0.2, records 1, nonce 0x730344FA-0x3712E4FA
*Jun 10 13:55:03.439: LISP-0: MS EID IID 0 prefix 192.168.2.0/24 site LISP2, Forwarding map request to ETR RLOC 10.0.0.6.
Здесь показан процесс обработки map-server-ом нашего запроса до EID префикса (Loopback — 192.168.1.1) LISP1 роутера R2 от роутера R4 (LISP2) с внешним адресом RLOC — 10.0.0.6.
Encap-Control message — означает, что сообщение (пакет) инкапсулирован (упакован) LISP протоколом.
Более подробнее о внутренностях работы самого LISP протокола и его структуре, я бы хотел написать в следующих статьях, если конечно же, будет интересно.
А теперь посмотрим, что происходит в этот момент в lisp процессе, а точнее кэшах на обоих роутерах
R2 (LISP1) и R4 (LISP2):
R4#sh ip lisp map-cache
LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries
0.0.0.0/0, uptime: 1d11h, expires: never, via static send map-request
Negative cache entry, action: send-map-request
192.168.1.0/24, uptime: 02:17:52, expires: 21:42:08, via map-reply, complete
Locator Uptime State Pri/Wgt
10.0.0.2 02:17:52 up 100/100
R2#sh ip lisp map-cache
LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries
0.0.0.0/0, uptime: 1d11h, expires: never, via static send map-request
Negative cache entry, action: send-map-request
192.168.2.0/24, uptime: 00:17:52, expires: 23:42:08, via map-reply, complete
Locator Uptime State Pri/Wgt
10.0.0.6 00:17:52 up 100/100
Как видим, каждый из LISP включенных роутеров наполняет свой локальный map-cache c ответами, который он получает от других ETR роутеров.
Надо также отметить, что в таблице маршрутизации нет ничего, что говорило бы нам о подсети 192.168.1.0.
R4 (LISP-2)# sh ip route
Codes: L — local, C — connected, S — static, R — RIP, M — mobile, B — BGP
D — EIGRP, EX — EIGRP external, O — OSPF, IA — OSPF inter area
N1 — OSPF NSSA external type 1, N2 — OSPF NSSA external type 2
E1 — OSPF external type 1, E2 — OSPF external type 2
i — IS-IS, su — IS-IS summary, L1 — IS-IS level-1, L2 — IS-IS level-2
ia — IS-IS inter area, * — candidate default, U — per-user static route
o — ODR, P — periodic downloaded static route, H — NHRP, l — LISP
+ — replicated route, % — next hop override
Gateway of last resort is 10.0.0.5 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.0.0.5
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.4/30 is directly connected, FastEthernet1/0
L 10.0.0.6/32 is directly connected, FastEthernet1/0
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.2.0/24 is directly connected, Loopback0
L 192.168.2.1/32 is directly connected, Loopback0
Но процесс CEF (Сisco Express Forwarding) знает куда отправлять пакеты, и что next-hop-ом является IP адрес удаленного RLOC интерфейса нужного xTR роутера. То есть cef, также выполняет действие по инкапсуляции пакетов, перед тем как отправить их через нужный интерфейс наружу.
LISP2#sh ip cef 192.168.1.0 detail
192.168.1.0/24, epoch 0, flags subtree context, check lisp eligibility, default route SC owned: LISP remote EID — locator status bits 0x00000001
LISP remote EID: 9 packets 774 bytes fwd action encap
LISP source path list nexthop 10.0.0.2 LISP0
2 IPL sources [active source]
Dependent covered prefix type inherit cover 0.0.0.0/0
recursive via 0.0.0.0/0
recursive via 10.0.0.5
attached to FastEthernet1/0
В настройках каждого из роутеров участвующих в нашей схеме, я не случайно поднял процесс ipv6 cef и ipv6 unicast routing, это необходимое условие для работы ipv6 маршрутизации. Давайте в качестве еще одного эксперимента заведем ipv6 адреса под уже созданными loopbacks интерфейсами на R2 и R4 роутерах.
На R2 (LISP1):
interface Loopback0
ip address 192.168.1.1 255.255.255.0
ipv6 address 2002:FD89:C::1/48
На R4 (LISP2):
interface Loopback0
ip address 192.168.2.1 255.255.255.0
ipv6 address 2001:FD85:B::1/48
Теперь настроим последовательно, map-server (R5), и два LISP сайта.
Конфигурация map-server (R5 роутер):
router lisp
site LISP1
description Site LISP1
authentication-key LISP1
eid-prefix 192.168.1.0/24
eid-prefix 2002:FD89:C::/48
exit
!
site LISP2
description LISP2
authentication-key LISP2
eid-prefix 192.168.2.0/24
eid-prefix 2001:FD85:B::/48
exit
!
ipv4 map-server
ipv4 map-resolver
ipv6 map-server
ipv6 map-resolver
ipv6 itr
ipv6 etr
Конфигурация R4 (LISP2 сайт):
router lisp
database-mapping 192.168.2.0/24 10.0.0.6 priority 100 weight 100
database-mapping 2001:FD85:B::/48 10.0.0.6 priority 1 weight 100
ipv4 itr map-resolver 10.0.0.10
ipv4 itr
ipv4 etr map-server 10.0.0.10 key LISP2
ipv4 etr
ipv6 itr map-resolver 10.0.0.10
ipv6 itr
ipv6 etr map-server 10.0.0.10 key LISP2
ipv6 etr
Конфигурация R2 (LISP1 сайт):
router lisp
database-mapping 192.168.1.0/24 10.0.0.2 priority 100 weight 100
database-mapping 2002:FD89:C::/48 10.0.0.2 priority 1 weight 100
ipv4 itr map-resolver 10.0.0.10
ipv4 itr
ipv4 etr map-server 10.0.0.10 key LISP1
ipv4 etr
ipv6 itr map-resolver 10.0.0.10
ipv6 itr
ipv6 etr map-server 10.0.0.10 key LISP1
ipv6 etr
exit
Настало время проверить доступность наших IPv6 адресов , используем для этого команду ping c роутера R2 (LISP1 сайт) до IPv6 адреса на роутере R4 (LISP2 сайт).
R2#ping 2001:FD85:B::1 source 2002:FD89:C::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:FD85:B::1, timeout is 2 seconds:
Packet sent with a source address of 2002:FD89:C::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/92/112 ms
Ура, все работает!
Состояние локального map-cache на R2 (LISP1 сайт) и R4 (LISP2 сайт):
R2#sh ipv6 lisp map-cache
LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries
::/0, uptime: 1d14h, expires: never, via static send map-request
Negative cache entry, action: send-map-request
2001:FD85:B::/48, uptime: 00:04:43, expires: 23:55:16, via map-reply, complete
Locator Uptime State Pri/Wgt
10.0.0.6 00:04:43 up 1/100
R4#sh ipv6 lisp map-cache
LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries
::/0, uptime: 1d14h, expires: never, via static send map-request
Negative cache entry, action: send-map-request
2002:FD89:C::/48, uptime: 00:01:49, expires: 23:58:10, via map-reply, complete
Locator Uptime State Pri/Wgt
10.0.0.2 00:01:49 up 1/100
На R5 роутере (mapserver) видно, что все наши префиксы зарегистрированы:
mapserver#sh lisp site
LISP Site Registration Information
Site Name Last Up Who Last Inst EID Prefix
Register Registered ID
LISP1 00:00:13 yes 10.0.0.2 192.168.1.0/24
00:00:08 yes 10.0.0.2 2002:FD89:C::/48
LISP2 00:00:56 yes 10.0.0.6 192.168.2.0/24
00:00:22 yes 10.0.0.6 2001:FD85:B::/48
Таким образом, используя LISP протокол мы легко соединили два IPv6 (острова) адреса между собою через IPv4 адресное пространство, без специальных туннелей (manual ipv6 tunnels, isatap, automatic 6to4 tunnels и другие).
Метки: lisp
Опубликовано: Маршрутизаторы и коммутаторы
А что будет, если 192.168.2.0/24 переедет в какой-нибудь третий сайт? Как R2 поймет, что нужно очистить кэш и снова запросить Map Resolver?
Приветствую!
Для того, чтобы произошел переезд, а в LISP это называется роумингом EID префикса (vm машины), необходимо, чтобы EID префикс в данном случае 192.168.2.0/24 должен быть описан как dynamic-EID префикс в lisp процессах тех xTR роутеров, где ожидается данный роуминг,кроме того, на соответствующих интерфесах, откуда и куда мы ждем переезд на необходимых интерфейсах должна быть включена соответствующая команда lisp mobility для поддержки
данного роуминга.
То есть мы должны знать заранее куда переезжает данный хост и зарегистрировать данную подсеть на mapserverе.
Надо сказать, что в процессе перезда, а как правило переезжает хост (vm машина), а не вся подсеть, а это префикс хоста /32 , то на map-server нам надо будет явно описать ее как 192.168.2.0/24 и что данная подсеть должна принимать accept-more-specifics.
Если просто убрать данную подсеть с одного LISP сайта, при этом наш другой сайт получит извещение об этом от map-servera о регистрации данного EID префикса и поднять его на другом LISP сайте, то есть
зарегистрировать вновь на mapserver, но уже с другим RLOC адресом, то это сложно назвать роумингом, где виртуальные машинки переезжают с одного сайта на другой и обратно, при этом сохраняя свой EID адрес.
Я постараюсь изобразить переезд машинки и показать это на примере в своей другой статье.
Спасибо за оф интересную статью.
Теперь хоть немного имею представление, которого раньше не было)
Из пожеланий: не мешало бы пару слов написать о том, как осуществляется инкапсуляция, и чем она отличается от GRE например.
Вообще вызвало оч странные ощущения, что в CEF таблице сеть упоминается, а в таблице маршрутизации — нет)
Приветствую!
Спасибо за интерес к данной вводной статье, надо сказать,что в ней я не ставил цель охватить внутреннюю кухню данного протокола, о ней , конечно же , я напишу и, думаю, уже скоро.
Спасибо за стстью!
Пожалуйста, не забывайте тэг MORE для отделения части, которая показывается на главной странице. Сейчас этот тэг добавлен мной.
Заранее спасибо!