четверг, 6 апреля 2017 г.

Простая лаба по Frame Relay


Как я упомянул в анонсе, один мой коллега упрекнул меня в том, что про сам Frame Relay я написал, а вот про настройку ни слова. Пока появилось время, надо устранить этот недостаток. Как всегда, все оказалось не так уж просто для человека, который не каждый день конфигурирует Frame Relay коммутаторы. Погнали.


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

Я вспомнил примерную топологию из старой книжки по CCNA и наваял что-то похоже на картинку из шапки. Приведу её ещё раз, не в век Dial-Up'a живем.


Три кубика в центральной части картинки - Frame Relay коммутаторы. К ним подключено по одному клиенту, в данном случае это просто роутеры. Клякса в центре символизирует FR облако. Я решил организовать hub-and-spoke топологию настроив два секита - VC1 и VC2. R11 и R12 в такой конфигурации не смогут общаться напрямую. Также я решил размазать одну подсеть 172.16.0.0/24 на все линки через облако. На каждом роутере есть по loopback интерфейсу для тестов. Также у каждого роутера есть по DLCI. Как видно, я выбрал глобальный подход к распределению DLCI. Об этом можно почитать в посте про базовый Frame Relay. Стоит обратить внимание, что на R11 я решил настроить подключение прям на физическом Serial интерфейсе. На R12 это будет уже сабинтерфейс с типом point-to-point. А вот на hub'e это будет сабинтерфейс с типом multipoint.

Всю эту топологию я перенес в старый добрый IOU и начал конфигурировать...


Базовая конфигурация

Здесь я проделал довольно простые манипуляции (не считая указания hostname и прочего такого)

1. Включение FR коммутации на FR1, FR2, FR3

FR1>en
FR1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
FR1(config)#en
FR1(config)#fr
FR1(config)#frame-relay swi
FR1(config)#frame-relay switching
FR1(config)#exit

 2. Настройка инкапсуляции и типа интерфейсов в облаке. С инкапсуляцией в целом все ясно, это "frame-relay". С типом интерфейса чуть сложнее. В сторону клиентов у нас смотрят DCE интерфейсы, в сторону соседних FR коммутаторов - NNI. На FR1 я настроил следующее. FR2 и FR3 имеют похожий конфиг.

interface Serial0/0
 description to R11
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay intf-type dce
!
interface Serial0/1
 description to FR2
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay intf-type nni
!
interface Serial0/2
 description to FR3
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay intf-type nni

3. Настройка портов от клиентов к FR коммутаторам. Всё та же инкапсуляция "frame-relay". Тип порта не трогаем, он по умолчанию выставлен в DTE. Коммутацию FR само собой включать не стоит. Все сводится к настройке нужных интерфейсов и адресов на них. R11 имеет в конфиге следующие строки.

interface Loopback0
 ip address 10.0.0.11 255.255.255.255
!
interface Serial0/0
 description to FR cloud
 ip address 172.16.0.11 255.255.255.0
 encapsulation frame-relay
 serial restart-delay 0

На R12 согласно схеме настроен point-to-point сабинтерфейс. Нужно помнить, в таком случае, не работает механизм Inverse-ARP. Роутер считает, что вся прописанная на интерфейсе подсеть находится за ним.

interface Loopback0
 ip address 10.0.0.12 255.255.255.0
!
interface Serial0/0
 description to FR cloud
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
!
interface Serial0/0.12 point-to-point
 ip address 172.16.0.12 255.255.255.0

На R13 настроен сабинтерфейс с типом multipoint.

interface Loopback0
 ip address 10.0.0.13 255.255.255.255
!
interface Serial0/0
 description to FR cloud
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
!
interface Serial0/0.1 multipoint
 ip address 172.16.0.13 255.255.255.0

Итак, что мы можем посмотреть уже сейчас? Да в целом и ничего. Интерфейсы подняты, lmi посылает какие-то пакетики, в остальном тишина... Заметьте, что тип lmi у Cisco по умолчанию выставлен в 'cisco', что очень типично. В реальной жизни, я бы все-таки поставил 'ietf'.

R11#sh frame-relay lmi

LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO
  Invalid Unnumbered info 0        Invalid Prot Disc 0
  Invalid dummy Call Ref 0        Invalid Msg Type 0
  Invalid Status Message 0        Invalid Lock Shift 0
  Invalid Information ID 0        Invalid Report IE Len 0
  Invalid Report Request 0        Invalid Keep IE Len 0
  Num Status Enq. Sent 691        Num Status msgs Rcvd 691
  Num Update Status Rcvd 0        Num Status Timeouts 0
  Last Full Status Req 00:00:13        Last Full Status Rcvd 00:00:13

