Как я упомянул в анонсе, один мой коллега упрекнул меня в том, что про сам 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.
Три кубика в центральной части картинки - 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
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
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
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
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
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
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
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".
Смотря на картинку с топологией, наша схема будет работать примерно так.
- R11 отправляет трафик с DLCI 111 в сторону R13.
- FR1 меняет DLCI на транзитный 1001 и отправляет его в сторону FR3.
- FR3 меняет транзитный 1001 на понятный 113.
- Обратный трафик претерпевает зеркальные изменения.
Короче... так работать не будет. Картинка дает в корне неверное представление. На ней мы указываем локальное значение DLCI, которое идентифицирует узел в сети. Значение с которым будут отправлять трафик узлы сети другие.
Правильная последовательность и картина ниже.
- R11 отправляет трафик с DLCI 113 в сторону R13.
- FR1 меняет DLCI на транзитный 1001 и отправляет его в сторону FR3.
- FR3 меняет транзитный 1001 на понятный DLCI 111. Чтобы R13 понял, откуда пришел трафик.
- Обратный трафик претерпевает зеркальные изменения.
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 прописанный на интерфейсе.
В нашем случае,
- На пришедшие LMI сообщения только R13 ответить In-ARP Request'ом. R12 зафиксирует DLCI, но ответ не пошлет.
- In-ARP Request от R13 дойдет до R12. Содержащаяся в нем информация будет проигнорирована, но в ответ пошлется In-ARP Reply. В нем будет содержаться адрес R12.
- In-ARP Reply дойдет до R13 и тот добавит себе запись в таблицу маппингов.
PVC1 <-> PVC2
В общем-то теперь наша сеть с первой картинки работает. У нас есть два PVC через которые ходит трафик. Реализована простейшая hub-n-spoke архитекрута... почти. На самом-то деле R11 сейчас не может обмениваться пакетами с R13. Ок, первое что приходит в голову - прописать маршруты или настроить какой-либо протокол маршрутизации. Однако так не получится. Я размазал одну подсетку на все три роутера. Когда R11, скажем, захочет отправить пакет на R12, он попытается отправить ARP, потому что они с R12 в одном подсети 172.16.0.0/24. Значит связность между нашими споками (spoke) придется организовывать средствами L2.
Посмотрим как это все бегает сейчас.
- Как ни странно, но R12 уже знает как добраться до R11. Любой пакет в подсеть 172.16.0.0/24 будет отправлен им в se0/0 интерфейс с DLCI 113. Например, пинг на 172.16.0.11.
- Такой пакет придет на R13. Тот посмотрит в свою таблицу маппингов и увидит, что к 172.16.0.11 привязан DLCI 111. R13 сформирует новый кадр и отравит данные на R11.
R11 получит кадр и обработает его. Только вот куда отправить ответ он не знает, у него есть только мапинг для 172.16.0.13 в DLCI 113.
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", а значит моя совесть чиста.
Спасибо за интерес.
Комментариев нет:
Отправить комментарий