Cisco OER/PfR

Brzmi to bardzo ciekawie i szczególnie może być przydatne w sytuacjach gdy mamy dwa wyjścia do Internetu i chcemy aby dany ruch biznesowy wybrał to łącze, które oferuje aktualnie najmniejsze opóźnienia do serwerów oraz jitter.

Gdzie stosować?

PfR to stosunkowo nowy „feature”, jednak może być bardzo przydatny w sieciach, gdzie administrator często reagować musi na złą jakość (ruchu głosowego czy biznesowego) oferowaną przez sieć/Internet. Dla ruchu krytycznego pod kątem biznesowym wydaje się wręcz „magiczne” – nie robimy nic a sieć sama się rekonfiguruje i szuka najlepszych ścieżek zanim zadzwonią zdenerwowani użytkownicy. Może być bardzo ciekawym rozwiązaniem dla firm korzystających z wielu tuneli IPSEC przez Internet.

Jak to działa?

Routery cały czas monitorują jakość połączenia – mogą to robić aktywnie generując testowy ruch lub pasywnie, patrząc na przepływ ruchu TCP. Sprawdzane są takie parametry jak throughput, delay, jiitter (a nawet można sprawdzać MOS score dla voice). Według ustawionych wytycznych np. minimalizuj opóźnienie wybierane jest najlepsze łącze. Router wymusza zmianę trasy poprzez automatyczne utworzenie trasy statycznej lub zmianę parametru local-preference dla ścieżki BGP.  Znów powatarzalna jest faza monitorowania i weryfikacji jakości połączeń.

Czy łatwo jest to zaimplementować?

Niestety nie, PfR jest dość skomplikowany i elastyczny, co więcej są sytuacje gdy wymaga odpowiedniej topologii sieci, w której jest uruchomiony. Co więcej jako dość nowy, zdarzaja się problemy „że coś nie działa i nie do końca wiadomo dla czego”. Jednak bardzo polecam to zaawansowanym administratorom, którzy zamiast wykonywać dużo prostych operacji zmian rouingu, wolą się naprawcować z implementacją PfR, aby potem spokojnie odpocząć!