R11#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/0                  172.16.0.11     YES manual up                    up
Serial0/1                  unassigned      YES NVRAM  administratively down down
Serial0/2                  unassigned      YES NVRAM  administratively down down
Serial0/3                  unassigned      YES NVRAM  administratively down down
Loopback0                  10.0.0.11       YES NVRAM  up                    up


R11#sh frame-relay map
R11#
R11#show frame-relay traffic
Frame Relay statistics:
    ARP requests sent 0, ARP replies sent 0
    ARP request recvd 0, ARP replies recvd 0

PVC 1...

Далее я решил посмотреть как работает LMI в связке с Inverse-ARP. Для этого я решил настроить коммутаторы в облаке и оставить без изменений конфиг на стороне клиентов. Все должно было заработать "automagically".
 


Смотря на картинку с топологией, наша схема будет работать примерно так.
  1. R11 отправляет трафик с DLCI 111 в сторону R13.
  2. FR1 меняет DLCI на транзитный 1001 и отправляет его в сторону FR3.
  3. FR3 меняет транзитный 1001 на понятный 113.
  4. Обратный трафик претерпевает зеркальные изменения.
Короче... так работать не будет. Картинка дает в корне неверное представление. На ней мы указываем локальное значение DLCI, которое идентифицирует узел в сети. Значение с которым будут отправлять трафик узлы сети другие.

Правильная последовательность и картина ниже.



  1. R11 отправляет трафик с DLCI 113 в сторону R13.
  2. FR1 меняет DLCI на транзитный 1001 и отправляет его в сторону FR3.
  3. FR3 меняет транзитный 1001 на понятный DLCI 111. Чтобы R13 понял, откуда пришел трафик.
  4. Обратный трафик претерпевает зеркальные изменения.
Вообще, строго говоря, настраивая по прошлой картинке с применением LMI и In-ARP, все заработает. Просто маппинг IP-DLCI не будет соответствовать задуманному. Ладно, обратимся к консоли.

1. FR1 нужно проинструктировать, чтобы он отправлял кадры с DLCI 113 пришедшие на Serial0/0 интерфейс в сторону FR3 с транзитным DLCI 1001. Что мы и делаем. Прям на входящем интерфейсе...

FR1(config)#int serial 0/0
FR1(config-if)#frame-relay route 113 interface serial 0/2 1001

2. FR3 должен пришедшие от соседа в интерфейс Serial0/1 кадры с DLCI 1001 отправить в сторону R13 в интерфейс Serial0/0 c DLCI 111.

FR3(config)#int ser0/1
FR3(config-if)#fram route 1001 int ser0/0 111

Видим, что роут есть, но в неактивном статусе. Это потому что нужно прописать и обратный маршрут.

FR3#sh fram route
Input Intf     Input Dlci     Output Intf     Output Dlci     Status
Serial0/1       1001         Serial0/0       111         inactive

3. FR3 будет входящие в интерфейс Serial0/0 кадры с DLCI 111 отправлять FR1 с DLCI 1001.

FR3(config)#int se0/0
FR3(config-if)#fram route 111 int se0/1 1001

4. Завершает цепочку FR1, который кадры c DLCI 1001 из интерфейса Serial0/2 скоммутирует в Serial0/0, но уже с DLCI 113.

FR1(config-if)#int se0/2
FR1(config-if)#frame-relay route 1001 int ser0/0 113

Смотрим, что с нашим созданным PVC

FR1#sh fram pvc | include DLCI
DLCI = 113, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
DLCI = 1001, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0/2

А как там с маршрутами?

FR1#sh frame-relay route
Input Intf     Input Dlci     Output Intf     Output Dlci     Status
Serial0/0       113         Serial0/2       1001         active
Serial0/2       1001         Serial0/0       113         active

В целом, все прекрасно. Итак, кадры будут бегать по следующей цепочке.
R11 -> Serial0/0 (113) -> Serial0/2 (1001) ->  Serial0/1 (1001) -> Serial0/0 (111) - R13
R13 -> Serial0/0 (111) -> Serial0/2 (1001) ->  Serial0/1 (1001) -> Serial0/0 (113) - R11

