Собственно ситуация проста и банальна, транзит подключили, маршрутизатор (на
схеме - R2) на удаленном узле поставили, ping побежал... И тут вполне резонный
вопрос - соответствует ли канал заявленным характеристикам?

Если бы за R2 стоял какой-то сервер, где можно было iperf запустить - проблема
решилась бы быстро, но там на данный момент ничего кроме собственно самого R2
нет, ехать почти 200 км тоже не очень хочется, а примерное представление о
качестве сервиса получить надо.



Возникла одна простая идея - между R1 и R2 поднять 2 туннеля, на R1 поместить
их в разные VRF и в VRF 1 добавить интерфейс с Server 1, а в VRF 2
соответственно интерфейс с Server 2, слегка поднастроить маршрутизацию и по
получившейся петле прогнать трафик с сервера 1 на сервер 2.

ВАЖНО! ТРАНЗИТНЫЙ КАНАЛ ДОЛЖЕН БЫТЬ СИММЕТРИЧНЫМ, т.е. с одинаковой скоростью в обоих направлениях

Реализация 

Выбираем номера VLAN-ов и IP-ы для линков:
Т.к. подсеть 172.19.0.0/16 у меня нигде не используется, ее и выберем для тестов

   S1 -- R1 vlan 101 172.19.1.0/30
   S2 -- R1 Vlan 102 172.19.4.0/30

   R1 -- R2 Tun1 172.19.2.0/30
   R1 -- R2 Tun2 172.19.3.0/30


Конфигурация серверов (OS CentOS)

Настроим сервера

Server 1:

   vconfig add eth0 101
   ifconfig eth0.101 172.19.1.1/30
   route add -net 172.19.0.0/16 gw 172.19.1.2

Server 2:

   vconfig add eth0 102
   ifconfig eth0.101 172.19.4.1/30
   route add -net 172.19.0.0/16 gw 172.19.4.2

Конфигурация маршрутизаторов

R1

   !
   ip vrf serv_1 
    rd 111:111
   !
   ip vrf serv_2 
    rd 111:222
   !
   interface Loopback1
    description For_Tun1
    ip address 172.19.101.1 255.255.255.255
   !
   interface Loopback1
    description For_Tun2
    ip address 172.19.102.1 255.255.255.255
   !
   interface Tunnel1
    ip vrf forwarding serv_1
    ip address 172.19.2.1 255.255.255.252
    keepalive 10 3
    tunnel source 172.19.101.1
    tunnel destination 172.19.101.2
   !
   interface Tunnel2
    ip vrf forwarding serv_2
    ip address 172.19.3.1 255.255.255.252
    keepalive 10 3
    tunnel source 172.19.102.1
    tunnel destination 172.19.102.2
   !
   interface FastEthernet0/0.101
    description Server_1
    encapsulation dot1Q 101
    ip vrf forwarding serv_1
    ip address 172.19.1.2 255.255.255.252
   !
   interface FastEthernet0/0.102
    description Server_2
    encapsulation dot1Q 102
    ip vrf forwarding serv_2
    ip address 172.19.4.2 255.255.255.252
   !
   ip route vrf serv_2 172.19.1.0 255.255.255.0 172.19.2.2 
   ip route vrf serv_2 172.19.2.0 255.255.255.0 172.19.2.2
   ip route vrf serv_1 172.19.3.0 255.255.255.0 172.19.1.2 
   ip route vrf serv_1 172.19.4.0 255.255.255.0 172.19.1.2

R2

   ip vrf tranzit 
    rd 111:333
   !
   interface Loopback1
    description For_Tun1
    ip address 172.19.101.2 255.255.255.255
   !
   interface Loopback1
    description For_Tun2
    ip address 172.19.102.2 255.255.255.255
   !
   interface Tunnel1
    ip vrf forwarding tranzit
    ip address 172.19.2.2 255.255.255.252
    keepalive 10 3
    tunnel source 172.19.101.2
    tunnel destination 172.19.101.1
   !
   interface Tunnel2
    ip vrf forwarding tranzit
    ip address 172.19.3.2 255.255.255.252
    keepalive 10 3
    tunnel source 172.19.102.2
    tunnel destination 172.19.102.1
   !
   ip route vrf tranzit 172.19.1.0 255.255.255.0 172.19.2.1 
   ip route vrf tranzit 172.19.4.0 255.255.255.0 172.19.3.1

Настройки интерфейсов для транзита и маршрутизации глобальной не показаны

Все, теперь трафик c Server 1 на Server 2 и обратно (точнее трафик с IP
172.19.1.1 на 172.19.4.1) будет проходить по маршруту:

   Server 1 <-VLAN_101-> R1(vrf serv_1) <-Tun1-> R2(vrf tranzit) <-Tun2-> R1(vrf serv_2) <-VLAN_102-> Server 2

Можно запускать iperf, или гонять любой иной трафик, строить графики загрузки и делать выводы :) 


PS. Возникла еще одна необходимость подобной проверки R2 - cisco 2811; транзитный канал 35Мбит.

1. ttcp - cisco 2811 при 5Мбит уходит в 100% CPU.
2. Через 2 тунеля с VRF-ом - все 35М были успешно "переварены" с CPU в районе
50-90% (сильно разнился PPS т.к. канал забивали то большими то мелкими пакетами).

Вывод - ttcp ограничено применим в cisco реализации так как вся обработка уходит на процессор.