DMVPN Zonder full mesh?

[Yariva]

Ik zit lekker te sleutelen aan DMVPN, maar ik vroeg mij wat af. Ik heb een klein lab gemaakt in GNS3.



R1 dient als hub in dit verhaal, alles zit (werkend) in elkaar geknoopt met GRE, NHRP, IPSEC en EIGRP. Kortom, R2 heeft het interne netwerk van R3 in zijn routing tabel staan. Om naar deze next hop te komen stuurt R2 een verzoek naar de NHS (R1) om het externe, dynamische adres van R3 te krijgen. Helemaal mooi.

Maar wat nou als ik niet wil dat eindlocaties (R2 en R3) met elkaar gaan praten, zij moeten enkel bij een of andere server op R1 komen, en tussenliggende communicatie wil ik helemaal niet. Dit lijkt mij lastig te controleren, gezien er geen firewall zit tussen R2 en R3.

Het enige wat ik mij kan bedenken is of de routes niet adverteren richting neighbors (enkel een default route injecteren richting R2 en R3 naar R1) of de next-hop instellen voor alle eindlocaties (R2 en R3) naar het DMVPN adres van R1 zodat je hier policy's / ACL's kan instellen.

Mocht het niet helemaal duidelijk zijn excuses, ik lever graag wat meer info.

[plizz]

Misschien is VRF een oplossing. Je houdt twee route tabellen op R1. Zodat R2 en R3 kennis maakt van elkaars netwerk. Of je kunt routes adverteren icm route-maps. Dan filter je die netwerk van R2 en R3.

[ Voor 26% gewijzigd door plizz op 05-11-2016 22:52 . Reden: Toevoeging route-maps ]

[Yariva]

Dat is inderdaad een oplossing, echter had ik nu "enkel" 2 routers gebruikt. Ga ik 12 locaties uitrollen moet ik 12 VRF's aanmaken, daar ging het gemak van DMVPN

overigens heb ik verder lopen kijken, volgens mij kan je gebruik maken van "normale" GRE interfaces op de spokes en een mGRE interface op de hub's. Ik ga morgen wel kijken hoe / of dat werkt.

Thanks voor je advies though

[Bl@ckbird]

Het idee achter DMVPN is juist dat er VPN tunnels lopen tussen twee bijlocaties. Dit is vooral bij voice verkeer het geval. Als je tussen twee bijlocaties belt, hoeft dit voice verkeer niet via een hoofdlocatie te lopen en dat scheelt latency. Kijk ook even in de CVD voor DMVPN:
http://www.cisco.com/c/da...NWANDesignGuide-AUG14.pdf

http://www.cisco.com/c/en...h-wan/index.html#~designs

iWAN is een extensie op DMVPN waarmee je ook intelligent verkeer kan sturen op basis van latency, jitter en packet loss:
http://www.cisco.com/c/da...WANDeployment-2016OCT.pdf

[RedShift]

Met prefix lists kan je instellen op de EIGRP routing instance op de spokes dat enkel de subnetten van de hub in de routing tabel geïnstalleerd worden.

[Yariva]

RedShift schreef op zondag 06 november 2016 @ 18:36:
Met prefix lists kan je instellen op de EIGRP routing instance op de spokes dat enkel de subnetten van de hub in de routing tabel geïnstalleerd worden.

Dit zou inderdaad de beste oplossing zijn. Dit is ook te definiëren in een template voor meerdere locaties voordat routers de deur uit gaan. Thanks!

[PerfectPC]

Waarom nhrp comfigureren? Als je dit niet doet komt spoke-to-spoke niet up en heb je enkel hub-to-spoke routing.