VRF Lite – VRF без MPLS

MPLS VRF-ите са едно колкото популярно, толкова и рекламирано решение за provider vpn-и и сегрегация на трафик в трета мрежа, което предлага и разчита на няколко неща, за да се продава 😉 :

  • Сегментиране на трафик между устройства на различни клиенти през трета мрежа, обикновено доставчик на услуга;
  • Възможност за запазване на маршрутната информация на клиента, чрез прозрачно пренасяне на маршрутната информация между неговите устройства от различните страни на мрежата на доставчика;
  • Възможност за доставчика да носи няколко маршрутни таблици, сегментирани една от друга, и евентуално включващи припокриващи се адресни пространства, вkл. RFC1918 адреси;

Решението за такава ситуация, базирано на MPLS VPN-и с различни VRF-и (Virtual Routing and Forwarding) разрешава всички от гореизброените проблеми на базата на няколко неща:

  • Настройка на маршрутно отношение между клиентският (Customer Edge – CE) рутер, и граничен рутер на доставчика (Provider Edge – PE), използвайки рутинг протокола на клиента;
  • Анонсиране от клиента на всички вътрешни мрежи по това рутинг отношение, както към вътрешен рутинг съсед в клиентската мрежа;
  • Наличие на поне една VRF инстанция за всеки клиент;
  • Маркиране от страна на PE устройството на клиентските маршрути със специфичен Route Distinguisher (RD) етикет, по този начин формирайки т.нар. VPNv4 адрес;
  • Редистрибуция от PE устройтвото на клиентските маршрути от клиентският рутинг протокол към MP-iBGP протокол, вървящ между PE устройствата в различните краища на мрежата на доставчика;
  • Наличие на стабилен вътрешен IGP рутинг протокол, осигуряващ свързаност на MPLS мрежата и косвено на MP-BGP;
  • Наличие на стабилна и мащабируема MPLS конфигурация в опорната мрежа на доставчика;

Всичко това е чудесно, ако сте доставчик, имащ готов MPLS Core. Ако обаче се опитвате да разработите специфично решение за собствени нужди, решение базирано на MPLS VPN ви изправя пред няколко предизвикателства, повечето от които са свързани с осигуряване на скъпи ресурси:

  • Настройка на 3 рутинг протокола на всяко PE-устройство (протокол на клиента, MP-BGP, и отделен вътрешен рутинг протокол);
  • Осигуряване  на достатъчно мощни и надеждни PE-рутери, способни да поддържат надеждно и мащабируемо 3те рутинг протокола, както и определен брой VRF-и;
  • Осигуряване на достатъчно мощни и надеждни core рутери, поддържащи MPLS Core на мрежата;

VRF Lite представлява VRF без изискване за опорна MPLS свързаност, и без необходимост от 3 рутинг протокола на PE устройствата. По този начин можем да постигнем пренос на няколко паралалелни рутинг таблици през опорна мрежа, без да имаме MPLS.

При използването на VRF с MPLS разделеността на комуникацията между рутинг таблиците се постига чрез използването на отделен рутинг протокол между PE устройствата, който носи различните маршрутни таблици, тагнати със съответният етикет. За да има разделяне на комуникацията и сегрегация на отделните рутинг таблици при използването на VRF Lite, т.е. без MPLS, трябва да има разделена комуникация между рутинг отношенията, носещи различните маршрутни таблици.

За илюстрация на двата варианта VRF, можем да използваме две топологии на тестови мрежи.

(more…)

OSPF Adjacency building. ExStart. Exchange.

Малък пример за OSPF adjacency building и по-специално за Database Description процеса.

Имаме серийна PPP връзка м/у два рутера – R5 и R1. Току-що сме задали hello интервал на PPP интерфейс(serial 0/1) м/у R1(Router ID: 1.1.1.254) и R5(Router ID: 1.1.1.5) на 5 секунди, което е различно от стойността по подразбиране от 10 секунди, която е настроена на R5. След изтичането на dead-интервала (4х hello, автоматично изчислен) на R1, за което време той не е получил съответстващ hello пакет от R5, R1 дропва neighbor-отношението. Използваната команда за показване на тези отношения е:

R1#debug ip ospf adj

Ето и дропването на neighbora, с log съобщение за dead timer expired на R1:

R1#
1d16h: OSPF: 1.1.1.5 address 192.168.15.2 on Serial0/1 is dead
1d16h: OSPF: 1.1.1.5 address 192.168.15.2 on Serial0/1 is dead, state DOWN
1d16h: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.5 on Serial0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#

Преглед на съседите за ospf process id 1:

R1#sh ip ospf neighb

Neighbor ID Pri State Dead Time Address Interface
1.1.1.3 1 FULL/BDR
00:00:31 192.168.101.254 FastEthernet0/0.101
1.1.1.3 1 FULL/BDR
00:00:31 192.168.102.254 FastEthernet0/0.102
1.1.1.3 1 FULL/ –
00:01:50 192.168.123.3 Serial0/0
1.1.1.5 1 FULL/ –
00:01:55 192.168.123.5 Serial0/0
1.1.1.4 1 FULL/ –
00:01:49 192.168.123.4 Serial0/0
R1#

Което потвърждава, че 1.1.1.5 е flush-нат от neighbor-таблицата, за интерфейс Serial0/1 и вече не се разпознава като ospf neighbor за този интерфейс.. (Заб: в използваната топология, имаме още един директен L3 линк към 1.1.1.5 през S0/0, който е свързан през Frame Relay облак към 1.1.1.5 с ip address 192.168.123.5) В такава ситуация, автомата на съседските отношения не може да премине в състояние Two-Way, единственото което се случва с него са преходи от Down->Init при всеки получен hello пакет от 1.1.1.5 през интерфейс S0/1.

След като сме установили пропадането на neighbor отношението, можем да вдигнем отново hello-интервала на стойността по подразбиране, за да оставим neighbor-отношението да се формира отново. (more…)