01-22-2014 06:40 AM - edited 03-04-2019 10:08 PM
Our primary link was being saturated and a second ADSL HWIC was installed into the 1841 to host the DMVPN Hub on a dedicated ADSL circuit.
Dialer0 is the default gateway for general internet traffic and the Dialer1 hosts the DMVPN Hub.
The problem I'm trying to solve is how to get the mGRE Tunnel to use Dialer1 without having to install manual routes to the spokes, which some are on dynamic IP's.
I've tried local PBR without any success.
The information is I have read here and other places suggests to use VRF-Lite, but I'm not sure how to adjust the config. I hoping someone might be able to shine some light on how to achive this.
The below config is working, with exception to needing the static routes.
With the static routes removed the spokes still register NHRP, but it's not possible to ping the spoke end of the tunnels, nor does EIGRP propagate routes.
Any help would be gladly appreciated.
! crypto isakmp policy 10 hash md5 authentication pre-share crypto isakmp key xxxxx address 0.0.0.0 0.0.0.0 ! ! crypto ipsec transform-set STRONG esp-3des esp-md5-hmac mode transport ! crypto ipsec profile CISCO set security-association lifetime seconds 120 set transform-set STRONG ! interface Tunnel0 ip address 192.168.100.1 255.255.255.0 no ip redirects ip mtu 1380 no ip next-hop-self eigrp 90 ip nhrp authentication xxxxxx ip nhrp map multicast dynamic ip nhrp network-id 1 ip nhrp holdtime 300 ip tcp adjust-mss 1340 no ip split-horizon eigrp 90 tunnel source Dialer1 tunnel mode gre multipoint tunnel key 0 tunnel route-via Dialer1 mandatory tunnel path-mtu-discovery tunnel protection ipsec profile CISCO ! interface FastEthernet0/0 description LAN ip address 192.168.5.1 255.255.255.0 ip nat inside ! interface Dialer0 description ADSL2+ (a.a.a.a) ip address negotiated ip mtu 1492 ip nat outside ip virtual-reassembly encapsulation ppp dialer pool 1 dialer-group 1 no cdp enable ppp chap hostname xxxxx ppp chap password xxxxx ! interface Dialer1 description ADSL2+ (b.b.b.b) ip address negotiated ip mtu 1492 ip virtual-reassembly encapsulation ppp dialer pool 2 dialer-group 2 no cdp enable ppp chap hostname xxxx ppp chap password xxxxx ! router eigrp 90 redistribute static network 192.168.5.0 network 192.168.100.0 no auto-summary ! ip local policy route-map local ip route 0.0.0.0 0.0.0.0 Dialer0 ! !static routes to spokes ip route c.c.c.c 255.255.255.255 Dialer1 ip route d.d.d.d 255.255.255.255 Dialer1 ip route e.e.e.e 255.255.255.255 Dialer1 ip route f.f.f.f 255.255.255.255 Dialer1 no ip http server no ip http secure-server ! ! ip nat inside source route-map SDM_RMAP_1 interface Dialer0 overload ! access-list 100 remark IPs To NAT access-list 100 permit ip 192.168.5.0 0.0.0.255 any access-list 198 permit ip host b.b.b.b any access-list 199 permit ip host a.a.a.a any no cdp run ! route-map SDM_RMAP_1 permit 1 match ip address 100 match interface Dialer0 ! route-map local permit 10 match ip address 198 set interface Dialer1 route-map local permit 20 match ip address 199 set interface Dialer0 !
01-22-2014 07:16 AM
Rob
I saw the original post you made for this a while back and i didn't respond because i have nothing to test with so i couldn't say for sure what would and wouldn't work and i have no experience with DMVPN.
I stil don't so take this as a general answer rather than me saying it will definitely work.
Basically as i understand it the default route is the problem ie. because it points to the internet you are having to configure static routes to the spokes.
If so placing the dialer1 interface into a VRF would then allow you to have default route in that VRF which would not conflict with the default route in the global routing table.
But that doesn't solve your issue because then your internal networks have no visibility of this VRF. You could leak routes between the VRF and the global routing table but you can't leak the defaultl route obviously. The leaking of the routes can either be done with statics or using MP-BGP (but see note below about MP-BGP and global routing table).
So the issue now becomes addressing ie.
1) the global routing table needs to know about all the remote networks via the DMVPN tunnels so your internal subnets route via dialer1
2) the VRF routing table needs to know about the local site subnets so return traffic from the DMVPN tunnels gets back to your local subnets
if you are using private addressing though you may be able to do this with static routes eg. if all your network used 192.168.x.x addressing you could -
1) in the global routing table simply add a route for 192.168.0.0/16 pointing to the VRF
2) in the VRF you would need specific routes for local subnets pointing back to the global routing table so it depends on how may local subnets there are
MP-BGP uses the RT (Route Target) to import/export routes between VRFs. The main issue here is that the global routing table does not have a route target associated with it. There is a command to allow you to import routes from the global routing table into the VRF ie this would be the local subnets bit but whether it is supported on your device i don't know. And there is still no way that i am aware of to import routes from the VRF into the global routing table without a route target.
Using MP-BGP would complicate it considerably i think and if there are not that many local subnets per site or they could be summarised then statics would make sense.
Two further points -
1) i am assuming that the lack of a default route is the issue
2) i don't know whether your device supports VRF-Lite so all the above may be useless anyway
Jon
01-22-2014 07:48 AM
Hello.
Local PBR does not work for tunnel interfaces, so no use to try.
So, I agree the only way is to use VRF-lite to deal with the issue. At the same time putting Di1 into VRF would not allow you to use it as a backup for Internet access.
Solution:
Sample configuration:
ip vrf WAN2
rd 1:1
crypto keyring DMVPN_KEYS vrf WAN2
description Keys for DMVPN
pre-shared-key address 0.0.0.0 ...
crypto isakmp profile DMVPN
keyring DMVPN_KEYS
self-identity my.wan ! any other
match identity user-fqdn my.wan ! or whatever match you want
keepalive 10 retry 3
crypto ipsec transform-set DMVPN_TRANSFORM ...
mode transport
!
crypto ipsec profile DMVPN_IPSEC_PROFILE
set transform-set DMVPN_TRANSFORM
set isakmp-profile DMVPN
int Di1
ip vrf forwarding WAN2
!re-apply ip address after
int Tu0
tunnel vrf WAN2
tunnel protection ipsec profile DMVPN_IPSEC_PROFILE
ip route vrf WAN2 0.0.0.0 0.0.0.0 Di1
---
PS: please remove local PBR you have configured.
01-22-2014 07:52 AM
Mikhail
For my own clarification do you still need static routes for traffic to and from the VRF or is there something to do with DMPVN that makes this work without the routes ie. the LAN facing interface on the router will not be in the VRF so how does traffic from the local subnets get routed to the VRF for remote networks reachable via the DMVPN tunnel and the return traffic get routed back to the global routing table ?
Jon
01-22-2014 10:09 PM
Hello, Jon.
Traffic from LAN won't flow into WAN VRF.
DMVPN tunnel belongs to the same VRF (that is default global routing table) as LAN, but using WAN VRF as a transport.
To make the tunnel using VRF as a transport we have command "tunnel vrf ...."
So, WAN VRF needs only default gateway toward Internet; it should not know about LAN.
LAN needs route for remote site (Office), it should not know about WAN.
So, putting WAN link into dedicated VRF also helps us to harden our security: LAN can't access WAN and vice versa (as they have no routes).
PS: the only issue in such a design: you won't be able to provide local internet access over NAT, as LAN RIB has no information about Internet.
PS2: if you don't need local NAT (internet access) and put WAN into VRF, then Hub may advertise default gateway only over tunnel[s], that could be an aid for some designs.
01-23-2014 03:42 AM
Hi Mikhail
So the tunnel interface is in the global routing table and it knows about all the LAN subnets so there is no need for the WAN VRF to know about these routes. I now understand that bit. It's the outbound traffic i am not sure about eg.
LAN needs route for remote site (Office), it should not know about WAN.
I can't see that anywhere in the configuration you posted. Would this just be a static route added to the router pointing to the tunnel interface ?
Apologies for all the questions, it's just that i haven't used DMVPN before so i just want to understand exactly how this works in terms of routing to and from the VRF.
Jon
01-23-2014 04:45 AM
Hello, Jon.
I can't see that anywhere in the configuration you posted. Would this just be a static route added to the router pointing to the tunnel interface ?
I assume that you are using dynamic routing protocol over primary and secondary DMVPN clouds.
i just want to understand exactly how this works in terms of routing to and from the VRF.
There is no routing to/from VRF. Routing tables are completely independant. You just use VRF WAN as a transport for your tunnel. Try suggested configuration in GNS.
01-23-2014 09:27 AM
Hi Mikhail
If i had GNS3 i would have tried it ages ago
Hopefully i will get it up and running if/when i get hold of an IOS. I think i just don't understand how routes learnt from remote sites get from the WAN VRF into the global routing table ie. you say the routing tables are completely independant but all the routes learnt from the DMVPN tunnels would be in the VRF not the global routing table.
I guess it my lack of understanding of DMVPN and it's just one of those things that i need to lab up when i can to see exactly how it is working.
Jon
01-24-2014 01:04 AM
Hello, Jon.
but all the routes learnt from the DMVPN tunnels would be in the VRF not the global routing table.
LAN and all the routes learnt from tunnel will be in global RIB.
But Internet routing will be in WAN VRF only.
01-24-2014 02:44 AM
Mikhail
Thanks for the explanation, that all makes perfect sense now.
Jon
01-22-2014 07:57 AM
Btw:
01-24-2014 06:43 PM
Thanks for the solution MikhailovskyVV. It's much appreciated. This question was un answered for some time.
So if I understand your solution correctly, I only need to add Di1 to a VRF and have the tunnel use VRF for the transport.
Di1 Will be dedicated to DMVPN Hub only. No other traffic is needed. Spokes access internet locally, not via the Hub, so I think this solution should suffice.
I'm not sure I fully understand the vrf/isakmp, specifically what is needed at
crypto isakmp profile DMVPN
keyring DMVPN_KEYS
self-identity my.wan ! any other
match identity user-fqdn my.wan ! or whatever match you want
keepalive 10 retry 3
I'll have a read up and if I have questions ( which I will most likely will ;-) ) I'll post back.
Once again, thanks to both of you for the advice and suggestions
Regards
Rob
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide