Tunel GRE + EIGRP

Wiadomość

kurđ · #1

Chyba mam jakiś błąd myślowy lub brak mi informacji.
Mam taki diagram
Obrazek

Postanowiłem skonfigurować routing dynamiczny z EIGRP między R1 i R2
Założyłem że zrobię tunel GRE by R1 i R2 mogły być sąsiadami - ok to się udało (Routerów ISP nie chcę w ten routing mieszać). EIGRP też zadziałał. Ale teraz mam jakiś błąd myślowy. Jeśli link ISP padnie to i EGRP a za tym też trasy do 10.1.0.1 i do 10.2.0.1, więc gdy link znów powstanie to EIGRP nie zadziała bo tunnel interface nie powstanie z powodu braku tras. Default Gateway na obu routerach R1 i R2 pokazuje na inne adresy nie w kierunku ISP.
Kwestia Backup route przez VPN-ASA jest jeszcze do skonfigurowania.
Da się to jakoś ugryźć, czy może najlepszym rozwiązaniem tutaj będzie użycie IP SLA zamiast routingu dynamicznego.

drozdov · #2

Hej

Na routerach R1 i R2 można ustawić routing statyczny do hostów odpowiednio R1 - 10.1.0.1 i R2 - 10.2.0.1 przez ISP. Wtedy jak hosty będą się widzieć to tunel się zestawi - można pokombinować z keepalive jak nie będzie działać. Jeżeli chodzi o konfiguracje zapasowego łącza przez internet - nie piszesz o tym ale pewnie ASY mają zapięty IPSEC VPN - w takim przypadku może pomyśleć o OSPF - na ASA możesz skonfigurować coś takiego jak OSPF over IPSec

http://www.cisco.com/c/en/us/support/do ... -ospf.html

Na wszystkim odpalasz OSPF, zmieniasz koszty tak żeby trasa przez isp była preferowana i powinno być ok

ar3k · #3

IP SLA - bedzie dobrym zastosowaniem tutaj.

Jak napisal kolega powyzej mozesz tez pobawic sie OSPFem

horac · #4

koledzy OSPF w takiej topo to strzelanie z armaty do komara, w dodatku OSPF ma duzo problemow gdzie jesli nie ma odpowiedniej topologii to wiecej szkodzi jak pomaga. EIGRP w tym przypadku jest OK, chociaz statici jeszcze lepsze. Tunele sie skladaja dlatego ze jest to typowy fate sharing, gdzie virtualna topologia w pelni zalezy od tego co sie dzieje w warstwie ponizej (fizycznej).

Jesli masz mozliwosc, zeby endpoint tunelowe widzialy sie przez siec ASA to jak padnie ci polaczenie z R1 do ISP badz z R2 do ISP to mozesz przeroutowac do ASA. Na ASA musisz puscic GRE IP 47. Ustaw trase statyczna na ASA do endpoint tunelu z wiekszym AD zeby wskoczyla w tablice routingu dopiero jak ci padnie polaczenie do ISP

kurđ · #5

No więc z tunelami to chyba musiałbym zrobić tak.
1 Tunel przez ISP.
2 Tunel przez VPN ASA.
Enpointy tuneli statycznie routowane, odpowiednio do ISP i do ASA.
EIGRP przez tunele + odpowiednie metryki by tunel przez ASA miał większy koszt.
Jeśli tunel ISP padnie to automatycznie wskoczy ASA, jeśli wróci to wywali route przez ASA.

Na razie zrobiłem IP SLA, z fajną ciekawostką, może komuś się przyda. ISP jest z jednej strony podłączone redundant (sorry za ten polnglish).

Kod: Zaznacz cały

track 1 ip sla 105 reachability
 delay down 60 up 60
!
track 2 ip sla 106 reachability
 delay down 60 up 60
!
track 105 list boolean or
 object 1
 object 2

Kod: Zaznacz cały

Track 1
  IP SLA 105 reachability
  Reachability is Up
    1 change, last change 2d18h
  Delay up 60 secs, down 60 secs
  Latest operation return code: OK
  Latest RTT (millisecs) 23
  Tracked by:
    EEM 105
Track 2
  IP SLA 106 reachability
  Reachability is Down
    1 change, last change 2d18h
  Delay up 60 secs, down 60 secs
  Latest operation return code: Timeout
  Tracked by:
    EEM 105
Track 105
  List boolean or
  Boolean OR is Up
    2 changes, last change 2d18h
    object 1 Up
    object 2 Down
  Tracked by:
    STATIC-IP-ROUTINGTrack-list 0

drozdov · #6

horac pisze:koledzy OSPF w takiej topo to strzelanie z armaty do komara, w dodatku OSPF ma duzo problemow gdzie jesli nie ma odpowiedniej topologii to wiecej szkodzi jak pomaga.

A możesz rozwinąć tę myśl ? IMHO dynamiczny protokół routingu to najfajniejsze rozwiązanie w tym przypadku. Logicznie dostajesz 4 urządzenia które są połączone w logiczny kwadrat i mają zestawione relację sąsiedztwa. Modyfikujesz koszt na łaczach tak żeby wybrało odpowiednią trasę. Zaproponowałem OSPF bo wiem (na 99% coś takiegoś robiłem) że na ASAch możesz zestawić relację sąsiedztwa OSPF na tunelu IPSec. Możliwe że w EIGRP też tak jest ale jakoś tego nie wynalazłem.

horac · #7

drozdov pisze:
horac pisze:koledzy OSPF w takiej topo to strzelanie z armaty do komara, w dodatku OSPF ma duzo problemow gdzie jesli nie ma odpowiedniej topologii to wiecej szkodzi jak pomaga.
A możesz rozwinąć tę myśl ? IMHO dynamiczny protokół routingu to najfajniejsze rozwiązanie w tym przypadku. Logicznie dostajesz 4 urządzenia które są połączone w logiczny kwadrat i mają zestawione relację sąsiedztwa. Modyfikujesz koszt na łaczach tak żeby wybrało odpowiednią trasę. Zaproponowałem OSPF bo wiem (na 99% coś takiegoś robiłem) że na ASAch możesz zestawić relację sąsiedztwa OSPF na tunelu IPSec. Możliwe że w EIGRP też tak jest ale jakoś tego nie wynalazłem.

Chodzi o to ze z zalozenia dynamiczny routing na FW jest srednim rozwiazaniem, a w dodatku OSPF, gdzie firewall musi oprocz robienia to do czego zostal stworzony to jeszcze martwic sie przeliczeniami topologii OSPF, ageowaniem LSA etc. W dodatku chyba throttling nie jest wspierany na ASA dla OSPFv2 wiec w przypadku flappingu na linkach moze oszalec.

Do tego dochodza kwestie zwiazane z bezpieczenstwem, kazdy FW ktory wymienia dynamicznie trasy jest narazony na route injecting. Kolega chyba tutaj w ogole ma te routery wystawione do internetu, co szczegolnie powoduje ze nalezy zadbac o bezpieczenstwo.

Takze uwazam ze w przypadku 4 pudelek w kwadracie wystarczy routing statyczy z SLA i odpowiednim AD