cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1595
Views
10
Helpful
11
Replies

DMVPN Hub on Secondary WAN interface

robardill
Level 1
Level 1

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
!



11 Replies 11

Jon Marshall
Hall of Fame
Hall of Fame

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

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:

  • put Di1 into VRF;
  • for DMVPN interface (that is dedicated to the VRF) you need to add command tunnel vrf ...
  • make isakmp aware of VRF.

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.

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

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.

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

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.

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

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.

Mikhail

Thanks for the explanation, that all makes perfect sense now.

Jon

Btw:

  • why do you use mtu equal to 1380 and not 1400 on the Tunnel?
  • why don't you configure bandwidth (could be an issue for EIGRP process);
  • I would add ip tcp adjust-mss 1452 on Di interfaces;
  • on Di interfaces I would use dialer persistent and not dialer group;
  • do you miss inbound ACLs on public (Di) interfaces?

    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

    Getting Started

    Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: