Today I have a site with 2 E-1's.
I am currently running BGP with 2 different neighbors. I am announceming 2 networks out both peers.
I have created a loopback for the tunnel source. I am also receiving default routes from ISP. When trying to bring up DMVPN I have no luck. I am trying to create one tunnel with one of the public IP's I have assigned and being announced.
Please see config attached:
Im a bit confused about something.
This router you're showing us is the VPN hub router, isn't it? This is the router that is the nhs for this DMVPN, correct?
If that's the case, and Im assuming it is, especially since you have configured this Tunnel interface's tunnel destination as "GRE Multipoint," then those nhs statements do not need to be there.
It's the spokes who need to know where the nhs is located, as well as the tunnel interface address-to-public address mapping, so that they can independently establish a session and begin isakmp phase 1 negotiation.
Also, you may want to use the loopback interface as the tunnel source, since it is a public, routable address.
This is a spoke, but in a DMVPN there is no hub and spoke model, you get a fully meshed since you can create a site to site without going through the hub. This is the advantage of DMVPN.
I stated in the first post that I want to use the loopback but cannot for some reason and not sure why. When I use the loopback as the source I stop routing across the VPN.
My concern is the way BGP is set-up. Do I need to have a loopback IP I peer with at the providers side, insert a ebgp multi-hop statement and then configure a loopback IP, assign it to the tunnel source?
Or is there a better way of setting this up given the current configuration?
"..in a DMVPN there is no hub and spoke model,..."
That is incorrect. You have a hub and spoke model. The nhs is the hub and the client is the spoke.
"you get a fully meshed since you can create a site to site without going through the hub"
That is partially correct. Yes, you can create a spoke-to-spoke tunnel with DMVPN, but you STILL initially go through the hub router to get the spoke's nhrp mappings, since the nhs (hub) populates an nhrp database with all the spoke tunnel-to-outside interface mappings. Once you do, then you can create direct tunnels. This is why you dont need all those nhrp mappings you created for each spoke you want to communicate with.
Just think about it, how UNscalable would it be to have to add an nhrp mapping to every tunnel interface on every spoke to allow it to communicate with another spoke!
To enable spoke-to-tpoke functionality, you change the spoke router to include a multicast nhrp mapping under the tunnel interface, and you also change the tunnel destination to "gre multipoint." I see you have done that. In my initial post, I thought the router was a hub because of the "gre multipoint" configuration, not knowing you wanted spoke-to-spoke functionality.
you have set the source interface of the mGRE tunnel to one serial interface.
In this way the IPSec sessions are coming up but you have no redundancy: if that link fails you cannot use the second link for this.
Using a loopback interface as a source is not a viable option (at least I remember I've tried but I wasn't able to achieve the mGRE to work together with the ipsec protection with a loopback source)
So I see two possible options:
a) if the provider is only one ( I see it is telmex) ask them to build a multilink PPP bundle.
In this way the outgoing layer3 interface becomes the interface multilink and both links are used if one fails the other one is enough to make the spoke to talk with central site
b) you build a second DMVPN cloud and one link connects to cloud1 and the second connects to cloud2, you need to use two mGRE tunnels for this on the spoke and of course on the hub routers (unless you terminate cloud2 in a second hub, some care is needed here to have nhrp to work between the two it is called daisy chaining , you need on hub1 to indicate as nhs server hub2)
first option is to be preferred if this is the only spoke to be multihomed.
Second option can be interesting if multiple spokes are or are going to be multihomed (multiple wan links).
Hope to help
I tried the Multilink Bundle but Telmex does not offer it.
We started with one E-1 so the set-up for DMVPN was fine. Then we added another and at the time I did not think about the DMVPN connection and brought both links up together and wanted 2 different peering sessions so I could control the routing by AS prepending and such. Then the DMVPN came into play. I tried to use the loopback and it did not come up. With my lack of knowledge of how DMVPN worked I had to think about how to make it work with what I have. I am afraid I will need to go back to Telmex and ask them to set-up a peer with a loopback and use ebgp multihop, this should work? In theory? See any issues with this?
"Using a loopback interface as a source is not a viable option (at least I remember I've tried but I wasn't able to achieve the mGRE to work together with the ipsec protection with a loopback source)"
I have been using a loopback address as the tunnel source at the DMVPN hub for years.
with this same type of configuration?
I have used it for one ckt but not 2 with this type of BGP set-up?
Please explain how you are using it.
>> I have been using a loopback address as the tunnel source at the DMVPN hub for years
There is some trick here to be used, I suspect a static route to the loopback, isnt it ?
Hope to help
In our head end we have to add a static route back to the public IP, in this case we have a static route of the serial interface. I removed it and added the loopback with no luck
The tunnel source address is the routable address that the spokes and hubs have to know how to reach. So, its a chicken and egg situation in my environment, for example.
We have a hub router that is running DMVPN with mGRE with many spokes. We run BGP between the hub and the spokes. So, the hub is peering with the spoke's Tunnel inetrfaace address and vise versa.
So, of course the routing protocol cannot establish a peer relationship and converge until the tunnel is first brought up. Hence, at each end we have a static route pointing to the peers "tunnel source."
The tunnel is negotiated, BGP peers are brought up and the routes are exchanged.
Can you please educate me on something? Im trying to understand why you're peering with the SP. Im guessing that the set up you have is similar to what I have on my network. You are using DMVPN/mGRE and running BGP for the purpose of having the hub learn spoke local routes and vise versa.
Am I wrong?
I think Im missing something.
The hub will learn of the spoke network via EIGRP. We are running BGP with the ISP for redundancy and traffic shaping.
So really we are dealing with 2 different enviroments, the DMVPN and internet link with ISP.
All routes in the DMVPN are learned via EIGRP. This is the only site with multiple T-1's or in this case E-1's that cannot be multi-linked. So I set up BGP in this manner. I believe to correct all of this would be to set-up bgp with one ip and loopback IP at the providers side and add ebgp multihop to essentially have the same set-up as a MLPPP bundle.
It sounds like you may have something.
I appreciate the info.
Would it be too much if I asked you to attach the configs for the hub and, say, one of the spokes?
thanks for your confirmation.
However, Rick's environment is different: he uses EIGRP as the routing protocol in the DMVPN and BGP provides the external routing.
I have seen this in the messages you have exchanged
check it telmex can give FR multilink FRF.16.1 it would be the same as ppp multilink. (probably you have already asked)
Hope to help