Самое время посмотреть на клиентов. В теории, после того как PVC поднялось на коммутаторах, в сторону R11 и R13 ушли соответствующие сообщения. R11 должен узнать, что DLCI 113 настроен в его сторону и находится в состоянии Up, R13 должен узнать тоже самое про DLCI 111.

Посмотрим, что там на железе.

R11#sh fram pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       0            0            0            0
  Unused         1            0            0            0

DLCI = 113, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

R13#sh fram pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       0            0            0            0
  Unused         1            0            0            0

DLCI = 111, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

Таак... про DLCI наши клиенты узнали от FR коммутаторов через LMI. Но вот DLCI в состоянии UNUSED. Почему? Потому что нет IP-DLCI маппингов. Что-то не так с Inverse-ARP, потому что в ручную мы ничего не настраивали. show frame-relay map пустой на обоих роутерах.

Дело в том, что с Inverse-ARP все не так-то просто... Его поведение зависит от типа интерфейса:
  • Physical. Тут-то как раз все просто. Для каждого пришедшего DLCI будет отправлен In-ARP. Наш R11 отправит сообщение с DLCI 113 вида "Я 172.16.0.11".
  • Point-to-point. In-ARP не отправляется вообще. С этим столкнемся, когда будем настраивать второй секит. Есть там небольшая тонкость...
  • Multipoint. In-ARP включен, но как бы не совсем. In-ARP будет отправлен только, если на интерфейсе будет прописан DLCI. И отправлен будет только в этот DLCI (или в эти, если их много). 
По началу случай с Multipoint казался мне странным. Погодите, думал я, вот хочется мне полностью автоматической настройки на клиентах, чтобы и DLCI на клиенте появился и мапинги IP - DLCI сами натроились. А тут придется настраивать DLCI, для того чтобы все заработало. Это неверный подход к вопросу. LMI сделал свою работу - рассказал клиенту какие DLCI настроены и в каком состоянии. И In-ARP свою работу сделает, замапит IP на соответствующий DLCI. Ни тот ни тот протокол не придуманы для того, что бы автоматически настроить клиентов.

Так почему же In-ARP не отправляется? А что если кофигурация будет такой?

interface Serial0/0.1 multipoint
 ip address 172.16.0.13 255.255.255.0
!
interface Serial0/0.2 multipoint
 ip address 172.32.0.13 255.255.255.0

Пришло сообщение LMI о том, что DLCI 111 поднято. Какой адрес отправить в него? 172.16.0.13 или 172.32.0.13? Воооот.

Исправим ситуацию на R13

R13(config)#interface Serial0/0.1
R13(config-subif)#frame-relay interface-dlci 111

И, после некоторого ожидания, вуаля!

R13#sh fram pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 111, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

R13#sh fram map
Serial0/0.1 (up): ip 172.16.0.11 dlci 111(0x6F,0x18F0), dynamic,
              broadcast,, status defined, active

R11#ping 172.16.0.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 25/25/26 ms

R13 увидел In-ARP от R11, R11 - от R13. Все счастливы, пинги пошли, PVC поднялся.

PVC 2

Пришло время быстренько сделать второй PVC между R13 и R12. Напомню, на R12 у нас ptp интерфейс, который In-ARPы сознательно игнорирует.


Для начала надо настроить PVC на коммутаторах по уже известной схеме.

FR2(config)#interface Serial0/0
FR2(config-if)# encapsulation frame-relay
FR2(config-if)# frame-relay intf-type dce
FR2(config-if)# frame-relay route 113 interface Serial0/1 1002

FR3(config)#interface Serial0/2
FR3(config-if)#encapsulation frame-relay
FR3(config-if)#frame-relay intf-type nni
FR3(config-if)#frame-relay route 1002 interface Serial0/0 112

FR3(config-if)#interface Serial0/0
FR3(config-if)#frame-relay route 112 interface Serial0/2 1002

FR2(config-if)#interface Serial0/1
FR2(config-if)#encapsulation frame-relay
FR2(config-if)#frame-relay intf-type nni
FR2(config-if)#frame-relay route 1002 interface Serial0/0 113

После чего, PVC в FR облаке должен поднятся. И это так.

FR2#sh fram route
Input Intf     Input Dlci     Output Intf     Output Dlci     Status
Serial0/0       113         Serial0/1       1002         active
Serial0/1       1002         Serial0/0       113         active

Далее нужно настроить DLCI на нашем Multipoint интерфейсе

