Собственно ситуация проста и банальна, транзит подключили, маршрутизатор (на схеме - 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 реализации так как вся обработка уходит на процессор.
А полученный результат это скорость между серверами и роутерами, а не "из вне через R2", что не одно и тоже.
Одна полоса используется на два потока, то есть результат будет вдвое ниже. К тому еще необходимо учитывать проценты на оверхед и возможную фрагментацию в туннелях.
обычно берут и вычитают 22-25%
Для RTT можно и echo. Для jitter и потерь надо responder. Для оценки BW надо побольше пакетов.