Yes, it is possible to use a static default route on the spokes and use a routing protocol on the hub. You still have to configure the routing protocol on the spokes as well, however.
The advantage of using the summary route is that all routing is dynamic and nothing has to be configured statically. This means that if you change your IP addressing of the hub or if you add new spokes, you don’t need to modify or configure anything beyond a simple routing protocol adjacency, and all the appropriate information is exchanged.
Using a default summary address on the Hub does not eliminate the need for a routing protocol. The Hub still needs to learn all of the networks connected to all of the spokes in order for the network to work correctly, and this is achieved using the routing protocol.
Imagine you have a network with 50 spokes. If no summary default route is used, each spoke will have in its routing table all of the networks behind all other spokes. And the next-hop IP address for all of those (potentially hundreds) of routes is the hub. This is a waste of memory, and a waste of CPU processing power since every packet sent by the router must be compared to the entries in the routing table before being sent out.
So by creating the summary default route, you eliminate all of those entries and replace them with a single entry. However, the hub itself must learn of those hundreds of networks of all the spokes, and this is done via the routing protocol used.
My question was that can we only use default route on all Hub and spokes instead of configuring routing protocol and default summary, forget about memory usage, cpu utilization.
If you wanted to yes you could eliminate the use of any routing protocol and simply put in static routes to every network. But that defeats the purpose of a dynamically configured DMVPN system. I only mention memory and CPU utilization because that is still part of network design and should always be considered.
Yes, the split-horizon configuration takes place under the address family interface configuration mode. Take a look at the following context sensitive help:
R1(config-router-af)#af-interface g0/0
R1(config-router-af-interface)#?
Address Family Interfaces configuration commands:
authentication authentication subcommands
bandwidth-percent Set percentage of bandwidth percentage limit
bfd Enable Bidirectional Forwarding Detection
dampening-change Percent interface metric must change to cause update
dampening-interval Time in seconds to check interface metrics
default Set a command to its defaults
exit-af-interface Exit from Address Family Interface configuration
hello-interval Configures hello interval
hold-time Configures hold time
next-hop-self Configures EIGRP next-hop-self
no Negate a command or set its defaults
passive-interface Suppress address updates on an interface
shutdown Disable Address-Family on interface
split-horizon Perform split horizon
summary-address Perform address summarization
As you can see, the command for split-horizon is found in this mode.
It is not immediately perceivable why we need to employ a routing protocol in a DMVPN environment. DMVPN has its own mechanisms (NHRP etc) to enable communication between the hub and spoke routers.
The primary reason for using routing protocols in such an environment is to enable communication between the networks behind the spoke routers. Remember that each spoke router is a branch or remote office of an organization that has its own internal network with various internal subnets and network services.
The routing protocols employed in a DMVPN environment will advertise those networks behind the spoke routers, enabling devices at each spoke location to communicate with devices at other spoke locations.
In the lessons, we use loopbacks to represent the remote location networks, and the routing protocols are used to advertise the loopback addresses. In your mind’s eye, imagine that those loopbacks are actually LANs of hosts.
In the real world, we would most likely have a default route pointing towards the ISP/The Internet instead. So in such a situation, we couldn’t really configure a default route 0.0.0.0/0 using an IGP for the DMVPN cloud as well like Rene showed in this lesson, right?
So in such a scenario, we would typically just use a summary route for the prefixes in the DMVPN cloud but not a default route, correct?
If hosts behind one of your spokes and hub need to reach both the internet as well as the rest of the DMVPN topology, then yes, you wouldn’t use a default route to send everything to the hub. One solution is to have the hub send the summary route of only the prefixes in the DMVPN cloud as you suggest. However, if your topology changes or if you add or remove subnets, you will have to change that summary command, so it’s not that scalable.
If you need to be able to reach both the internet and the remote devices on the DMPVN network, your best bet is to simply allow EIGRP to share all the routes, without doing summarization. This will make the routing tables somewhat larger, but will make routing more efficient. If your topology gets too big, you can always use EIGRP auto-summary as well.