R13(config)#int se0/0.1
R13(config-subif)#frame-relay interface-dlci 112

На R12 настроен ptp интерфейс, а значит его никак не заставить отправить In-ARP. Значит придется сделать маппинг вручную.

R12(config)#interface Serial0/0.12 point-to-point
R12(config-subif)#frame-relay interface-dlci 113

После чего, можно будет увидеть мапинг типа "Все отправляем в DLCI 113"

R12#sh fram map
Serial0/0.12 (up): point-to-point dlci, dlci 113(0x71,0x1C10), broadcast
          status defined, active

Проверяем пингом

R12#ping 172.16.0.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.13, timeout is 2 seconds:
!!!!!

Что произошло в этом случае? С двух сторон прописаны соответсвующие DLCI. R13 сразу же отправит In-ARP в DLCI 112 и расскажет про свой адрес 172.16.0.13. Но R12 его проигнорирует, потому что на ptp интерфейсе он создаст мапинг на всю подсеть. А вот как R13 узнает про то, что за DCLI 112 сидит 172.16.0.12? А он узнает.

R13#sh fram map 112
Serial0/0.1 (up): ip 172.16.0.12 dlci 112(0x70,0x1C00), dynamic,
              broadcast,
              CISCO, status defined, active

Тут скрывается ещё одна тонкость. В In-ARP есть два типа сообщений.
  • Inverse-ARP Request, который не отправляется с ptp интерфейса в ответ на LMI. Информация из пришедшего от кого-либо Inverse ARP Request просто игнорируется. 
  • Inverse-ARP Reply - это ответ на пришедший Request. Этот Reply содержит IP и отправляется он в DLCI прописанный на интерфейсе.  
В нашем случае,
    1. На пришедшие LMI сообщения только R13 ответить In-ARP Request'ом. R12 зафиксирует DLCI, но ответ не пошлет.
    2. In-ARP Request от R13 дойдет до R12. Содержащаяся в нем информация будет проигнорирована, но в ответ пошлется In-ARP Reply. В нем будет содержаться адрес R12.
    3. In-ARP Reply дойдет до R13 и тот добавит себе запись в таблицу маппингов.


PVC1 <-> PVC2

В общем-то теперь наша сеть с первой картинки работает. У нас есть два PVC через которые ходит трафик. Реализована простейшая hub-n-spoke архитекрута... почти. На самом-то деле R11 сейчас не может обмениваться пакетами с R13. Ок, первое что приходит в голову - прописать маршруты или настроить какой-либо протокол маршрутизации.  Однако так не получится. Я размазал одну подсетку на все три роутера. Когда R11, скажем, захочет отправить пакет на R12, он попытается отправить ARP, потому что они с R12  в одном подсети 172.16.0.0/24. Значит связность между нашими споками (spoke) придется организовывать средствами L2.

Посмотрим как это все бегает сейчас.
  1. Как ни странно, но R12 уже знает как добраться до R11. Любой пакет в подсеть 172.16.0.0/24 будет отправлен им в se0/0 интерфейс с DLCI 113. Например, пинг на 172.16.0.11. 
  2. Такой пакет придет на R13. Тот посмотрит в свою таблицу маппингов и увидит, что к 172.16.0.11 привязан DLCI 111. R13 сформирует новый кадр и отравит данные на R11.
  3. R11 получит кадр и обработает его. Только вот куда отправить ответ он не знает, у него есть только мапинг для 172.16.0.13 в DLCI 113.
В нашем случае нужно просто прописать статический мапинг на R11 вида

R11(config)#int se0/0
R11(config-if)#frame-relay map ip 172.16.0.12 113 broadcast

После чего, R11 отправит ответ в сторону R13. Тот снова заглянет в таблицу маппингов, найдет там запись для 172.16.0.12 и отправит данные до R12. А в консоли мы получим заветные палочки с точками

R11(config-if)#do ping 172.16.0.12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds:
!!!!!


Я обозначил основные шаги на картинке ниже.


Пора подводить итоги. Frame Relay не самая простая технология. За внешней простотой скрывается много мест, где можно допустить ошибку или просто запутаться. Я за время написания поста сделал таких ошибок не мало. За пределами осталось много тем, таких как: SVC, протоколы маршрутизации поверх FR, FECN/BECN и т.д. Но в заголовке написано "Простая лаба по Frame Relay", а значит моя совесть чиста.

Спасибо за интерес.


Комментариев нет:

Отправить комментарий